auf Zeitreihen in Postgres vernünftig zugreifen

M. Pritsch

M. Pritsch

Grünschnabel
Hallo alle zusammen,
weis nicht ob ich im richtigen Forum bin, frag aber trotzdem mal:

Und zwar hab ich die Aufgabe mein Speicherverfahren von Zeitreihen
(-> http://de.wikipedia.org/wiki/Zeitreihen)
in Postgresql/Unix neu zu überdenken. Ein Zeitreihenglied besteht in der Regel aus einem Zeit- und einem Meßwert, sowie möglicherweise mehreren Zusatzinformationen. Man kann sie als Zeit-Funktion mit x-y-Werten auffassen bzw. wenn man sie in Blöcke zerlegt, als Vektoren in einem n-dimensionalen Raum.

In meiner Datenbank liegen schon an die 50 millionen Einträge und steigern sich täglich um ca. 25 000 weitere. Das bisherige Speicherverfahren beschränkte sich auf triviales Einfügen aller Daten in eine Tabelle. Dabei Stand sequentielles Durchsuchen/Sortieren nach Datum im Vordergrund. Leider dauert dieses mit der Zeit immer länger. Auch das interne Indizierungsverfahren mit B-Trees stellt nicht die Verbesserung dar, die gewünscht wäre. Am meisten bemerkbar machen sich aber die ganzen Joins.

Ist hier jemanden bekannt welche Techniken oder Indexe (z.B. Skyline Index) sich bewehrt haben bzw. ob vielleicht ein Hybridverfahren mit Auslagerung in Blockdateien (z.B. in C geschrieben - vorallem unter welcher lib-benutzung) den Datenzugriff beschleunigen könnten. Hier würde ich mich sehr über Tipps zu einschläger Literatur freuen.

Desweiteren würde mich das Quadermodell interessieren, mit dem das destatis arbeitet (hab leider keine Publikationen im Netz gefunden).

Vielleicht kann mir ja jemand mit ein bischen Erfahrung auf diesem Gebiet einschlägige Ratschläge geben. Würde mir sehr weiterhelfen. Danke.
 
Hallo,

unsere Datenbank (Oracle) verarbeitet zur Zeit an die 15 Millionen Meßwerte pro Tag und die Performance ist immer noch sehr gut.
Wie sieht denn so ein Meßwertdatensatz bei Dir aus und was genau mußt Du abfragen?
Vielleicht kann man deine Tabelle und deine Indexe anders organisieren, aber dazu bräuchte ich eben noch etwas mehr Informationen.

Wenn Du spezielle Fragen zu Postgres hast, kannst Du Dich auch ans
Postgres Forum wenden.

Gruß, Jobi
 
Also:

> unsere Datenbank (Oracle) verarbeitet zur Zeit an die 15 Millionen Meßwerte pro Tag und die Performance ist immer noch sehr gut.

Ihr werdet sicher mit der Time-Series Erweiterung (IOTs, etc.) arbeiten, diese ist für uns aber leider nicht akzeptabel, weil diese lizensiert werden muss und unsere Lösung ausschließlich auf OpenSource und Eigenentwicklung basieren soll. Wenn du mir aber erklären kannst wie sie Grundlegend funktioniert bzw. auf was es ankommt, würd ich mich sehr freuen und darrauf basierend eine Lösung/Konzept entwickeln, dass ich der Öffentlichkeit zur Verfügung stellen würde. Es muss nicht Postgres sein es kann genauso gut irgend eine andere Datenbank sein oder ein C-Programm.

> Wie sieht denn so ein Meßwertdatensatz bei Dir aus und was genau mußt Du abfragen?

Hier mal ein kleiner Ausschnitt aus unserer wetterdatenbank:

wetter=> select * from wetter_aktuell;

sensor_id | epoche | wert
-----------+------------------------+--------
22 | 2004-08-06 06:36:31+00 | 0
46 | 2004-09-16 23:45:00+00 | 1002.8
56 | 2004-08-06 06:36:31+00 | 0
91 | 2004-09-06 23:45:00+00 | 87.9
87 | 2004-09-21 23:45:14+00 | -19
85 | 2004-09-23 00:45:46+00 | 996.2
76 | 2004-09-22 23:45:57+00 | 967.6
...

Hier noch ein representiever Ausschnitt aus der postgres_debug.log für wetter(ich weis select * from ist nicht die beste Variate, oft steht nach where auch ein between):
...
Sep 20 15:27:57 ### postgres[65563]: [103560] DEBUG: StartTransactionCommand
Sep 20 15:27:57 ### postgres[65563]: [103561] LOG: query: SELECT * FROM wetter WHERE sensor_id=17 AND epoche = '2004-09-20 13:30:20+00';
Sep 20 15:27:57 ### postgres[65563]: [103562] DEBUG: ProcessQuery
Sep 20 15:27:57 ### postgres[65563]: [103563] DEBUG: CommitTransactionCommand
...
Die eigentliche Wetterdatenbank "wetter" beinhaltet dann sämtliche Einträge der vergangenen Jahr(zehnt)e in gleicher Form, blos das Primärschlüssel dann sensor_id und epoche sind. Die Meßwertdatensätze von den anderen Aplikationen/Datenbanken sind sehr ähnlich, fallen aber um den Faktor x öfters an. Die Abtastung erfolgt meistens in relativ gleichen Intervallen.

Im Moment führen wir beim Laserranging Messungen im MHz-Bereich(Licht liegt bei THz) durch und da die Effekte die wir beobachten wollen erst bei KHz-Abtastung "richtig" sichtbar werden, beschränkte sich bis jetzt die Datenverwendung auf mehr oder weniger chronologische Verarbeitung. Es wurden Standartindexe von Postgres verwendet (hier am Beispiel wetter abfrage "\di" ):

Schema | Name | Type | Owner | Table
--------+-------------------------------+-------+-----------+----------
public | idx1_wetter_aktuell | index | postgres | wetter_aktuell
...
public | wetter_pkey_2002 | index | postgres | wetter
public | wetter_pkey_2003 | index | postgres | wetter
public | wetter_sensor_id_idx_1988 | index | postgres | wetter
public | wetter_sensor_id_idx_1989 | index | postgres | wetter
...

Da es gut sein kann, dass wir in absehbarer Zeit in den KHz-Bereich vorstossen, wandeln sich dann die Anforderungen gewaltig und es ist sogar möglich, dass wir "matching" oder ähnliches betreiben werden. Auch das Datenaufkommen wird drastisch steigen.

> Wenn Du spezielle Fragen zu Postgres hast, kannst Du Dich auch ans
Postgres Forum wenden.

Hab ich schon, scheint aber nicht so belebt zu sein;)


Letztendlich ist mir am wichtigsten:
- Die "Rohdaten" sollen möglichst orginalgetreu gespeichert werden, dass die wichtigste Abfrage, nämlich von - bis -, schnell von Hand geht.
- Es sind zig verschiedene Messverfahren (meines wissens alle zeitlich gleichmäßig angeordnet, aber zum Teil lückenhaft), die alle integriert werden sollten(natürlich in die Datenbank).
-Wie gehe ich mit Lücken um?
-Es soll möglich bleiben, für andere Suchanfragen optimale Indexe zu erstellen.
-Es darf ruhig das schnellste und denkbar beste Speicherverfahren sein. Muss halt dann möglicherweise neu programmiert werden.

Ich hoffe das reicht fürs erste.
mfg max
 
Hallo Max,

soweit ich gesehen (und verstanden) habe, selektierst Du die Meßwerte eines Sensors über ein Zeitintervall. Sind diese Intervalle fest vorgegeben, z.B. Tages-/Stundenintervalle, oder muß der Zeitraum komplett frei wählbar sein?
So wäre es etwa möglich, in dieser Tabelle ein zusätzliches Feld zu benutzen, das als String "Sensor_ID || to_char(epoche,'yyyydddhh')" enthält und indiziert ist.

Oder wenn Du Meßwerte aller Sensoren über frei wählbare Zeiträume abfragen willst, so könnte ein extra indiziertes Feld mit "to_char(epoche,'yyyyddd')" auch einen erheblichen Speedup bringen.

Du kannst mir gerne einen Dump deiner Testdaten (freilich nicht alle) mailen und mir deine beötigten Abfragen genauer schildern.
Ich würde dann versuchen, das Beste an Geschwindigkeit rauszuholen.

Gruß, Jobi
 
hallo Jobi,
hab dir ne mail mit nem kleinen Datenpack geschickt. Danke auch für die anderen Tipps. ich werds ausprobieren.
mfg max
 
Zurück
Oben