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)
[Reactie gewijzigd door Ariejan op woensdag 15 februari 2012 16:10]
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.
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.
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.
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 282252 op woensdag 15 februari 2012 16:18]
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.
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 woensdag 15 februari 2012 17:00]
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?
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.MySQL zou sowieso een stuk sneller zijn als ze MyISAM dumpen...
Kom op nou 30GB in één bestand?
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 woensdag 15 februari 2012 19:44]
Voor mij met duizenden queries per seconde, is MyISAM prima.
[Reactie gewijzigd door Paul - K op woensdag 15 februari 2012 20:10]
MySQL heeft net zoals alle relationele databases table- en row locking mechanismes. In MyISAM is dit standaard table locking zoals je hier kunt lezen.
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..
[Reactie gewijzigd door Jeffrey v. Hees op woensdag 15 februari 2012 22:18]
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 donderdag 16 februari 2012 21:00]
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.
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.
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.
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
