Open source-database overhaler MySQL med faktor 100

Er der monstro nogle eksterne links til denne interessante nyhed?

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

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.

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

Mig bekendt må man da ikke lave benchmarks på Oracles DB og sammenligne den med andre...?

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?

Tror nu deres advokater er ligeglade.

"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.

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.

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...

Evt. bruge SolidDB?

http://www-01.ibm.com/software/data/soliddb/

Tak for det

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? :-)

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 ;-)

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).