Table-Partitions im OLTP Betrieb

hiho …

die meisten (eigentlich alle) beispiele zu Table-Partitions zielen darauf ab, inserts zu triggern und somit die tupel ihrer Zielpartition zuzuführen.

soweit so gut … dann liegen sie dort - für OLAP lastige anwendungen / DBs ja sehr sinnvoll

ich habe hier aber ein thema, in dem die partition sich je nach “status” eines records ändern könnte. das hiese auch auf updates zu triggern.

das ist ja implementatorisch kein riesiges problem - nur stelle ich mir das hin und herschreiben größerer datenmengen recht aufwendig für die DB vor … um große datenmengen geht es ja - sonst müsste ich ja nicht an partitionierung denken.

Hi,

und deine Frage war …? :stuck_out_tongue:

Du könntest versuchen den Partitionierungs-Key so zu wählen ,dass er nicht von Updates betroffen ist.

Partitionierung soll dir die Wartung erleichtern, bessere Performance ist ein netter Nebenefekt, der sich nicht automatisch einstellt.

Aber am besten du probierst es selbst mal aus und berichtest von deinen Erfahrungen.

Freundliche Grüße

hkocam

“die frage” kam doch an :slight_smile:

der performance-aspekt ist bei mir der kern der geschichte - hmm ich sehe eher dass partitionierung die wartung komplexer gestaltet :slight_smile: man hat halt ein paar mehr tables (aber egal)

eine performance-bremse in meinem syschdem ist die ACL für row-level berechtigungen … bis ca 150k-250k records kann man damit arbeiten … es riecht aber danach, dass es mit 1 mio records keine freude mehr macht. da gibts dann halt einen view der rel. aufwendig ist.

daher hab ich mir gedacht (grob umrissen) zwischen private und public oder passiven und aktiven daten zu unterscheiden - wobei die ACL funktionalitaet nur auf die aktiven daten angewendet werden sollen (geringe kardinalitaeten). zu erwarten ist naemlich auch, dass es für den großteil der daten die zugriffskontrolle nicht braucht - weil sie eh “public” sind … in diesem fall brauch das view die ACL nicht hinzujoinen -> dat ginge dann fix

bleibt dann nur die frage wie sich das view (union) verhaelt - weil ich auch mit den partitionen eben NICHT direkt auf der master-table arbeite

hmm - und manchmal denke ich - dass ich die partition dafuer garnicht brauche - dann bin ich geneigt den key in den view aufzunehmen - was natuerlich dazu führt, dass ein index begnuegt werden muss.

von der partition erwarte ich, diese einfach dazu mergen zu koennen …

ich muss da noch a weng drüber nachdenken