logisches Aufteilen mehrerer Projekte/Struktur der DB

Konfiguration & Verwaltung Konfiguration
1

Hallo!

Ich komme aus der Oracle-Welt, arbeite aber jetzt in einem Projekt (oder eigentlich in mehreren Projekten… siehe weiter unten) mit Postgres. Dieses Projekt wird langsam immer grösser und ich wollte einfach schon mal hier nachfragen, wie ich die Datenbank am besten strukturiere.

Die Situation ist folgende: wir wollen mehrere alte Systeme nun an einer Stelle zusammenfassen, teils auch mit neuer Funktionalität. Allen Projekten gemeinsam ist das “Containersystem” welches eigentlich nur besagt, dass wir 3 Ebenen haben, die untereinander via ETL verbunden sind: Staging-DB, Produktions-DB und Liefer-DB - erstere als erster Anlaufplatz der Daten (raw data), die 2. mit den gewaschenen, als korrekt angesehenen Daten und die 3. mit gerade den Informationen, die für verschiedene Verwendungen benötigt werden. Also ungefähr so:
Staging —ETL—> Produktion —ETL—> Lieferung

So weit, so gut. Aber wir haben nun mal mehrere Projekte parallel und teils müssen die auch auf gemeinsame Daten (z.B. Kundenregister) zugreifen können, was die Sache leider etwas verkompliziert - und skalierbar soll alles natürlich auch noch sein. Zudem bin ich kein DBA sondern eher DB-Entwickler (früher PL/SQL Transaktions-DB, mittlerweile mehr ETL/Data Warehousing). Deshalb will ich nun, bevor wir uns hier unwiederruflich verrannt haben, kurz fragen ob meine Ideen in Ordnung oder total daneben sind.

Bisher dachte ich also daran, dass jedes Projekt eine neue Datenbank bekommt. In jeder Datenbank dann 3 Schemata (Staging, Produktion, Lieferung) und 3 oder 4 User (einer pro Schema plus einer pro DB). Jetzt ist mir aber aufgefallen, dass User wohl über den gesamten Server existieren, was diese Aufteilung wieder in Frage stellt… (sonst habe ich am Ende dutzende User und keinen Überblick)
Also etwa so:
Staging(Proj. 1) —ETL—> Produktion(Proj. 1) —ETL—> Lieferung(Proj. 1)
Staging(Proj. 2) —ETL—> Produktion(Proj. 2) —ETL—> Lieferung(Proj. 2)
Staging(Proj. 3) —ETL—> Produktion(Proj. 3) —ETL—> Lieferung(Proj. 3)

Meine Frage also: wie kann man das Ganze ordentlich strukturieren? Ich weiss, dass das ne sehr allgemeine Frage ist und ich will natürlich nicht, dass hier einer meine Arbeit macht. Nurr paar Tips oder Denkanstösse wären schon super. Braucht es eine DB pro Projekt oder ist das sinnlos? Reicht nicht ein User pro DB (und damit dann evtl. pro Projekt)? Wie leicht ist es später, auf Daten in einer anderen DB zuzugreifen (also besagte allgemein nötigen Daten)? Hier weiss ich von Oracle, dass es nicht sonderlich schwer, aber performance-mässig totaler Mist ist. Wie leicht ist es, das Ganze dann später evtl. auf mehreren Servern zu verteilen?
Bin wirklich für jede Idee, jeden Tip dankbar!

Beste Grüsse,
Daniel

2

User sind in der Tat global, also über alle Datenbanken in einem Cluster. DB-übergreifender Zugriff geht so erst einmal nicht out-of-the-box, aber mit Tools wie dblink oder, moderner und besser, postgresql_fdw. Ich gehe davon aus, daß Du mit aktuellen Versionen unterwegs bist. Ob Du via FDW auf eine lokale Instanz oder einen entfernten Server zugreifst ist dann aber egal.

Und wenn Du einen Hoster sucht: mich fragen.

3

Danke für die Antwort!
Wie sieht’s mit den Datenbanken/Schemas aus? Gibt’s da Daumenregeln, was man wo rein packt? Macht es einen Unterschied in der Performance, ob man z.B. 2 Tabellen aus verschiedenen Schemas joint (im Vergleich zu zweien im gleichen Schema)? Und wie löse ich das Problem mit den “allgemein interessanten Daten” elegant?
Ich denke, ich werde die ganzen User über Bord werfen, so lange ich noch kann, und einen User per Projekt nehmen (statt 4…). Das ist sauberer und es gibt keine Anforderungen an Zugriffsbeschränkungen. Die einzige Einschränkung dürfte dann ja sein, dass ich nicht mehr ohne weiteres horizontal ausgliedern kann (also das Lieferung-Schema von einem oder mehreren Projekten auf nen neuen Server), sondern ganze Projekte (Staging, Produktion, Lieferung) umziehen muss.
Danke für das Angebot mit dem Hosten, aber zum einen lebe ich seit 6 Jahren in Schweden (was sicher nicht mal ein Problem wäre), zum anderen bin ich Consultant und mein Auftraggeber hat seinen “Stamm-Hoster”, der auch die neuen PG-Datenbanken übernimmt. Werde es aber für die Zukunft im Hinterkopf behalten, versprochen!

4

Nein, Schemas innerhalb einer DB haben auf die Performance keinen Einfluß.

Ich weiß z.B. von Zalando, daß die ihre komplette Geschäftslogig in Funktionen innerhalb von PG haben, und bei neuen Versionen einfach ein neues Schema machen und dann den search_path schwenken. Das könnte man sicherlich auch für Staging / Production - Tabellen etc. machen.