MagLev - pierwsza wersja publiczna

Opublikowane przez Jarosław Zabiełło Sat, 21 Nov 2009 03:43:00 GMT

Gdy ok 1.5 roku pisałem o szumie i nadziejach związanych z MagLev’em, trudno było przewidzieć ile czasu zajmie dostosowanie wirtualnej maszyny Smalltalka do pracy z kodem bajtowym Ruby’ego. Dziś (właściwie to jakieś 2 godziny temu) oficjalnie ogłoszono że jest dostępna publicznie pierwsza wersja alpha. Z tego, co podaje dokumentacja, to Maglev jeszcze nie działa tam gdzie są wymagane rozszerzenia w C, ale w przykładach widać, że działa Sinatra, Rack, RubyGems czy interaktywna konsola. Najciekawsza jest transakcyjna, przezroczysta pamięć stała MagLev’a, bo to zupełnie zmienia styl myślenia i pracy z danymi. Może będzie można w końcu zapomnieć o przestarzałych ORM’ach i RDBMS? (technologia baz relacyjnych pochodzi z lat 70-tych, jest wolna i przestarzała).

Ruby everywhere – czyli najważniejsze implementacje Ruby’ego:

  • Ruby 1.8 MRI – implementacja w języku C (najstarsza)
  • Ruby Enterprise Edition – implementacja w C, mniejsze zużycie pamięci, używana głównie z Passengerem
  • Ruby 1.9 – implementacja w języku C, używa wirtualnej maszyny YARV
  • JRuby – implementacja w języku Java, wirtualna maszyna Javy (JVM)
  • IronRuby – implementacja w języku C# (środowisko .NET)
  • Maglev – implementacja w języku Smalltalk, wirtualna maszyna Smalltalka (Gemstone)
  • MacRuby – implementacja w języku Objective-C dla systemu Mac OS-X
  • Rubinius – implementacja Ruby w… Ruby (z loaderem w C++)
  • BlueRuby – Ruby działający w SAP Web Application Server (ABAP Virtual Machine)

Zobacz też State of Ruby VMs: Ruby Renaissance

Tagi , , , ,  | 9 comments

Comments

  1. Avatar sprae powiedział about 13 hours later:

    A jak to wypada w porównaniu z tym? http://macournoyer.wordpress.com/2008/09/02/ruby-on-v8/

  2. Avatar Mekk powiedział about 18 hours later:

    Hmm, ale co Twoim zdaniem ma transakcyjna pamięć do ORMów? Przecież ta transakcyjność dotyczy grupowania zmian w pamięci a nie ich trwałości…. (nie znam maglev-a, reaguję na słowa kluczowe ;-))

    A niezależnie od pytania – możesz podrzucić jakieś ciekawe linki dotyczące praktycznych idiomów programowania z tego typu zabawkami?

  3. Avatar Jiima powiedział 2 days later:

    @JZ Nie żegnałbym się tak szybko z ORM’ami, wiele systemów ma “trwałą pamięć”, na rynku są też bazy obiektowe itp. Jednak przyzwyczajeń łatwo nie zmienisz. Pomijam marketing Oracle / IBM/ Microsoft, którzy przekonają każdego managera większego projektu, że spotkają ich plagi egipskie jeśli w systemie nie będzie bazy danych. A małe systemiki? Kogo one obchodzą? Nawet nie wiadomo jaki los spotka MySQL…

    A co do Mag’a jestem conajmniej sceptyczny. Implementacja wymaga użycia VM której licencje są dość drogie, a Gemstone nie wypowiedziało się jeszcze co do licencjonowania dla Ruby. Sam kod jest na GitHub, więc jest szansa że jakieś świry przepiszą go na Pharo lub GNU Smalltalk, choć nie wiem czy wtedy będzie aż taki wydajny…

    Mnie bardziej interesuje obecnie MacRuby.

  4. Avatar Jarosław Zabiełło powiedział 3 days later:

    @Jiima: nie mówię, że ORM’y upadną. Cobol do dziś jeszcze jest używany. Chodzi o to, że praca z ORM’ami, mimo że trochę wygodniejsza niż z SQL, to nadal jest to tylko obiektowa atrapa. Bazy obiektowe są już dużo ciekawsze i szybsze.

    Jeśli chodzi o MagLev’a to użyty tam GemStone jest bardzo dojrzały i szybki. Z tą ceną bym się nie martwił. Przecież GemStone jest też oferowany nawet za darmo (np. w opcji dla frameworka Seaside i do 4GB).

    MagLev zawiera też wsparcie dla bazy relacyjnej. Może być użyty jako obiektowa baza danych dla dowolnego kodu Ruby’ego (obok ORM’a, czy czegokolwiek innego). Właśnie się tym teraz trochę bawię. Jak skończę, wrzucę coś do bloga. Jestem też ciekaw jak MagLev wypada w porównaniu z JRuby pracującym z obiektową (javową) bazą Neodatis. Podyskutujemy sobie pewnie o tym na kanale IRC #ruby.pl

    @Mekk: Co do idiomów użycia, to zajrzyj na świeży artykuł na infoq.com, a konkretnie zobacz pierwszy, trochę rozbudowany komentarz do artykułu, bo jest b. ciekawy. Poza tym, pobierz MagLev’a i zajrzyj do katalogu “examples”.

  5. Avatar Jiima powiedział 4 days later:

    @JZ Niestety na ircach nie bywam, bo fizycznie nie mam czasu. Jak już nie pracuję, to wolę pobyć z rodziną.

    NeoDatis’a bym akurat nie porównywał, bo to skromniutkie, proste rozwiązanie…

    Zaś co do baz obiektowych – owszem, są szybsze, ale zależy do czego. Model obiektowy się szajsiarsko przetwarza w RDBMS, to fakt (właśnie się biedzę z czymś takim), ale w drugą stronę jest równie źle – a sporo rozwiązań biznesowych opartych jest właśnie o model relacyjny – potrzebujemy dużych, spójnych tabelek z niewielką ilością powiązań i bez perwersji typu drzewa czy grafy cykliczne. Poza tym jest to nieco inna kwestia niż w wypadku COBOL’a. COBOL’a nikt nie lubił nigdy i wielu przeklinało IBM za to że uczynił go swoim głównym językiem programowania. Dzisiaj mainframe da się programować w innych językach (choćby i w Javie), COBOL jest do utrzymywania istniejących molochów bankowych, których nikogo nie stać na wymianę i napisanie od zera w czymś sensowniejszym i łatwiejszym do utrzymania. Z RDBMS jest zupełnie inaczej. Wielu ludzi ich lubi, lub nie wyobraża sobie innego podejścia, bo tak ich nauczono na studiach. Modele obiektowe są może i bardziej naturalne, ale nie dla każdego, a na pewno nie dla analityków biznesowych, których głównym narzędziem pracy jest M$ excel. A modeli alternatywnych jest na kopy. Model dokumentowy (Couch) – w wielu projektach były jeszcze lepszy od obiektowego, zwłaszcza w językach dynamicznych. Model drzewiasty (XML, LDAP). Model skojarzeniowy (Prolog, RDF). Wszystkie mają swoje nisze i jakoś w nich żyją, nawet da się na tym pieniądze zarabiać. Ale RDBMS rządzą i raczej jeszcze się to długo nie zmieni. Zobacz chociażby na takiego Oracle’a. Ma w sobie możliwość szybkich zapytań XQuery na danych XML, ma możliwość transparentnego składowania obiektów (o ile piszesz w PL/SQL), struktur i innych cudów. A kto z tego korzysta? Ja pracowałem na jednym projekcie gdzie wykorzystywano kolumny XML i to też w sposób urągający logice. I koniec.

  6. Avatar Jarosław Zabiełło powiedział 23 days later:

    @Jiima: myślę że od MacRuby ciekawszy jest lispowy Nu. Jest znacznie prostszy i ma pełne jeden-do-jednego mapowanie z Objective-C (nic dziwnego, Nu jest stworzony w Objective-C. Implementacja Nu jest 4x krótsza niż MacRuby: 1MB vs 40MB).

    Inną ciekawym projektem jest smalltalkowy F-Script. Pozwala na interaktywną introspekcję i manipulację obiektami Cococa.

  7. Avatar tomek powiedział 25 days later:

    “Bazy obiektowe są już dużo ciekawsze i szybsze.”

    Jaka to obiektowa baza danych jest szybsza od klasycznych RDBMS ? Badałem kilka obiektowych i wydajność w porównaniu z MySQL miały zerową nie mówiąc np. o Oracle. Chętnie przetestuję tą, o której piszesz.

  8. Avatar Jarosław Zabiełło powiedział 25 days later:

    Coś musiałeś skopać. Zobacz sobie db4o albo neodatis. Proste wczytaniu 350 tys. rekordów posortowanych po dacie tworzenia: db4o: 3.6s, mysql 13.6.s.

    Im bardziej złożone struktury tym gorzej dla MySQL (bo koszmarnie zwalnia na joinach jak jest dużo rekordów). Dlatego m.in. BigTable, kolumnowa baza używana przez Google nie ma joinów. MySQL jest od 4 do 40 x wolniejszy dla bardziej złożonych danych.

    Z kolei GemStone to baza smalltalkowa operująca na danych wielkości wielu petabajtów. I przechowuje całe obiekty. Taka ilość danych wymagająca użycia joinów rozłoży na łopatki każdą bazę relacyjną. Największe i najszybsze bazy to bazy obiektowe. Np. giełda Nowego Jorku używa Gemstone.

  9. Avatar JC powiedział 4 months later:

    A dlaczemu to jest takie szybkie ? http://hsqldb.org/

    (szybsze wg nich od db4o)

(leave url/email »)

   Pomoc języka formatowania Obejrzyj komentarz