Nieuwe testversie MySQL 6 met Falcon-engine beschikbaar

De populaire database-engine MySQL heeft de laatste jaren een stormachtige ontwikkeling doorgemaakt. Deze maand verscheen de tweede alphaversie van MySQL 6 met een nieuwe storage engine die InnoDB moet doen vergeten.

Nadat Oracle eind 2005 InnoDB overnam, waardoor de ontwikkelaar van de belangrijkste storage engine van MySQL in handen van deze 'concurrent' kwam, besloot het bedrijf om onder leiding van databaseguru Jim Starkey een eigen engine te ontwikkelen. Deze engine, die door het leven gaat onder de naam Falcon, zal een van de vernieuwingen zijn die in versie 6 van MySQL zijn opwachting maakt.

Momenteel bevindt Falcon zich nog in alphastadium als onderdeel van de deze maand uitgebrachte alphaversie van MySQL 6. Ten opzichte van de huidige MySQL-versies zijn de voordelen nog beperkt. Falcon biedt ondersteuning voor een groot aantal features, waaronder multi version concurrency control, waardoor lees- en schrijfacties van verschillende gebruikers niet op elkaar hoeven te wachten. Verder is er ondersteuning voor acid-transacties, crash-recovery en verbeterde prestaties ten opzichte van InnoDB. Dit laatste zou bereikt moeten worden door een innovatieve cachingstrategie en een implementatie van b-tree-indices, waarbij de lees- en schrijfacties van de harddisk minimaal zullen zijn.

Eerst bewijzen

Hoewel al deze features veelbelovend klinken en wellicht een verbetering zullen zijn ten opzichte van de huidige storage engines die beschikbaar zijn voor MySQL is het nog te vroeg om volop te gaan juichen. Ten opzichte van InnoDB biedt Falcon weinig aanvullende features, maar vooral een verbeterde implementatie van bestaande mogelijkheden.

Zo mist Falcon, net als de meeste andere storage engines voor MySQL, ondersteuning voor foreign key constraints. Volgens de informatie van MySQL zal dit ook niet aanwezig zijn in de eerste versie van MySQL 6, maar zal het later toegevoegd worden waarbij het ook gelijk beschikbaar gemaakt zal worden voor alle andere storage engines. Ook de zeer goede prestaties die worden beloofd zijn nog geen realiteit.

Uit een eenvoudig opgezette benchmark waarin de prestaties bij het ophalen en schrijven van blob-data worden gemeten, blijkt bijvoorbeeld dat InnoDB het nog altijd beter doet dan Falcon. Dit laatste is niet verrassend, gezien het feit dat al geruime tijd aan InnoDB wordt ontwikkeld en er dus meer tijd is geweest om de prestaties van deze engine te optimaliseren. Falcon moet eerst nog volledig bugvrij worden gemaakt, voordat men zich volledig op snelheidstuning kan gaan richten.

Pluggable storage engines

Een van de features waarin MySQL zich onderscheidt van veel concurrenten is de plugin-architectuur voor storage engines. Hierdoor is het mogelijk om in een enkele database verschillende storage engines te combineren die geoptimaliseerd zijn voor specifieke toepassingen.

Een voorbeeld van een dergelijke engine is de nieuwe Scalable Blob Streaming Infrastructure voor MySQL, die de ietwat opmerkelijke naam MyBS heeft gekregen. Deze storage engine is geoptimaliseerd voor de opslag van binaire data in de database, ook wel Blobs genoemd.

Een van de problemen met dit data type is dat het ophalen van de data uit de database vaak langzamer gaat dan wanneer hetzelfde bestand van harddisk zou worden gelezen, waardoor het voordeel van de opslag in de database teniet wordt gedaan door de slechte performance. De oorzaak hiervan is dat de database de binaire data eerst leest van de harddisk en tijdelijk buffert in het werkgeheugen, alvorens de data wordt doorgegeven naar de client die de data opvraagt.

MyBS verhelpt dit probleem door de Blob-data te 'streamen' via een eigen webserver, die de data direct van de harddisk leest. Deze nieuwe storage engine is te gebruiken in combinatie met alle storage engines voor MySQL. MyBS verzorgt namelijk niet de opslag van 'gewone' data in tabellen.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (17)

Ik vind het trouwens wel opvallend dat ze nu al bezig zijn met versie 6, terwijl 5.1 nog steeds beta genoemd wordt bron. Ik denk dat we daar ook wel uit kunnen opmaken dat versie 6 voorlopig niet final zal worden.

Ik vind het trouwens wel opvallend dat ze nu al bezig zijn met versie 6, terwijl 5.1 nog steeds beta genoemd wordt bron.

Waarom is dat zo opvallend? Moeten developers die (normaal) aan nieuwe features werken maar even een paar maanden vakantie nemen?

Zo werkt MySQL al jaren. Een versie is de GA, eentje Beta, en eentje Alpha.

Geen foreign key support? Dan houdt het wel een beetje op jongens.....als ze willen dat MySQL serieus genomen gaat worden moeten ze eerst zelf beginnen met het serieus nemen van een database.

Dat wordt inderdaad in dit artikel geschreven, maar klopt niet. MySQL 5 en dan de innodb engine ondersteunt wel foreign keys. Ik gebruik ze zelf ook. Zie http://dev.mysql.com/doc/...eign-key-constraints.html

Het klinkt inderdaad als een grote domper. Maar zoals je kan lezen zijn ze van plan om dit op zo'n manier te implementeren dat alle engines er gebruik van kunnen maken. Er is geen reden om het ontwerp van een nieuwe engine te overhaasten. Falcon zal waarschijnlijk nog jaren en jaren mee moeten. Vergeet ook niet dat het aantal features wat ze al leveren opzich helemaal niet slecht zijn voor een eerste versie. Tot falcon zo ver is kun je nog rusting innodb blijven gebruiken. Niks aan het handje dus.

met 'geen foreign key support' wordt bedoelt dat er geen _constraints_ van dat type gedefinieerd kunnen worden. maar functioneel kun je natuurlijk gewoon foreign keys gebruiken; een relationele database waarbij je tabellen niet kunt joinen moet nog uitgevonden worden.

foreign key constrains stellen een database in staat zeker te stellen dat elke foreign key verwijzing geldig is. dat er geen dangling pointer achtige foreign keys zijn, bijvoorbeeld een medewerkertabel foreign key 'afdeling' met een afdelingnummer dat niet in de 'afdeling' tabel bestaat. het borgt de referentieele integriteit van de database.

als je in een database met foreign key constraints een rij wilt weggooien uit de afdeling tabel dan lukt dat alleen als er geen foreign key referenties zijn naar die rij. als er bijvoorbeeld medewerker rijen zijn die verwijzen naar de betreffende afdeling rij dan lukt het deleten van die afdeling rij niet; de foreign key constraint dwingt die consistentie af. je zult dan eerst de medewerkers moeten omhangen naar een andere afdeling alvorens je de bestaande afdeling kan deleten.

overigens kent innodb wel foreign key constraints zie de zoufiax' bijdrage.

Waarom ondersteunt mySQL dan geen foreign key constrains? Dat lijkt me toch redelijk belangrijk voor een database.

De belangrijkste engines van MySQL zijn MyIsam en InnoDB. MyIsam ondersteunt geen foreign key constraints, en InnoDB wel. MyIsam ondersteunt het niet omdat ze het er niet ingebouwd hebben. Lekker simpel antwoord natuurlijk. Omdat dit soort zaken niet door de MyIsam ondersteund worden, heeft deze engine wel als voordeel dat hij erg snel is, hetgeen bijvoorbeeld voor websites erg handig is, vandaar dat MyIsam toch veel gebruikt wordt. De engines zijn door elkaar te gebruiken, binnen één database kunnen sommige tabellen de MyIsam engine gebruiken, en andere de InnoDB engine.

Vooral dat MyBS (MyBullShit? ) klinkt interessant. Zo verdwijnt langzamerhand alle beperking om bestanden die je wil beveiligen (bijvoorbeeld afbeeldingen die niet iedereen mag zien, of geüploade documenten) in een blob te proppen zodat de bestanden niet meer direct op te vragen zijn.

Uiteraard is zoiets mogelijk door de documenten buiten de webroot op te slaan, of de uploadmap te beveiligen met een .htaccess, maar dit is niet op alle servers mogelijk, de hoster moet zoiets wel toestaan.

Bij een standaard hosting pakket zit altijd wel een direcory die niet in de webserver wordt getoond. Daarin kan je je bestanden opslaan en 'streamen' vanuit je applicatie naar de client (uiteraard na de security checks).
Voor de performance is dit niet echt geweldig ...

[Reactie gewijzigd door DavidAxe op 21 september 2007 11:56]

Vooral dat MyBS (MyBullShit? ) klinkt interessant. Zo verdwijnt langzamerhand alle beperking om bestanden die je wil beveiligen (bijvoorbeeld afbeeldingen die niet iedereen mag zien, of geüploade documenten) in een blob te proppen zodat de bestanden niet meer direct op te vragen zijn.

Of je het op bestandssysteem opvraagt, of vanuit de DB, opvragen moet je toch wel, hoe je het ook wend of keert, anders kan je het beter niet opslaan (waar dan ook...)

Dus echt een voordeel zie ik er niet in, zeker niet als je een goed preseterende RAID setup hebt...

Uiteraard is zoiets mogelijk door de documenten buiten de webroot op te slaan, of de uploadmap te beveiligen met een .htaccess, maar dit is niet op alle servers mogelijk, de hoster moet zoiets wel toestaan.

De hoster moet anders wel MySQL 6 gaan draaien, wat (logischerwijs) nu nog lang niet wenselijk is gezien de huidige status van MySQL 6.

En hosters moeten dan jou ook nog eens een keer gaan toestaan, dat jij de instellingen van hun MySQL server aanpast, door een plugin voor database storage engines te installeren, wat ook niet wenselijk is...

[Reactie gewijzigd door CH4OS op 21 september 2007 17:48]

Dat Pluggable storage engines klinkt erg goed. Plugin-systemen wakkeren altijd een community-driven participatie aan en ik denk dat dat hier ook zal gebeuren. Distributed storage bijvoorbeeld. Of interfaces naar search-engines. Erg veel mogelijkheden. Goeie zaak.

Dit is nu ook al gewoon mogelijk met mysql 5. Je kunt InnoDB tabellen (voor transacties en FK's) en MyIsam tabellen(performance, full text search) in 1 enkele database (schema).

Dat Pluggable storage engines klinkt erg goed. Plugin-systemen wakkeren altijd een community-driven participatie aan en ik denk dat dat hier ook zal gebeuren.

Op zich heb je gelijk, het is mooi voor de community en de goedwillenden.

Maar bedenk je ook, dat kwaadwillenden nu wel een extra deur hebben, om binnen te komen en aan de hand daarvan misschien wel toegang weten te verschaffen tot jouw mooie MySQL 6 servertje en daardoor dan jouw databases vernielen, aanpassen en, in het ergste geval, verwijderen...

[Reactie gewijzigd door CH4OS op 21 september 2007 17:51]

back-up......

ik heb liever dat ze alles verwijderen, dan dat ze wat kleine dingen veranderen.
Als het namelijk allemaal weg is valt het wel op... anders zie je het misschien niet en ben je het in je back-ups ook al kwijt....

Ik denk dat ze voor een echte release toch even moeten realiseren dat alle features van MySQL 5 weer terug aanwezig zijn in een stabiel en snel(lere) vorm