2009-04-24 9 views
24

Ich habe eine Web-App mit LAMP. Wir haben in letzter Zeit eine Erhöhung der Belastung und suchen nun nach Lösungen für die Skalierung. Scaling Apache ist ziemlich einfach, wir werden nur mehrere Maschinen haben, die es hosten und round robin den eingehenden Verkehr.Wie skaliere ich MySQL mit mehreren Maschinen?

Jede Instanz von Apache wird jedoch mit MySQL kommunizieren und schließlich wird MySQL überlastet sein. Wie skaliere ich MySQL in diesem Setup auf mehrere Rechner? Ich habe mir schon this angesehen, aber speziell brauchen wir die Updates von der DB sofort verfügbar, also denke ich nicht, dass Replikation eine gute Strategie ist? Dies kann hoffentlich auch mit minimalem Code-Wechsel erreicht werden.

PS. Wir haben ungefähr ein 1: 1 Lese-Schreib-Verhältnis.

Antwort

21

Es gibt nur zwei Strategien: Replikation und Sharding. Die Replikation erfolgt häufig, wenn Sie weniger Schreib- und viel Lesezugriff haben. Sie können also die Lesevorgänge an viele Slaves umleiten, wobei viel Replikationsverkehr mit der Zeit und einer Wahrscheinlichkeit für Inkonsistenz einhergeht.

Mit sharding shard Ihre Datenbanktabellen über mehrere Maschinen (genannt funktionale Sharding), die besonders Joins viel schwieriger macht. Wenn dies nicht mehr passt, müssen Sie Ihre Zeilen auch über mehrere Maschinen hinweg teilen, aber das macht keinen Spaß und hängt von einer Ebene ab, die zwischen Ihrer Anwendung und der Datenbank implementiert ist.

Dokumentorientierte Datenbanken oder Spaltenspeicher funktionieren zwar für Sie, sind jedoch derzeit für OLAP und nicht für OLTP optimiert.

5

Sie denken vielleicht nicht, dass die Replikation nicht die optimale Strategie ist, aber werfen Sie einen Blick auf diese link, die einen ziemlich einfachen und direkten Tipp für die Verwendung der Replikation bietet, um die Last über mehrere Maschinen auszugleichen.

+0

Verbindung ist unterbrochen. – sunnyrjuneja

+0

Den Link aktualisieren –

+1

Broken Link Bro .. – tesmojones

0

Abhängig vom Anwendungs-Backend (d. H. Wie die PKs, Transaktionen und Einfüge-IDs gehandhabt werden), könnten Sie die MASTER-MASTER-Replikation mit verschiedenen auto_increment-Konfigurationen in Betracht ziehen. Dies kann schwierig sein und muss gründlich getestet werden, aber es kann funktionieren.

Im neuen MySQL 5.6 gibt es auch eine GTID (Global Transaction Identifier), die im Allgemeinen hilft, die Replikation synchron zu halten, besonders in diesem Szenario.

0

Nun ... viel Glück skalieren all diese Schreibarbeiten zu einem echten großen Maßstab. Die Datenbank-Engine wird zum Engpass, zu viele Sperren und Puffer mgmt und so Sachen ...

Der einzige Weg, den ich gefunden habe, funktioniert wirklich skalieren, sharding, leider sharding ist nicht für MySQL "out of the box" (wie in einigen NoSQLs wie Mongo). ScaleBase (Disclaimer: Ich arbeite dort) ist ein Hersteller einer kompletten Scale-Out-Lösung eine "automatische Schneidemaschine", wenn Sie möchten. ScaleBae analysiert Ihre Daten und den SQL-Datenstrom, teilt die Daten über DB-Knoten auf, routet Befehle und aggregiert Ergebnisse zur Laufzeit - Sie müssen also nicht!