Open source-database overhaler MySQL med faktor 100
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.
Kommentarer (15)
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 pointer" linker til:
http://voltdb.com/_pdf/VoltDB-MikeStonebraker-SQLMythsWebinar-060310.pdf
-
0 -
0
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
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
Mig bekendt må man da ikke lave benchmarks på Oracles DB og sammenligne den med andre...?
-
0
-
0
Mig bekendt må man da ikke lave benchmarks på Oracles DB og sammenligne den med andre...?
Gælder det ikke kun dem som kan læse engelsk?
-
0
-
0
"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
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
Bl.a. SAP ser på at lægge deres data i en in-memory database:
http://www.zdnet.com/blog/btl/sap-plots-in-memory-database-pilots-analyt...
-
0
-
0
Men det kan blive meget værre når man hiver fat i de komplicerede features som fx joints og nestede queries.
"Joints" må vist være én af de mere sjældne features. Er det når beregningerne er så komplicerede, at pc'en begynder at ryge? :-)
-
0
-
0
Der findes en memory driver til MySQL, der bruger nøjagtig samme strategi - den holder hele databasen i hukommelsen.
Memory-baserede databaser er jo mægtig fint, hvis man ikke har noget i databasen man skal bruge, og ikke har noget andet at bruge 4 GB RAM til ;-)
-
0
-
0
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
