MySQL fork: Drizzle
Opmerkelijk nieuws afgelopen maand, enkele ontwikkelaars - waaronder een co-founder van MySQL A.B. zelf, hebben besloten dat ze MySQL momenteel, sinds 5.1/6.0, te weinig vinden aansluiten bij de eisen van 'het web' en hebben een fork genaamd Drizzle aangekondigd om dit probleem aan te pakken.
Na regen komt...
Drizzle is een MySQL fork waarbij allerlei enterprise functionaliteit, zoals de Drizzle ontwikkelaars het noemen, permanent verwijderd wordt en andere functionaliteit prominenter zal worden toegepast. Zo zal Drizzle in eerste instantie gebaseerd worden op de InnoDB storage engine, terwijl allerlei features - zoals views, stored procedures, triggers, de query cache, allerlei 'extra' datatypes, enzovoorts, worden verwijderd. Op deze manier moet Drizzle de eigenschappen waar MySQL beroemd mee is geworden (lightweight, simpel, snel) weer beschikbaar maken.
Q: "This is not a SQL-compliant relational..."
A: That's true. We do not aim to be that.
Drizzle is een echte fork van MySQL, wat inhoudt dat er wel vanaf de MySQL 6.0 basis gebouwd wordt maar ook dat er radicale, niet MySQL-compatible, wijzigingen zullen plaats vinden welke hun weg waarschijnlijk ook niet terug gaan vinden naar MySQL. Het is dus niet bedoeld als research project, maar echt een apart product dat naast de steeds 'enterprisier' wordende MySQL kan bestaan.
And now the weather forecasts..
Hoewel de features uit MySQL 5.1 / 6.0 - zoals stored procedures, etc. - best interessant zijn hebben de meest grote MySQL-based websites het tot nu nog toe weten te redden met oudere minder feature rijke versies van MySQL.
Daarom denk ik dat als Drizzle, als gevolg van het verwijderen van allerlei uitgebreidde features, een significant performance verschil weet te realiseren, Drizzle best de nodige aandacht zal trekken, met name bij high performance websites, wellicht op eenzelfde manier als Lighttpd of nginx dat nu doen tegenover Apache.
Beschikbaarheid
Drizzle is nog hevig in ontwikkeling en heeft dan ook nog geen officiele release vrijgegeven. Maar aangezien ook Drizzle (vanzelfsprekend) een open source project is, is de source code wel al beschikbaar via de Drizzle homepage. Daar vind je ook een FAQ met antwoord op de vragen als Can you add back feature X? (het antwoord is nee, overigens :) ).
Q: Can I run a website with this?
A: No. We are still making incompatible changes, and certainly do not believe the code is production quality. Right now we are defaulting many configure operations to generate debugging code for us so our binaries are not optimal. Therefore, do not go out and benchmark this and expect it to be one way or the other. We are currently only doing benchmarks where it makes sense for us to determine where bottlenecks are.
Mensen die hopen Drizzle op Windows te kunnen proberen hebben pech - de ontwikkelaars geven specifiek aan momenteel geen Windows support te bieden en ook bijzonder weinig interesse daarin te hebben.
Volg Scriptorama via RSS!
on 
on 
on 
on 
on 
on
Reageer ook!
Op zich klinkt dat allemaal leuk, maar de keuze voor het verwijderen van de query cache snap ik niet helemaal. Natuurlijk voegt die nogal wat overhead toe indien een query niet in de cache staat, maar bij sites die voornamelijk lezen uit de DB kan de query cache nog een aardige winst betekenen.
Zo draait 1 van mijn sites bijna geheel op de cache en worden ÏNSERT & UPDATE queries opgevangen door een message server. De queue hiervan wordt via een soort producer/consumer systeem eens in de 10 minuten uitgelezen. Hierdoor lopen bepaalde onbelangrijke zaken (stats, e.d.) wel altijd 10 minuten achter, maar het scheelt aanzienlijk in de hardware die nodig is.
Door Alex Kamsteeg
op 08.07.08 @ 9:13 am | Permalink
De Drizzle developers vinden waarschijnlijk dat een dergelijke cache waarschijnlijk beter vanuit de applicatie gecached kan worden, in plaats van in de database server en daar hebben ze op zich wel een punt. Als je PHP + Memcache gebruikt om je gegevens te cachen heb je dan ook meer flexibiliteit.
Door Mathieu Kooiman
op 08.07.08 @ 9:26 am | Permalink
Wil je eens een artikel schrijven over de verschillende caching methodes in PHP en MySQL Mathieu?
Door Marten
op 08.07.08 @ 10:04 am | Permalink
"Hoewel de features uit MySQL 5.1 / 6.0 - zoals stored procedures, etc. - best interessant zijn hebben de meest grote MySQL-based websites het tot nu nog toe weten te redden met oudere minder feature rijke versies van MySQL. "
Dat komt omdat je namelijk geen andere keuze hebt!
Je hebt of MyISAM (fulltext search) of InoDB (FK, transactions).
"te weinig vinden aansluiten bij de eisen van 'het web'".
De eisen van het web?
Wat ik wil is een website welke altijd werkt (en niet als het iets teveel voor de database word deze over de kop gaat).
We leven niet meer in de jaren 90, het internet word steeds en steeds groter. Om nu terug te gaan naar een simpele database architectuur is onzin.
Wil je een database hebben: Die snel is, wel al die dingen ondersteund, en toch nog gewoon fulltext search heeft. En op elke OS kan draaien?
Neem dan PostgreSQL en je begrijpt wat ik bedoel.
Juist om die beperkingen ben ik over gestapt op PostgreSQL :)
Door Sebastiaan Stok
op 08.07.08 @ 11:05 am | Permalink
Ik hoop van harte dat dit project vroegtijdig sterft. Eindelijk wordt mysql volwassen en ontstaan er interessante mogelijkheden. En dan krijg je zulk soort devolutie.
Hosters die ondersteuning voor mysql schrappen ten faveure van deze retromeuk zal ik mijden. Waarom een stored procedures en views niet net zo goed in een webomgeving handzaam zijn is mij een raadsel. Een ultradunne dbms is prettig voor google-achtige technologieën waar iedere milliseconde telt. Daarnaast kan men slechts hopen op een grotere snelheid:
Het lijkt me verstandiger om prestatiewinst te bereiken via het optimaliseren van de query-uitvoerplannen.
En ik vraag me af wat ze bij mysql aan het uitspoken zijn. Mysql 5.1 laat al heel lang op zich wachten, en de ontwikkelaars beginnen allemaal aan alternatieve ideeen te werken. Je wilt niet weten hoeveel storage engines in pre-alpha status verkeren :'). Ze kunnen beter met gebundelde kracht richting een gemeenschappelijk afgesproken doel ontwikkelen.
Tenslotte houd ik postgre ook al een poosje in de gaten. ;)
Door Alfa
op 08.07.08 @ 1:45 pm | Permalink
Okee, dit is een typische WTF.
Wanneer je de features die een RDBMS maakt tot wat hij is (denk aan SQL standaard) uit een systeem gaat halen dat in mijn ogen toch al niet hoog scoort is volgens mij het einde echt zoek.
Het kan mij niet boeien hoe snel een database is, zolang het maar betrouwbare resultaten geeft en een betrouwbare kern heeft. Dankzij de SQL modes waren de grootste databetrouwbaarheidsproblemen opgelost, omdat MySQL nu eindelijk queries begon af te schieten. Dat zal ongetwijfeld nog wel even blijven ziten, maar wie weet hoe lang het duurt voordat ze die delen gaan verwijderen omdat "het voor teveel vertraging zorgt"?
Nee, geef mij dan PostgreSQL maar. Compleet gericht op het neerzetten van een betrouwbare, snelle database, die de snelheid haalt uit statistische analyse van tabel- en datastructuren. Alles wat je van een database verwacht is aanwezig, en wordt ook tot in den treure afgedwongen. Dit is overigens geen slecht punt.
Het punt hierbij is eigenlijk: als MySQL vanaf het begin complete integriteitsbewaking e.d. had gehad was niemand ooit op het idee gekomen om de database uit de database te halen door dit soort geintjes te flikken, want dan had niemand ooit gehoord van een database zonder integriteitsbewaking.
Door Ben van Velzen
op 04.29.09 @ 4:58 pm | Permalink
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>