Open source-database overhaler MySQL med faktor 100

100 gange hurtigere transaktioner end Mysql, 13 gange hurtigere end NoSQL-favoritten Cassandra og 45 gange hurtigere end Oracle. Det er ydelsen, som spritnye Voltdb kan byde på.

Med bestemte begrænsninger er det ikke noget problem at slå alverdens databaser målt på transaktioner. I hvert fald ikke, når databasens ophavsmand hedder Michael Stonebraker og tidligere har haft en finger med i spillet om Ingres, Postgres, Vertica og meget mere.

Michael Stonebraker, som til daglig er professor på MIT, har bygget databasen Voltdb oven på en tidligere udviklet forskningsdatabase H-store, som han selv har udviklet sammen med forskere fra en række andre universiteter. Dertil kommer et grænsefladelag skrevet i Java.

Ifølge ophavsmanden selv kan Voltdb klare transaktioner væsentligt hurtigere end mange andre databaser: 100 gange hurtigere end Mysql, 13 gange hurtigere end NoSQL-favoritten Cassandra og 45 gange hurtigere end Oracle.

Det hemmelige trick består først og fremmest i at placere hele databasen i hukommelsen. Det er ikke det store problem med billig RAM og 64-bit styresystemer, mener Michael Stonebraker. De fleste databaser er nemlig ikke oppe i Facebook- og Google-størrelse.

Voltdb har en SQL-grænseflade og understøtter ACID-kravene, som består i, at transaktionen udføres helt eller slet ikke, men aldrig delvis, at systemet er altid i en konsistent tilstand, at transaktioner foregår isoleret fra omverdenen, samt at transaktioner ikke kan gå tabt på grund af systemnedbrud (på engelsk atomicity, consistency, isolation og durability).

SQL-grænsefladen benyttes via stored procedures, som skrives i Java. Voltdb kommer ikke med nogen gængs databaserdriver, så som ODBC eller JDBC. Sådanne drivere er nemlig alt for langsomme, mener Michael Stonebraker.

SQL i sig selv er ikke rigtigt en flaskehals, lyder en anden af hans pointer. Men hvis man alligevel hellere vil have en nøgle-baseret database, som det kendes fra NoSQL-verden, er det nemt at få Voltdb til at opføre sig på den facon.

Hans database er heller ikke god til analytisk arbejde, men det er muligt at sende transaktionerne videre til et datavarehus i et særskilt system.

Voltdb er open source under GNU-licensen og kan afvikles på de fleste Unix-agtige systemer, herunder Linux og Mac. Den findes også i kommerciel aftapning med support-muligheder.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (15)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jacob Christian Munch-Andersen

Rigtig godt at se, det har i lang tid irriteret mig at se hvor langsomt praktisk talt alle databaser kører, samt en 'sådan er det bare' accept fra de fleste udviklere.

Jeg vil lige præcisere omkring SQL. Hvor langsomt det er kommer primært an på hvilke features man vælger at benytte. Hvis man bruger en 'gammeldags' query streng vil der altid være et overhead i forbindelse med at få den omsat til kode, relativt til udførslen af en simpel forespørgsel er det et stort overhead. Men det kan blive meget værre når man hiver fat i de komplicerede features som fx joints og nestede queries. (At hitte ud af hvor galt eksakt det går er en kompliceret affærer som afhænger af hvordan disse features bliver brugt, og hvor god databasen er til at optimere den genererede kode.)

I Voltdb kan en simpel SQL sætning kompileres helt væk så der basalt set ikke er nogen spor af SQL i den kode som rent faktisk bliver kørt, men jeg går ud fra at det også er muligt at skrive kode som ikke tager turen lige så pænt.

  • 0
  • 0
Jonas Finnemann Jensen

Ved godt det er off-topic, men GNU er ikke en licens, ifølge [1]:

GNU was launched in 1984 to develop a complete Unix-like operating system which is free software— software which respects your freedom.

For de interesserede er VoltDB, ifølge [2], frigivet under GNU GPLv3.

Derudover ved ikke lige hvad jeg skal mene om oversættelsen "Unix-agtige". For min skyld behøver man ikke oversætte Unix-like, men okay...

[1] http://www.gnu.org/
[2] http://en.wikipedia.org/wiki/VoltDB

  • 0
  • 0
Flemming G. Jensen

"Det hemmelige trick består først og fremmest i at placere hele databasen i hukommelsen. Det er ikke det store problem med billig RAM og 64-bit styresystemer, mener Michael Stonebraker"

MySQL, Oracle og sikkert også alle andre relationelle databaser har da kunnet det samme trick i årevis, nemlig at implementere data i forskellige former for RAM baserede caches i årevis, hvis vi taler om read transaktioner. Hvis Mr. Stonebraker taler om inserts eller updates, så lyder det besynderligt at sammenligne ustrukturede data i NoSQL med strukturede data i relationelle databaser.

Det er et ret gammelt trick fra leverandører at påstå netop deres produkt er ca. 101,45% hurtigere end alle konkurrenternes. Den type målinger sammenligner imidlertid altid æbler med pærer og kan i sidste ende ikke bruges til andet end reklamer og artikler i agurketiden.

Hvis man vil "bevise" at et statement kører rigtigt langsomt i MySQL eller Oracle, så skal man såmen blot sørge for at det bliver hard parset hver gang det bliver eksekveret.

  • 0
  • 0
Hans Schou

Hvis man slår fsync(2) fra med Postgresql, så får man også bedre skrivehastighed. Ulempen er at man kan miste hele databasen ved system-crash. I mange sammenhænge kan det være helt fint at gøre det, specielt hvis input til databasen er maskin-genereret og kan reproduceres. Så bliver der lige enkelt gang om året eller så, hvor databasen skal genopbygges, og har man så valgt at leve med. Når man kun har data i RAM, så bruger man heller ikke fsync().

Der findes alle mulige slags data, og de skal behandles forskelligt. Nogen mener de har behov for Oracle, andre at de kan nøjes med MySQL - dem om det.

  • 0
  • 0
Kristian Larsen

Huh?

Som jeg læser det er VoltDB stadig ACID og re-etablering sker via replica.
Og som det nævnes, hvis alle binære data ikke bliver proppet i databasen så er det altså MEGET få databaser som kommer op i 1TB størrelse.

Jeg skal lige have læst lidt mere på det fordi jeg kan se nogle backup/restore problemer - samt jeg kan forudse nogle problemer med at snakke med en DB hvor man selv skal lave stored procedures hele vejen for det man vil (ie. DB'en bliver hurtigt "bundled" til applikationen).

  • 0
  • 0
Log ind eller Opret konto for at kommentere