MySQL Cluster 7.2 moet tegenwicht bieden aan NoSQL

Oracle heeft MySQL Cluster 7.2 uitgebracht. De nieuwe MySQL-versie voor clusteromgevingen biedt een memcached-api en het zou complexe queries sneller kunnen verwerken. Daarmee moet het beter kunnen concurreren met NoSQL.

MySQL Cluster is een door Oracle ontwikkelde versie van de opensource-database MySQL en is geschikt gemaakt om te draaien op diverse servers binnen een cluster. De software is redundant opgebouwd: als één van de servers uitvalt zal het cluster blijven draaien. Ook kan een MySQL Cluster in theorie oneindig worden geschaald dankzij deze 'shared nothing'-architectuur.

Om clusteromgevingen waarin databases op basis van MySQL Cluster draaien beter te laten presteren, heeft Oracle in versie 7.2 ondersteuning voor de memcached-api aan de software toegevoegd. Memcached, dat een bsd-licentie heeft, biedt de mogelijkheid om kleine brokjes informatie met behulp van een hash table op te slaan in ram-geheugen.

Via het memcached-cachingmechanisme, dat onder andere door sites als Facebook, Reddit en Twitter wordt gebruikt, kan de toegang tot databases flink worden versneld. Met de ondersteuning voor de api, die geheel open is, zouden ontwikkelaars MySQL Cluster volgens Oracle naar een zelfde prestatieniveau kunnen tillen als NoSQL-databases.

Oracle belooft in MySQL Cluster 7.2 ook verbeterde prestaties door middel van 'query-lokalisering'. Hierbij zouden complexe queries, waarbij data uit meerdere tabellen wordt opgevraagd, tot zeventig maal sneller verwerkt kunnen worden. De prestatiewinst zou worden behaald door individuele nodes binnen een cluster een groot deel van dergelijke 'cross table'-queries uit te laten voeren voordat het resultaat wordt doorgestuurd naar de server die de query oorspronkelijk kreeg aangeboden.

In MySQL 7.2 moet ook de schaalbaarheid zijn verbeterd. Zo stelt Oracle dat databasenodes binnen een cluster voortaan in meerdere datacenters kunnen staan. Ook is de beheertool MySQL Cluster Manager bijgewerkt. MySQL Cluster kan gratis worden binnengehaald. Wie ondersteuning wil hebben vanuit Oracle zal de buidel moeten trekken: Carrier Grade Edition-supportlicenties beginnen bij 10.000 dollar.

Reacties (27)

[Verwijderd]

Maar ja, het blijft MySQL met zijn rariteiten...

Dat je complexe queries met deze update 70 maal sneller kan uitvoeren verbaast me ook niets, MySQL is/was altijd rete traag met complexe queries. Ikzelf heb het wel eens voor de gein naast PostgreSQL gelegd en PG was toch wel een aardig stuk sneller.

Zelfs hele simple WHERE foo IN (SELECT bar FROM ....) zijn/waren rete traag in MySQL.

ik hoop voor de MySQL lovers dat ze ook eens bitmap indexen gaan ondersteunen..

[Reactie gewijzigd door Verwijderd op 3 augustus 2024 06:17]

[djantje]

Ja klopt, sub-select is extreem traag in MySQL, totdat je de query ombouwt naar een INNER JOIN (die gebruik maakt van een index), dan is de performance prima.

[Verwijderd]

Tegenwoordig niet meer hoor, dat was jaren geleden zo maar MySQL heeft nog steeds de slechte naam. Kijk hier maar eens voor een paar voorbeelden waar subqueries, inner joins en self joins worden geprobeerd.
http://www.xaprb.com/blog...max-row-per-group-in-sql/

Als je vervolgens de subqueries vergelijkt met inner joins, of selfjoins dan zie je dat het tijdsverschil nihil is geworden.

Ook met de MySQL functie explain zul je zien dat sub-select queries tegenwoordig bijna altijd net zo goed geoptimaliseerd kunnen worden als joins. Ik ben geen MySQL fanboy maar subqueries zijn geen probleem meer voor MySQL, het zijn vaker niet-geindexeerde velden in de where clause die de problemen veroorzaken. Explain bewijst dat het executiepad vaak bijna hetzelfde is voor subqueries en joins.

[s.stok]

MySQL zou sowieso een stuk sneller zijn als ze MyISAM dumpen...
Kom op nou 30GB in één bestand?

Als je de niet beschikbare ondersteuning zoals Windowing, Aggregates and custom operators buiten beschouwing laat, presteert MyISAM ver onder de maat.

Alle data word in een één bestand gedonderd, waardoor je maar één update kan uitvoeren en niet zoals je met iedere normaal database systeem en InnoDB gewoon gelijktijdig. Maar met InnoDB heb je weer geen Fulltext search.

Plus nog een paar andere leuke details waar je al heel snel tegen aan loopt met MyISAM, doe maar is voor de grap één index verwijderen. Gaat meneer heel leuk een nieuwe tabel aanmaken en dan alle date overzetten http://www.pfz.nl/forum/t...ql-drop-index-versnellen/

De reden waarom WHERE foo IN (SELECT bar FROM ....) op zijn eigen tabel uitvoeren (oh wacht volgens mij kan dat mij niet eens) traag is, is omdat hij het zelfde bestand moet doorzoeken wat een enorme vertraging oplevert.

Meeste Database systemen verdelen de data zogenaamde in pages die verdeeld zijn in verschillende bestanden. MyISAM is vergelijkbaar met SQLite.

Met InnoDB heb je een aanzienlijk betere snelheid, maar lever je wel in met Fulltext.
Hoe staat het eigenlijk met die Falcon engine waar destijds mee bezig waren?

Ipv een onnodig (duur) alternatief voor NoSQL te maken zouden ze zich is moeten gaan richten op wat echt belangrijk is. Cluster oplossing voor MySQL zijn er al dus waarom zou je nog een alternatief moeten hebben?

NoSQL en een relationele database kunne prima naast elkaar worden gebruikt

[Reactie gewijzigd door s.stok op 3 augustus 2024 06:16]

[fdh]

Ik weet niet of Mysql slechts 1 update tegelijk kan uitvoeren, maar dit zal dan niets te maken met het feit of alles in 1 bestand zit of niet.
Bij een write wordt er gewoon een offset en een range doorgegeven die moet overschreven worrden.

Ook bij het lezen moet men niet het hele bestand gaan inlezen en de meeste databases hebben een caching waarin ze recente gelezen records gaan bewaren.
Dus het lezen van dezelfde records binnen 1 select zal meestal gebeuren uit deze cache, niet van disk.

Bij Oracle databases heb je de mogelijkheid om te gaan werken met bigfile tablespaces die maximaal 8 exabytes groot kunnen zijn (bij een db block size van 32KB).
Denk je nu echt dat ze dit zouden doen als er maar 1 update tegelijk op zo'n file zou mogelijk zijn?

[NTAuthority]

Falcon is na de overname door Oracle stopgezet aangezien het oorspronkelijke doel niet meer 'noodzakelijk was' binnen Oracle (onafhankelijkheid van het eerder door Oracle overgenomen InnoDB-product).

[_Thanatos_]

MySQL zou sowieso een stuk sneller zijn als ze MyISAM dumpen...
Kom op nou 30GB in één bestand?

Ik vind het sowieso aan de database server om te bepalen hoe de tabellen worden opgeslagen. Of dat nou gaat met MyISAM of die andere, of nog een andere, zal me een kontworst wezen. Als ie maar snel is. Ik denk dat het vooral een legacy-dingetje is.

Maar dan nog, er is niets mis met 30GB in een bestand. Vertel es, wat is precies het nadeel van puur het hebben van 30GB in 1 bestand?

Let wel, een virtual machine heeft in z'n disk image ook tientallen gigabytes in 1 bestand. Dat is een hele bewuste keuze.

[Reactie gewijzigd door _Thanatos_ op 23 juli 2024 04:14]

[Paul - K]

INNODB is ook waardeloos als je grotendeels selects uitvoert, ik heb het eens geprobeerd, maar daarna kwam vrijwel alles tot stilstand en leek het net stroop, daarna weer terug gegaan naar MyISAM en alles draaide weer rete snel.

Voor mij met duizenden queries per seconde, is MyISAM prima.

[Reactie gewijzigd door Paul - K op 3 augustus 2024 06:16]

[3raser]

File locking is helemaal niet aan de orde in MySQL, net zoals in Microsoft SQL Server (waar ook je hele database in 1 bestand staat). Ik weet dus niet waar je die wijsheid vandaan hebt, maar het klopt in ieder geval niet.

MySQL heeft net zoals alle relationele databases table- en row locking mechanismes. In MyISAM is dit standaard table locking zoals je hier kunt lezen.

[borft]

maar als je je inner query in een temp table met primary key zet en eraan joined is het wel weer ree te snel. Mysql kan wel snel zijn, alleen het query optimizen is soms een redelijk lastig en handmatig klusje

[Verwijderd]

Maar ja, dan begin je wel alle eigenaardigheden van MySQL te omzeilen om het geheel sneller te maken, iets wat met de meeste queries wel automatisch zou moeten gebeuren als er een betere query optimmer in zou zitten. Zeker die IN query zou toch wel geoptimaliseerd moeten worden. En dan hebben we het nog maar van tabellen met < 2 miljoen records.

[Ariejan]

In den beginne (bij de overname door Oracle) was iedereen bang dat MySQL niet langer gratis beschikbaar zou zijn. Het valt me mee dat deze versie dus gratis beschikbaar wordt. Wel 'n stevig prijskaartje voor de supportlicentie van $10k.

[Reactie gewijzigd door Ariejan op 25 juli 2024 11:28]

[mphilipp]

De community edition is (nog steeds) gratis. De cluster en de enterprise editie zijn nooit gratis geweest. Nu dus ook niet. Je kunt ze downloaden voor een trial, maar na een bepaalde tijd moet je toch echt gaan dokken.

Die enterprise editie is ook niet voor de thuisgebruiker bedoeld. Die heeft daar geen bal aan. Maar MySQL is nog altijd aanzienlijk goedkoper dan Oracle. Qua basisfeatures kan ie ook nog redelijk wedijveren met Oracle. Echter, als je een bedrijfskritische omgeving hebt, wil je kunnen vertrouwen op de stabiliteit van iets als Oracle. Ook de certificatie met producten als SAP is belangrijk.

[locke960]

Laatste link in het artikel, http://www.mysql.com/downloads/cluster/ , is toch echt de cluster versie met gpl licentie.
Waar je voor moet betalen zijn de support en software zoals de cluster manager die niet opens source is. Die dingen dus die je eigenlijk wel nodig hebt als je serieus behoefte hebt aan een cluster.

Het echte voordeel van Open Source natuurlijk niet dat het gratis is. Het voordeel is dat het je afhankelijkheid van de originele leverancier verminderd. Als die plotseling besluit er mee te stoppen kan een ander er tenminste mee verder.

[Mellow Jack]

Ik vind 10k wel weinig voor een bedrijf wat database clusters gaat gebruiken

[pruxor]

Het begint bij 10k hè?

[Mellow Jack]

Dan is het nog weinig... Stel je voor dat je naast je normale systeembeheerders ook nog een specifieke MySQL guru in dienst moet nemen om de cluster te onderhouden, dit zal je met gemak 50 000 euro kosten op jaar basis en dan is de kennis alsnog beperkt (het is en blijft maar 1 persoon.) Dit terwijl je voor 10K (of meer) al de kennis hebt die je ooit nodig zal hebben

[lordfragger]

Maar je hebt nog altijd iemand nodig met genoeg kennis om alle onderhoudsacties uit te voeren. De oracle support cases moeten ook opgevolgd worden, en oracle is nogal sterk in cases zo snel mogelijk terug naar de klant sturen.

Akkoord, het is niet zo duur als een degelijk premium support contract, maar echt goedkoop kan je het nu ook weer niet normen. Grotere bedrijven kijken niet naar zo'n bedragen, maar die zullen ook eerder voor oracle server en oracle rac gaan dan mysql.

[Verwijderd]

ik kies voor nosql voor de document object.. zo dat iedere opdracht verschillend kan zijn voor velden..

voor mij gaat niet op de snelheid maar juist voor de flexibiliteit

ik vindt deze zet dat juist raar.. snelheid owke.. maar goed ze hadden beter kwa structuur kunnen doen..

[_Thanatos_]

Als jij ieder veld verschillen wil kunnen laten zijn, ben je dan niet eerder op zoek naar een XMLDB?

[Exception]

Ik ken XMLDB niet, maar slaat een XMLDB zijn data op als XML? Zoja, dan is dit overhead vergeleken met bijvoorbeeld NoSQL-databases als MongoDB. Deze slaan de data op als BSON (JSON) wat veel minder overhead is dan XML.

[Reactie gewijzigd door Exception op 3 augustus 2024 06:16]

[_Thanatos_]

Nee, de fysieke opslag is natuurlijk een binaire representatie van een XML DOM, maar dat is de kracht juist: je slaat een XML DOM op, met schema-validatie en alles erop en eraan. "velden" (dus tags en attributen) zijn indexeerbaar en je kunt selects doen met XPath. updates gaan met een vergelijkbaar iets.

In je progtaal krijg je een XmlDocument of XmlNode terug, of je taal ze ook noemt. En of het dan daadwerkelijk als textuele xml over de lijn gaat, zal van de implementatie afhangen. XMLDB is nml geen product, maar een techniek, in rijtje van RDBMS en NoSQL.

Bottomline: XML is niet per se tags tussen anglebrackets en escape-hell en verbose namespaces. Het kan ook snel, compact, binair en machine-readable.

[Reactie gewijzigd door _Thanatos_ op 3 augustus 2024 06:16]

[Korben]

XML is alleen hell voor mensen die niet weten hoe ze met een fatsoenlijke API XML kunnen lezen of schrijven, en voor de mensen die moeten omgaan met de 'XML' die dergelijke mensen genereren.

Een XMLDB lijkt me vergelijkbaar met een object database, met als verschil dat de structuur van objecten in een object database simpeler is, en beter mapbaar naar daadwerkelijke objecten in je code. XML heeft weer allerlei onnodige quirks die ofwel moeilijk mapbaar zijn of verloren gaan in het mapping proces. Denk aan attributen en CDATA.

[kwaakvaak_v2]

En toch denk ik dat dit in php webland best een boeiend product kan worden. Ingebouwde memcached met een write back strategy naar tables. Verbeterde clustering, wat hopelijk wat makkelijker te beheren is dan master/slave nu.

Ik vind het zeker wel een boeiend product, en ga hier de komende tijd toch even meespelen.

BTW, ISaFeeliN je kunt de source downloaden en zelf compilen. Moet lukken op een BSD bak lijkt mij. En misschien dat de ports mensen het over hun hart kunnen verkrijgen om dit als binary toe te voegen

Zie http://mysql.com/downloads/cluster/#downloads voor de Community/GA editions en dus ook de source code.

[voodooless]

En hoe zit het met windowing functions, aggregate functions, CTE's en reverse sort indexering? Zijn ze dat allemaal weer vergeten? Allemaal dingen die een "Enterprise" grade database wel zou moeten ondersteunen.

Dennog, mooie vooruitgang van MySQL. Jammer dat het niet allemaal opensource is gebleven. 't Klinkt ook allemaal te mooi om waar te zijn, en gezien de minimiale informatieverstrekking die er is, zal dat ook wel zo zijn. Tijd zal leren hoe mooi het allemaal echt is.

[Beatboxx]

Ik hoop dat Tweakers dit gaat reviewen!

[ISaFeeliN]

Hmm, geen versies voor FreeBSD? Da's jammer .....