MySQL komt binnenkort met versie voor clusters

In april zal tijdens de MySQL Users Conference & Expo 2004 in Orlando de MySQL-clusterversie worden uitgebracht. Deze clusterversie is gebaseerd op de storage engine van Ericsson, die door MySQL in november is aangekocht. Dankzij deze engine kan er geclusterd worden over verschillende soft- en hardwareplatformen. Hierdoor kan MySQL worden toegepast in meerdere applicaties en meer kritische systemen.

Naast de aankondiging van de clusterversie, heeft het bedrijf ook aangegeven dat er een meer flexibelere open-source licentie voor MySQL-programmabestanden is opgezet. Met de Free and Open Source Software Exception policy kunnen de programmabestanden nu zowel onder de open-source als de commerciële licentie worden toegepast. Iets wat in het verleden niet mogelijk was en daardoor de programmeurs te veel beperkte in hun bewegingsvrijheid met betrekking tot de programmabestanden.

Reacties (39)

[whoami]

Ik vraag me af of MySQL eigenlijk al transacties, stored procedures, triggers, views, .... ondersteund.
Zonee, dan zouden ze imo zich daar beter eerst op concentreren als ze een serieus RDBMS willen hebben.

Clustering, allemaal mooi en wel, maar de punten die ik opnoemde vind ik toch veel belangrijker, en zullen door meer mensen kunnen gebruikt worden.

[Verwijderd]

van [url="http://www.mysql.com:"]www.mysql.com:[/url]

.."Multiple storage engines including full transaction support with commit, rollback, crash recovery and low-level locking capabilities."...

...It includes features such as stored procedures, triggers and views for the most demanding enterprise use....

Ja dus !!!

[ACM]

Men heeft bij MySQL de neiging om iets globaal te implementeren en dan alsnog gigantisch de plank mis te slaan op details.

Zo is er transaction-support (via innodb), maar de mysqldump-tool maakt al geen transactie aan, waardoor je een inconsistente view op je data dumpt en tenzij je $1000 over hebt voor een hotbackuptool (die dan weer alleen maar met innodb werkt) kan je daar alleen omheen werken door alle tabellen te locken en dan te dumpen of je client-verbindingen allemaal te sluiten

Bij foreign keys zit net zo'n stom detail, je kan tabellen met relaties hebben, inserts/updates/deletes worden netjes gechecked, maar als je de tabel dropt, wordt er niet eens gewaarschuwd! Verder kan je prima foreign keys in je create-table stoppen voor opslagengines die het niet snappen en je krijgt geen waarschuwing dat je FK's niet gaan werken.

De ACID-regels zijn ook niet bijzonder fijn uitgewerkt in MySQL, de Consistency vereist bijvoorbeeld dat als je entry X erin stopt, je exact die entry er weer uitkrijgt. MySQL schendt dat op vele, vele, heel veel, punten zoals:
- Een foutieve datum (je kan zelfs niet-bestaande data opgeven) wordt bijvoorbeeld naar 0000-00-00 omgezet als ie er niks van snapt, niet wat je invoerde ook al was dat fout. Je krijgt er geen waarschuwing van dat het fout was. Andere DB's geven overigens vaak een error dan.
- Getallen hetzelfde, stop 'a' in een integer en er komt 0 uit.
- Stop een string van 11 karakters in een varchar(10) en er is ineens een karakter weg, geen waarschuwing wederom.

Andere dingetjes:
NOT-NULL velden zijn niet af te dwingen, er komt altijd een default op je veld ook als je dat juist expliciet niet wilde.
Nahja, alles wat er in MySQL5 bijkomt mist nog in 4, dus die zal ik niet allemaal noemen...

Anyway, ik heb een poging gedaan een lijstje bij te houden van zulk soort puntjes, maar het is zijn allemaal van dat soort kleine dingetjes die het irritant in-compliant met SQL maken.

[ACM]

Zij weten dondersgoed dat die die dingen er in zitten, een groot deel staat in de manual uitgelegd dat het zo "hoort".
Dat hoort staat tussen "" omdat het imho niet zo hoort, maar dat is deels een meningsverschil.

Op het moment dat zij echter gaan claimen volledig ACID-complaint te zijn, dan vind ik dat ik best ruchtbaarheid mag geven aan punten en hiaten in hun implementatie.

Ik heb iig 2x een bug in mysql gesubmit en beide keren te horen gekregen dat het helemaal geen bug was (in mijn ogen nog steeds wel, magoed).
Als dat de instelling is die ze hebben en ook nog eens weinig tot niets ermee doen, dan kunnen ze het wmb bekijken. Mocht ik iets komen waarvan ik denk dat het een bug is en het niet in hun manual als "zo hoort het" staat, dan zal ik dat overigens alsnog wel rapporteren bij bugs.mysql.com

Waar jij mijn houding t.o.v. Open Source van denkt af te kunnen leiden in het feit dat ik het wel nuttig vind er alsnog een lijstje van bij te houden snap ik niet.
De manier waarop MySQL bezig is en/of lijkt te zijn zint me alleen minder dan bijvoorbeeld de cultuur die postgresql uitdraagt (vorige week nog een query+zwik data aan een van de developers opgestuurd zodat ie niet zelf een test case voor iets hoefde te bedenken) of de gemoedelijkheid van het kleine clubje rond Xapian/omega

[Verwijderd]

Nou heb ik zijn lijstje niet doorgekeken en alleen zijn post gelezen maar ACM heeft het niet over bugs maar over slechte implementaties van features en daar kan ik hem alleen maar gelijk in geven.

[Verwijderd]

Dit heeft weing met Open Source te maken maar alles met slechte software (IMNSHO)

Wil je een open source database kijk dan naar PostgreSQL of Firebird (Open Source versie van Interbase)

Beide gewoon compatible, beide goed gesupport en beide net zo Open Source dan MySQL.

[LauPro]

De instelling die jij hebt t.o.v. Open Source vind ik niet echt geweldig. Imo moet je als een potentiële 'bug' ziet die melden en eventueel meehelpen oplossen. Maar niet zomaar ergens een lijstje online gooien met wat 'eisen'. Om even minister Donner te quoten: "kritiek mag, maar dan wel binnens kamers."

[mjtdevries]

Waarom zou iemand verplicht moeten worden zijn instelling te veranderen voor Open Source.

MySQL wil met de grote jongens meedoen. Dan moeten ze dus ook zorgen dat de net zoals de grote jongens aan de klant kunnen leveren wat de klant wil.

Zelf de problemen van een ander (de leverancier) moeten oplossen is niet wat de klant wil.

Ik zou jouw stelling dus willen omgooien: De instelling van Open Source t.o.v. hun klanten is niet echt geweldig.

(Valt me trouwens vies tegen dat MySQL clustering nog niet ondersteunde. Al jaren roepen allerlei fans dat MySQL zo'n supercompleet alternatief is voor de commerciele pakketen. Maar dat blijkt in de praktijk dus nog wel tegen te vallen)

[_JGC_]

IMHO ga je toch voor postgresql als je een GPL databaseserver met alle nodige features wilt. Postgresql heeft views, stored procedures, triggers, foreign keys, en niet de knullige dingen van MySQL. Tuurlijk heeft het wel andere nadelen, maar die kan ik nu niet opnoemen omdat ik alleen oppervlakkig over psql heen heb gekeken en het nog nooit gebruikt heb.

[RM-rf]

Mysql 5 ondersteund ook Stored Procedures, en MaxDB naar ik meen transactions.
http://www.mysql.com/doc/en/ANSI_diff_Transactions.html
http://www.mysql.com/doc/en/Stored_Procedures.html

echter dit is een beetje het afstappen van het grondconcept van MySQL
het was oorspronkelijk juist bedoeld als light-weight rdbms, ontstaan vanuit mSQL, opegezet toen een databank beheerder (David Hughes) ontdekte dat juist eenvoudige selects 99% van de handelingen innamen echter de bloated ondersteuning van de hele SQL-standaard van het toenmalige PostGRESSQL voornamelijk veel overbodige belasting opleverde.

Ik kan begrijpen dat voor MySQL AB, het zweedse bedrijf achter MySQL, juist extra opties en mogelijkheden vanuit commercieel idee interessant zijn, en ze makkelijk kunnen meekomen in een concurentie met grotere en commerciele RDBMS-en, maar de basis van MySQL blijft juist die light-weight versie.

[ripexx]

Light weight is leuk maar primaire zaken zoals een goede sorteringen (geen filesort) en foreignkeys zijn toch wel essentiel. Als is het maar voor een simpele database.

Dat trigger, storedprocedures, views enz niet in de light versie zitten kan ik me wel voorstellen.

Verder is MySQL versie 4 nog niets een goed beschikbaar bij de gemiddelde hoster laat staan dat men snel naar versie 5 zal gaan.

[Verwijderd]

Uhm, als een hoster pertinent weigert updates te installeren voor software ook al heb jij ze nodig, dan wordt het toch es tijd naar een concurrent te gaan zoeken..
Je kan moeilijk MySQL de schuld geven dat sommige hosters lamzakken zijn =)

Verder heeft MySQL zeker zijn nut, het lijkt wel alsof tweakers uit mensen bestaan just de features nodig hebben die hun crew bloat noemt.. Da's prima natuuriljk (genoeg andere oplossingen) maar het feit dat MySQL zoveel gebruikt wordt is vast niet voor niets.

[hiostu]

Daar ben ik het helemaal mee eens. Ik heb me niet echt heel erg bezig gehouden met MySQL, dus ik weet niet welke van deze features al ondersteund worden.

Maar transacties en stored procedures zijn toch wel vereisten voor mij om een applicatie te ontwikkelen.

[ripexx]

Helemaal mee eens, met de huidige mogelijkheden van multiprocessor systemen is de noodzaak van clustering ook veel minder.

Verder is het wellicht beter om de basis fucntionaliteit op orde te krijgen. Zoals onder ander FK, transacties, views, triggers enz Hoewel FK nu in versie 4 wel werken.

Wellicht dat de samenwerking met SAP toch voor wat verbetering gaat zorgen, de eerste varianten zijn nu al beschikbaar ik de vorm van MaxDB maar ik mis nog een beetje de profesionaliteit. Verder zijn er ook nog een aantal heel irritante bugs in MySQL zoals een filesort bij een ORDER BY DESC

[svanuden]

Hierdoor zal de markt voor serieuze database gebruikers nog wel eens een ander beeld kunnen krijgen. Als MySQL zo door gaat dan wordt het toch wel een interessant alternatief voor de midden tot grote bedrijven!

edit:

Niet alleen met php handig, maar gewoon heel sterk en snel met sql. Dat is nog veel belangrijker aangezien niet alle applicaties met php zullen werken.

[hardwareaddict]

Ik denk dat je het hier wel HEEL zachtjes uitdrukt.

Een bepaald soort query gaat nog vrij slecht in mysql, daar heb je absoluut oracle voor nodig, maar het gros van de databases worden zulke lastige queries niet gegeven.

Op het moment dat dit geclustered werkt voor mysql, dan is het einde verhaal voor heel veel instellingen die dure databases gebruiken nu.

Dat loopt op tot miljoenen per jaar, dus die besparing is *enorm*.

[Verwijderd]

MySQL kan bepaalde zaken heel goed (snel sneller snelst) maar andere dingen heel slecht (transacties, referential integrety e.d.)

Dus ik denk niet dat Oracle e.d. wakker liggen van MySQL als serieuze bedrijfsdatabase.

[bitflusher]

misschien is dit ook wel handig voor t-net er komt al meer hardware om in noodgevallen beter te kunnen reageren http://www.tweakers.net/plan/244 misschien en redundantie van servers dmv een cluster wel beter

[ripexx]

Van wat ik ACM begrepen heb is men niet direct van plan om te gaan clusteren. Te meer omdat het opzet van een cluster ook genoeg problemen met zich mee brengt.

[bitflusher]

alles heeft voor en nadelen, updates uitvoeren op een node terwijl het cluster blijft lopen is een van de voordelen

[ACM]

MySQL heeft de neiging (hmm, dat heb ik eerder gebruikt hier ) om dingen ruim voor het ook maar "verstandig is toe te passen" aan te kondigen.
Zo is MySQL 5 al "gereleased" terwijl ze eigenlijk bedoelden dat ze de eerste public alpha's hadden. Bij MySQL 4 duurde het daarna nog een half jaar voor de beta's verschenen geloof ik en meer dan een jaar voor het stable was verklaard...

Dus bij MySQL 5 en alle andere aankondigingen neem ik sowieso een enorme korrel zout bij de daadwerkelijke beschikbaarheid.

[Verwijderd]

Maar even terugkomend op wat Beaves zich af vroeg.
Waarom zou je eigenlijk kiezen voor MySql als er PostgreSQL beschikbaar is?
Zelf gebruiken we MS SQL maar kan me voorstellen dat PostgreSQL ook een solide oplossing is. MET enterprise features.

[jb044]

Toegankelijker en lichter, al spreekt dit bericht dat wat tegen.....
Om het ontopic te houden wat heeft Postgresql eigenlijk te bieden qua multiplatform clustering??

[Verwijderd]

tips voor mysql:
1 maak mysql beter
2 maak mysql nog beter
3 kom met een cluster versie
in die volgorde aub.

Wat een onzin, het is een prima database programma maar het is nog lang niet capabel genoeg om echt serieus deel te nemen op de middel tot grotere bedrijven markt. Laat ze liever hun tijd nuttiger besteden.

[Verwijderd]

Zowiezo is het al een mooie ontwikkeling dat naast commerciele software ook een open source komt. Ik weet niet of mysql nu de eerste is maar wel een van de eerste. Ik heb een beetje gespeeld met mysql en het is wel wat type werk als je code based gaat maar wel handig in combinatie met php...

@svanuden: Voor web toepassingen is het dan wel weer handig. Ik weet niet de precieze voordelen/nadelen/betekenis van:transacties, stored procedures, triggers, views, ...., zou iem. dat kunnen uitleggen? Ik weet alleen dat je er een db mee kan maken. (les gehad in php), Het is ook wel makkelijk met kleine- =>middel- grote databases.

[Verwijderd]

Voor web toepassingen is het dan wel weer handig. Ik weet niet de precieze voordelen/nadelen/betekenis van:transacties, stored procedures, triggers, views, ...., zou iem. dat kunnen uitleggen? Ik weet alleen dat je er een db mee kan maken. (les gehad in php), Het is ook wel makkelijk met kleine- =>middel- grote databases.

Even snel dus een goed boek over databases is beter, preciezer en duidelijker.

Transacties: Stel je bent aan het boekhouden.
Dus aanschaf computer € 500,-
Aan kas € 500,-

Nu is de database lekker bezig en maakt record 1 aan. Het tweede record wordt echter niet aangemaakt (gebruiker voert het niet in, computer van gebruiker crasht enz, enz.)
Zonder transacties is je boekhouding niet meer correct terwijl met transacties automatisch het eerste record weer wordt verwijderd. Transacties zijn dus vrij belangrijk

Triggers. Stel ik boek in mijn boekhouding € 500,- af van de kas (=contant geld) Echter ik heb helemaal geen contant geld in kas. Met een trigger kan ik nu een routine schrijven die elke keer als ik de database opdracht geef het saldo van het kasgeldrecord in mijn boekhouding te verlagen, controleert of dit mogelijk is. Ook kun je met triggers altijd unieke serienummers genereren. Ook vrij belangrijk.

Serienummers zonder trigger en transactie.
Probleem 1
- Gebruiker 1 maakt een record aan maar vult geen serienummer in. OOPS. Met trigger: trigger herkend nullveld en vult automatisch het nummer in (of geeft een foutmelding of.....)
Probleem 2
- Gebruiker 1 maakt een record aan en leest het serienummer uit een tabel.
- Gebruiker 2 maakt een record aan en leest het serienummer uit een tabel (dit is dus HETZELFDE serienummer)
- Gebruiker 1 verhoogt het serienummer in de tabel
- Gebruiker 2 verhoogt het serienummer in de tabel
- gebruiker 1 Post zijn record
- Gebruiker 2 post zijn Record.
OOPS serienummer is niet uniek.
Met transacties gebruiker 2 krijgt een foutmelding zodra hij het serienummer verhoogt Met sequences (= een reeks unieke nummers) kun je ervoor zorgen dat het onmogelijk is om twee dezelfde nummers te gebruiken.

Stored procedure. Voer complexe code uit op de database server in plaats van op de clientmachine.
Voorbeeld, geef iedere werknemer die tenminste leiding geeft aan 5 andere werknemers én werkzaam is op de IT afdeling, niet meer dan 3 dagen ziek geweest is en een voornaam heeft die begint met een "A" of een achternaam die eindigt op "berg" een bonus van 10% van zijn jaar salaris.

Zonder stored procedures gaat dit waarschijnlijk een hele hoop netwerkverkeer veroorzaken. Dit zijn heerlijke geneste SQL statements die ofwel een complex SQL statement benodigen ofwel door code op de client verwerkt moet worden. Bij stored procedures blijft alle code en data op de server en is er dus geen sprake van veel netwerk verkeer (in dit geval enkel een OK als de routine klaar is)

Views maak een beeld (=view) van een veel gebruikte query zodat de database server de query alvast kan optimaliseren voor het herhaalde gebruik (=sneller)

VB SELECT * from LINEITEMS where LINEITEM.FACTUURNUMMER=FACTUUR.FACTUURNUMMER
voor de items die op een bepaalde factuur staan.

Daarnaast hebben triggers en stored procedures het voordeel dat de code op de server staat en dus veranderd kan worden zonder de (honderden, duizenden of nog meer) clients te moeten updaten.

De conclusie is dan ook dat je zonder deze dingen niet eens aan een serieuze multi user omgeving moet gaan denken.

MySQL is hier traditioneel heel zwak in vandaar dat het weinig kans maakt om als backend voor "serieuze" toepassingen gebruikt te worden.
Maar alles is relatief en MySQL wordt ook verbeterd dus misschien gaat MySQL wel eens een serieuze contender worden.

[SubSpace]

Transacties worden ondersteund (als InnoDB tabelformaat gebruikt wordt en niet MyISAM), stored procedures, functions en views zijn gepland voor versie 5.0, wat nog wel even duurt.
Ondersteuning voor subqueries komt in versie 4.1, wat ook erg belangrijk is. Dat is eigenlijk de voornaamste reden dat ik voor bepaalde dingen MS SQL Server gebruik.

[Beaves]

Dat is eigenlijk de voornaamste reden dat ik voor bepaalde dingen MS SQL Server gebruik.

Waarom zou je MS SQL gebruiken als je een beetje extra security/feature's nodig hebt als MySQL kan bieden? PostgreSQL is een open source database net zoals MySQL maar dan wel met (bijna) alle feature's die professionele databases zoals MS SQL, Oracle en Sybase bieden. Dus ook met geavanceerde security zaken zoals roll back mogelijkheden etc.

Ik weet eigenlijk geen reden waarom je voor MySQL zou kiezen als je ook kan kiezen voor PostgreSQL, misschien omdat er meer documentatie over MySQL te vinden is?

[ripexx]

Het probleem zit hem voor in de history tussen PHP en MySQL. Door de goede ondersteuning vanuit PHP naar MySQL was het mogelijk om met goedkope hosting een dynamische site op te zetten.

Ik weet niet hoe goed PostgreSQL zal reageren op zo'n grote dataset zoals bijvoorbeeld T.net en ook de afhandeling van de queries zo snel kan doen. Helaas hebben features vaak tot gevolg dat de snelheid iets inzakt.

[berend_engelbrecht]

Subselect is niet een 'beetje features', er zijn best wel veel dingen die je iteratief in je client software (dus traag) moet oplossen als je dat niet hebt. Ook voor ons is dat het voornaamste wat we missen in MySQL.

Van al de andere genoemde features vonden we het juist prettig dat ze er niet inzitten, onze software gebruikt ze niet en het lichte gewicht maakt MySQL in sommige situaties veel sneller dan concurrerende database engines op dezelfde hardware met een identieke dataset (wij ondersteunen Oracle, SQL Server en MySQL in onze software).

Er zijn trouwens ook features die MySQL wel en anderen niet hebben. B.v. het LIMIT statement is heel handig voor het pagineren van recordsets in web software en is op SQL Server niet helemaal en op Oracle helemaal niet op die manier beschikbaar.

[EfBe]

Subselect is niet een 'beetje features', er zijn best wel veel dingen die je iteratief in je client software (dus traag) moet oplossen als je dat niet hebt. Ook voor ons is dat het voornaamste wat we missen in MySQL.

Subqueries zijn erg vaak gewoon middels joins te formuleren. Daarnaast zijn joins vele malen beter te optimaliseren dan subqueries. Ze zijn leuk, subqueries, maar zeker geen 'noodzaak'.

Er zijn trouwens ook features die MySQL wel en anderen niet hebben. B.v. het LIMIT statement is heel handig voor het pagineren van recordsets in web software en is op SQL Server niet helemaal en op Oracle helemaal niet op die manier beschikbaar.

SqlServer kan dit juist helemaal NIET. Oracle heeft nog 'rownum' waarmee je heel makkelijk pages kunt selecteren. SqlServer heeft zo'n feature niet en dan ben je overgeleverd aan bepaalde sql truuks

[florizla]

Ter informatie: in PostgreSQL kan at je beschrijft ook aan: het zit er in als LIMIT en OFFSET...

[Verwijderd]

Dat subselects vaak ook als joint te formuleren zijn klopt. Dat joints beter te optimaliseren zijn dan subselects ook. Echter subselects die als joint te formuleren zijn, zijn niet beter te optimaliseren als je ze ook daadwerkelijk als joint opschrijft. Tenminste de parser zou dit zelf moeten kunnen herkennen en dus uiteindelijk hetzelfde resultaat moeten geven.

B Sql Server ondersteunt inderdaad geen limit of iets dergelijks. Echter je kan natuurlijk "eenvoudig" een stored procedure schrijven die het voor je doet. Is misschien niet zo effectief qua geheugen op je server maar niet moeilijk om te maken (tenminste, ik vond het vrij eenvoudig)

Lees recordset. Skip X records.
Bouw een recordset van Y records.
Dump de eerste recordset en retourneer de tweede.
Tada een limit routine.

Nu heb ik misschien wel teveel data op mijn server in gebruik maar zodra je een sort in je query gebruikt lijkt het mij ook voor MySQL of Oracle onontkoombaar dat ze eerst de complete dataset moeten genereren voordat ze een stuk kunnen retourneren.

Andere oplossing die vaak efficienter is, is trouwens de complete dataset naar de webserver te sturen en die daar te cachen. Hoeft de database maar 1 keer het werk te doen maar dit is natuurlijk afhankelijk van de groote van de recordset én de belasting van de webserver.

[Verwijderd]

De enige reden die ik kan bedenken is dat je dan een hoop PHP programma's zoals forums (fora?) in een keer op je site kan zetten

Scheelt natuurlijk een hoop werk en als de traffic laag is zal het allemaal best werken,

[Verwijderd]

Er is al iets dergelijks op de markt, http://www.emicnetworks.com/. Ik ben momenteel aan het uitzoeken of het iets is, maar 't lijkt er niet op dat ze hun product updaten als er een nieuwe update van mysql uitgebracht is.

[Verwijderd]

Ongelofelijk dat er steeds weer nieuwe versies van MySQL uitkomen. Laten ze maar eerst eens versie 4.1 uit het alpha stadium halen, i.p.v. meerdere halfafgemaakte versies uit te brengen!

[Verwijderd]

Ben benieuwd wat programmeurs nu inelkaar zetten of aan gaan passen en wat het resultaat is.