it-swarm.com.de

Skalierbarkeitsbeschränkungen von PostgreSQL und MySQL

Ich habe gehört, dass die Leistung von nicht gesplardeten relationalen Datenbanken wie MySQL oder PostgreSQL über 10 TB hinaus "bricht".

Ich vermute, dass es solche Grenzwerte gibt, da man sich Netezza, Greenplum oder Vertica usw. nicht einfallen lassen würde. Ich möchte jedoch fragen, ob hier jemand einen Verweis auf ein Forschungspapier oder formale Fallstudien hat, in denen diese Grenzwerte quantifiziert werden.

43
Edmon

Es gibt keine einfache Antwort auf Ihre Frage, aber hier sind einige Dinge, über die Sie nachdenken sollten.

Erstens ist die Skalierung nicht das einzige, worüber man sich Sorgen machen muss. Was Sie mit Ihren Daten machen, ist. Wenn Sie 500 Tabellen mit 30 TB Daten) haben und einfach OLTP mit sehr wenig Berichterstellung) arbeiten, werden Sie wahrscheinlich nicht zu viele Probleme haben Es gibt 32-TB-Datenbanken auf PostgreSQL. Gleichzeitig wird sich die Leistung jedoch etwas verschlechtern, da die Festplatte auf alles übertragen werden muss. Wenn Sie über 50 TB Daten verfügen, aber häufig einen Treffer von etwa 100 GB haben, können Sie dies auch Erstellen Sie einen Server mit genügend RAM, um diesen Teil der Datenbank im Speicher zu halten, und Sie sind golden.

Wenn Sie jedoch versuchen, den Modus (häufigster Wert) aus 1 TB Daten zu entfernen, spielt es keine Rolle, welches System Sie verwenden. Dies wird schmerzhaft sein mit oder ohne Scherben. (Bearbeiten: Sharding kann dieses Problem tatsächlich verschlimmern. )

Die Hauptprobleme, auf die Sie mit riesigen Datenbanken unter MySQL und PostgreSQL stoßen werden, sind die Tatsache, dass keine der beiden Parallelen zwischen Abfragen unterstützt. Mit anderen Worten, eine Abfrage wird von einem einzelnen Thread als einzelner Block ausgeführt und kann nicht in Teile zerlegt und separat ausgeführt werden. Dies ist meistens ein Problem, wenn große analytische Abfragen über große Datenmengen ausgeführt werden. Hier kommen Postgres-XC und Green Plum zur Rettung, da sie Speicher von Ausführung trennen und dies auf Koordinatorebene tun können. Beachten Sie, dass Postgres-XC und Green Plum im Wesentlichen intern Sharding verwenden, die Koordinatoren jedoch die gesamte Konsistenz global erzwingen.

Mit Intraquery-Parallelität können Sie die Abfrage aufteilen, verschiedene Prozessoren/Festplatten-E/A-Kanäle Teile davon ausführen lassen und Teile der Ergebnismenge zurückmelden, die zusammengestellt und an die Anwendung zurückgegeben werden sollen. Auch dies ist normalerweise am hilfreichsten bei analytischen und nicht bei Transaktionsverarbeitungslasten.

Die zweite Sache ist, dass einige Systeme wie Vertica oder Greenplum Informationsspalten zusammen speichern. Dies erschwert die Verwendung des Systems aus der Perspektive von OLTP] und verringert die Leistung dort, erhöht jedoch die Leistung für große analytische Workloads drastisch. Dies ist also ein Workload-spezifischer Kompromiss.

Die Antwort ist also, dass Sie , sobald Sie über 1-2 TB in der Größe) stehen, möglicherweise mit einer Zahl konfrontiert werden Dies ist wiederum spezifisch für Datenbanken, Größe der Arbeitssätze usw. An diesem Punkt müssen Sie sich jedoch wirklich für Schneeflockensysteme entscheiden, dh solche, die einzigartig und auf Ihre Arbeitslast zugeschnitten sind.

Dies bedeutet natürlich, dass die Grenzwerte im Allgemeinen nicht quantifizierbar sind.

Bearbeiten: Ich habe jetzt mit einer 9-TB-Datenbank gearbeitet, die eine Mischung aus Entscheidungsunterstützung und Transaktionsverarbeitungs-Workloads in PostgreSQL verarbeitet. Die größte Herausforderung besteht darin, dass Sie bei Fragen, die große Teile des Datensatzes betreffen, eine Weile auf die Antwort warten müssen.

Bei sorgfältiger Beachtung der Grundlagen (einschließlich Indizes, Autovakuum, Funktionsweise auf niedrigem Niveau usw.) und ausreichender Rechenressourcen sind diese jedoch vollständig verwaltbar (und ich schätze, dass sie bis weit in den 30-TB-Bereich in Pg verwaltbar sind).

Edit2: Sobald Sie 100 TB erreicht haben, hängt es von Ihrem Datensatz ab, was funktioniert. Ich arbeite gerade an einem, der nicht in diesen Bereich skaliert, da er zuerst das Limit von 32 TB pro Tabelle in PostgreSQL erreicht.

52
Chris Travers