Maximale Anzahl von Datenbanken für eine einzelne Instanz von PostgreSQL 9

8

Bei der Entwicklung einer Multicustomer-Anwendung planen wir, für jeden Kunden eine andere Datenbank zu verwenden. Es könnten aber mehr als 1000 Kunden (Anwendungen) sein.

Wird PostgreSQL problemlos damit umgehen?

Hat jemand etwas ähnliches versucht?

Hinweis: 35 Tabellen für jede Datenbank mit durchschnittlich bis zu 3000 Datensätzen für jede Datenbank.

postgresql postgresql-9.1 Juanin
quelle

Antworten:

5

Ich habe es nicht selbst versucht, aber es gibt andere, die es haben. Hier sehen Sie, dass sogar 10.000 Datenbanken problemlos auf einer einzelnen Instanz ausgeführt werden können. Sie können sogar einige praktische Aspekte in ServerFault finden .

Da Ihre Datenbanken recht klein sind, werden Sie keine Einschränkung der Dateinummer des Host-Betriebssystems feststellen. Das einzige Problem, an das ich denken kann, ist, dass es schwierig ist, alle diese Verbindungen zu handhaben, wenn auf alle diese Datenbanken gleichzeitig zugegriffen wird.

Und als letzte Anmerkung: Sie sind auf dieser Seite sehr willkommen. Wir hoffen, dass Sie noch lange bei uns bleiben.

dezso
quelle
Danke für deine Kommentare. Ja, gleichzeitige Verbindungen können Kopfschmerzen verursachen, aber die andere Option ist eine gemeinsam genutzte Tabelle für jede Anwendung, die unglaublich komplexer ist (für die App muss neu programmiert werden).
Juanin
2

Klingt aus Managementsicht nach einer chaotischen Sache. Wie wollen Sie so viele Datenbanken sichern? mit einem Skript, das jeden durchläuft?

Wenn Sie keinen guten Grund haben, warum nicht einfach eine Datenbank haben, in der die Struktur so gestaltet ist, dass alle Daten mit einer Kunden-ID verknüpft werden. Fügen Sie basierend auf diesem Feld Indizes / Fremdschlüssel / Primärschlüssel hinzu, um die Datenintegrität sicherzustellen.

Dann brauchen Sie nur noch eine where-Klausel in all Ihren Abfragen, um auf nur eine Kunden-ID zuzugreifen. Dies ist viel einfacher zu warten und ebenso einfach zu entwickeln (in beiden Fällen müssen Sie die Kundenidentifikation berücksichtigen).

Adam f
quelle
1
Dies ist ein sehr guter und gültiger Punkt. Vielleicht sollte das OP über die Verwendung von Schemas nachdenken und nur wenige Tabellen im öffentlichen Schema haben, die zum VERBINDEN mit Tabellen im Schema des Privatkunden verfügbar sind.
François Beausoleil
Danke, aber diese Option wurde von Anfang an verworfen. Dies ist eine Portierung einer bereits entwickelten Anwendung, und ändern Sie den gesamten Code, der zu diesem Zeitpunkt nicht so trivial ist. Aber ja, die tägliche Verwaltung von mehr als 100 Datenbanken wird ... interessant ... nicht wahr?
Juanin
1
Der Wechsel von separaten Datenbanken zu separaten Schemata sollte keine wesentliche Änderung des Codes bedeuten. Insbesondere müssen Sie den Objekten search_pathkeine Schemata voranstellen, da dies für Sie erledigt wird.
Daniel Vérité
Eine Archivierung für ein Backup wäre hier sinnvoll.
Jharwood
0

Es gibt Leute, die dies tun, insbesondere für das Hosting von gemeinsam genutzten Servern.

Wenn man die Themen hier durchdenkt, gibt es kein kostenloses Mittagessen. Sie könnten dies wahrscheinlich mit Schemata auf anwendungstransparente Weise tun. Dann gelangen Sie jedoch zu Tausenden von Schemata und Zehntausenden von Tabellen, was zusätzliche Probleme aufwirft.

Ich denke im Großen und Ganzen, der Multiple-DB-Ansatz ist angesichts Ihrer Kommentare am vernünftigsten.

Management (wie Backups) wird interessant. Ich würde auch denken, dass die Verbindungen zur Datenbank irgendwann länger dauern werden. Wenn Sie pg_hba.conf verwenden, um den Zugriff einzuschränken (was Sie tun sollten), wird dies ebenfalls zu Kopfschmerzen und Sie möchten wahrscheinlich eine Lösung erstellen, um diese Datei für Sie zu generieren .....

Chris Travers
quelle
Ich kann das Problem mit pg_hba.conf nicht sehen. Unsere App verwendet Ruby on Rails und schaltet Verbindungen für verschiedene Datenbanken um, jedoch immer in derselben Linux-Box. sprechen Sie über Parallelitätsprobleme beim Zugriff auf die Datei?
Juanin
1
Nein, nur wenn Sie verwalten möchten, auf welche Datenbank von welchen Hosts zugegriffen werden kann, wird dies zu einer langen Datei, und die Verwaltung kann etwas ärgerlich werden.
Chris Travers
0

Ich hoffe , dass diese Verbindung besser ist zu lesen: 10.000 Datenbanken auf einem PostgreSQL Cluster von Jon Jensen, 2008.

Ein Auszug:

Die kurze Antwort: Postgres 8.1 verarbeitet 10.000 Datenbanken einwandfrei. \l in psql generiert natürlich eine lange Liste von Datenbanken, kehrt aber schnell genug zurück. Ad-hoc-Parallelitätstests waren in Ordnung. Das Ausführen von Abfragen, Einfügungen usw. in einer handverlesenen Gruppe der verschiedenen Wiedergabedatenbanken funktionierte einwandfrei, auch während neue Datenbanken erstellt wurden.

[...]

Das tatsächliche Limit auf dieser [ Linux ext3 ] -Plattform liegt wahrscheinlich bei 31995 Datenbanken, da jede Datenbank ein Unterverzeichnis in data / base / belegt und das ext3-Dateisystem ein Limit von 31998 Unterverzeichnissen pro Verzeichnis hat, was sich aus dem Limit von 32000 Links pro Verzeichnis ergibt Inode.

user117336
quelle
1
Antworten, die nur Links enthalten, sind nicht sehr nützlich, da Links im Laufe der Zeit veraltet sind. Bitte fügen Sie in Ihrer Antwort die Zusammenfassung der Links hinzu, auf die Sie verweisen.
Mustaccio