Ich habe gehört, dass die Leistung einer relationalen Nicht-Shard-Datenbank wie MySQL oder PostgreSQL über 10 TB hinaus "bricht".
Ich vermute, dass Grenzen als solche existieren, da man sich Netezza, Greenplum oder Vertica usw. nicht ausgedacht hätte. Ich möchte jedoch fragen, ob hier jemand einen Verweis auf ein Forschungspapier oder formale Fallstudien hat, in denen diese Grenzen quantifiziert werden.
Antworten:
Es gibt keine einfache Antwort auf Ihre Frage, aber hier sind ein paar Dinge, über die Sie nachdenken müssen.
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 einfaches OLTP mit sehr wenig Berichterstellung ausführen, werden Sie wahrscheinlich nicht zu viele Probleme haben. Es gibt 32 TB Datenbanken auf PostgreSQL. Gleichzeitig wird sich die Leistung jedoch etwas verschlechtern, da auf allen Datenträgern ein Treffer erzielt werden muss. In ähnlicher Weise können Sie einen Server mit genügend RAM aufbauen, um diesen Teil der Datenbank im Speicher zu belassen, wenn Sie über 50 TB Daten verfügen, aber häufig über eine Treffermenge von etwa 100 GB verfügen.
Wenn Sie jedoch versuchen, den Modus (den häufigsten Wert) aus 1 TB Daten zu entfernen, spielt es keine Rolle, welches System Sie verwenden. Dies kann mit oder ohne Scherben schmerzhaft sein . (Edit: Sharding kann dieses Problem in der Tat verschlimmern. )
Die Hauptprobleme, auf die Sie mit riesigen Datenbanken auf MySQL und PostgreSQL stoßen, sind die Tatsache, dass keine von beiden die Parallelität zwischen Abfragen unterstützt. Mit anderen Worten, eine Abfrage wird als einzelner Block von einem einzelnen Thread ausgeführt und kann nicht in Teile zerlegt und separat ausgeführt werden. Dies ist häufig ein Problem, wenn große analytische Abfragen über große Datenmengen ausgeführt werden. Hier kommen Postgres-XC und Green Plum zum Einsatz, da sie die Speicherung von der 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 durchsetzen.
Mit der Intraquery-Parallelität können Sie die Abfrage auflösen, Teile der Abfrage von verschiedenen Prozessoren / Festplatten-E / A-Kanälen ausführen lassen und Teile der Ergebnismenge zurückmelden, die zusammengestellt und an die Anwendung zurückgegeben werden sollen. Auch dies ist in der Regel eher bei analytischen als bei Transaktionsverarbeitungslasten hilfreich.
Das zweite ist, dass einige Systeme wie Vertica oder Greenplum Informationsspalten zusammen speichern. Dies erschwert die Verwendung des Systems aus OLTP-Sicht und verringert dort die Leistung, erhöht jedoch die Leistung für große analytische Workloads drastisch. Das ist also ein Workload-spezifischer Kompromiss.
Die Antwort lautet also, dass Sie bei einer Größe von mehr als 1 bis 2 TB möglicherweise vor einer Reihe von Kompromissen zwischen Systemen und Workloads stehen. Dies ist wiederum spezifisch für Datenbanken, Größe der Arbeitssets usw. An diesem Punkt müssen Sie sich jedoch wirklich für Schneeflockensysteme entscheiden, dh für Systeme, die einzigartig und auf Ihre Arbeitsbelastung 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 Berücksichtigung der Grundlagen (einschließlich Indizes, Autovakuum, wie diese auf der niedrigen Ebene funktionieren usw.) und ausreichender Rechenressourcen sind diese jedoch vollständig verwaltbar (und ich schätze, dass sie bis in den 30-TB-Bereich in Pg verwaltbar sind).
Edit2 : Sobald Sie sich auf 100 TB begeben, 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 überschreitet.