100-Terabyte-Datenbank unter PostgreSQL ohne Sharding

Ist es realistisch, eine 100-TB-Datenbank (tatsächlich etwa 90 TB) unter PostgreSQL einzurichten, ohne dass Daten zwischen mehreren Knoten ausgetauscht werden? Gibt es Erfolgsgeschichten / Beispiele zu ähnlichen Setups?

50.000 Schreibvorgänge pro Sekunde, die absorbiert werden müssen, sind normalerweise mehr als eine Herausforderung. Selbst bei synthetischen Benchmarks mit recht einfachen Einfügungen liegen die Grenzwerte von PostgreSQL in der Regel bei etwa 10 K / s - und dort haben Sie nicht einmal ein so großes Biest in Bezug auf die Datenbankgröße.

Auch das E / A-System für diesen einzelnen PostgreSQL-Knoten wird interessant sein, wie selbst bei RAID 10, und es wird davon ausgegangen, dass 50K-Inserts nur 50K-IOPS entsprechen (was wahrscheinlich falsch ist, aber von Ihrem Datenbankschema und Ihren Indizes abhängt ) benötigen Sie ungefähr hundert Festplatten, gepaart mit einem sehr guten Array, das Sie davon abhält, mehrere hundert Festplatten zu kaufen, um diese Schreibvorgänge rechtzeitig zu warten.

Wenn das Sharding einfach ist und Sie eine so große Schreiblast erwarten, sollten Sie sich für das Sharding entscheiden. Das Skalieren von Schreibvorgängen kann sehr schwierig sein.

Es ist realistisch und wird funktionieren. Die Leistung hängt wesentlich davon ab, wie viel RAM Sie haben. Je größer der Arbeitsspeicher, desto größer der Cache und desto länger kann PostgreSQL Daten zwischenspeichern, bevor sie auf die Festplatte ausgelagert werden.

PostgreSQL schreibt Daten in den Cache und entlädt den Cache von Zeit zu Zeit. 50.000 INSERTs pro Sekunde werden also nicht in 50.000 IOPS übersetzt. Es wird viel weniger sein, weil es Datensätze zusammenfasst und sie alle gleichzeitig schreibt.

Eine so große Datenbank ist kein Problem, wenn der Großteil der Arbeit INSERT ist. PostgreSQL muss hier und da die Indizes ändern, aber das ist wirklich eine leichte Aufgabe. Wenn Sie viele SELECTs in einer Datenbank dieser Größe hätten, müssten Sie wirklich shard.

Ich habe einmal an einer Oracle-Datenbank (Oracle 10g) mit 400 TB auf einem 16-GB-Server gearbeitet, nur eine Instanz. Die Datenbankauslastung war ebenfalls primär INSERTs, also ein paar SELECTs pro Tag und Millionen von INSERTs pro Tag. Leistung war kein Problem.

Bei 100 TB haben Sie einige wichtige Herausforderungen. Ob es für Sie funktioniert oder nicht, hängt davon ab, wie Sie diese beheben möchten.

1. Sie benötigen ausreichende Möglichkeiten, um die Schreiblast zu absorbieren. Dies hängt von der Schreiblast ab. Aber mit ausreichend großartigem Speicher kann es gelöst werden. Geschwindigkeit ist hier ein großes Problem. Ebenso muss der Lesezugriff sorgfältig geprüft werden.

2. Die meisten Datenbanken bestehen nicht aus einer Reihe kleinerer Tabellen, sondern haben oft eine oder zwei wirklich große, die bis zur Hälfte der Datenbankgröße betragen können. PostgreSQL hat ein festes Limit von 32 TB pro Tabelle. Danach gehen dem TID-Typ die Seitenzähler aus. Dies könnte durch einen benutzerdefinierten Build von PostgreSQL oder durch Tabellenpartitionierung erledigt werden, aber es ist eine ernsthafte Herausforderung, die zuerst angegangen werden muss.

3. PostgreSQL hat echte Grenzen, wie viel RAM es für verschiedene Aufgaben verwenden kann. Mehr RAM kann Ihnen also über einen bestimmten Punkt hinaus helfen oder auch nicht.

4. Backups .... Backups sind in dieser Größenordnung interessant. Die mir bekannte 60-TB-Datenbank musste fs-Snapshot-Backups verwenden und dann die Backups für Barmann für die Wal-Archivierung fälschen. Diese gefälschten Backups waren Proxys für fs-Snapshot-Backups. Wie gesagt "Sie sind keine gefälschten Backups. Sie sind alternative Backups!"

Es gibt Leute mit Datenbanken, die sich diesem Bereich nähern. Ich habe mindestens eine Person getroffen, die für eine Bank in den Niederlanden gearbeitet hat, die über eine 60-TB-PostgreSQL-Datenbank verfügt. Es hängt jedoch wirklich von Ihrer Arbeitsbelastung ab und die Größe an sich ist nicht das Problem.