Nutze das System, das du hast, maximal aus

• Der Autor beschreibt seine Erfahrungen mit dem Management der Postgres-Performance in einer SaaS-Anwendung, bei der die Datenbank Schwierigkeiten hatte, die Last zu bewältigen.
• Das Team des Autors skalierte vertikal, indem es die Datenbank immer dann auf eine größere Instanz umstellte, wenn sie zu stark ausgelastet war. Schließlich nutzten sie jedoch bereits die größte verfügbare Instanz und standen kurz vor einer Überlastung.
• Als zwei mögliche Lösungen wurden vorgeschlagen, Schreibvorgänge auf unabhängige Datenbank-Cluster zu sharden und den Monolithen in mehrere verbundene Services (Microservices) aufzuteilen.
• Beide Lösungen würden die Kapazität erhöhen und interessante Optionen für Fehlertoleranz und operative Resilienz bieten, aber die Komplexität erheblich steigern.
• Der Autor argumentiert, dass die tatsächlichen Kosten zusätzlicher Komplexität in der gebundenen Aufmerksamkeit liegen, was jede nachfolgende technische Entscheidung komplizierter macht.
• Der Autor schlägt vor, dass es vor einer deutlichen Erhöhung der Komplexität in der Regel Möglichkeiten gibt, dem bestehenden System noch etwas zusätzliche Performance „abzuringen“, etwa durch Anpassung der Workloads, Performance-Tuning oder Ergänzungen am System.
• In ihrem Fall senkten sie die maximale wöchentliche CPU-Auslastung der Datenbank von 90 % auf 30 %, indem sie schwere Queries optimierten, Postgres-Einstellungen feinjustierten und einige teure schreibgeschützte Queries auf eine Replikat-Datenbank auslagerten.
• Der Autor kommt zu dem Schluss, dass Komplexität zwar notwendig und unvermeidlich ist, es aber wünschenswert ist, ihren Anstieg so lange wie möglich hinauszuzögern und zuerst so viel Performance wie möglich aus dem bestehenden System herauszuholen.

[GN⁺]

Hacker-News-Kommentare

• Der Artikel betont, wie wichtig es ist, das Potenzial des bestehenden Systems maximal auszuschöpfen, bevor man einen Austausch oder ein Upgrade in Betracht zieht.
• Er legt nahe, dass Teams das nutzen sollten, was sie bereits haben, auch wenn es nicht perfekt ist, und Wege finden sollten, ihre Ziele mit vorhandenen Ressourcen zu erreichen.
• Diskutiert wird die Idee, Anwendungen so zu entwerfen, dass in der Datenbank keine Joins nötig sind; Speicherplatz sei günstig, und alles solle denormalisiert und innerhalb von Transaktionen aktualisiert werden.
• Zur Vermeidung von Hot Partitions wird der Einsatz von UUIDs vorgeschlagen, damit horizontal skaliert werden kann, anstatt sich auf Ganzzahlen zu verlassen, die letztlich scheitern können.
• Es wird ein Erfolgsbeispiel eines Teams geteilt, das die Systemleistung deutlich verbesserte, indem es seinen Problemlösungsansatz änderte, statt mehr Hardware oder zusätzliche Komplexität hinzuzufügen.
• Der Artikel spricht sich dagegen aus, einen Monolithen in einem Schritt in mehrere verbundene Services aufzuteilen, und empfiehlt stattdessen, die Aufteilung mit der größten Wirkung zu identifizieren.
• Hervorgehoben wird, wie wichtig es ist, Queries in Web-Apps zu optimieren, die auf einem ORM aufbauen, da es dort oft viel Verbesserungspotenzial gibt.
• Gewarnt wird vor der mentalen Belastung und Komplexität bei der Arbeit mit Microservices-Systemen, die häufig zu Downtime und Verwirrung führten.
• Es wird zwischen Effizienz (Verluste minimieren und Komplexität vermeiden) und Optimierung (spezialisierte Algorithmen auf Kosten zusätzlicher Komplexität einsetzen) unterschieden.
• Es werden Bedenken gegenüber dem Wechsel zu komplexerer Infrastruktur geteilt; diese sei möglicherweise nicht die Allzwecklösung, die alle erwarten.
• Gerade wenn Ressourcen begrenzt sind und das System nicht hochkritisch ist, wird Einfachheit gegenüber Komplexität bevorzugt.
• Abschließend behandelt der Artikel Sharding nach Tenant (Kunde) als potenzielle Lösung für Skalierungsprobleme.