RootForum Community

Hi,

wie macht man mit mysql eine lastverteilung wenn die anwendung theoretisch 500 writes in der sekunde produziert?

ich kenne die möglichkeit der replikation. schreibe-operationen werden dann auf dem master ausgeführt und lese-operationen an die slaves. die slaves ziehen sich die aktuellen daten vom master.

wenn die anwendung hauptsächlich aus der db liest, ist das sicher ganz nett.

wenn aber mindestens genauso oft in die db geschrieben wird, wie von ihr gelesen wird, denke ich an folgende probleme:

1. irgendwann geht der master in die knie, wenn er mit sovielen schreibzugriffen bombardiert wird. gut, das lässt sich bis zu nem gewissen grad mit mehr festplatten, prozessoren und ram kompensieren. aber was ist dann?

2. die slaves müssen von haus aus ne größere hardware haben als der master. wenn ich das richtig verstehe, ziehen die slaves ja nur einfach das binlog vom master. dann werden auf den slaves ja auch sämtliche write-queries ausgeführt (wie auf dem master) + die ganzen read-queries.

3. die slaves werden bei der masse an schreibzugriffen immer dem aktuellen stand des masters hinterher hinken. für das problem hab ich mal was über heartbeat gehört. ist das performant?

wie kann man die obigen probleme umgehen?

Wie ist das mit einem Cluster gelöst? Mal abgesehen davon, dass die Cluster-Engine absolut wenig Features bietet (im Vergleich zu InnoDB).
Habe wo gelesen, dass in einem Cluster alle "Slaves" (nennt man die dort so) die Daten komplett im Arbeitsspeicher halten und nur der Master auf Platte schreibt.
Damit fällt das Problem ja schonmal weg, dass die Slaves die Leistung des Masters + Lesezugriffe haben müssen.

Was gibts sonst für Möglichkeiten? Welche Vor- und Nachteile?

Danke!

MfG

Einige hilfreiche Infos findest Du unter Anderem unter:
http://dev.mysql.com/tech-resources/articles/
http://dev.mysql.com/tech-resources/art ... ing_wp.pdf
http://www.planetmysql.org/

Wenn Du das in einem klassischen Master-Slave-Setup umsetzen willst, kommst Du um den Einsatz eines Hochleistungs-SAN wahrscheinlich nicht drumherum.

Rechenexempel:

Eine moderne Festplatte hat eine Zugriffszeit von 8ms, kann also pro Sekunde 125 Seeks ausführen. Bei 500 INSERTs oder UPDATEs hast Du im schlechtesten Fall 500 * (n + 1) Seeks (n = Anzahl von Nebenbedingungen, die nicht aus dem Cache abgefragt werden können) + die Zeit für's eigentliche Schreiben der Daten.

Um diese Last überhaupt bewältigen zu können, müsstest Du schon auf mindestens 5 Platten verteilt stripen - mit Reserve wohl eher auf 8 (Zeit für's schreiben der Daten, außerdem ist 8 ne Zweierpotenz ). Dazu kommen noch mal so viele Platten für die Ausfallsicherheit (wer will schon ein Produktivsystem mit 8 RAID0-Platten?) - Du müsstest also ein SAN mit 16 Platten ansprechen - und zwar mit derart guter Anbindung, dass auch wirklich parallel 8 Schreibanforderungen an's SAN durchgehen - und das ca. 70 mal pro Sekunde!

Du kannst natürlich mehrere Master aufsetzen, die wiederum Slave der übrigen Master sind - aber wie Du schon richtig gesagt hast, müssen dann alle Server trotzdem das komplette Binlog verfrühstücken. Und in dem Szenario ist noch keine Luft einkalkuliert, die Daten auch lesenderweise wieder abzufragen... bei gleicher Frequenz an SELECTs kommen noch mal so viele Seeks dazu (wobei n hier durch die Verschachtelung mit JOINs bestimmt wird).

stanglwirt wrote:wie macht man mit mysql eine lastverteilung wenn die anwendung theoretisch 500 writes in der sekunde produziert?

Indem man ausreichend Platten bereitstellt, die Writes verzögert und dann batched.

Eine einzelne Platte oder ein Paar in einem RAID-1/RAID-10 kann zwischen 125 und 200 Writes pro Sekunde wegschaffen. FÜr 500 Writes/sec brauchst Du also um die 5 Platten oder Paare, damit Du auch Peaks ausreiten und aus einer degraded-Situation wieder sinnvoll recovern kannst.

Der limitierende Faktor sind idR die Seeks, die sich aus den Writes ergeben und nicht die Datenrate selber. Wenn Du also jeweils 100-1000 Insert/Update/Delete in eine Transaktion batchen kannst, dann kann es sein, daß Du mit einem deutlich kleineren System auskommst.

1. irgendwann geht der master in die knie, wenn er mit sovielen schreibzugriffen bombardiert wird. gut, das lässt sich bis zu nem gewissen grad mit mehr festplatten, prozessoren und ram kompensieren. aber was ist dann?

Dann kann man nur versuchen, zu partitionieren, also das Problem auf n Datenbanken zu verteilen, von denen jeder für ein Teilproblem zuständig ist. web.de macht das zum Beispiel auf eine Weise, die deutlich sichtbar ist: Nach dem Login wirst Du auf einen Cluster und in dem Cluster auf ein Frontend redirected, etwa https://freemailng2402.web.de. Hier bist Du also User der Datenbank 24 (die für die Daten von ca. 1 Mio User zuständig ist) und Frontend-Node 02 (von 4-6 pro Datenbank, je nach Alter der Maschinen).

In einer Lookup-Datenbank, die kaum beschrieben wird und oft repliziert werden kann, werden Username, Paßwort und Clusternummer für jeden User gespeichert. Beim Login wird die für den Benutzer zuständige Clusternummer aus dieser Verteil-Tabelle geholt.

dann werden auf den slaves ja auch sämtliche write-queries ausgeführt (wie auf dem master) + die ganzen read-queries.

Nicht nur das: Auf dem Cluster müssen diese Writes aus dem Binlog noch dazu SERIELL abgearbeitet werden, also unter Verlust der Concurrency und alle auf einer CPU. Die Art und Weise wie MySQL bis 5.0 Replikation implementiert, erzwingt das.

3. die slaves werden bei der masse an schreibzugriffen immer dem aktuellen stand des masters hinterher hinken. für das problem hab ich mal was über heartbeat gehört. ist das performant?

heartbeat löst ein anderes Problem.

Wie ist das mit einem Cluster gelöst? Mal abgesehen davon, dass die Cluster-Engine absolut wenig Features bietet (im Vergleich zu InnoDB).
Habe wo gelesen, dass in einem Cluster alle "Slaves" (nennt man die dort so) die Daten komplett im Arbeitsspeicher halten und nur der Master auf Platte schreibt.

Im Cluster gibt es keinen Master.

Cluster besteht aus Storage Nodes, die Daten enthalten (sie führen den ndbd aus) und SQL-Nodes, die Queries bearbeiten (sie führen den mysqld aus).

Daten werden in den ndbds gespeichert, also im Hauptspeicher der Maschine. Daten werden dabei repliziert und mindestens zweimal auf zwei verschiedenen Nodes des Cluster gehalten.

Jeder ndbd führt regelmäßig einen Dump der Daten auf Platte durch (fährt einen global Checkpoint GCP) und führt außerdem ein Log von Deltas gegenüber dem letzten GCP, den Local Checkpoint. Das sind aber alles sequentielle Writes, die sehr viel schneller durchgeführt werden können als die Seeks, die eine normale mysqld ausführt.

Tabellen werden im Cluster nicht nur repliziert, sondern auf fragmentiert. Dadurch können Tabellen größer werden als der Hauptspeicher einer ndbd Node. Es kann also sein, daß die ungeraden Zeilen einer Tabelle t auf ndbd Node 1 liegen, die geraden Zeilen aber auf ndbd Node 3.

Cluster ist, weil es sich um eine In-Memory-Datenbank handelt, sehr schnell: Es müssen ja niemals Daten von der Platte geladen werden. Cluster ist, weil es sich um eine verteilte Datenbank handelt, sehr langsam: Daten müssen für eine Join-Operation zwischen der mysqld-Node und mehreren ndbd-Nodes transferiert werden und dabei spielt Netzwerk-Latenz eine entscheidende Rolle.

Oder in anderen Worten, das Verhalten von Cluster ist stark von der Art der Queries abhängig und ohne eine genaue Planung und Analyse nur schwer vorhersagbar.

Hy,
"der Gott hat gesprochen" (kleiner Spaß an Rande).

Mal ne Frage am Rande: Du sprichst Web.de an, nehmen wir das mal als Beispiel. Gehst du davon aus, dass die eine MySQL-Datenbank einsetzten? Dann stellt sich mir aber schon die Frage: Haben die einfach ziemlich viele Datenbankserver in Einsatz die alle andere Daten speichern (also die Paritionierung wie du sie beschrieben hast) und nur wenig replizieren müssen, oder gehst du davon aus das die einen Cluster aufgesetzt haben.

Allgemein (ich habe es ehrlich gesagt auch nur kurz angelesen) fällt mir auf, das der MySQL-Cluster schon ziemliche Grenzen hat: Wenn ich das richtig sehe fehlen zum Beispiel foreign-keys.

Was ist zum Beispiel mit Wikipedia, ich kenn zwar die kurze Serverbeschreibung versteh es aber nicht ganz: Seh ich das richtig: Die haben MySQL in Einsatz und einen master-Server. Mit dem synchronisieren x Slaves. Alle Leseanfragen werden an die Slaves gestellt nur die Schreibanfragen (die ja bei wikipedia vergleichsweise selten sind) werden an den Master gestellt. Stimmt das soweit?

Gruß derweil
TO

theomega wrote:Mal ne Frage am Rande: Du sprichst Web.de an, nehmen wir das mal als Beispiel. Gehst du davon aus, dass die eine MySQL-Datenbank einsetzten?

web.de setzt historisch Oracle-Datenbanken ein (in http://kris.koehntopp.de/artikel/linuxtag/ aber nicht namentlich erwähnt) und zwar früher auf DL380-Maschinen von HP mit zwei MSA30-Arrays pro Server. Der Grund für die fetten Arrays ist weniger Platzbedarf als der Zwang eine große Anzahl von Spindeln bereistellen zu müssen um die Seeks zu schlucken. Beim Ausfall einer solcher Maschine kam auf http://status.web.de die bekannte Meldung mit dem Text "weniger als fünf Prozent unserer User betroffen" - nämlich alle, deren Daten auf einem solchen Datenbank-Knoten liegen (etwa 1 Mio von mehr als 20 Mio Accounts).

Die Freemail-Datenbank etwa hinter Cluster 24 wäre vor zwei oder drei Jahren eine solche Maschine gewesen. Da DL380 jedoch im Speicheradreßraum begrenzt sind, hat man danach mit DL585 mit bis zu 64G Speicher experimentiert. Solche Maschinen können bis zu fünf DL380 konsolidieren und haben durch den größeren Adreßraum trotzdem noch genug Speicher, um die Anzahl der Seeks im System drastisch zu reduzieren (etwa um den Faktor (!) 300, es findet ein Übergang von einem I/O-begrenzten System zu einer speichergesättigten CPU-begrenzten System statt, die verbleibenden Plattenzugriffe sind alle Writes). Das hat jedoch den Nachteil, daß ein Ausfall einer solchen Maschine nun 25% aller Benutzer betrifft, weswegen einerseits der Meldungstext geändert werden mußte ("einen Teil unserer Benutzer" ohne Spezifikation) und man mit Oracle RAC experimentieren mußte.

Wie die Entwicklung derzeit aussieht ist mir nicht im Detail bekannt.

Neuere Projekte bei web.de setzen zum Teil MySQL ein, ebenfalls auf 64 Bit-Hardware aus der DL 585/385-Klasse.

Dann stellt sich mir aber schon die Frage: Haben die einfach ziemlich viele Datenbankserver in Einsatz die alle andere Daten speichern (also die Paritionierung wie du sie beschrieben hast) und nur wenig replizieren müssen, oder gehst du davon aus das die einen Cluster aufgesetzt haben.

Eingesetzt werden historisch Oracle-Datenbankserver mit Cold Standby bzw. Oracle Replikation. Mein letzter Stand hinsichtlich RAC war, daß die Erfahrungen sehr durchwachsen sind. Mir ist nicht bekannt, daß man dort Clusterarchitekturen einsetzen würde. Das würde der generellen Designphilosophie bei web.de auch widersprechen: Das ganze System web.de ist eine Ansammlung von lose gekoppelten, asynchron zusammenarbeitenden, massiv parallen Diensten wie etwa in http://blog.koehntopp.de/archives/1349- ... leout.html beschrieben. Cluster sind jedoch nichts anderes als zentrale, synchrone Systeme mit zusätzlichen Latenzproblemen. Cf dazu auch http://radar.oreilly.com/archives/2006/ ... _1_se.html, wo es heißt

Like everybody else, we started with One Database All Hail The Central Database, and have subsequently been forced into clustering. However, we've eschewed any of the general purpose cluster technologies (mysql cluster, various replication schemes) in favor of explicit data partitioning. So, we still have a central db that keeps track of where to find what data (per-user, for instance), and N additional dbs that do the heavy lifting. Our feeling is that this is ultimately far more scalable than black-box clustering.

Allgemein (ich habe es ehrlich gesagt auch nur kurz angelesen) fällt mir auf, das der MySQL-Cluster schon ziemliche Grenzen hat: Wenn ich das richtig sehe fehlen zum Beispiel foreign-keys.

Was willst Du mit Foreign Key Checks, wenn Du sowieso schon ein Performance-Problem hast? Foreign Key Checks sind Integritätsprüfungen, die an zentraler Stelle durchgeführt werden, also an der Stelle, an der Leistung am teuersten ist und am schwierigsten skaliert werden kann. Besser ist es, zu versuchen, mit den Fehlern zu leben wo möglich (siehe den Scaleout-Artikel von mir, den ich weiter oben referenziert habe) und die notwendigen und wirklich unverzichtbaren Integriätsprüfungen an der Peripherie zu machen, wo CPU um ein vielfaches leichter zu bekommen und zu skalieren ist.

Alle Leseanfragen werden an die Slaves gestellt nur die Schreibanfragen (die ja bei wikipedia vergleichsweise selten sind) werden an den Master gestellt. Stimmt das soweit?

Ja. Wenn Du mehr wissen willst, redest Du am Besten mit domas in freenode:#mysql bzw. #wikimedia-tech (Domas Mituzas). Domas ist MySQL-Mitarbeiter und arbeitet außerdem aktiv bei der Wikimedia/Wikipedia mit. Er ist für deren Architektur verantwortlich.

Hy,
sorry wenn ich so dämlich frage, aber es stellt sich mir da doch eine Frage:
Das mit der Partitionierung ist ja gut und schön wenn du bestimmte Fälle bei Freemail beschreibst. Aber es gibt doch auch ganz viele (stellenweise würde ich sogar sagen ein großteil) der Fälle wo du nicht einfach einen Schnitt ziehen kannst und die einen Daten auf den einen Server und die anderen daten auf den anderen Server packen kannst. Meistens geht es deshalb doch nicht weil ich in den Queries Joins drin habe und die Daten von zwei Systemen benötige.

Kleines Beispiel (an dem ich zu kämpfen habe):
Es existiert eine Tabelle mit Themen (threads) (simpler Fall, eine ID und ein TextFeld für den Titel). Zu jedem Thema gehören verschieden viele Beiträge (posts) (simpler Fall, eine ID, einen verweis auf die threadid und den eigentlichn text). Zusätzlich gibt es noch eine Tabelle mit Benutzern (simpler Fall, eine ID und ein benutzername).
Es soll nun festgehalten werden wann welcher Benutzer welchen Thread zum letzten mal besucht hat. Also eine Tabelle mit threadid,userid,und einer timestamp. Performance-Technisch ist das vergleichweise kritisch: Bei ungefähr 1 Mio Beiträgen und 100.000 Benutzern macht sehr viele Zielen die theoretisch vorhanden sein könnten. Auch gut gesetzte Idizies bringen da nicht viel, es sind einfach sehr viele Zeilen. Also hätte ich gerne die eigetnlichen Daten (threads, posts, users) von der "Letzter Besuch"-System getrennt und auf zwei Server gespielt.
Das führt aber zu ziemlichen Problemen: Was ist wenn ich zum Beispiel die liste aller Threads ausgeben will mit dem Datum des lezten Besuches? Wenn es nur ein Server wäre, wäre das ein simpler Join, aber wenn ich die Daten getrennt habe kann ich ja nichtmehr joinen.

Oder habe ich das ganze konzept falsch verstanden?

War jetzt nur ein Beispiel, aber mir fallen einige von dieser Kategorie ein.

Gruß und Danke für die Zeit
TO

theomega wrote:Kleines Beispiel (an dem ich zu kämpfen habe):
Es existiert eine Tabelle mit Themen (threads) (simpler Fall, eine ID und ein TextFeld für den Titel). Zu jedem Thema gehören verschieden viele Beiträge (posts) (simpler Fall, eine ID, einen verweis auf die threadid und den eigentlichn text). Zusätzlich gibt es noch eine Tabelle mit Benutzern (simpler Fall, eine ID und ein benutzername).
Es soll nun festgehalten werden wann welcher Benutzer welchen Thread zum letzten mal besucht hat.

Manchmal ist es schwierig, richtig herum zu partitionieren, das ist richtig.

Aber in Deinem Beispiel ist das irgendwie nicht der Fall. Du kannst doch leicht eine Kopie eines relevanten vertikalen Auszuges der Benutzertabelle auf jedem Shard (jeder Partition) bereit halten. Das Sharding machst Du dann nach Threads, etwa threadid%anzahl der server. Du kannst dann auf jedem Shard vorgerechnete Subsets speichern (also ein 1:n benutzerid 1->n threadid, datum).

Das dann von allen Servern für eine spezische Benutzerid runterzuladen ist für den einzelnen Server in PK Lookup, also quasi kostenfrei - der Client haut sich das in einen Hash und ist fertig (also quasi ein remoter UNION ALL, weil es sich ja um eine Partition handelt). Dort stehen die Daten dann in Memory zur Weiterverarbeitung zur Verfügung.

Das ist nichts anderes als was die Datenbank intern gemacht hätte, nur in die Applikation rausgezogen - halt ein applikationsseitiger Hash-Join (Hash-Joins sind sowieso ohne zu große Mehrkosten auf der Anwendungsseite emulierbar).

Das führt aber zu ziemlichen Problemen: Was ist wenn ich zum Beispiel die liste aller Threads ausgeben will mit dem Datum des lezten Besuches?

Dann versuchst Du eine Enumeration auf einem sehr großen Datenbestand. Das ist fast niemals eine gute Idee (Warum glaubst Du ist auf allen größeren IRC-Servern /list ohne weitere Bedingung disabled? Aus genau demselben Grund).

Wenn Du für einen Benutzer eine Liste der jeweils ersten neuen Postings haben willst (also für eine Benutzerid mit dem Lastlogin-Datum d die minimale ID, deren Postingdate größer ist das d), dann ist das relativ gut zu sharden, weil man die Resultate einfach im den applikationsseitigen Hash mergen kann. Du kriegst, wenn Du das asynch machst, sogar eine Paralleisierung hin. Teuer ist das in einem System mit vielen Threads aber sowieso, drum würd ich das nur bei Threads machen wollen, die der Benutzer subscribed hat, um den Resultset weiter einzuschränken.

Edit: Woher der Begriff "Sharding" kommt

@ isotopp.

vielen dank für die ausführlichen erläuterungen.

wenn ich das fazit richtig verstehe, wärst du bei einer anwendung mit vielen writes für einen cluster und wenn es dann zu performance-problemen kommt, für eine aufteilung der anwendung?

gibt es eigentlich infos wann mysql 5.1 kommt? da sollen sich ja in sachen cluster und replikation weitere möglichkeiten ergeben?

stanglwirt wrote:gibt es eigentlich infos wann mysql 5.1 kommt? da sollen sich ja in sachen cluster und replikation weitere möglichkeiten ergeben?

Produktankündigungen der MySQL AB erfolgen nicht durch Consultants in Threads in Webforen.

ok letzte blöde fragen:

1. ist es denn bei einer replikation möglich, die slave-server nur memory-tabellen benutzen zu lassen, statt den original-tabellen-typ des masters?
d.h. auf dem master wird auf disk geschrieben, die slaves ziehen sich das zeug, schreiben bei sich selbst jedoch nicht auf platte sondern nur in den hauptspeicher.

2. das backup eines clusters hab ich nicht richtig verstanden. Es ist doch so, daß auf jedem datenknoten ein teil der daten gespeichert wird. jetzt hat der cluster selbst eine backup funktion (start backup o.ä.).
damit wird doch auf jedem knoten nur der eigene teil der daten gespeichert oder? in welcher form geschieht das? ich denke mal, das sind keine dump-dateien die sich bei bedarf einfach (evtl. woanders) einspielen lassen.
wenn doch, ok super, wenn nein, wie erreicht man ein *komplettes* backup der cluster-daten, wenn möglich mittels einfacher dump-datei? bleibt da wirklich nur wieder, die anwendung anzuhalten, und mit mysqldump alles auszulesen?

danke!

stanglwirt wrote:1. ist es denn bei einer replikation möglich, die slave-server nur memory-tabellen benutzen zu lassen, statt den original-tabellen-typ des masters?

Tabellen können auf einem Slave eine andere Engine benutzen als auf dem Master. Für Memory-Tabellen mußt Du die entsprechenden Größenlimits passend setzen.

2. das backup eines clusters hab ich nicht richtig verstanden.

Es ist in http://dev.mysql.com/doc/refman/5.0/en/ ... ackup.html, speziell http://dev.mysql.com/doc/refman/5.0/en/ ... store.html beschrieben.

stanglwirt wrote:ist es denn bei einer replikation möglich, die slave-server nur memory-tabellen benutzen zu lassen, statt den original-tabellen-typ des masters?

Vorsicht, die MEMORY-Engine kann mit bestimmten Datentypen nicht umgehen (kennt z. B. TEXT und BLOB nicht).

jfreund wrote:

stanglwirt wrote:ist es denn bei einer replikation möglich, die slave-server nur memory-tabellen benutzen zu lassen, statt den original-tabellen-typ des masters?

Vorsicht, die MEMORY-Engine kann mit bestimmten Datentypen nicht umgehen (kennt z. B. TEXT und BLOB nicht).

Und behandelt - genau wie Cluster bis einschließlich 5.0 - VARCHAR wie CHAR.

ich habe mal eine frage die hier ganz gut reinpasst. ich habe auch eine anwendung, die sehr viele daten ständig aktualisieren muss. ich bin derzeit am überlegen den db-server auf mehrere raid-platten umzurüsten. jedoch frage ich mich, ob es nun wirklich an der festplatte liegt (mein system derzeit: last ist zwischen 3 und 5, cpu 50% idle, auf dem server läuft nur die DB!)

woran kann man sehen, dass die festplatte den flashenhals darstellt?

ach und ihr habt hier von "writes" gesprochen. was genau zählt als write? ist das eine zeile in der db die geschrieben werden muss oder eine komplette update-anfrage?

evgueni wrote:woran kann man sehen, dass die festplatte den flashenhals darstellt?

An "iostat -x 1", %util

ach und ihr habt hier von "writes" gesprochen. was genau zählt als write?

Ein Write. Also ein Schreibzugriff auf die Festplatte.

danke!

%util liegt bei mir bei etwa 10 bis 15. das ist also wohl nicht so kritisch?

was könnte es denn noch außer cpu und festplatte sein? ich verstehe das jetzt wirklich nciht mehr.. cpu ist nicht voll, festplatte ist nicht voll, und der server ist aber trotzdem voll ausgelastet

Weitere Ursachen können beispielsweise ein suboptimales Filesystem oder ein überlastetes PCI-BUS oder...

gibt es denn zu diesem zwecke irgendwelche analysetools?