PDA

Bekijk Volledige Versie : SQL cluster



YardP
06/10/08, 13:45
Hallo,

Momenteel heb ik een website lopen waar erg veel bezoek op zit. Dit bezoek maakt vele acties op de database, waardoor de server geregeld vast loopt. Alle queries zijn al behoorlijk goed geoptimaliseerd en de database is geheel voor eigen gebruik. Nu ben ik aan het zoeken naar een geschikte oplossing voor dit probleem en dan kom ik uit op database clustoring.

Afgelopen weekend heb ik een testcluster laten opzetten met MySQL, maar na wat testen kwam naar voren dat een MySQL cluster niet geschikt is voor complexe queries of queries met JOINS erin. Helaas gebruik ik veel queries met JOINS. Deze queries kan ik helaas niet allemaal omschrijven zodat er geen JOINS meer nodig zijn..

Nu moet ik dus verder zoeken naar andere oplossingen, die voor mij geschikt zijn. Echter weet ik niet waar ik moet beginnen. Hopelijk kunnen jullie mij tips geven wat een goede oplossing voor mij is.

Ik heb de volgende voorwaarden:
-Schaalbaarheid, makkelijk een server/node toevoegen
-Redundant, valt 1 systeem weg, dan moeten de andere het opvangen
-Snel, ook queries met JOINS of een complexere opbouw moeten snel afgehandeld worden.

Dit project heeft nog geen budget, maar dit zal ook niet erg groot worden.

Alvast bedankt voor het advies!

Dreas
06/10/08, 14:31
Heb je veel read of juist veel write acties? Een master-->slave setup kan handig zijn als je veel reads hebt.

YardP
07/10/08, 01:05
Beide acties worden ongeveer evenveel gebruikt. Zo ver ik weet is een master / slave optie ook niet echt schaalbaar? Als ik het goed heb heeft deze oplossing ook te maken met delays, welke ik voor mijn applicatie niet kan gebruiken.

Randy
07/10/08, 01:11
Een Master-slave optie is zeker wel schaalbaar. Ik heb deze onlangs voor een van de grootste webshops van Nederland moeten bouwen. Een proxy, een master server en 2 slaves. Ik moet wel zeggen dat het 80% readq's waren. Er draait nog een single webserver op, dus dat is het volgende dat opgeschaald moet worden. Maar mocht de capaciteit weer een probleem geven, is het enkel een (3e) slave erbij hangen,

wonko
07/10/08, 08:51
heb je info over het aantal Q's per seconde? Over de grootte van je dataset? En wat gebeurt er precies als de database "vastloopt"?

YardP
07/10/08, 11:38
Op het drukste moment (+-5 uur lang) lopen er ongeveer 1000 queries per seconde, met pieken naar 1500/2000 queries per seconde. De database is ongeveer 5Gb groot.

Vanmorgen zijn we overgestapt naar een zwaardere server, maar dit is helaas maar een tijdelijke oplossing. Als deze server offline valt dan hebben we geen andere server die de load kan opvangen.

Jesperw
07/10/08, 12:03
Op zich zin 2000 query's niet zo bijzonder, dat doe ik ook op een VM. Kijk naast je cluster of master/slave oplossing ook 'ns goed naar je IO. Dat scheelt enorm.

YardP
07/10/08, 12:26
Klopt, die stats waren van de server waar we tot vanmorgen op draaide. Bovendien hadden we limieten ingesteld op de website waardoor er geen leden meer konden inloggen als het druk was. Dus het aantal queries per seconde zal wellicht veel meer zijn.

Waar ik naar op zoek ben is een redundant systeem wat ook schaalbaar is. Wat bedoel je precies met de IO?

opinion
07/10/08, 14:44
Klopt, die stats waren van de server waar we tot vanmorgen op draaide. Bovendien hadden we limieten ingesteld op de website waardoor er geen leden meer konden inloggen als het druk was. Dus het aantal queries per seconde zal wellicht veel meer zijn.

Waar ik naar op zoek ben is een redundant systeem wat ook schaalbaar is. Wat bedoel je precies met de IO?

De I/O is de lees/schrijf snelheid van je disks. Als je een 7.2k rpm SATA2 tegen over 15k rpm SAS zet, dan moet je wel weten wat ik bedoel..

http://nl.wikipedia.org/wiki/I/O

:-)

Bakker ICT
07/10/08, 14:49
Input/Ouput, dus je hardware en hoe je deze hardware gebruikt. RAID, SSD ?

wonko
07/10/08, 14:57
hoe gedraagt de caching zich? is alles voldoende ruim ingesteld (key buffers, sort buffers)... worden er onnodige queries gedaan? Heb je je niet-indexed queries bekeken?

Het lijkt me vreemd dat je met 1000 a 2000 queries per seconde zit voor één site; en dat dit een probleem vormt. Mijn ervaring doet me vermoeden dat je gewoon even moet investeren in een optimalisatie van de code en/of de tuning van de mysql.

YardP
07/10/08, 15:31
Server is goed geoptimaliseerd. De database en het script zijn ook ver geoptimaliseerd. Zo ver ik weet zitten in die server SAS schijfjes in een raid opstelling. Average I/O ligt tussen de -695 en + 1900. Daar moet ik erbij zeggen dat de hoge + wordt veroorzaakt door optimize processen die we 's nachts altijd laten draaien.

Jesperw
07/10/08, 15:57
Da's wel veel IO voor een paar SAS schijven hoor. Met veel geheugen en goede caching kun je dat omlaag brengen en anders moet je even kijken of je ergens snellere storage vandaan kunt trekken.

YardP
07/10/08, 17:03
Zoals vermeld zijn we nu over gestapt naar een betere server, deze is uitgerust met SSD schijven. Van deze server heb ik nog geen statistieken, dus daar valt nog niks over te zeggen.

Als ik het goed heb dan zijn de volgende oplossingen mogelijk:
master/slave constructie
database clustoring

daar heeft master/slave het nadeel dat het niet redundant is als de master weg valt en database clustoring heeft het nadeel dat complexe queries met joins vrijwel onmogelijk zijn.

maxnet
07/10/08, 17:10
Beide acties worden ongeveer evenveel gebruikt. Zo ver ik weet is een master / slave optie ook niet echt schaalbaar? Als ik het goed heb heeft deze oplossing ook te maken met delays, welke ik voor mijn applicatie niet kan gebruiken.

Denk niet dat clusteren een oplossing voor je probleem is.
Je eisen zijn hoog en geen van de veelgebruikte cluster methoden is uberhaupt geschikt om de performance te verhogen van toepassingen die veel writes hebben.


Kortweg bestaan er de volgende methoden:

- Asynchroon (MySQL replicatie, PostgreSQL met Slony, etc.)

Mutaties worden naar de overige servers doorgestuurd, er wordt niet gewacht tot deze overal verwerkt zijn.
De gegevens op de verschillende systemen kunnen dus iets achter lopen (delay).


- Synchroon (PostgreSQL met pgpool)

Mutaties worden op alle servers tegelijk uitgevoerd, en er wordt gewacht tot alle servers deze verwerkt hebben.
De performance van writes is die van de traagste server in het cluster..


- Gedistribueert

Een deel van de gegevens staat op server 1, een ander deel op server 2, etc.
Indien je gegevens nodig hebt die op meerdere systemen verspreid staan, wordt het er niet sneller op.
En met veel joins is dat risico zeker aanwezig.




Zo ver ik weet zitten in die server SAS schijfjes in een raid opstelling. Average I/O ligt tussen de -695 en + 1900.


IO is erg hoog, terwijl je database slechts 5 GB is.
Zorg dat er voldoende geheugen in de server zit (denk aan 8-16 GB).

YardP
09/10/08, 15:23
Ik ga eens kijken of we het geheugen wat kunnen uitbreiden. Met een test op internet kwam al naar voren dat er wellicht meer geheugen in moet, maar ik weet niet hoe betrouwbaar deze test is.

Voor de nieuwsgierigen is dit de link naar die test/calculator (http://www.slayit.com/mysqlcalc.php)

Ik ben zojuist op software van continuent gestuit.

Linkje naar de homepage (http://www.continuent.com/)
Linkje naar een pdfje met wat key notes (http://www.continuent.com/images/stories/whitepapers/mysql/Continuent%20unicluster%20for%20MySQL%20-%20Overview.pdf)

Wellicht is dit een oplossing voor mij. Zoals ik het begrijp is dit een manier om database servers te loadbalancen. Zodra er een write query wordt uitgevoerd, dan stuurt de loadbalancer deze query naar alle nodes. Zodra er een read query wordt uitgevoerd, kijkt de loadbalancer welke server de minste processen in de wachtrij heeft staan.

Tevens is deze oplossing uitgerust met wat handige technieken. Servers kunnen zonder probleem uit het cluster gehaald worden voor onderhoud, na het terugplaatsen zal hij weer automatisch gesynct worden met de rest. Bovendien wordt een server automatisch bijgewerkt/gesynct als hij even fout zit. Er zullen nog meer handige technieken in verwerkt zijn, maar dit waren voor mij de belangrijkste.

Is er iemand bekend met deze software?

jinxedworld
09/10/08, 15:40
Is er iemand bekend met deze software?

Yups, ik ken de software van Continuent, en heb veelvuldig contact met hun salesafdeling gehad. Het is een erg mooi product wat ze neerzetten! Enige nadeel is het prijskaartje voor hun UniCluster omgeving. De opensource variant Sequoia is ook prettig, maar een pain in the *ss om op te zetten. Een nieuwe database erin hangen is ook niet iets wat je zomaar even doet, aangezien je een virtuele database aanmaakt in de configs, en niet in 1 config file maar in een hele zooi. Gebruiksvriendelijk is het allemaal niet. Maar als je tijd over hebt om het allemaal uit te pluizen, doen! Is een erg mooie multi-master setup! :thumbup:

Bakker ICT
09/10/08, 15:46
Aan welke richting kwa prijs moet je dan denken?

maxnet
09/10/08, 16:57
Wellicht is dit een oplossing voor mij. Zoals ik het begrijp is dit een manier om database servers te loadbalancen. Zodra er een write query wordt uitgevoerd, dan stuurt de loadbalancer deze query naar alle nodes. Zodra er een read query wordt uitgevoerd, kijkt de loadbalancer welke server de minste processen in de wachtrij heeft staan.


Voor het loadbalancen van read queries is dat inderdaad een mogelijke optie.
Maar als je inderdaad maar liefst 50% write queries hebt, zoals je eerder suggereerde, dan wordt het er niet sneller op.
Die gaan dan zo snel als de traagste node uit het cluster.



Aan welke richting kwa prijs moet je dan denken?

Inclusief service contract en MySQL enterprise licentie $ 3600 / CPU / jaar.

YardP
10/10/08, 01:20
Voor het loadbalancen van read queries is dat inderdaad een mogelijke optie.
Maar als je inderdaad maar liefst 50% write queries hebt, zoals je eerder suggereerde, dan wordt het er niet sneller op.
Die gaan dan zo snel als de traagste node uit het cluster.

We hebben het aantal read en write queries nog eens geanalyseerd, er is een verhouding van 1:2.5 (W/R). Naar mijn idee moet het nog geen probleem zijn om hier een cluster voor op te zetten?


Yups, ik ken de software van Continuent, en heb veelvuldig contact met hun salesafdeling gehad. Het is een erg mooi product wat ze neerzetten! Enige nadeel is het prijskaartje voor hun UniCluster omgeving. De opensource variant Sequoia is ook prettig, maar een pain in the *ss om op te zetten. Een nieuwe database erin hangen is ook niet iets wat je zomaar even doet, aangezien je een virtuele database aanmaakt in de configs, en niet in 1 config file maar in een hele zooi. Gebruiksvriendelijk is het allemaal niet. Maar als je tijd over hebt om het allemaal uit te pluizen, doen! Is een erg mooie multi-master setup!

Zelf heb ik geen kennis in huis om een server op te zetten, dus dat laat ik aan de hoster over ;). Wat zijn je bevindingen over de documentatie die er te vinden is? Heb je enig idee hoeveel tijd een basis installatie in beslag neemt?


Inclusief service contract en MySQL enterprise licentie $ 3600 / CPU / jaar.

Dat is nog een redelijke prijs vind ik. Heb je toevallig ook de prijzen zonder service contract en/of MySQL enterprice licentie?

Detonator
10/10/08, 11:20
Als je slechts 5GB data hebt en slechts 1-2k q/s, en een server uitgerust met SAS disks trekt dit niet, dan zijn je queries, je tabellen, indexes en je serverconfig absoluut niet geoptimaliseerd.

Je hebt slechts 5GB data en doet vrij veel writes en diskio. Als dit pure logging is, van bijvoorbeeld statistieken, zou je moeten overwegen deze logging te doen naar een MEMORY table (waar bijv. ieder uur een backup van wordt gemaakt naar een disktable zodat je nooit meer dan 1 uur aan stats kwijt raakt).

Je kunt beter je hele systeem en al je queries onder de loep nemen, want als je site nog een factor 5 groeit, wat voor hardware wil je dan plaatsen?