MySQL Cluster vs. Oracle RAC

[Verwijderd]

Goedendag,

Ik heb een vraag. Ik ben onze huidige server aan het migreren naar een cluster. Op dit cluster draait mysql cluster 7.1. Helaas is het met mysql cluster niet mogelijk indexen hoger dan 8k te gebruiken in je database. Echter kan je van bv een varchar een text field of blob maken, maar als je daar ook teveel van hebt, wordt het kiezen opsplitsen of naar andere mogelijkheden kijken.

Ik vroeg mij dus eigenlijk af of in dit geval oracle RAC dit wel ondersteund, of zijn er nog andere mogelijkheden?

Alvast bedankt.

[Freeaqingme]

Ik zal meteen toegeven dat me dit boven de pet gaat. Dat gezegd hebbende, je zou eens in #maria op freenode kunnen vragen of dit mogelijk is met MariaDb. MariaDb is in principe een drop-in replacement voor mysql, maar zij hebben heel veel optimalisaties doorgevoerd, nieuwe functionaliteit toegevoegd (ook wat cluster functionaliteit betreft), en beperkingen van mysql opgeheft.

Ik heb geen aandelen in mariadb, maar wellicht kan je daarmee jouw problemen overkomen.

[ Voor 0% gewijzigd door Freeaqingme op 20-09-2010 16:09 . Reden: #mariadb moest #maria zijn ]

[cariolive23]

Wat voor data probeer je te indexeren? varchar en text klinkt als tekst, daar gebruik je full text search voor. Ik mag toch aannemen dat MySQL dan geen beperking heeft op de lengte van de tekst, daar zou je niets aan hebben.

Uiteraard kun je ook naar Sphinx of Lucene kijken, dat zijn echte fts optimalisaties.

RAC is erg fraai en kan erg veel, het kost dan ook vele miljoenen om dat succesvol te implementeren.

[Verwijderd]

Dank voor de reacties,

Het probleem waar ik tegen aan loop is zeg maar error 738 ('Got error 738 'Record too big' from NDB');
Dit schijnt te komen door te veel columns.

[MueR]

Uit pure interesse, hoeveel columns zitten er in die tabel waar je die error op krijgt?

[Verwijderd]

De tabel bestaat uit 43 columns. Is erg veel en zou het zelf ook anders opgezet hebben, probleem is helaas dat deze oude databases toch overgezet moeten worden naar het cluster totdat deze vernieuwd worden

[JaQ]

Verwijderd schreef op maandag 20 september 2010 @ 15:40:
Ik vroeg mij dus eigenlijk af of in dit geval oracle RAC dit wel ondersteund, of zijn er nog andere mogelijkheden?

Alles wat je in een single instance Oracle database kan, kan je ook in RAC. Je moet je echter afvragen of je RAC nodig hebt (RAC = scale out. MySQL cluster is alles behalve scale out).

Ik begrijp niet precies wat je bedoelt met "indexen hoger dan 8k"? .

edit:
even opgezocht wat die error betekent in MySQL. Ik kan bevestigen dat je dit probleem in Oracle niet zou hebben, bijvoorbeeld door een grotere blocksize dan 8k te kiezen. Tevens kan een rij in meer dan 1 block zitten, "row chainging"

cariolive23 schreef op maandag 20 september 2010 @ 16:57:
RAC is erg fraai en kan erg veel, het kost dan ook vele miljoenen om dat succesvol te implementeren.

Wat een onzin. Deze uitspraak kan je niet onderbouwen.

[ Voor 13% gewijzigd door JaQ op 22-09-2010 03:43 ]

[cariolive23]

JaQ schreef op woensdag 22 september 2010 @ 03:39:
[...]

Wat een onzin. Deze uitspraak kan je niet onderbouwen.

Hier een voorbeeldje uit 2007, in USD: http://www.dba-oracle.com...ws_oracle_prices_2007.htm

Dat is exclusief het inrichten en testen van de omgeving, maar inclusief een aantal extra's die je ook nodig hebt. Met korting kwamen ze 3 jaar geleden uit op 1,6 miljoen dollar.

[Verwijderd]

Oke dank voor de confirmatie dat RAC dit wel kan. Weet iemand waarom die indexes bij mysql cluster zo'n groot probleem is? Je zou denken dat ik niet de enigste ben met mysql die een redundant database wil hebben. Je zou toch denken dat meer grote bedrijven hier gebruik van maken? of is de opstap naar RAC dan logisch?

[Xiphalon]

Je weet dat je voor RAC je software moet aanpassen? Je krijgt namelijk gewoon een foutmelding als je met een node praat die down is, dan mag je zelf je transactie terugrollen en opnieuw doen op een andere node.

[JaQ]

cariolive23 schreef op woensdag 22 september 2010 @ 09:10:
Hier een voorbeeldje uit 2007, in USD: http://www.dba-oracle.com...ws_oracle_prices_2007.htm

Dat is exclusief het inrichten en testen van de omgeving, maar inclusief een aantal extra's die je ook nodig hebt. Met korting kwamen ze 3 jaar geleden uit op 1,6 miljoen dollar.

Als je echt leest wat daar staat, dan zie je dat de meerderheid van de kosten niet uit RAC bestaan maar uit andere opties. Bovendien betaald er helemaal niemand in deze wereld list-price. De kosten van RAC zijn in principe 50% hoger dan van een "normale" database. Dat kan wel miljoenen zijn, maar dat hoeft zeker niet.

Anyway, dat is een andere discussie, voor het probleem van TS is RAC helemaal niet nodig.

Verwijderd schreef op woensdag 22 september 2010 @ 13:25:
Oke dank voor de confirmatie dat RAC dit wel kan. Weet iemand waarom die indexes bij mysql cluster zo'n groot probleem is? Je zou denken dat ik niet de enigste ben met mysql die een redundant database wil hebben.

MySQL doet standaard niets wat performance kost (zoals row chaining, meten waar de tijd van je database echt in gaat zitten, integriteit afdwingen, etc.).

Verwijderd schreef op woensdag 22 september 2010 @ 13:25:
of is de opstap naar RAC dan logisch?

Je maakt een stap naar RAC als je hoog beschikbaar wilt zijn (onder strikte voorwaarden wel absoluut dikke kosten aan zitten), of als je meer CPU's tot je beschikking wilt hebben dan in een (relatief goedkope) x86 doos zitten. Dat heeft weinig te maken met de grootte van een rij (of index). Ik denk dat je je eens moet inlezen in wat RAC eigenlijk doet

darkmage schreef op woensdag 22 september 2010 @ 19:38:
Je weet dat je voor RAC je software moet aanpassen? Je krijgt namelijk gewoon een foutmelding als je met een node praat die down is, dan mag je zelf je transactie terugrollen en opnieuw doen op een andere node.

Ook dit is niet RAC gerelateerd. Ja met RAC kan je een sessie laten overfailen naar een andere node. Daar kan je een foutmelding door laten genereren. Op zich is dat niets anders dan iedere andere willekeurige geclusterde database. Als je bijvoorbeeld een mysql cluster (wat eigenlijk multi-master replicatie is, en niets met een cluster te maken heeft) gebruikt, zal je ook je transactie opnieuw moeten uitvoeren. (met overigens een zeer grote kans op data-corruptie).

[cariolive23]

JaQ schreef op vrijdag 24 september 2010 @ 06:18:
Bovendien betaald er helemaal niemand in deze wereld list-price.

Daarom hebben ze in genoemd artikel ook al een flinke korting meegerekend, zie het artikel.

Anyway, dat is een andere discussie, voor het probleem van TS is RAC helemaal niet nodig.

Helemaal mee eens!

[Verwijderd]

Ik weet zeker dat wij geen miljoenen hebben betaald voor een RAC cluster... (Al zijn het wel 3 machines).

[Ford Prefect]

darkmage schreef op woensdag 22 september 2010 @ 19:38:
Je weet dat je voor RAC je software moet aanpassen? Je krijgt namelijk gewoon een foutmelding als je met een node praat die down is, dan mag je zelf je transactie terugrollen en opnieuw doen op een andere node.

Klopt DML failt niet automatisch over, selects gaan gewoon netjes verder op de andere overlevende node(s). Een een rollback voor een transactie hoef je natuurlijk niet zelf te doen. 1 van de overlevende nodes doet netjes de transaction recovery.

[GlowMouse]

NDB is een hele aparte storage engine die zich heel anders gedraagt dan bv. MyISAM of InnoDB. Zonder enige ervaring ga je zeker tegen veel problemen oplopen. Waarom voer je de migratie uit?