Ich habe viel über die verfügbaren Optionen gelesen. Ich habe auch High Performance MySQL 2nd Edition in die Finger bekommen, das ich sehr empfehlen kann.
Dies ist, was ich geschafft habe, zusammenzusetzen:
Clustering
Clustering im allgemeinen Sinne verteilt die Last auf viele Server, die für eine externe Anwendung als ein Server erscheinen.
MySQL NDB-Cluster
MySQL NDB Cluster ist eine verteilte, speicherinterne, Shared-Nothing-Speicher-Engine mit synchroner Replikation und automatischer Datenpartitionierung (entschuldigen Sie, ich entlehne buchstäblich dem High Performance-Buch, aber sie haben es dort sehr schön formuliert). Es kann für einige Anwendungen eine Hochleistungslösung sein, aber Webanwendungen funktionieren im Allgemeinen nicht gut damit.
Das Hauptproblem besteht darin, dass der Cluster über sehr einfache Abfragen (die nur eine Tabelle berühren) im Allgemeinen auf mehreren Knoten nach Daten suchen muss, wodurch sich Netzwerklatenz einschleichen und die Ausführungszeit für Abfragen erheblich verlangsamen kann. Da die Anwendung den Cluster als einen Computer behandelt, kann sie ihm nicht sagen, von welchem Knoten die Daten abgerufen werden sollen.
Darüber hinaus ist die In-Memory-Anforderung für viele große Datenbanken nicht praktikabel.
Fortlaufender Mammutbaum
Dies ist eine weitere Clustering-Lösung für MySQL, die als Middleware auf dem MySQL-Server fungiert. Es bietet synchrone Replikation, Lastausgleich und Failover. Es stellt auch sicher, dass Anforderungen immer die Daten von der neuesten Kopie erhalten, indem automatisch ein Knoten mit den aktuellen Daten ausgewählt wird.
Ich habe einige gute Dinge gelesen darauf, und insgesamt klingt es ziemlich vielversprechend.
Föderation
Federation ist dem Clustering ähnlich, also habe ich es auch hier gezogen. MySQL bietet Föderation über die Federated Storage Engine. Ähnlich wie die NDB-Cluster-Lösung funktioniert es nur mit einfachen Abfragen gut - aber noch schlechter mit dem Cluster für komplizierte (da die Netzwerklatenz viel höher ist).
Replikation und Lastausgleich
MySQL verfügt über die eingebaute Fähigkeit, Replikationen einer Datenbank auf verschiedenen Servern zu erstellen. Dies kann für viele Dinge verwendet werden - Aufteilen der Last zwischen Servern, Hot-Backups, Erstellen von Testservern und Failover.
Die grundlegende Einrichtung der Replikation umfasst einen Master-Server, der hauptsächlich Schreibvorgänge verarbeitet, und einen oder mehrere Slaves, die nur Lesevorgänge verarbeiten. Eine fortgeschrittenere Variante ist die des master-master Konfiguration, die es ermöglicht, Schreibvorgänge auch zu skalieren, indem mehrere Server gleichzeitig schreiben.
Jede Konfiguration hat ihre Vor- und Nachteile, aber ein gemeinsames Problem ist die Replikationsverzögerung – da die MySQL-Replikation asynchron ist, verfügen nicht alle Knoten zu jeder Zeit über die aktuellsten Daten. Dies erfordert, dass die Anwendung die Replikation kennt und replikationsfähige Abfragen integriert, um wie erwartet zu funktionieren. Für einige Anwendungen mag dies kein Problem sein, aber wenn Sie immer die aktuellsten Daten benötigen, wird es etwas kompliziert.
Die Replikation erfordert einen gewissen Lastenausgleich, um die Last zwischen den Knoten aufzuteilen. Dies kann so einfach sein wie einige Änderungen am Anwendungscode oder die Verwendung dedizierter Software- und Hardwarelösungen.
Sharding und Partitionierung
Sharding ist ein häufig verwendeter Ansatz zum Skalieren von Datenbanklösungen. Sie teilen die Daten in kleinere Shards auf und verteilen sie auf verschiedene Serverknoten. Dies erfordert, dass die Anwendung die Änderung am Datenspeicher kennt, um effizient zu arbeiten, da sie wissen muss, wo sie die benötigten Informationen finden kann.
Es stehen Abstraktions-Frameworks zur Verfügung, die beim Umgang mit Daten-Sharding helfen, wie z. B. Hibernate Shards , eine Erweiterung des Hibernate ORM (das leider in Java ist. Ich verwende PHP). HiveDB ist eine weitere solche Lösung, die auch das Shard-Rebalancing unterstützt.
Andere
Sphinx
Sphinx ist eine Volltextsuchmaschine, die für weit mehr als Testsuchen eingesetzt werden kann. Bei vielen Abfragen ist es viel schneller als MySQL (insbesondere beim Gruppieren und Sortieren) und kann entfernte Systeme parallel abfragen und die Ergebnisse aggregieren - was es bei der Verwendung mit Sharding sehr nützlich macht.
Im Allgemeinen sollte Sphinx mit anderen Skalierungslösungen verwendet werden, um mehr aus der verfügbaren Hardware und Infrastruktur herauszuholen. Der Nachteil ist, dass Sie wiederum den Anwendungscode benötigen, um sich der Sphinx bewusst zu sein, um sie sinnvoll einzusetzen.
Zusammenfassung
Skalierungslösungen unterscheiden sich je nach den Anforderungen der Anwendung, die sie benötigt. Für uns und die meisten Webanwendungen glaube ich, dass Replikation (wahrscheinlich Multi-Master) der richtige Weg ist, wenn ein Load Balancer die Last verteilt. Das Sharding bestimmter Problembereiche (riesige Tabellen) ist ebenfalls ein Muss, um horizontal skalieren zu können.
Ich werde auch Continuent Sequoia ausprobieren und sehen, ob es wirklich halten kann, was es verspricht, da es die geringste Menge an Änderungen am Anwendungscode erfordert.
