Firebird Datenbankgröße

[tsteinmaurer]

Ich kann mir nicht vorstellen, dass niemals gelöscht wird, sprich die Tabelle ins Unendliche wachsen darf/kann.

Firebird hat auch keinen Clustered Index wie in SQL Server bzw. eine Index-Organized Table wie in Oracle.

[haentschman]

Zitat:

Ich kann mir nicht vorstellen, dass niemals gelöscht wird, sprich die Tabelle ins Unendliche wachsen darf/kann.

Das ist schon richtig. Das ganze sind Meßdaten welche mindestens 10 Jahre aufbewahrt werden müssen / sollen. In den internen Speicher (128 MB) gehen, je nach Speicherzyklus (1m / 15m) zwischen 1 Jahr bis zu 3 Jahren Daten.
Die sollen in der DB verbleiben. Quasi die letzten 10 Jahre. Wenn die DB an dieser Stelle ankommt werden die ersten entfernt.

Beim aktuellen Beispiel wären das 1,6GB zu 0,75 = x zu 10 -> 21,3GB
(0,75 Jahre im Gerät bei 10 Jahre gesamt)

Inzwischen ist die Entscheidung gefallen, daß jedes Gerät seine eigene DB für die Record Daten bekommt. Damit sind ein paar Probleme vom Tisch (Gesamtgröße)

PS: Ich rechne lieber mit dem WorstCase als später in Probleme zu laufen weil man sich nicht richtig Gedanken gemacht hat.

Zitat:

nur mal so :
128MB durch 21 Mio = 6 Bytes

...angeblich erst 25% Auslastung. Das wären dann 1,5 Byte je DS.

[tsteinmaurer]

In welcher Granularität musst du die Messdaten aufbewahren?

Bei Timeseries Anwendungsfällen geht man in der Regel so vor, dass periodisch Daten von einer höheren Auflösung in kleinere Auflösungen aggregiert wird und im selben Kontext Daten der höheren Auflösung gelöscht werden. Außer du bist im Bereich Garantie wo du die feingranularen Daten zur Nachvollziehbarkeit benötigst.

Bzgl. Datenbank je Gerät. Im Prinzip musst du dann X Datenbanken bzgl. Schemastruktur auf einem entsprechenden Stand halten, jede Datenbank sichern etc., bei einem Firebird/ODS Upgrade diese sichern/wiederherstellen etc. Dann hast du vielleicht auch Stammdaten, die jedem Gerät gemein sind. Wie machst du das?

Je nach Datenvolumen and Anwendungsfall haben hier (für Zeitreihen) BigData-Lösungen ala Cassandra absolut ihre Daseinsberechtigung. Aber das ist eine ganz andere Welt ...

[haentschman]

Hallo Thomas...

ich bin ein wenig von der Größe überfahren worden. Im Leben hätte ich (Bauchgefühl) nicht mit der Größe gerechnet.

Zum Thema Statistik:

Delphi-Quellcode:

T_RECORD_DATA (153) 
    Primary pointer page: 150, Index root page: 172 
    Data pages: 82929, data page slots: 82929, average fill: 63% 
    Fill distribution: 
         0 - 19% = 0 
        20 - 39% = 1 
        40 - 59% = 0 
        60 - 79% = 82928 
        80 - 99% = 0 
 
    Index FK_T_RECORD_DATA_1 (0) 
        Depth: 3, leaf buckets: 8073, nodes: 21680580 
        Average data length: 0.00, total dup: 21679353, max dup: 19155 
        Fill distribution: 
             0 - 19% = 1 
            20 - 39% = 0 
            40 - 59% = 2451 
            60 - 79% = 0 
            80 - 99% = 5621 
 
    Index T_RECORD_DATA_IDX1 (2) 
        Depth: 3, leaf buckets: 7010, nodes: 21680580 
        Average data length: 0.06, total dup: 20624315, max dup: 87 
        Fill distribution: 
             0 - 19% = 0 
            20 - 39% = 0 
            40 - 59% = 1 
            60 - 79% = 0 
            80 - 99% = 7009

... bedeutet ja, daß reichlich Platz verschwendet wird. Die Inserts laufen als Block wie hier empfohlen
http://www.delphipraxis.net/1256983-post42.html

Delphi-Quellcode:

execute block as begin //25Kb je Block
insert into T_RECORD_DATA...  // 200x je Block. Änderung der Menge machte keinen Unterschied.
end

Alle Blöcke laufen in einer Transaktion. Wo läßt sich da noch was rausholen.

Zitat:

Bzgl. Datenbank je Gerät. Im Prinzip musst du dann X Datenbanken bzgl. Schemastruktur auf einem entsprechenden Stand halten, jede Datenbank sichern etc., bei einem Firebird/ODS Upgrade diese sichern/wiederherstellen etc. Dann hast du vielleicht auch Stammdaten, die jedem Gerät gemein sind. Wie machst du das?

Ich würde nur diese eine Tabelle auslagern. Der Rest ist zusammengenommen, auch bei 500 Geräten, unter 30MB. Denkst du eher an eine Aufsplittung ab X GB? Geht das automatisch? Wo kann man das nachlesen?

[Union]

Vielleicht kannst Du Deine Speicherung auch der auf dem Gerät angleichen. Wenn ich mir die Struktur aus dem OP ansehe, habe ich da so Vermutungen:

• F_PARAMETER_ID ID /* ID = INTEGER NOT NULL */,
  Wie groß wird diese ID maximal? Wenn es z.b. so etwas wie max. 127 oder 255 wäre, könnte man das in einem Nibble, Byte oder Word zusammen mit z.b. POWER_STATE speichern
• F_TIMESTAMP_UNIX INTEGER_NORMAL /* INTEGER_NORMAL = INTEGER NOT NULL */,
  Wenn man die Basis des Timestamp (den Offset 0) in die nähere Vergangenheit setzt, kommt man auch mit weniger Platz aus.
• F_POWER_STATE INTEGER_NORMAL /* INTEGER_NORMAL = INTEGER NOT NULL */,
  Siehe Anmerkung zu Parameter-ID
• F_VALUE STRING10 /* STRING10 = VARCHAR(10) NOT NULL */
  Sind das wirklich individuelle Werte oder sind das Fixtexte? Je nach Anzahl der möglichen Fixtexte könnte man das dann als Index auf ein konstantes Fixtext-Array bzw. eine entsprechende normalisierte Fixtext-Tabelle verkleinern.

Nachteil wäre die Rechnerei die Du beim Auswerten hättest. Immer das Selbe: Platzersparnis <> Performance.

[Dejan Vu]

Ist das mit dem Platz im Jahr 2014 wirklich ein Problem?

[Union]

Zitat von Dejan Vu:

Ist das mit dem Platz im Jahr 2014 wirklich ein Problem?

Von Anfang an Platz zu sparen und die Performance zu optimieren zeugt immer von zukunftsorientiertem Denken. Irgendwann ist nämlich 2015 oder es sollen noch mehr Geräte eingebunden werden oder der Zugriff erfolgt in eine Cloud mit begrenzeter Bandbreite oder...

Leider ist das Denken "wieso Performance? Ich hab unendlich viel Speicher und Dutzende von Prozessorkernen." genau so weit verbreitet wie die Verwechselung einer IDE mit einem Point-And-Click-Adventure.

[haentschman]

Danke an Alle...

@Union: interessante Ansätze.

Zitat:

Wie groß wird diese ID maximal?

unbekannt. Vermute 6 stellig. Für einen SmallInt zu groß. Außerdem benötige ich später sowohl den Timestamp als auch den Parameter im SQL bei den Auswertungen. Da bleibt nicht mehr viel übrig.

Zitat:

Wenn man die Basis des Timestamp (den Offset 0) in die nähere Vergangenheit setzt, kommt man auch mit weniger Platz aus.

Du meinst so nah, daß der Rest in einen SmallInt paßt? Geht nicht.
Im Beispiel: letzter DS = 1398999942 erster = 1381299573

Zitat:

Sind das wirklich individuelle Werte oder sind das Fixtexte?

Kann sowohl ein Zeichen ('+'), ein digitaler Wert ('0'/'1') oder ein analoger Wert ('-999.99' bis '999.99') sein. In der ersten Version waren das sogar getrennte Felder. Varchar(10) soll das absolute Maximum darstellen. Der Platzbedarf sollte ja nur so groß sein wie die Daten oder? Der Timestamp könnte auch ein TDateTime sein. Was braucht weniger Platz?

Zitat:

Ist das mit dem Platz im Jahr 2014 wirklich ein Problem?

Da macht es die Masse über die Dauer. Im Maximum könnten 500 Geräte für 10 Jahre gespeichert werden. (rechnerisch derzeit ca. 11 TB) Im Normalfall reden wir über 1 - 3 Geräte. Da ist das natürlich kein Problem...

PS: Es geht um Temperaturaufzeichnungen in der Lebensmittelbranche und Pharmaciebranche. Die genauen Speicherzeiträumen per Gesetzt sind mir unbekannt. Da aber das Finanzamt 10 Jahre Aufbewahrung hat ging ich mal ebenso davon aus.
Rein theoretisch hat das Gerät einen Speicherzyklus von 1-3 Jahren je nach Auflösung. Dann werden die ersten Daten wieder überschrieben. Per Gesetz sind die so zugelassen und man könnte die DB Speicherung auch darauf begrenzen. Ich will aber einen Mehrwert für den Kunden. Quasi das was die Hardware nicht leistet.

Zitat:

Übersehen nicht, nur nicht explizit drauf eingegangen. Aufgrund der Beschreibung bin ich davon ausgegangen, dass die Daten einmal importiert werden um dann für Auswertungen vorgehalten werden bzw. bei Aktualisierungen die Daten als "Masseninserts" rein kommen und nicht individuell von den Anwendern geändert werden können / sollen. Und hier würde ich (wenn die DB-Größe wirklich ein Thema sein sollte) ggf. die beschrieben Dinge anwenden.

Unter 2.5 soll es ja auch möglich sein über StoredProcedures auf anderen DBs zugreifen zu können. Somit könnten diese Gerätedaten in eigene, ggf. auch als Read-OnlyDBs ausgelagert werden und die Pages voll gemacht werden.

Im Prinzip sind die Daten als ReadOnly zu betrachten und werden nur für Auswertungen etc. vorgehalten. Um aber die Größe nicht bis ins unendliche wachsen zu lassen sollen die Ältesten nach einem Zeitraum X entfernt werden.