Postgres ist nicht langsam – dein Storage ist es

SQLite + NVMe fühlt sich manchmal wie Schummeln an. Wenn meine oberste Anforderung die niedrigstmögliche Latenz ist, kann ich mir nichts anderes vorstellen.

Kestrel (AspNetCore) + SQLite + NVMe alle auf derselben Maschine ist in meiner Erfahrung der Punkt, an dem es richtig spannend wird. Stell dir vor, du bearbeitest eine komplette Formularübermittlung, die den Datenbankzustand in Zehn- bis niedrigen Hundertmikrosekunden verändert. Die gesamte Wall-Clock-Zeit, die benötigt wird, um eine beliebige HTTP-Anfrage zu bedienen, kann deutlich unter einer Millisekunde liegen. Wenn deine durchschnittliche CPU-Zeit pro Anfrage 30uS beträgt, könntest du auf einer 16-32-Kern-Maschine eine halbe Million pro Sekunde erreichen.

"Früher" mussten wir das zugrunde liegende Storage-Array sorgfältig planen, um jedes Quäntchen Leistung aus dem Datenbankserver herauszuholen.

Ich denke, es gibt eine Generation von Devs, die große Memory-Pools und SSDs einfach als selbstverständlich betrachtet; es gibt eine mentale Trennung von der Tatsache, dass Datenbanken das zugrunde liegende Storage abbilden.

Es wird offensichtlich, sobald ich es in Diskussionen anspreche, und ich kann fast sehen, wie ihnen ein Licht aufgeht (passierte bei einer Diskussion über Partitionierung und Sharding), aber sie stellen nie die Verbindung her, dass eine Query auf irgendeine Art von Artefakten abbildet, die auf Storage liegen.

Habe kürzlich unsere RDS-Instanzen von r8g. auf r8gd. umgestellt, was lokales NVMe hinzufügt, und ich denke, die durchschnittliche I/O-Latenz ging von 1,0 ms auf 0,1 ms zurück. Das summiert sich bei großen Queries!

CloudNativePG unterstützt Kubernetes Local Storage als eines seiner Hauptmerkmale [0]

Persistent Volume Management, einschließlich:

Unterstützung für Local Persistent Volumes mit PVC-Templates.

Wiederverwendung von Persistent Volumes Storage in Pods.

Separate Volumes für WAL-Dateien und Tablespaces.

Kapitel Temporary PostgreSQL Cluster Degradation [1] beschreibt, wie man es einrichtet, und beginnt mit Folgendem:

> Während der Standardansatz Servicezuverlässigkeit gewährleistet und die Selbstheilungsfähigkeiten von Kubernetes nutzt, gibt es Szenarien, in denen der Betrieb mit einem vorübergehend degradierten Cluster akzeptabel sein kann. Dies ist besonders relevant für PostgreSQL-Cluster, die auf knotenlokalem Storage basieren, bei dem der Storage lokal zum Kubernetes-Worker-Node ist, auf dem die PostgreSQL-Datenbank läuft. Knotenlokaler Storage, oder einfach lokaler Storage, wird eingesetzt, um die Performance zu verbessern.

[0] https://cloudnative-pg.io/docs/devel/#main-features

[1] https://cloudnative-pg.io/docs/devel/kubernetes_upgrade/#tem...

Das ist das grundlegende Problem mit netzwerkbasiertem Storage: Alle Apps darüber gehen davon aus, dass kleines I/O schnell und lokal ist, sodass sich die Netzwerklatenz nicht amortisiert.

Mit Replikation auf Anwendungsebene kann man sie auf ein paar Schritte amortisieren (z. B. beim Commit 2PC machen).

Natürlich gibt es Nuancen, besonders wenn man von einem anderen Node lesen muss, aber deshalb performt es bei DBs im Allgemeinen besser, die Replikation so weit wie möglich nach oben im Stack zu verlagern – die DB weiß besser als die Disk, wann sie das Netzwerk berühren muss.

Ehrlich gesagt ergab netzwerkangebundener Storage nur mit HDDs Sinn; es ist lächerlich, für etwas "operational flexibility" einen 10-fachen Malus bei IOPS und Latenz zahlen zu müssen. Man bekommt eine viel einfachere und deutlich robustere Architektur, wenn man einfach bei lokalem NVMe und Replikation bleibt – nicht, dass man auf eines davon in der (ebenfalls replizierten) Netzwerk-Block-Storage-Lösung verzichten könnte...

Ich habe peinlich lange Postgres benutzt, bevor ich den Unterschied zwischen "index scans" und "index only scans" gelernt habe.

Relevante Spalten in den Index aufzunehmen kann die Performance massiv verbessern, weil Postgres dann nicht das zufällig sortierte Tuple in der Originaltabelle lesen muss.