Kann MySQL Cluster eine Terabyte-Datenbank handhaben?

Ich muss nach Lösungen für die Bereitstellung einer MySQL-Datenbank suchen, die Datenvolumen im Terabyte-Bereich bewältigen und hochverfügbar sein kann (fünf Neunen). Jede Datenbankzeile hat wahrscheinlich einen Zeitstempel und bis zu 30 Gleitkommawerte. Die erwartete Arbeitslast beträgt bis zu 2500 Einsätze/Sek. Abfragen sind wahrscheinlich weniger häufig, könnten aber groß sein (möglicherweise 100 GB Daten), obwohl wahrscheinlich nur einzelne Tabellen betroffen sind.Kann MySQL Cluster eine Terabyte-Datenbank handhaben?

Ich habe MySQL Cluster betrachtet, da dies ihr HA-Angebot ist. Aufgrund der Datenmenge müsste ich Festplattenspeicher verwenden. Realistisch gesehen denke ich, dass nur die Zeitstempel im Speicher gehalten werden können und alle anderen Daten auf der Festplatte gespeichert werden müssen.

Hat jemand Erfahrung mit MySQL Cluster in einer Datenbank dieser Größenordnung? Ist es überhaupt möglich? Wie wirkt sich Disk-basierter Speicher auf die Leistung aus?

Ich bin auch offen für andere Vorschläge, wie man die gewünschte Verfügbarkeit für diese Datenmenge erreichen kann. Wäre es beispielsweise besser, eine Bibliothek von Drittanbietern wie Sequoia zu verwenden, um das Clustering von Standard-MySQL-Instanzen zu handhaben? Oder eine einfachere Lösung basierend auf MySQL Replikation?

Die einzige Bedingung ist, dass es sich um eine MySQL-basierte Lösung handelt. Ich glaube nicht, dass MySQL der beste Weg ist, um mit den Daten umzugehen, mit denen wir es zu tun haben, aber es ist eine harte Anforderung.

Quelle

2009-05-11 Mark

Wenn Sie nach Technologien suchen, sollten Sie einige Projekte in Betracht ziehen, die auf Googles BigTable basieren. HBase von Hadoop und Hypertable sind interessante Projekte zum Betrachten. http://hadoop.apache.org/hbase/ und http://www.hypertable.org/ – Kekoa

Diese Frage kann besser auf serverfault.com gestellt werden. – lothar

Geschwindigkeit, es kann gehandhabt werden. In der Größe ist die Frage nicht die Größe Ihrer Daten, sondern die Größe Ihres Indexes, da die Indizes vollständig in den Speicher passen müssen.

Ich würde gerne eine bessere Antwort anbieten, aber High-End-Datenbank-Arbeit ist sehr abhängig von der Aufgabe. Ich müsste viel mehr darüber wissen, was mit den Daten passiert, um weitere Hilfe zu leisten.

Quelle

2009-05-11 22:17:46

Die Datenbank wird einen Strom von Zeitstempeldaten speichern, die wir bei 50 Hz für eine Anzahl von Orten erhalten, daher die 2500 Einsätze/Sek. Die Konfiguration des Streams kann sich jederzeit ändern, daher könnte es eine variable Anzahl von Float-Werten geben. Der Zeitstempel ist der Primärschlüssel und hat einen Index. Wir nehmen an, dass die Timestamp-Spalte mit dem Rest der Daten auf dem Datenträger im Speicher sein wird. – Mark

Ich würde dann Stapel einfügen. Ein Einsatz/Client/Sekunde für mehrere Zeilen. Durch die einfache Master-Master-Replikation können Sie Failover durchführen und eine Auslastung von 50 Einfügungen/Sekunde problemlos bewältigen. Die einzige wirkliche Frage ist, wie wichtig es ist, zu vermeiden, dass jemals ein Sample verloren geht, und ich vermute, dass Sie mit 2 oder 3 Sekunden verlorener Daten für einen Serverabsturz fertig werden können. Als zusätzlichen Hinweis kann das Partitionieren Ihrer Tabelle nützlich sein, wenn Sie einen anderen Index als den Primärschlüssel haben. Es kann auch Data-Warehouse-Tricks geben, um diese großen Abfragen zu beschleunigen. –

Danke für die Kommentare. Wir dachten, Batch-Einsätze wären der richtige Weg. Ich habe einige Berechnungen mit dem Skript ndb_size.pl durchgeführt und Sie hatten Recht mit der Größe des Index. Der erforderliche Speicher macht die Verwendung von Cluster nicht möglich. Wir haben jedoch heute auch erfahren, dass ein gewisser Datenverlust in Ordnung ist. Wir versuchen nun, wie Sie sagten, einfache Replikation zu verwenden. – Mark

Okay, ich tat lesen Sie den Teil über mySQL ist eine harte Anforderung.

Also, lassen Sie mich zuerst darauf hinweisen, dass die Arbeitslast, über die Sie sprechen - 2500 Inserts/Sek., Seltene Abfragen, Abfragen, die wahrscheinlich Ergebnismengen von bis zu 10 Prozent des gesamten Datensatzes haben - ist für jedes relationale Datenbanksystem nahezu pessimal.

(Dies erinnert mich eher an ein Projekt, vor langer Zeit, wo ich eine harte Anforderung hatte, 100 Megabyte Programmdaten über eine 9600 Baud RS-422-Leitung (auch eine harte Anforderung) in weniger als 300 Sekunden zu laden eine harte Anforderung.) die Tatsache, dass 1kByte/sec × 300 Sekunden = 300kbytes nicht zu kommunizieren schien.)

Dann gibt es den Teil über „enthalten bis zu 30 schwimmt.“ Die Phrasierung legt zumindest nahe, dass die Anzahl der Samples pro Insert variabel ist, was wiederum einige Normalisierungsprobleme nahelegt - oder aber jede Zeile 30 Einträge breit machen und NULLs verwenden muss.

Aber mit allem, was gesagt wird, okay, du sprichst 300Kbytes/sec und 2500 TPS (vorausgesetzt, das ist wirklich eine Sequenz von nicht verwandten Proben). Dies deutet zumindest darauf hin, dass es nicht außerhalb des Bereichs der Möglichkeiten liegt.

Quelle

2009-05-11 23:58:07

Danke für die Kommentare und für das Lehren eines neuen Wortes! (pessimal) Um mit der variablen Anzahl von Samples umgehen zu können, denken wir daran, bei jeder Änderung eine neue Tabelle zu erstellen, da dies nicht zu oft sein sollte. Wir hätten dann eine Nachschlagetabelle, die es Ihnen ermöglichen würde, die passende Datentabelle für einen bestimmten Zeitraum zu finden. – Mark

This article ist wirklich hilfreich bei der Identifizierung, was eine große MySQL-Datenbank verlangsamen kann.

Quelle

2009-05-12 00:01:16

Eventuell Hibernate-Shards ausprobieren und MySQL auf 10 Knoten mit jeweils 1/2 Terabyte laufen lassen, so dass man 5 Terabyte bewältigen kann;) also weit über dem Limit, denke ich?

Quelle

2010-11-23 17:27:02

Kann MySQL Cluster eine Terabyte-Datenbank handhaben?

Antwort

Verwandte Themen