Division durch 0 vermeiden

Für jede Stunde gibt es eine Partition, die nach 14 Tagen wieder gelöscht wird. Am Import arbeiten mehrere Prozesse parallel 5-Minuten-Scheiben ab. Ich glaube, wenn man für jede 5-Minutenscheibe eine Partition machen würde, habe ich Probleme, das ganze noch zu händeln.

Nunja … die Partitionen machen in deinem Fall ja nur Sinn, wenn sie in verschiedene Tablespaces/laufwerke zeigen - damit die IO moeglichst wenig blockiert - und die clients auch parallel arbeiten koennen (mehrkernprozessoren sind auch kein thema mehr).

Das semantische zusammenmischen macht Postgres dank Tabellenvererbung … du sollst ja keine sinnlosen Partitionen erzeugen …

wie auch immer - soll ne Anregung sein …

Da steht weder, was das für Daten sind, noch in welchem Format die ankommen noch was du bisher probiert hast und was gescheitert ist.
Außerdem reicht es aus, dass du die Daten in 4 Minuten 50 Sekunden einspielen kannst, um eine Chance zum Aufholen zu haben. Die Vorgabe mit 2,5 Minuten ist völlig aus der Luft gegriffen.

Das habe ich nur mit pg_bulkload geschafft.

Das möge sein, aber hast du alle anderen gültigen Möglichkeiten ausgereizt?


Desweiteren nehme ich mal schlicht an, dass man am Datenmodell noch einiges optimieren kann, um dein Schreiben (und generell die meisten Abfragen) schneller zu gestalten. Würde mich wundern, wenn ihr diese Ecke schon ausgereizt habt.

Warum? Außerdem schreibst du somit ständig in die gleiche Tabelle, da die meisten Prozesse ja Daten aus nahe beieinanderliegenden Zeitsätzen schreiben. Statt dessen könnte man die Daten bequem auf verschiedene Platten verteilen und die Performance beim Schreiben vervielfachen.

Woran dachtest Du bei “anderen gültigen Möglichkeiten”?

Es ist ein Snowflake Shema. Hauptsächlich werden smallint und int übertragen, so dass das Datenvolumen auf ein Minimum reduziert ist.

Der I/O wird von der Hardware verteilt.

@dardanus

das mag sich jetzt erstmal sehr kompliziert anhoeren - ist es aber nicht - ausserdem wirst du belohnt - du hast spaeter weniger arbeit - die loesung wird außerdem skalierbar sein … und wir reden auch weiterhin mit dir …

aber pg_brechcopy … nee … des fassen wir nicht an :smiley:

nunja … das sind doch text-daten … daher wird erstmal text importiert

  1. darauf achten, dass die rohdaten von einer anderen platte stammen (weil pg_dingskopy sicher auf dem selben system wie die db ist)

  2. IO verteilt die HW nur wenn du sie laesst … wenn du viele clients hast gewinnst du nur, wenn die daraus resultierenden serverprozesse sich nicht gegenseitig blockieren - was sie aber tun wenn sie alle in die selbe table auf dem gleichen tablespace operieren …

Im speziellen COPY. Habt ihr das wirklich mit diversen Möglichkeiten ausgereizt und dann festgestellt, dass das zu langsam ist?
Dann braucht ihr eigentlich mehr Hardware. Wie andere dir hier auch schon gesagt haben: direkt auf dem HEAP herumfummeln ist eigentlich eine böse Angelegenheit.


Es ist ein Snowflake Shema. Hauptsächlich werden smallint und int übertragen, so dass das Datenvolumen auf ein Minimum reduziert ist.

Ihr verwendet also schon Partitionierung der Tabellen?


Der I/O wird von der Hardware verteilt.

Aber nur anonym, oder?
RAID? NAS?

Um das mal zu erklären: ihr nehmt 2,3 oder mehr reale Platten an je eigenen Controllern. Dann verteilt ihr z.B. Daten, Index und die WAL-Logs auf eigene Platten. Oder aber ihr überlegt, wie ihr die Daten, die anfallen, logisch Partitionieren könnt. Angenommen, das sind Daten von N Sensoren, dann kann man die Datentabelle partitionieren und je Sensor eine Teil-Partition verwenden, die dann auch noch auf getrennten Tablespaces liegen können. Der Phantasie sind hier keine Grenzen gesetzt. Damit erreicht man, daß das Nadelöhr I/O auf mehrere Kanäle aufgeteilt wird.

Andreas