MySQL-Partitionierung / Sharding / Splitting – welcher Weg soll gehen?
https://stackoverflow.com/questions/45879
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Wir verfügen über eine InnoDB-Datenbank mit einer Größe von etwa 70 GB und gehen davon aus, dass diese in den nächsten zwei bis drei Jahren auf mehrere hundert GB anwachsen wird.Etwa 60 % der Daten gehören zu einer einzelnen Tabelle.Derzeit funktioniert die Datenbank recht gut, da wir einen Server mit 64 GB RAM haben, sodass fast die gesamte Datenbank in den Speicher passt, aber wir machen uns Sorgen, dass die Datenmenge in Zukunft erheblich größer sein wird.Im Moment denken wir über eine Möglichkeit nach, die Tabellen aufzuteilen (insbesondere diejenige, die den größten Teil der Daten ausmacht), und ich frage mich jetzt, wie das am besten geht.
Die Optionen, die mir derzeit bekannt sind, sind:
- Verwendung der MySQL-Partitionierung, die in Version 5.1 enthalten ist
- Verwendung einer Drittanbieter-Bibliothek, die die Partitionierung der Daten kapselt (z. B. Hibernate-Shards)
- Wir implementieren es selbst in unserer Anwendung
Unsere Anwendung basiert auf J2EE und EJB 2.1 (hoffentlich wechseln wir eines Tages zu EJB 3).
Was würdest du vorschlagen?
BEARBEITEN (11.02.2011):
Nur ein Update:Derzeit beträgt die Größe der Datenbank 380 GB, die Datengröße unserer „großen“ Tabelle beträgt 220 GB und die Größe ihres Index beträgt 36 GB.Während also die gesamte Tabelle nicht mehr in den Speicher passt, passt der Index schon.
Das System funktioniert immer noch einwandfrei (immer noch auf der gleichen Hardware) und wir denken immer noch über eine Partitionierung der Daten nach.
BEARBEITEN (04.06.2014):Noch ein Update:Die Größe der gesamten Datenbank beträgt 1,5 TB, die Größe unserer „großen“ Tabelle beträgt 1,1 TB.Wir haben unseren Server auf einen 4-Prozessor-Rechner (Intel Xeon E7450) mit 128 GB RAM aufgerüstet.Das System funktioniert immer noch einwandfrei.Als nächstes planen wir, unseren großen Tisch auf einen separaten Datenbankserver zu stellen (die notwendigen Änderungen in unserer Software haben wir bereits vorgenommen) und gleichzeitig auf neue Hardware mit 256 GB RAM aufzurüsten.
Dieser Aufbau soll zwei Jahre dauern.Dann müssen wir entweder endlich mit der Implementierung einer Sharding-Lösung beginnen oder einfach Server mit 1 TB RAM kaufen, was uns noch einige Zeit durchhalten dürfte.
BEARBEITEN (18.01.2016):
Seitdem haben wir unsere große Tabelle in einer eigenen Datenbank auf einem separaten Server abgelegt.Derzeit beträgt die Größe dieser Datenbank etwa 1,9 TB, die Größe der anderen Datenbank (mit allen Tabellen außer der „großen“) beträgt 1,1 TB.
Aktuelles Hardware-Setup:
- HP ProLiant DL 580
- 4 x Intel(R) Xeon(R) CPU E7-4830
- 256 GB RAM
Die Leistung ist mit diesem Setup in Ordnung.
Lösung
Wenn Sie glauben, dass Sie an E/A/Speicher gebunden sind, wird die Partitionierung meines Erachtens nicht hilfreich sein.Wie üblich hilft Ihnen zunächst ein Benchmarking dabei, die beste Richtung herauszufinden.Wenn Sie keine Ersatzserver mit 64 GB Arbeitsspeicher haben, können Sie Ihren Anbieter jederzeit um eine „Demoeinheit“ bitten.
Ich würde zum Sharding tendieren, wenn Sie keine aggregierte Berichterstattung über eine Abfrage erwarten.Ich gehe davon aus, dass Sie die gesamte Datenbank teilen würden und nicht nur Ihre große Tabelle:Es ist am besten, ganze Einheiten zusammenzuhalten.Na ja, jedenfalls, wenn sich Ihr Modell gut aufteilen lässt.
Andere Tipps
Sobald die 42-GB-Tabelle nicht mehr in den Speicher passt, werden Sie mit Sicherheit auf Probleme stoßen.Tatsächlich nimmt die Leistung extrem schnell ab, sobald es nicht mehr in den Speicher passt.Eine Möglichkeit zum Testen besteht darin, diese Tabelle auf einen anderen Computer mit weniger RAM zu stellen und zu sehen, wie schlecht sie funktioniert.
Zunächst einmal ist es nicht so wichtig, Tabellen aufzuteilen, es sei denn, Sie verschieben auch einige der Tabellen auf ein separates physisches Volume.
Das ist falsch.Die Partitionierung (entweder über die Funktion in MySQL 5.1 oder dasselbe mithilfe von MERGE-Tabellen) kann erhebliche Leistungsvorteile bieten, selbst wenn sich die Tabellen auf demselben Laufwerk befinden.
Nehmen wir als Beispiel an, dass Sie SELECT-Abfragen für Ihre große Tabelle unter Verwendung eines Datumsbereichs ausführen.Wenn die Tabelle vollständig ist, muss die Abfrage die gesamte Tabelle durchsuchen (und bei dieser Größe kann selbst die Verwendung von Indizes langsam sein).Der Vorteil der Partitionierung besteht darin, dass Ihre Abfragen nur auf den Partitionen ausgeführt werden, auf denen dies unbedingt erforderlich ist.Wenn jede Partition 1 GB groß ist und Ihre Abfrage nur auf 5 Partitionen zugreifen muss, um sich zu erfüllen, ist die kombinierte 5-GB-Tabelle für MySQL viel einfacher zu handhaben als eine riesige 42-GB-Version.
Sie müssen sich fragen, wie Sie die Daten abfragen.Wenn die Möglichkeit besteht, dass Ihre Abfragen nur auf bestimmte Datenblöcke zugreifen müssen (z. B.B. einen Datumsbereich oder einen ID-Bereich), wird sich eine Partitionierung als vorteilhaft erweisen.
Ich habe gehört, dass es immer noch einige Fehler bei der Partitionierung von MySQL 5.1 gibt, insbesondere im Zusammenhang mit der Auswahl des richtigen Schlüssels durch MySQL.MERGE-Tabellen können die gleiche Funktionalität bieten, erfordern jedoch etwas mehr Overhead.
Ich hoffe, das hilft ... viel Glück!
Dies ist ein großartiges Beispiel dafür, was die MySQL-Partitionierung in einem realen Beispiel großer Datenflüsse bewirken kann:
Ich hoffe, es wird für Ihren Fall hilfreich sein.
Vor einiger Zeit habe ich bei einer Microsoft ArcReady-Veranstaltung eine Präsentation über Skalierungsmuster gesehen, die für Sie nützlich sein könnte.Du kannst Sehen Sie sich die Folien an dafür online.
Ich würde mich für MariaDB InnoDB + Partitionen entscheiden (entweder nach Schlüssel oder nach Datum, abhängig von Ihren Abfragen).
Ich habe dies getan und jetzt habe ich keine Datenbankprobleme mehr.
MySQL kann in Sekundenschnelle durch MariaDB ersetzt werden ... alle Datenbankdateien bleiben gleich.
Zunächst einmal ist es nicht so wichtig, Tabellen aufzuteilen, es sei denn, Sie verschieben auch einige der Tabellen auf ein separates physisches Volume.
Zweitens ist es nicht unbedingt der Tisch mit der größten physischen Größe, den Sie verschieben möchten.Möglicherweise haben Sie eine viel kleinere Tabelle, die mehr Aktivität erhält, während Ihre große Tabelle ziemlich konstant bleibt oder nur Daten anhängt.
Was auch immer Sie tun, setzen Sie es nicht selbst um.Lassen Sie das Datenbanksystem damit umgehen.
Was macht der große Tisch?
Wenn Sie es aufteilen möchten, haben Sie mehrere Möglichkeiten:
- Teilen Sie es mithilfe des Datenbanksystems auf (ich weiß nicht viel darüber)
- Teilen Sie es nach Zeilen auf.
- Teilen Sie es nach Spalten auf.
Eine Aufteilung nach Zeilen wäre nur möglich, wenn Ihre Daten leicht in Blöcke unterteilt werden können.z.B.Etwas wie Basislager hat mehrere Konten, die völlig getrennt sind.Sie könnten 50 % der Konten in einer Tabelle und 50 % in einer anderen Tabelle auf einem anderen Computer aufbewahren.
Die Aufteilung nach Spalte eignet sich für Situationen, in denen die Zeilengröße große Textfelder oder BLOBS enthält.Wenn Sie beispielsweise eine Tabelle mit einem Benutzerbild und einem großen Textblock haben, können Sie das Bild in eine völlig andere Tabelle umwandeln.(auf einer anderen Maschine)
Sie unterbrechen hier die Normalisierung, aber ich glaube nicht, dass dies allzu viele Probleme verursachen würde.
Wie üblich hilft Ihnen zunächst ein Benchmarking dabei, die beste Richtung herauszufinden.
Das sagen mir die meisten, also denke ich, dass ich endlich diese Pille nehmen muss ...
Wahrscheinlich möchten Sie diesen großen Tisch irgendwann teilen.Sie möchten es wahrscheinlich auf einer separaten Festplatte speichern, bevor Sie an einen zweiten Server denken.Am bequemsten ist es, dies mit MySQL zu tun.Wenn es dazu in der Lage ist, dann machen Sie es.
ABER
Im Grunde hängt alles davon ab, wie Ihre Datenbank genutzt wird.Statistiken.
