Firebird Datenbankgröße

[Lemmy]

@Thomas: ich habe das ehrlich gesagt noch nie gemacht - aber wo ist der Unterschied zwischen einer (eingestellten) Read-Only DB und einer DB in die ich keine Inserts mache? Sortiert FB hier dennoch immer wieder Daten um?

[mkinzler]

Er macht ja Inserts

[Dejan Vu]

Und die sind immer am Ende? So von wegen Timestamp und Index drauf. Weiß jetzt nicht, wie FB das macht, aber die Daten werden ja wohl ans Ende gepackt,

[mkinzler]

Nein. Wenn vorher ein datensatz gelöscht wurde, wird der Speicherplatz für neue Inserts wieder verwendet.

[Dejan Vu]

Zitat:

Zitat von mkinzler (Beitrag 1257703)

Nein. Wenn vorher ein datensatz gelöscht wurde, wird der Speicherplatz für neue Inserts wieder verwendet.

Werden hier Datensätze gelöscht? Soweit wie ich das bisher verfolgt habe: Nein. Und dann stimmt meine Annahme ja wohl, das die neuen Datensätze automatisch und immer ans Ende kommen. Und wenn das so ist, kann man die Seiten auch mit einem Fillfactor von 100% füllen, oder nicht?

[hstreicher]

Zitat:

Zitat von Dejan Vu (Beitrag 1257685)

Hast Du mal nachgerechnet?
21 Mio Datensätze in 25% von 128MB Speicher sind irgendwie nicht ganz so viele Bytes pro Datensatz. Genauer gesagt: 1.6 Bytes.

Zitat:

Zitat von haentschman (Beitrag 1257678)

Datenquelle:Technisches Gerät mit (angeblich) 128MB internem Speicher und 25% Belegung

Was wir hier haben sind ca. 23 Bytes reine Nutzdaten. Das ergibt dann schon mal in Summe 460 MB (21 Mio recs # 23 Bytes). Pro Index über einen 4-Byte-Integer kommen da dann noch

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

der Index besteht auf 4 Byte Nutzdaten
Aufbau eines Index Records:

http://ibexpert.net/ibe/index.php?n=Doc.IndexB-treePage

struct btree_nod
{
UCHAR *nodePointer;
USHORT btn_prefix;
USHORT btn_length;
SLONG pageNumber;
UCHAR *data;
RecordNumber recordNumber;
bool isEndBucket;
bool isEndLevel;

1+2+2+4+4+4+1+1 = 19 Byte bei 4 Byte Nutzlast

sind dann 400 MB , dazu kommt dass die Indexe in Pages verwaltet werden die meist nicht ganz gefüllt werden
Plus Overhead um die Pages zu verwalten ,

2 Indizes laut dem anderen Thread also über 800MB

Record Header : (auch von der IBexpert seite)
struct rhd {
SLONG rhd_transaction;
SLONG rhd_b_page;
USHORT rhd_b_line;
USHORT rhd_flags;
UCHAR rhd_format;
UCHAR rhd_data[1];
};

4+4+2+2+1+ Nutzlast
36 Bytes bei 21 Mio Record 756 MB

Plus 800 MB Index


so dass das mit den 1.65 GB schon hinkommt

mfg Hannes

[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 ...

[p80286]

Zitat:

Zitat von Lemmy (Beitrag 1257696)

@Thomas: ich habe das ehrlich gesagt noch nie gemacht - aber wo ist der Unterschied zwischen einer (eingestellten) Read-Only DB und einer DB in die ich keine Inserts mache? Sortiert FB hier dennoch immer wieder Daten um?

Du hast Die Updates übersehen! Je nach indizierten Feldern, kannst Du einige Änderungen in den Indizies bekommen, auch wenn der RecordCount stabil bleibt. Eine Readonly-DB ist eigentlich tot.

Gruß
K-H