Partitionieren oder nicht partitionieren?

Nachdem ich bereits mehrere Fragen zu SO, externen Blog-Posts und Handbuch gelesen habe

• SO : Fremdschlüsseleinschränkung für partitionierte Tabelle in Seite
• dba.SE : Verschiedene Arten der Behandlung von FK mit partitionierten Tabellen in Seite
• Handbuch : Vererbung
• Handbuch : Partitionierung
• Handbuch : Einschränkungsauslöser
• Blog : Postgres-Modellierung mit Vererbung

Ich frage mich immer noch, ob ich in Anbetracht meines Falls mit der Partitionierung beginnen soll oder nicht.

Der Fall - vereinfacht

Kundendaten speichern. Alle Namen der unten genannten Tabellen dienen der Übersichtlichkeit.

1. Objekte haben, die vom Kunden identifiziert werden können und nicht physische Wesen sind, auch ihre physischen Objekte, in denen sie tatsächlich gespeichert sind, falls einige Objekte bei Bedarf an den Kunden zurückgesendet oder auf andere Weise verarbeitet werden müssen. Sie werden in einer Viele-zu-Viele-Beziehung abgebildet. objects_nonphysical, objects_physical, objects_mapping_table.

2. Die zweite Viele-zu-Viele-Beziehung besteht zwischen diesen nicht-physischen Objekten und ihren Metriken. Es gibt Objekte, die an einige Metriken gebunden sind. metrics,metrics_objects_nonphysical

3. Sowohl nicht-physische als auch physische Objekte haben ihre Hierarchietabellen, die Kind-Eltern-Beziehungen sind. objects_nonphysical_hierarchy,objects_physical_hierarchy

Abhängig von den Bedürfnissen und Anforderungen jedes Kunden können die Daten zu physischen Objekten bereitgestellt werden oder müssen möglicherweise von Grund auf neu erstellt werden. Grundsätzlich muss ich Folgendes tun:

• Pflegen Sie das interne System für schnelle INSERTund SELECTAnweisungen, da hier das Mapping stattfinden wird.

• Warten Sie das System, damit externe Kunden ihre nicht-physischen Objekte anzeigen und bearbeiten können - schnelles Abrufen von Daten. Starkes Bedürfnis nach Effizienz für SELECTAussagen - diese Daten stehen vielen Kunden zur Verfügung, wann immer sie wollen.

Meine Überlegung

Es kann einen Kunden geben, der auf die Daten zugreifen, sie anzeigen und bearbeiten kann, aber das muss kein Auftragnehmer sein, von dem wir die Daten erhalten haben / für den wir die Daten verarbeiten.

Dies hat mich veranlasst, die Tabellenpartitionierung in mein System einzuführen, da ich immer weiß, in welche Partitionsdaten ich fallen soll ( Partitionierung für Auftragnehmer ), und dann das System für externe Kunden zu pflegen, bei denen ich eine Partitionierung für Kunden benötige (dies würde bei einigen der Fall sein) Verzögern Sie die Verwendung von Automatisierungstools und Regelsätzen, um die Daten auf Kundenart neu zu schreiben, sodass wir für jeden Kunden nur eine Partition für jede Tabelle scannen.

Datenvolumen

Meine Daten werden ständig wachsen, insbesondere beim Importieren von Objekten und Metriken neuer Kunden. Das Tempo, mit dem neue Daten in das System gelangen, ist derzeit auf lange Sicht nicht vorhersehbar. Es gibt wirklich keine Möglichkeit, dies zu messen, wenn man nicht weiß, wer der nächste Kunde sein wird. Derzeit gibt es nur 2 Kunden mit mehr oder weniger 1 Million Zeilen für jeden Kunden in jeder Tabelle. Aber in Zukunft gehe ich davon aus, dass neue Kunden auch ein Volumen von etwa 10 Millionen Zeilen haben werden.

Fragen

Diese Fragen hängen alle miteinander zusammen.

1. Sollte Partitionierung hier wirklich in Betracht gezogen werden, oder ist das ein Overkill? Ich halte es für nützlich, da ich immer genau eine Partition scanne.
2. Wenn Partitionierung der richtige Weg ist, wie kann ich FKEinschränkungen unter Berücksichtigung meiner Anforderungen am effektivsten durchsetzen ? Soll ich mich dafür entscheiden constraint triggersoder es einfach in der Anwendungsschicht für das interne System behalten oder vielleicht eine andere Methode?
3. Wenn Partitionierung nicht der richtige Weg ist, worauf sollte ich eingehen?

Wenn nicht genügend Daten bereitgestellt werden, lassen Sie es mich bitte in den Kommentaren unten wissen.

Ihre Frage hat viele offene Fragen, aber die Partitionierung nach Kunden könnte der richtige Weg sein - insbesondere, wenn:

• Sie erwarten viele Kunden,
• Jeder von ihnen könnte Tonnen von Daten haben ("Tonnen" bedeutet viel mehr als RAM-Cache-Größe),
• Die meisten ihrer Datensätze schließen sich gegenseitig aus (jeder Kunde sieht unterschiedliche Teilmengen von Daten).

REGELN oder Trigger sind ein Leistungsaufwand und können vermieden werden.

Betrachten Sie etwas in diese Richtung:

BEGIN;

CREATE USER tenant1;
CREATE USER tenant2;

CREATE SCHEMA app;
CREATE SCHEMA tenant1;
CREATE SCHEMA tenant2;

CREATE TABLE app.objects_nonphysical(id int);
CREATE TABLE app.objects_physical(id int);
CREATE TABLE app.objects_mapping(id int);    
CREATE TABLE tenant1.objects_nonphysical() INHERITS(app.objects_nonphysical);
CREATE TABLE tenant1.objects_physical() INHERITS(app.objects_physical);
CREATE TABLE tenant1.objects_mapping() INHERITS(app.objects_mapping);
CREATE TABLE tenant2.objects_nonphysical() INHERITS(app.objects_nonphysical);
CREATE TABLE tenant2.objects_physical() INHERITS(app.objects_physical);
CREATE TABLE tenant2.objects_mapping() INHERITS(app.objects_mapping);

GRANT USAGE ON SCHEMA tenant1 TO tenant1;
GRANT USAGE ON SCHEMA tenant2 TO tenant2;
GRANT SELECT,INSERT,UPDATE,DELETE ON ALL TABLES IN SCHEMA tenant1 TO tenant1;
GRANT SELECT,INSERT,UPDATE,DELETE ON ALL TABLES IN SCHEMA tenant2 TO tenant2;

/* TEST: simulate login as customer */
SET SESSION AUTHORIZATION tenant2;
/* No schema needed - default search_path works */
SELECT count(*) FROM objects_nonphysical; 

ROLLBACK;

Sie benötigen keine Trigger / Regeln, um es zu pflegen.

Hier gibt es offene Enden - das ist nur ein Entwurf ... Einige Probleme:

• PK, FK und Indizes werden nicht "vererbt".
• Selbst wenn Sie sie erstellen, wird die PK in der Mastertabelle nicht erzwungen
• Sie können dies überwinden, indem Sie für alle Mandanten dieselbe Reihenfolge verwenden
• Natürlich muss die Anwendung für dieses Modell angepasst werden

Es tut nicht weh, wenn Sie jetzt die Partitionierung implementieren, sondern eine einzelne Partition verwenden, bis Ihr System wirklich eine neue benötigt. In Bezug auf die Leistung wird es nur einen winzigen Aufwand geben, um mit Primärschlüsseln und dergleichen umzugehen.

Ich empfehle, Regeln für die Umleitung von Einfügungen und eine externe Tabelle für die Primärschlüssel zu verwenden (z. B. CREATE TABLE objects_physical_ids (id bigserial NOT NULL PRIMARY KEY)zusammen mit einem Funktionsauslöser, der eine Zeile in die IDs-Tabelle einfügt und in NEW.id kopiert (z. B. INSERT INTO objects_physical_ids DEFAULT VALUES RETURNING id INTO NEW.id;), und anderen Auslösern, die sich mit dem Löschen befassen und Aktualisierungen sowie ein Trigger, der diese Funktionsauslöser für jede geerbte Tabelle ausführt (vergessen Sie nicht, dies zu tun, wenn Sie eine neue geerbte Tabelle erstellen!). Dann können alle zugehörigen Tabellen eine FOREIGN KEYzu der entsprechenden IDs-Tabelle haben (einschließlich aller Fremdschlüsselaktionen wie ON UPDATEoder ON DELETE).