Diese Zahl ist nicht so hoch, wie Sie denken. In der aktuellen Arbeit speichern wir Metrikdaten für Websites und die Gesamtzahl der Zeilen, die wir haben, ist viel höher. Und in meinem vorherigen Job habe ich mit der pg-Datenbank gearbeitet, die Metriken aus dem Mobilfunknetz gesammelt hat und ungefähr 2 Milliarden Datensätze pro Tag gesammelt hat. Also keine Angst vor Milliarden von Datensätzen.
Sie müssen auf jeden Fall Daten partitionieren - höchstwahrscheinlich tagsüber. Bei dieser Datenmenge kann man Indizes recht nutzlos finden. Hängt von Flugzeugen ab, die Sie in EXPLAIN sehen werden Befehlsausgabe. Zum Beispiel hat diese Telco-App überhaupt keine Indizes verwendet, weil sie nur die gesamte Engine verlangsamen würden.
Eine andere Frage ist, wie schnell Sie Antworten auf Anfragen benötigen. Und welche Granularitätsschritte (Summen über Stunden/Tage/Wochen usw.) für Abfragen werden Sie für Benutzer zulassen. Möglicherweise müssen Sie sogar einige Aggregationen für Granularitäten wie Woche, Monat oder Quartal erstellen.
Zusatz:
Diese ~2 Milliarden Datensätze pro Tag in dieser Telekommunikations-App nahmen ungefähr 290 GB pro Tag in Anspruch. Und es bedeutete Einfügungen von ~23000 Datensätzen pro Sekunde mit Masseneinfügungen mit dem COPY-Befehl. Jeder Bulk bestand aus mehreren tausend Datensätzen. Rohdaten wurden nach Minuten partitioniert. Um Festplattenwartezeiten zu vermeiden, hatte db 4 Tablespaces auf 4 verschiedenen Festplatten/Arrays und Partitionen wurden darüber verteilt. PostreSQL konnte das alles ohne Probleme bewältigen. Sie sollten also auch über die richtige HW-Konfiguration nachdenken.
Eine gute Idee ist auch, das pg_xlog-Verzeichnis auf eine separate Festplatte oder ein separates Array zu verschieben. Nein, nur ein anderes Dateisystem. Es muss alles separate HW sein. SSDs kann ich nur in Arrays mit ordentlicher Fehlerprüfung empfehlen. In letzter Zeit hatten wir Probleme mit einer beschädigten Datenbank auf einer einzelnen SSD.
