Hallo liebe Forenmitglieder,
ich bin neu hier und arbeite mich geradein ein Projekt ein, in der es um die Verarbeitung sehr vieler Messdaten (ca. 100 Milliarden) geht. Soweit ich das gesehen habe, gibt es unter Firebird kein "Partitioning Table". Wenn die Tabellen eine gewisse Größe haben, ist es ja auch sehr leidlich sie (in Betrieb) auch zu sichern. Gibt es oder kennt ihr eine gute Einführung/Zusammenfassung für Firebird zu diesem Thema "Nutzung (oder auch Vermeidung) und Administration sehr großer Tabellen/Datenmengen"?
Speziell arbeite ich mit Debian 11 (bullseye) 64Bit und Firebird 3.0.7.
(dazu kommt aber gleich noch eine andere Frage, wenn ich die stellen darf;-))
Danke euch für jede/n Unterstützung/Hinweis!
Viele Grüße,
Helios
PS: Datenbank/SQL/P(l)SQL Kenntnisse sind vorhanden. Ich möchte aber mal schauen wie leistungsfähig Firebird ist (ich kenne es noch als Interbase aus Delphi 2.0 Zeiten, habe aber damals beruflich mit Oracle gearbeitet).
Administration/Sicherung sehr großer Tabellen/Daten in Firebird
Moderator: thorben.braun
-
martin.koeditz
- Beiträge: 474
- Registriert: Sa 31. Mär 2018, 14:35
Hallo Helios,
hier darf jede Frage gestellt werden. Davon lebt so ein Forum ja.
Performance und Wachstum hängen in erster Linie vom Datenbankdesign ab. Wenn du uns den Aufbau und die Anforderungen deiner Anwendung verrätst, finden wir sicherlich einen vernünftigen Weg.
Einige Vor- und Nachteile bzgl. der Verarbeitung von Messdaten wurde kürzlich im Thema von Groffy besprochen:
https://www.firebirdforum.de/viewtopic.php?f=12&t=162
Gruß
Martin
hier darf jede Frage gestellt werden. Davon lebt so ein Forum ja.
Performance und Wachstum hängen in erster Linie vom Datenbankdesign ab. Wenn du uns den Aufbau und die Anforderungen deiner Anwendung verrätst, finden wir sicherlich einen vernünftigen Weg.
Einige Vor- und Nachteile bzgl. der Verarbeitung von Messdaten wurde kürzlich im Thema von Groffy besprochen:
https://www.firebirdforum.de/viewtopic.php?f=12&t=162
Gruß
Martin
Martin Köditz
it & synergy GmbH
it & synergy GmbH
Auch partitionierte Tabellen wie im SQL-Server haben Schwierigkeiten diese zu sichern. DIes passiert auch dort im laufenden Betrieb, eben so, wie auch dei FB per gbak im laufenden Betrieb gesichert werden kann.
Es ist auch nicht eine Frage der Anzahl Zeilen sondern der Größe der DB.
Ich habe Kunden mit durchaus mehr als 70GB an Daten mit über 100 Tabellen (ist eben BI). Die Sicherung dauert hier ca. 90 Minuten.
Auf Grund der hohen Verdichtung durch Kompression kann man auch große Datenmengen durchaus klein halten.
Für die Partitionierung muss man sich halt überlegen, ob man diese Datenmengen nach Zeiträumen (Jahre/Monate) in andere DB's verteilt. Dies ist durchaus üblich.
Bei Auswertungen werden selten alle Daten gemeinsam ausgewertet, sondern nach Zeiträumen aggregiert. Somit lassen sich auch Abfragen partitionieren und die Ergebnisse im Programm zusammen fassen. Dies erlaubt dann sogar parallele Abfragen und könnte die Auswertung beschleunigen.
Es ist auch nicht eine Frage der Anzahl Zeilen sondern der Größe der DB.
Ich habe Kunden mit durchaus mehr als 70GB an Daten mit über 100 Tabellen (ist eben BI). Die Sicherung dauert hier ca. 90 Minuten.
Auf Grund der hohen Verdichtung durch Kompression kann man auch große Datenmengen durchaus klein halten.
Für die Partitionierung muss man sich halt überlegen, ob man diese Datenmengen nach Zeiträumen (Jahre/Monate) in andere DB's verteilt. Dies ist durchaus üblich.
Bei Auswertungen werden selten alle Daten gemeinsam ausgewertet, sondern nach Zeiträumen aggregiert. Somit lassen sich auch Abfragen partitionieren und die Ergebnisse im Programm zusammen fassen. Dies erlaubt dann sogar parallele Abfragen und könnte die Auswertung beschleunigen.
Hallo Martin, bfuerchau,
danke für eure Rückmeldungen.
Es geht um Diagnoseausleseprotokolle (derzeit 600.000 Protokolle) von Fahrzeugen. Jedes Protokoll enthält zu jedem Steuergerät (können bis zu 100 Steuergeräte sein) etwa 300-5000 Messwerte.
In einem Protokoll sind dann ca. 5.000 bis 50.000 Messwerte.
Die Suche nach einzelnen (oder mehreren) Messwerten aus jeweils vielen, bis zu 12 Monate alten Protokollen und ein bis mehrer Steuergeräte sollte schnell erfolgen (wenige Sekunden bis einige Minuten). Bei 1-3 Jahre alten Protokollen kann die Suche nach Messwerten langsamer erfolgen (Abfrage bis zu 4h) darüber hinaus (15 Jahre) dann auch bis zu einen Tag.
Die Struktur ist ganz grob:
Protokoll_1 (mit jeweils eindeutiger Fzg. Id + Auslesedatum)
-> Steuergeraet_1
---> Messwert Kategorie (Fehler, Identifikation (SW/HW Version des Steuergerätes, Messwert (Drehzahl))
----> Messwert_1
...
----> Messwert_K (5000 < K < 5000)
...
-> Steuergeraet_M (30 < M < 100)
...
Protokoll_N (N ungefär 600.000 für 1 Jahr)
Es sind Usecases wie "such mir Messwert x1...x1000 aus dem letzten Protokoll des Fzge y1 als auch "such mir die x1...x50 aus dem Fzg y1...y10000" aus den letzten 3Monaten.
Die Daten liegen roh in XML vor und bisher war unser Ansatz, diese Messwerte in eine entsprechende Tabellenstruktur zu packen und von den Tabellen aus auszuwerten (Multiuser).
Bisher haben wir Oracle verwendet und nun möchte ich mal sehen, ob man über einige verteilte und leicht wartbare Firebird Instanzen besser zum Ziel kommt.
Vielleicht habt ihr da ja ein paar Ideen für mich.
Den Ansatz über das Protokoll Auslesedatum zu Partitionieren wäre eine Möglichkeit, aber wie setze ich soetwas ohne Partitioning Tables mir Firebird (konkret) um?
Incl. wegspeichern/archivieren der Daten älter als z.B. 15 Jahre?
Danke erneut für eure Rückmeldung und euer Intresse
Gruß
Helios
danke für eure Rückmeldungen.
Es geht um Diagnoseausleseprotokolle (derzeit 600.000 Protokolle) von Fahrzeugen. Jedes Protokoll enthält zu jedem Steuergerät (können bis zu 100 Steuergeräte sein) etwa 300-5000 Messwerte.
In einem Protokoll sind dann ca. 5.000 bis 50.000 Messwerte.
Die Suche nach einzelnen (oder mehreren) Messwerten aus jeweils vielen, bis zu 12 Monate alten Protokollen und ein bis mehrer Steuergeräte sollte schnell erfolgen (wenige Sekunden bis einige Minuten). Bei 1-3 Jahre alten Protokollen kann die Suche nach Messwerten langsamer erfolgen (Abfrage bis zu 4h) darüber hinaus (15 Jahre) dann auch bis zu einen Tag.
Die Struktur ist ganz grob:
Protokoll_1 (mit jeweils eindeutiger Fzg. Id + Auslesedatum)
-> Steuergeraet_1
---> Messwert Kategorie (Fehler, Identifikation (SW/HW Version des Steuergerätes, Messwert (Drehzahl))
----> Messwert_1
...
----> Messwert_K (5000 < K < 5000)
...
-> Steuergeraet_M (30 < M < 100)
...
Protokoll_N (N ungefär 600.000 für 1 Jahr)
Es sind Usecases wie "such mir Messwert x1...x1000 aus dem letzten Protokoll des Fzge y1 als auch "such mir die x1...x50 aus dem Fzg y1...y10000" aus den letzten 3Monaten.
Die Daten liegen roh in XML vor und bisher war unser Ansatz, diese Messwerte in eine entsprechende Tabellenstruktur zu packen und von den Tabellen aus auszuwerten (Multiuser).
Bisher haben wir Oracle verwendet und nun möchte ich mal sehen, ob man über einige verteilte und leicht wartbare Firebird Instanzen besser zum Ziel kommt.
Vielleicht habt ihr da ja ein paar Ideen für mich.
Den Ansatz über das Protokoll Auslesedatum zu Partitionieren wäre eine Möglichkeit, aber wie setze ich soetwas ohne Partitioning Tables mir Firebird (konkret) um?
Incl. wegspeichern/archivieren der Daten älter als z.B. 15 Jahre?
Danke erneut für eure Rückmeldung und euer Intresse
Gruß
Helios
a) wie sehen deine Tabellen konkret aus
b) welche Abfragemethoden verwendest du heute
Die einfachste Trennung der Daten erfolgt nach Jahren, somit hast du je Jahr überschaubare kleinere Datenbanken.
Wenn die FB-Datenbanken dann den Jahreswert im Namen haben, kann man leicht zur entsprechenden Datenbank wechseln um die Daten auszulesen.
Da diese Form der Daten wohl nicht aggregiert wird, geht es eher ums finden und vergleichen. Für ein Fahrzeugt sind die Daten, egal über wievele Datenbanken, binnen Sekunden ermittelbar.
Dies ginge i.Ü. auch mit Oracle oder SQL-Server. Vorteil der Firebird: Lizenzfrei.
b) welche Abfragemethoden verwendest du heute
Die einfachste Trennung der Daten erfolgt nach Jahren, somit hast du je Jahr überschaubare kleinere Datenbanken.
Wenn die FB-Datenbanken dann den Jahreswert im Namen haben, kann man leicht zur entsprechenden Datenbank wechseln um die Daten auszulesen.
Da diese Form der Daten wohl nicht aggregiert wird, geht es eher ums finden und vergleichen. Für ein Fahrzeugt sind die Daten, egal über wievele Datenbanken, binnen Sekunden ermittelbar.
Dies ginge i.Ü. auch mit Oracle oder SQL-Server. Vorteil der Firebird: Lizenzfrei.
Hallo bfuerchau,
ganz grob sind die Tabellen wie folgt aufgebaut.
Tabelle Protokolle
Fahrzeug Id (VARCHAR2) --> Fahrgestellnummer
Protokoll Id (Number aus einer Sequence)
Tabelle Steuergeraete
Steuergeraete ID (Number)
Steuergeraete Bezeichnung (VARCHAR2) --> Motor, Getriebe, ESP, Tuer VR/HL etc.
Tabelle Label
Label Id (Number)
Label Kurztext/Code (VARCHAR2)
Label Langtext (VARCHAR2)
Tabelle Messwerte (hier liegen die Milliarden Daten, alles oben genannte ist Peanuts)
Messwert Id (Number aus einer Sequence)
Protokoll Id aus Protokolle
Steuergeraete Id aus Tabelle Steuergeraete
Label Id aus Tabelle Label
(Messwert) Einheit
(Messwert) Wert
Mit Oracle haben wir es umgesetzt aber die Zugriffe werden immer langsamer (steigende Anzahl User und komplexer werdende Anfragen). Cloud NoSQL Lösungen sind in Umsetzung. Elastic Search in einem "Proof of Concept", aber so richtig glücklich (bzw. schnell, resourcenschonend und günstig) sind wir nicht. Das Ganze mit einer anderen (Firebird?) schlanken (und verteilten) relationalen Datenbank anzugehen ist jetzt nochmal ein Versuch meinerseits, um zu schauen ob da nicht noch etwas mehr geht (bevor man sich in den Wolken verliert:-)).
Danke für Deine Unterstützung und Gruß
Helios
ganz grob sind die Tabellen wie folgt aufgebaut.
Tabelle Protokolle
Fahrzeug Id (VARCHAR2) --> Fahrgestellnummer
Protokoll Id (Number aus einer Sequence)
Tabelle Steuergeraete
Steuergeraete ID (Number)
Steuergeraete Bezeichnung (VARCHAR2) --> Motor, Getriebe, ESP, Tuer VR/HL etc.
Tabelle Label
Label Id (Number)
Label Kurztext/Code (VARCHAR2)
Label Langtext (VARCHAR2)
Tabelle Messwerte (hier liegen die Milliarden Daten, alles oben genannte ist Peanuts)
Messwert Id (Number aus einer Sequence)
Protokoll Id aus Protokolle
Steuergeraete Id aus Tabelle Steuergeraete
Label Id aus Tabelle Label
(Messwert) Einheit
(Messwert) Wert
Mit Oracle haben wir es umgesetzt aber die Zugriffe werden immer langsamer (steigende Anzahl User und komplexer werdende Anfragen). Cloud NoSQL Lösungen sind in Umsetzung. Elastic Search in einem "Proof of Concept", aber so richtig glücklich (bzw. schnell, resourcenschonend und günstig) sind wir nicht. Das Ganze mit einer anderen (Firebird?) schlanken (und verteilten) relationalen Datenbank anzugehen ist jetzt nochmal ein Versuch meinerseits, um zu schauen ob da nicht noch etwas mehr geht (bevor man sich in den Wolken verliert:-)).
Danke für Deine Unterstützung und Gruß
Helios
Da stellt sich nicht die Frage der Datenbank, sondern des Konzepts.
Ich hatte auch gefragt, wie z.B. die Abfragen aussehen.
Um aus Milliarden Zeilen die entsprechenden Messwerte eines Fahrzeugs oder einer Messstelle bereitzustellen sollte im Berech von Millisekunden liegen.
Die meisten DB's unterstützen performante Abfragen nur mittels Indizes. Dafür gibts u.U. auch Tools der Zugriffsanalyse nebst Indexempfehlungen.
Über welche Antwortzeiten sprechen wir?
Wie handelt die DB derzeit parallele Anfragen von verschiedenen Usern ab?
Gibt es Limits je nach DB-Version wie z.B. beim SQL-Server?
Wie groß ist die DB und wieviel Hauptspeicher habt ihr?
Es gibt sehr viele Faktoren, die es auch bei der FB zu berücksichtigen gilt.
Ich hatte auch gefragt, wie z.B. die Abfragen aussehen.
Um aus Milliarden Zeilen die entsprechenden Messwerte eines Fahrzeugs oder einer Messstelle bereitzustellen sollte im Berech von Millisekunden liegen.
Die meisten DB's unterstützen performante Abfragen nur mittels Indizes. Dafür gibts u.U. auch Tools der Zugriffsanalyse nebst Indexempfehlungen.
Über welche Antwortzeiten sprechen wir?
Wie handelt die DB derzeit parallele Anfragen von verschiedenen Usern ab?
Gibt es Limits je nach DB-Version wie z.B. beim SQL-Server?
Wie groß ist die DB und wieviel Hauptspeicher habt ihr?
Es gibt sehr viele Faktoren, die es auch bei der FB zu berücksichtigen gilt.
Hallo bfuerchau,
sorry das ich jetzt antworte (harte Arbeitswoche und dann noch Zimmerrenovierung:-). Wie gesagt, umgesetzt ist das als Oracle Datenbank im Multiuser (10-50 Concurrent User) Umfeld. Indizes, SQL Abfragen und Datenbank (Cost-Based optimized) sind alle weitestgehend optimiert (da kann man nicht mehr viel herausholen). Das Hauptproblem ist die sehr große Messwerttabelle und mit Firebird würde ich gerne einen Ansatz mit mehreren verteilten Tabellen (auf mehreren Datenbanken und Maschinen) angehen. Dazu würde ich gerne von euch Firebird Experten wissen, wie man geschickt große Tabellen partitioniert bzw. auf mehrer Rechner verteilt und diese entsprechend abfragen kann und die Archivierung der Daten geschickt anstellt. Ein Erfahrungsbericht von einem vergleichbaren umgesezten Projekt würde mir sehr helfen. Ein Beispiel SQL meinerseits hilft hier aus meiner Sicht nicht viel, da ich ja neue Pfade beschreiten will (es ist kein Nachbau des bisherigen Konzepts geplant:-)).
Falls da jemand einen guten Tipp hat, immer gerne her damit.
Danke, schönen Sonntag und Gruß
Helios
sorry das ich jetzt antworte (harte Arbeitswoche und dann noch Zimmerrenovierung:-). Wie gesagt, umgesetzt ist das als Oracle Datenbank im Multiuser (10-50 Concurrent User) Umfeld. Indizes, SQL Abfragen und Datenbank (Cost-Based optimized) sind alle weitestgehend optimiert (da kann man nicht mehr viel herausholen). Das Hauptproblem ist die sehr große Messwerttabelle und mit Firebird würde ich gerne einen Ansatz mit mehreren verteilten Tabellen (auf mehreren Datenbanken und Maschinen) angehen. Dazu würde ich gerne von euch Firebird Experten wissen, wie man geschickt große Tabellen partitioniert bzw. auf mehrer Rechner verteilt und diese entsprechend abfragen kann und die Archivierung der Daten geschickt anstellt. Ein Erfahrungsbericht von einem vergleichbaren umgesezten Projekt würde mir sehr helfen. Ein Beispiel SQL meinerseits hilft hier aus meiner Sicht nicht viel, da ich ja neue Pfade beschreiten will (es ist kein Nachbau des bisherigen Konzepts geplant:-)).
Falls da jemand einen guten Tipp hat, immer gerne her damit.
Danke, schönen Sonntag und Gruß
Helios
Ob du nun Firebird nimmst oder bei Oracle bleibst, die Konzepte sind doch eher DB-unabhängig. Oracle unterstützt ja selber bereits partitionierte Tabellen.
Die Frage der Abfrage bleibt jedoch weitgerhin bestehen.
Da du nun von Messdaten eines Geräts sprichst, suchst du nun die Messdaten zu einem Gerät oder Geräte zu bestimmten Messdaten?
Hier kann man sich dann auch eine andere Datenbankstruktur überlegen, dich ich bei einem anderen Kunden erfolgreich eingesetzt habe. Diese arbeitet nicht mit partitionierten Tabellen sondern mit komplett anderer Art der Speicherung und dementsprechend anderer Art der Abfrage.
Ich kann da gerne einen Kontakt vermitteln, denn der Kunde hat meine Gedankenspiele realisiert, wozu ich selber nie gekommen bin.
Hier wurde ein DMS realisiert, dass flexible und vor allem erweiterbare Strukturen enthält und mit nur wenigen Tabellen überhaupt auskommt.
Letztendlich wurde dann, wiederum auf dessen Kundenwünschen, trotzdem der SQL-Server verwendet.
Seine letzte Aussage war, dass selbst bei komplexeren Abfragen von mehr als 50 Usern gleichtzeitig keine nennenswerte Belastung des SQL-Servers überhaupt stattfand.
Da ich nun mal für Geld arbeite, also käuflich bin, biete ich gerne beratende Tätigkeit zur Erläuterung des Konzepts an.
Die Frage der Abfrage bleibt jedoch weitgerhin bestehen.
Da du nun von Messdaten eines Geräts sprichst, suchst du nun die Messdaten zu einem Gerät oder Geräte zu bestimmten Messdaten?
Hier kann man sich dann auch eine andere Datenbankstruktur überlegen, dich ich bei einem anderen Kunden erfolgreich eingesetzt habe. Diese arbeitet nicht mit partitionierten Tabellen sondern mit komplett anderer Art der Speicherung und dementsprechend anderer Art der Abfrage.
Ich kann da gerne einen Kontakt vermitteln, denn der Kunde hat meine Gedankenspiele realisiert, wozu ich selber nie gekommen bin.
Hier wurde ein DMS realisiert, dass flexible und vor allem erweiterbare Strukturen enthält und mit nur wenigen Tabellen überhaupt auskommt.
Letztendlich wurde dann, wiederum auf dessen Kundenwünschen, trotzdem der SQL-Server verwendet.
Seine letzte Aussage war, dass selbst bei komplexeren Abfragen von mehr als 50 Usern gleichtzeitig keine nennenswerte Belastung des SQL-Servers überhaupt stattfand.
Da ich nun mal für Geld arbeite, also käuflich bin, biete ich gerne beratende Tätigkeit zur Erläuterung des Konzepts an.
Hallo bfuerchau,
vielen Dank für das freundliche Angebot. Vielleicht komme ich darauf zurück sobald ich einwenig standfester mit Firebird geworden bin. Sobald ich etwas mehr technische Erfahrung gesamelt habe würde ich diesen Thread mit mehr technischen Details wieder aufleben lassen.
Danke und Gruß
Helios
vielen Dank für das freundliche Angebot. Vielleicht komme ich darauf zurück sobald ich einwenig standfester mit Firebird geworden bin. Sobald ich etwas mehr technische Erfahrung gesamelt habe würde ich diesen Thread mit mehr technischen Details wieder aufleben lassen.
Danke und Gruß
Helios