Infrastruktur für High Concurrent, High Write DB

Meine Anforderungen sind:

• 3000 Verbindungen
• 70-85% schreiben gegen lesen

Derzeit wird bei 700 Verbindungen eine besonders große Instanz mit hoher CPU ausgelastet. Alle 8 Kerne sind maximal. Wir denken, es ist die Anzahl der gleichzeitigen Verbindungen, da der Speicher in Ordnung ist. Das Schreiben selbst ist sehr einfach (Validierungen verlangsamen Dinge). Um auf 3000 zu skalieren, müssen wir zu mehreren Servern gehen, aktuelle Optionen:

• MySQL-Sharding
• MongoDB-Cluster
• Kassandra
• Hadoop & MySQL (Hadoop-Caches, Single-Dump zu MySQL)
• MongoDB & MySQL (anstelle von Hadoop verwenden wir Mongo für den Cache)

Um mit dieser Anzahl von Verbindungen fertig zu werden, müssen Sie eine Reihe von Fragen beantworten:

1. Kann MySQL Sharding die gleichzeitigen Verbindungen verarbeiten?
2. Kann ein einzelner Master mit diesen gleichzeitigen Verbindungen umgehen, oder ist ein Multi-Head wie Mongo eine bessere Option?

Ich entschuldige mich, wenn ich mein Problem nicht gut beschreibe. Bitte stellen Sie Fragen.

Wenn Sie MySQL als Hauptdatenbank verwenden, können Sie eine Sterntopologie über MySQL Replication verwenden.

Bevor Sie zu MySQL Replication UGHHH, ROFL und OMG sagen, hören Sie mich an.

Mit einer Sterntopologie können Sie auf einen DB-Server (als Distribution Mster [DM] bezeichnet) schreiben und die SQL-Befehle an mehrere DB-Server senden. Wie richten Sie eine solche DB-Infrastruktur ein?

Hier ist die Beschreibung

Sie haben 5 DB-Server (Server A, B, C, D, E)

Server A

• Im MySQL Replication-Setup wird dies der Master sein
• Spielt eine besondere Rolle als DM
• Master der Server B, C, D, E
• Alle Tabellen verwenden die Speicher-Engine BLACKHOLE (/ dev / null).
• Speichert nur binäre Protokolle
• Bare-Metal-Maschine
• Leistungen
  • Sehr schnelles Schreiben, da alle Tabellen auf dem DM BLACKHOLE verwenden
  • Die Netzwerklatenz ist ein geringeres Problem, da Lesezugriffe 15 bis 30% der DB-Aktivität ausmachen
  • Alle Slaves werden streng vom DM aktualisiert

Server B, C, D, E

• Sklave von A
• Server eine Basis für schwere SELECTs
• Server kann virtuell oder Bare-Metal sein
• Für alle Server, deren Benutzertabellen die Speicher-Engine InnoDB verwenden
  • Es kann als Warm-Standby-DB-Server dienen
  • Nichtintrusive Backups können dagegen ausgeführt werden
• Für alle Server, deren Benutzertabellen die Speicher-Engine MyISAM verwenden
  • Richten Sie mit schreibgeschütztem oprion ein
  • Die Zeilenformate von Tabellen können wiederholt werden, um das Lesen zu beschleunigen

Ich habe bereits Beiträge dazu geschrieben

• /server/264374/mysql-in-star-topology/264444#264444
• /programming/5273043/mysql-in-star-topology/5781504#5781504

Um MySQL Replication in Topform zu halten

• Verwenden Sie MySQL 5.5
• Verwenden Sie die semisynchrone Replikation
• Optimieren Sie InnoDB, um mehr CPUs einzubinden

MySQL Cluster könnte ein anderer Ansatz zum Sharding sein. Überprüfen Sie den Beitrag hier .

Ich bin auch ein großer Fan von Cassandra, aber es hängt stark von Ihrem Datenmodell und den Abfragen ab, die Sie ausführen möchten. Cassandra kann blitzschnell schreiben, weil sie immer sequentiell auf der Festplatte sind.

Wenn Sie mehrköpfig werden (was Sie wahrscheinlich brauchen, wenn Sie wirklich 3K aktive Verbindungen brauchen), würde ich wahrscheinlich Riak oder vielleicht Cassandra anschauen. Es hängt wirklich davon ab, was Ihre App tut, um festzustellen, wie gut diese passen, aber von dem, was Sie beschrieben haben, denke ich, dass es in etwas wie Riak passen würde.

Trotzdem scheint ein Shard-Ansatz ziemlich machbar zu sein, wenn Sie einen guten Weg finden, die Daten zu segmentieren, und den Bedarf an Cross-Shard-Dingen minimieren können. Ich würde mich von allen Ring- / Stern- / MMM-Dingen in MySQL fernhalten und mich einfach an das reine Scherben halten. Wenn Sie bereit wären, Postgres zu verwenden, könnten Sie mit Hilfe von Schemata auf Heroku-Basis ziemlich einfach Prototypen erstellen und dann Datenbanken aufteilen und aufteilen, sobald sie aus einzelnen Knoten herauswachsen.

Oh, und obwohl ich denke, dass Sie versuchen könnten, so etwas vertikal zu skalieren (ein einzelner Knoten, der alle 3K-Verbindungen verarbeitet), glaube ich nicht, dass Sie dies in der Cloud tun können.

Wenn dies eine Option für Ihre spezifische Anwendung ist, können Sie möglicherweise asynchron Daten in Ihre Datenbank schreiben (Warteschlange, Batch-Einfügungen ...) und / oder die vielen Client-Verbindungen von Ihrer Datenbank mit einem vorgelagerten Proxy entfernen .

Mit Sharding können Sie im Allgemeinen gut skalieren (2x db-Server == 2x Verbindungen), aber es hängt stark von der Art Ihres Datasets ab und davon, wie Sie es auf mehrere Shards aufteilen können.

Ich persönlich bevorzuge MongoDB wegen seiner einfachen Administration, Skalierbarkeit und allgemeinen Benutzerfreundlichkeit. Außerdem verwende ich, sofern ich kein RDBMS benötige, ein No-SQL.

Wählen Sie dann die Datenbank aus, die für Ihre Anwendung am sinnvollsten ist. Wenn Sie Transaktionen benötigen oder Ihre App ohne Joins nicht entwerfen können (oder es mit Joins einfach sinnvoller ist), verwenden Sie ein RDBMS (MySQL, PostGres usw.).

Während ich MongoDB persönlich bevorzuge, ist die Vorstellung, dass MySQL eine hohe Transaktionsrate nicht skaliert oder nicht verarbeiten kann, rein falsch. Das Facebook Engineering-Team (und das MySQL-Team darin) geht dabei sehr detailliert vor. Schauen Sie sich auch den Etsy Ops-Teamblog an. Sie lieben auch MySQL.

Schließlich würde ich MongoDB nicht für einen MySQL-Cache verwenden. benutze dafür Memcached.

Redis ist auch ein In-RAM-Schlüsselwertspeicher, der für die Behandlung bestimmter Anwendungsfälle geeignet ist. Es gibt einige Blog-Einträge auf blog.agoragames.com, die einige Anwendungsfälle beschreiben.

Sie sollten auch CouchDB ausprobieren, wenn Sie an No-SQL denken. Beachten Sie jedoch, dass eine regelmäßige Wartung erforderlich ist , um die Festplattenauslastung gering zu halten. (Es tauscht Geschwindigkeit und Bequemlichkeit gegen ...)

Schließlich ist die Kapazitätsplanung nicht leicht vorherzusagen. Sie müssen unter möglichst realistischen Bedingungen testen und darauf vorbereitet sein, anhand der angezeigten Informationen Korrekturen vorzunehmen. Leider ist "Informatik" ebenso Kunst wie Wissenschaft.