it-swarm.com.de

PostgreSQL: Ist es besser, mehrere Datenbanken mit jeweils einem Schema oder eine Datenbank mit mehreren Schemata zu verwenden?

Nach dieser Kommentar zu einer meiner Fragen überlege ich, ob es besser ist, eine Datenbank mit X-Schemata zu verwenden oder umgekehrt.

Meine Situation: Ich entwickle eine Webanwendung, bei der bei der Registrierung (tatsächlich) eine Datenbank erstellt wird (nein, es handelt sich nicht um ein soziales Netzwerk: Jeder muss Zugriff auf seine eigenen Daten haben und darf niemals die Daten des anderen Benutzers sehen.) .

So habe ich es in der Vorgängerversion meiner Anwendung (die noch unter MySQL ausgeführt wird) gemacht: Über die Plesk-API kann ich bei jeder Registrierung Folgendes tun:

  1. Erstellen Sie einen Datenbankbenutzer mit eingeschränkten Berechtigungen.
  2. Erstellen Sie eine Datenbank, auf die nur der zuvor erstellte Benutzer und der Superuser zugreifen können (zu Wartungszwecken).
  3. Füllen Sie die Datenbank

Jetzt muss ich dasselbe mit PostgreSQL machen (das Projekt wird ausgereift und MySQL ... erfüllt nicht alle Anforderungen).

Ich muss alle Datenbanken/Schemasicherungen unabhängig voneinander haben: pg_dump funktioniert auf beiden Wegen perfekt und das Gleiche für die Benutzer, die für den Zugriff auf nur ein Schema oder eine Datenbank konfiguriert werden können.

Angenommen, Sie haben mehr Erfahrung mit PostgreSQL als ich. Was ist Ihrer Meinung nach die beste Lösung für meine Situation und warum?

Wird es Leistungsunterschiede bei der Verwendung von $ x-Datenbanken anstelle von $ x-Schemata geben? Und welche Lösung ist in Zukunft besser zu warten (Zuverlässigkeit)?

Alle meine Datenbanken/Schemata haben immer die gleiche Struktur!

Für das Backup-Problem (mit pg_dump) ist es möglicherweise besser, eine Datenbank und viele Schemas gleichzeitig zu verwenden und alle Schemas auf einmal zu sichern: Bei der Wiederherstellung wird der Haupt-Dump ganz einfach auf eine Entwicklungsmaschine geladen und nur das benötigte Schema gesichert und wiederhergestellt: dort Dies ist ein zusätzlicher Schritt, aber das Ablegen des gesamten Schemas scheint schneller zu sein als das Ablegen nacheinander.

UPDATE 2012

Nun, die Struktur und das Design der Anwendungen haben sich in den letzten zwei Jahren stark verändert. Ich benutze immer noch das one db with many schemas Ansatz, aber ich habe immer noch eine Datenbank für jede Version meiner Anwendung:

Db myapp_01
    \_ my_customer_foo_schema
    \_ my_customer_bar_schema
Db myapp_02
    \_ my_customer_foo_schema
    \_ my_customer_bar_schema

Für Sicherungen stelle ich jede Datenbank regelmäßig ab und verschiebe dann die Sicherungen auf den Entwicklungsserver.

Ich verwende auch das PITR/WAL-Backup, aber wie gesagt, es ist unwahrscheinlich, dass ich alle Datenbanken sofort wiederherstellen muss ... also wird es wahrscheinlich in diesem Jahr abgewiesen (In meiner Situation ist das nicht der beste Ansatz).

Der One-DB-Many-Schema-Ansatz hat sich bei mir seitdem sehr gut bewährt, auch wenn sich die Anwendungsstruktur grundlegend geändert hat:

Fast hätte ich vergessen: Alle meine Datenbanken/Schemata werden immer die gleiche Struktur haben!

... jetzt hat jedes Schema eine eigene Struktur, die sich dynamisch an den Datenfluss der Benutzer anpasst.

129
Strae

Ein PostgreSQL "Schema" entspricht in etwa einer MySQL "Datenbank". Wenn eine PostgreSQL-Installation viele Datenbanken enthält, kann dies problematisch werden. Viele Schemata zu haben, wird problemlos funktionieren. Sie möchten also auf jeden Fall mit einer Datenbank und mehreren Schemas in dieser Datenbank arbeiten.

99
kquinn

Auf jeden Fall werde ich mich für den Ein-DB-Viele-Schemas-Ansatz entscheiden. Auf diese Weise kann ich die gesamte Datenbank sichern, aber nur eine auf vielfältige Weise ganz einfach wiederherstellen:

  1. Erstellen Sie eine Sicherungskopie der Datenbank (des gesamten Schemas), laden Sie die Sicherungskopie in eine neue Datenbank, sichern Sie nur das von mir benötigte Schema und stellen Sie sie in der Hauptdatenbank wieder her.
  2. Erstellen Sie nacheinander einen separaten Speicherauszug des Schemas (aber ich denke, die Maschine wird auf diese Weise mehr leiden - und ich erwarte 500 Schemas!)

Ansonsten habe ich beim Herum googeln festgestellt, dass es keine automatische Prozedur zum Duplizieren eines Schemas gibt (unter Verwendung eines Schemas als Vorlage), aber viele schlagen Folgendes vor:

  1. Erstellen Sie ein Template-Schema
  2. Benennen Sie die zu duplizierende Datei mit einem neuen Namen um
  3. Wirf es weg
  4. Benenne es wieder um
  5. Stellen Sie den Speicherauszug wieder her
  6. Die Magie ist vollbracht.

Ich habe dazu zwei Zeilen in Python geschrieben. Ich hoffe, sie können jemandem helfen (in 2 Sekunden geschriebener Code, nicht in der Produktion verwenden):

import os
import sys
import pg

# Take the new schema name from the second cmd arguments (the first is the filename)
newSchema = sys.argv[1]

# Temperary folder for the dumps
dumpFile = '/test/dumps/' + str(newSchema) + '.sql'

# Settings
db_name = 'db_name'
db_user = 'db_user'
db_pass = 'db_pass'
schema_as_template = 'schema_name'

# Connection
pgConnect = pg.connect(dbname= db_name, Host='localhost', user= db_user, passwd= db_pass)

# Rename schema with the new name
pgConnect.query("ALTER SCHEMA " + schema_as_template + " RENAME TO " + str(newSchema))

# Dump it
command = 'export PGPASSWORD="' + db_pass + '" && pg_dump -U ' + db_user + ' -n ' + str(newSchema) + ' ' + db_name + ' > ' + dumpFile
os.system(command)

# Rename back with its default name
pgConnect.query("ALTER SCHEMA " + str(newSchema) + " RENAME TO " + schema_as_template)

# Restore the previous dump to create the new schema
restore = 'export PGPASSWORD="' + db_pass + '" && psql -U ' + db_user + ' -d ' + db_name + ' < ' + dumpFile
os.system(restore)

# Want to delete the dump file?
os.remove(dumpFile)

# Close connection
pgConnect.close()
23
Strae

Ich würde sagen, mit mehreren Datenbanken UND mehreren Schemata gehen :)

Schemata in PostgreSQL ähneln Paketen in Oracle, sofern Sie mit diesen vertraut sind. Datenbanken sollen zwischen ganzen Datensätzen unterscheiden, wohingegen Schemata eher Datenentitäten ähneln.

Beispielsweise könnten Sie eine Datenbank für eine gesamte Anwendung mit den Schemata "UserManagement", "LongTermStorage" usw. haben. "UserManagement" würde dann die Tabelle "User" sowie alle gespeicherten Prozeduren, Trigger, Sequenzen usw. enthalten, die für die Benutzerverwaltung benötigt werden.

Datenbanken sind ganze Programme, Schemata sind Komponenten.

9
Callash

Eine Reihe von Schemata sollte kompakter sein als eine Reihe von Datenbanken, obwohl ich keine Referenz finden kann, die dies bestätigt.

Wenn Sie jedoch die Dinge wirklich sehr getrennt halten möchten (anstatt die Webanwendung so umzugestalten, dass eine "Kunden" -Spalte zu Ihren Tabellen hinzugefügt wird), möchten Sie möglicherweise immer noch separate Datenbanken verwenden: Ich behaupte, Sie können die Wiederherstellung einfacher durchführen auf diese Weise eine bestimmte Kundendatenbank - ohne die anderen Kunden zu stören.

3
Troels Arvin

In einem PostgreSQL-Kontext empfehle ich, eine Datenbank mit mehreren Schemas zu verwenden, da Sie (z. B.) ALLES über Schemas hinweg, aber nicht über Datenbanken hinweg, UNIONIEREN können. Aus diesem Grund ist eine Datenbank wirklich vollständig von einer anderen Datenbank isoliert, während Schemas nicht von anderen Schemas in derselben Datenbank isoliert sind.

Wenn Sie aus irgendeinem Grund in Zukunft Daten über mehrere Schemas hinweg konsolidieren müssen, können Sie dies problemlos über mehrere Schemas hinweg tun. Bei mehreren Datenbanken würden Sie mehrere Datenbankverbindungen benötigen und die Daten aus jeder Datenbank "manuell" nach Anwendungslogik sammeln und zusammenführen.

Letztere haben in einigen Fällen Vorteile, aber ich halte den Ansatz mit einer Datenbank und mehreren Schemas größtenteils für nützlicher.

3
emax