Guten Abend
wird sind daran unser Oracle abzulösen und sind momentan am migrieren von den Tabellen und Daten mit Hilfe von ora2pg
zu Postgresql
nun stellt sich auch die Frage ob wir das rudinätere Partitioning benutzen wollen und ob wir unsere Tabellen auch im Nachhinein auf sogenannte master --> xchild Tabellen anhand eines Splitting keys migriren können oder ob wird das schon mit ora2pg machen wollen oder können und ob das sich dann auch auf die migrations Performance auswirken würde
denke nicht das ora2pg sogenannte partiotion tabellen befüllen kann - man muss ja immer in die richtige Partition schreiben und kann nicht in die master Tabelle schreiben
Du kannst das auch später machen, aber es gleich richtig zu machen ist wohl auch kein Fehler. Der übliche Weg sind TRIGGER auf der Master-Tabelle.
Besten Dank für die schnelle Antwort
Ja ich habe da noch bedenken
-
partitioning ist unter PostgreSQL noch nicht ausgereift und zu händisch
-
ob es was bringt in Sachen performance
-
dass die migration massiv verlangsamt wird mit diesen Triggers
Es handelt sich um x mio Datensaetze und das ist so schon “langsam”
Ein Kunde von uns hat pro Tag 20 Millionen oder mehr Inserts, und muß die Daten mind. 3 Jahre aufheben. Das haben wir mit täglichen Partitionen gelöst. Wenn die Abfrage passend ist (also die ‘richtige’ Partition getroffen wurde (weil Datum Teil der Where-Condtion) dann geht das trotz mehrere Milliarden Rows flott (im Sinne von wenigen Millisekunden) - okay, ist auch gute Hardware verbaut. Ich glaube nicht, daß Oraggle das toppen kann.
Wenn Du (bzw. die Applikation) schlau sind, dann kann man ohne TRIGGER arbeiten. Wenn man gut mit umgeht, bekommt man aber auch die TRIGGER so hin, daß sie schnell sind. Eine ‘massive Verlangsammung’ ist dann eher Zeichen von Unvermögen.
Aber denke triggers bieten per SE schon overhead
Was man ja auch immer liest ist das unique key nicht ganz sicher gestellt werden
Zudem wenn man Daten auf dem key Feld verändert
Was man ja eigentlich nicht sollte klar
Benutzt ihr PG_partman oder aehnliches plug Ins oder generiert ihr die pasrtition
Per script im voraus?
Falls man montas partion macht dann würde ja auch die performance gut sein wenn man nicht d er n ganzen Monat abfrägt
Wie sieht es aus wenn man 2 partitioniert Tabelle joined?
Was macht ihr gegen die Überflut der Tabellen (unuebersichtlichkeit) sprich Partionen? Was macht ihr dagegen das jemand am dem Mechanismus rummfummelt?
Werden die Tabellen nur von einem bestimmten DB user verwaltet?
Deine Fragen sind schwer zu parsen …
“Was man ja auch immer liest ist das unique key nicht ganz sicher gestellt werden” ? Ohne Quelle auf den Bullshit gehe ich da nicht drauf ein.
“Benutzt ihr PG_partman oder aehnliches plug Ins oder generiert ihr die pasrtition
Per script im voraüs?” - zweiteres. Das prüfen, ob die Partition schon da ist / erstellen der Partition haben wir aus dem Trigger rausgelassen, das macht ein Cron, der täglich prüft, ob für die nächsten X Tage ( mit X zweistellig) die Partitionen da sind.
" Was macht ihr gegen die Überflut der Tabellen sprich Partionen? " bis in eine Größenordnung von 1000 ist das alles kein Thema. Und 3 Jahre täglich sind 3 * 365, da bleiben wir im Rahmen. Und der Rest der Frage: Zugriffsrechte kann man nutzen. Auch dafür.
Bezüglich unique key
Diese sind nur über Partionen zu definieren
Deshalb kann das Partitioning keine Garantie auf Eindeutigkeit geben über die ganze “Tabelle”