Binnenkort vrijgave details MySQL 'Falcon'

MySQL hoopt volgende week de eerste technische gegevens vrij te geven van de nieuwe storage engine en nieuwe beheersoftware waar het aan werkt. Het bedrijf is met de ontwikkeling van een eigen storage engine begonnen nadat Oracle de bedrijven achter de belangrijkste storage engines van MySQL opkocht. De nieuwe storage engine heeft de codename 'Falcon' gekregen.

MySQL logo nieuwe stijlDe ontwikkeling van Falcon kreeg een snelle start door de overname van het bedrijf Netfrastructure van database-expert Jim Starkey. De engine moet dit jaar gereed zijn en een eerste bètaversie van de storage engine hoopt het bedrijf deze zomer vrij te geven. Falcon is geoptimaliseerd voor transacties, waarmee het bedrijf een belangrijke eigenschap zal ondersteunen die in eerdere versies van MySQL altijd ontbrak. Falcon is ontworpen voor 'groeiende' databaseconfiguraties, waarmee het bedrijf applicaties bedoelt waarbij meerdere goedkopere databaseservers worden ingezet in plaats van enkele dure krachtige servers. Naast Falcon hoopt MySQL ook het nieuwe pakket 'Workbench' te presenteren. Workbench is een programma waarmee het mogelijk is om in een grafische omgeving databases te ontwerpen. Workbench zal, in goede MySQL-traditie, worden vrijgegeven onder de GPL en zal dus gratis beschikbaar zijn.

Door Martin Sturm

Nieuwsposter

21-04-2006 • 22:32

19

Bron: C|Net

Reacties (19)

19
19
7
1
0
12
Wijzig sortering
Inmiddels zijn er al zoveel storage engines voor MySQL dat je bijna de bomen door het bos niet meer ziet. NDB, InnoDB, MyISAM etc. etc. Alle databases hebben hun sterke kanten, maar het word steeds moeilijker om te kiezen tussen een van deze engines.
Anoniem: 14829 @FunzoneQ!22 april 2006 16:01
ISAM is m.i. een soort file based engine "on steroids" uit het verleden (zelfs de Amstrad CPC6128 CP/M computer had een ISAM module, al noemden ze die Jetsam).
Wel goed met indexen, maar dingen als foreign key constraints, transactions, roles, etc. daar moet je niet mee aankomen. En over triggers en stored procedures hebben we 't dan al helemaal niet.

De enige echte engine die ik ken (maar dat is wrs. mijn gebrek) is InnoDB, nu eigendom van Oracle. Niet zo gek dus dat ze nu met een eigen alternatief gaan komen, toch?
De enige echte engine die ik ken (maar dat is wrs. mijn gebrek) is InnoDB, nu eigendom van Oracle.
Belangrijkste nadeel van InnoDB vind ik dat het geen Full Text Indexen ondersteunt. MyIsam heeft dat weer wel.
Anoniem: 36664 21 april 2006 23:00
Ik krijg het idee dat MySQL een beetje begint te verzuipen in zijn eigen storage engines. Als ze zich nu eens zouden richten op 1 of 2 engines en die goed door zouden ontwikkelen, maar nu moet je onderhand een vergelijkend waren onderzoek gaan doen als je wat specifiekere dingen wil doen dan je standaard database voor websites.

Workbench is natuurlijk een mooie applicatie, maar waarom stoppen ze al die beheerstools niet gewoon in 1 omgeving, zoals ook gedaan is bij DB2, MSSQL en Oracle. Dat werkt wat mij betreft toch stukker fijner.

Centralisatie van dingen vind ik toch een groot gemis van MySQL, maar niet gecentraliseerd zijn wordt dan ook wel gezien als de kracht van Open Source, omdat niet alle kennis bij één organisatie ligt... Maar centraliseren van verschillende tools in 1 tool lijkt mij niet echt een probleem te veroorzaken.

@foxboy: Dat wordt weer tegengesproken door deze uitspraak:
"Rather than have one perfect engine, it's better to have a pluggable architecture," Urlocker said. "The idea is you can mix and match within a single application because data will be used in different ways."
Niet helemaal duidelijk dus. Ik ben het overigens absoluut niet eens met deze uitspraak. Maar met een perfect systeem ben ik het ook niet eens (bestaat niet). Ik ben de uitspraak daarover ff vergeten (komt uit DSDM).
Als ze zich nu eens zouden richten op 1 of 2 engines en die goed door zouden ontwikkelen
En dat is volgens het artikel nou juist nét wat ze gaan doen.
bovendien, -
ze richtten zicht toch nergens op???? ze ondersteunde / implementeerde andere storage engines, ....
lijkt me relatief weinig werk...

vergleken met wat ze nu hebbe gedaan (zelf from scratch)
Inderdaad. InnoDB is momenteel voor transacties en row-level locking, MyIsam voor de snelheid, space efficiency en de FULLTEXT indexing, enz...

Maar wat als ik nu eens in een situatie zit waarin ik én fulltext indexing wil, én acid? Dan kun je wel alles in huis hebben door (in dit geval) een overhypte 'pluggable architecture', maar als je deze niet samen kunt gebruiken, is het nog van gering nut.

Verder: Wat is de relatie tot de SolidDB Engine?
@3x1st4nz3 Bedoel je soms: beter is slechter dan goed genoeg?

Daarmee bedoelend: Een applicatie die precies aan de eisen van de gebruiker voldoet is goed. Een applicatie die meer heeft, wordt minder goed gebruikt en blijft dus wat dingen missen. En is dus slechter gebruikt. (geldt overigens ook voor programmeren: anders maak je er steeds weer extra dingen bij) :)
Anoniem: 81293 21 april 2006 23:06
Eerlijk gezegt doe ik denk ik te simpele dingen met MySQL om het verschil goed te merken tussen die engines.
De standaard (InnoDB geloof ik?) heeft mij in ieder geval nog nooit voor problemen doen staan.
Dat heeft denk ik te maken met het feit dat ik de database vooral gebruik als website back-end, iets waarvoor MySQL uitermate geschikt is: Veel kleine simpele lees en schrijfacties.
[waarvoor MySQL uitermate geschikt is: Veel kleine simpele lees en schrijfacties.]
Ik hoop dan ook dat deze eigenschap wel behouden blijft door alle innovaties....
[waarvoor MySQL uitermate geschikt is: Veel kleine simpele lees en schrijfacties.]
Ik hoop dan ook dat deze eigenschap wel behouden blijft door alle innovaties...
Ik ken mensen die op nieuwe servers nog MySQL 3 zetten precies om deze reden. Ikzelf zou gillend gek worden van het ontbreken van bepaalde toch standaard SQL functies, maar als het gaat om pure performance ben ik wel bereid om te geloven dat MySQL 3 beter performed.
Heel veel verstand heb ik er niet van (dat blijkt denk ik wel uit de vraag) maar wat is eigenlijk dan het verschil tussen MySQL en de Storage Engine?

Wat is het 'extra' dat een aparte naam rechtvaardigd als de kern eigenlijk een soort third party iets is?
Heel veel verstand heb ik er niet van (dat blijkt denk ik wel uit de vraag) maar wat is eigenlijk dan het verschil tussen MySQL en de Storage Engine?
Deze pagina lijkt me zeer volledig met het beantwoorden van die vraag: http://dev.mysql.com/tech...torage-engine/part_1.html

"MySQL Server features a concept called storage engines, or table types. The server, and in fact the developer, can choose how and where a database table is to be stored based on which storage engine is best suited for a particular situation."
Klinkt erg interessant. Tijd om een machientje in te richten om te gaan benchen met de vershillende engines. en ook workbench klinkt ok, hoewel Ik een codegenerator gebruik en maar weinig aanpas met de hand.
Anoniem: 84969 22 april 2006 10:09
"Workbench zal, in goede MySQL-traditie, worden vrijgegeven onder de GPL en zal dus gratis beschikbaar zijn."

GPL betekend niet automatisch gratis. Je kan je programma onder de GPL uitgeven en er toch geld voor vragen en het op traditionele wijze verkopen. GPL zegt echter wel dat het opensource is en de source vrij verkrijgbaar is.
Als de source vrij beschikbaar is, kun je die toch ten alle tijden zelf compileren? Is dat niet hetzelfde als gratis? Bij open source betaal je voor support, niet voor het programma.
De source hoeft niet gratis beschikbaar te zijn volgens de GPL.
Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange
for a charge no more than your cost of physically performing source distribution
Da's dus tegenwoordig gratis, of bijna gratis. Hoeveel kost 't om iemand een linkje naar een source file te geven, of de read only login codes voor een CVS of SVN tree?

Op dit item kan niet meer gereageerd worden.