Mein Arbeitgeber verfügt derzeit über mehrere Postgres-Instanzen (eine pro Kunde, mit einem eindeutigen Standortcode), die physisch auf dem Kundengelände getrennt sind. Jeder Kunde hat 1-4 Datenbanken, die in einer Instanz ausgeführt werden, wobei jede Datenbank über 20 Schemata enthält.
Wir versuchen, diese Datenbanken in einer einzigen Postgres-Instanz zusammenzuführen, entweder vor Ort oder bei einem Cloud-Anbieter (denken Sie an RDS), damit wir den Zugriff/die Kontrolle vereinfachen können. Der Kunde wird weiterhin auf die Datenbank zugreifen, wir werden jedoch eine gemeinsame RESTful-Serviceebene einführen, in der die jeweilige Datenbank mithilfe eines Site-Codes angesprochen wird, der als Teil des URL-Pfads jeder API hinzugefügt wird. Um unser SLA hinsichtlich der Leistung (90 % unter 1 s) einzuhalten und den Ressourcenverbrauch niedrig zu halten, beabsichtigen wir, in der Serviceebene Verbindungspooling zu verwenden.
Das Hauptproblem, mit dem wir konfrontiert sind, ist, dass Postgres während der Verbindung eine Datenbank benötigt, was bedeutet, dass wir einen Verbindungspool pro Kunde haben müssen, der viele Ressourcen ineffizient nutzt. Da wir die Ressourcen nicht effizient nutzen, benötigen wir möglicherweise mehr Instanzen der Serviceebene, was zu höheren Kosten und höherer Komplexität der Architektur führt. Obwohl es möglich ist, Kunden effektiv über mehrere Instanzen der Serviceebene zu „sharden“, wird dadurch das eigentliche Problem, nämlich die ineffiziente Nutzung von Verbindungen, nicht gelöst!
Gibt es eine andere Lösung, die ich nicht in Betracht gezogen habe? Vielleicht eine Möglichkeit, einen einzelnen Verbindungspool zu haben, in dem Anforderungen an bestimmte Datenbanken weitergeleitet werden? Oder vielleicht dynamische Verbindungspools, deren Größe je nach Auslastung dynamisch angepasst werden kann?
Danke
Antwort1
AWS RDS-Proxykönnte eine praktische Möglichkeit sein, die Verbindungsanforderungen zu reduzieren.