Hallo,

in Anlehnung an mein anderes Problem (http://www.delphipraxis.net/180221-f...index-max.html) noch folgende Frage:

Ich bin mit der Datenbankgröße auf der Platte nicht wirklich zufrieden.


Gegeben:

markieren

Delphi-Quellcode:

CREATE TABLE T_RECORD_DATA (
    F_PARAMETER_ID ID /* ID = INTEGER NOT NULL */,
    F_TIMESTAMP_UNIX INTEGER_NORMAL /* INTEGER_NORMAL = INTEGER NOT NULL */,
    F_POWER_STATE INTEGER_NORMAL /* INTEGER_NORMAL = INTEGER NOT NULL */,
    F_VALUE STRING10 /* STRING10 = VARCHAR(10) NOT NULL */

21000000 Datensätze in Tabelle
1,65 GB Plattenplatz

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

Wo kommen die extremen Größendifferenzen her? Der Index belegt nicht wirklich viel. Etwa 5% der Gesamtgröße geschätzt nach 2 Versuchen in leere DB (3,6 MB) sowohl mit Index als auch ohne.

Wie kann ich die Datenbankgröße verkleinern?

Betroffen von der Datenflut ist nur diese Tabelle. Dies ist nur ein Gerät. Max 500 sollen möglich sein. Das wären
1,65*4(Belegung 100%)*500 = 3,3 TB (größte bekannte FB Datenbank hat rund 980 GB)...Klar gibt es da wieder Möglichkeiten (1 DB je Gerät etc.). Mir ist nur diese Ausgangsbasis zu viel.

Danke für Info´s...

1.)Bei Updates eines Datensatzes wird eine neue Kopie des Datensatzes (neue Version) angelegt.
2.)Gelöschte Datensätze werden nicht gelöscht sondern markiert.
zu 1.) Bei einem Sweep werden die Versionen bereinigt.
zu 2.) Backup/Restore

Geht das nicht mit

markieren

Code:

gfix -sweep

?

Ja:

markieren

Code:

gfix -user SYSDBA -password masterkey dbserver:/db/mydb.fdb -sweep

Danke.

Die Datensätze werden nur per Insert eingefügt. Eine Bearbeitung (update) ist nicht vorgesehen. Die Datenbankgröße ist die nach den 21 Mio Insert incl Index.

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 von haentschman:

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

Wenn im Gerät keine Dimensionsfaltenkompression eingebaut ist, würde ich hier annehmen, das das 'angeblich' nicht 100% korrekt ist.

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 84 MB + Overhead hinzu. Ich kenne FB jetzt nicht, aber ich würde pro Record einen Overhead von ca 10-15 Bytes annehmen, das wären dann also ca. 40 Bytes Brutto ohne Index, also ungefähr 800MB. Dann noch der Index mit 80MB + X Overhead und wir sind schon nahe am GB. Na, vielleicht ist der Overhead doch etwas höher.

Danke für deine Berechnungen.

Zitat:

Hast Du mal nachgerechnet?

...nicht exakt. Es ist nur unglaublich wie die Values da rein passen. Die Belegung kann ich nur aus der Weboberfläche des Gerätes wiedergeben.

Zitat:

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

... und die haben je Value auch den Unix Timestamp. Selbst damit wären wir schon drüber. (128MB)

Zitat:

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 84 MB + Overhead hinzu. Ich kenne FB jetzt nicht, aber ich würde pro Record einen Overhead von ca 10-15 Bytes annehmen, das wären dann also ca. 40 Bytes Brutto ohne Index, also ungefähr 800MB.

...damit könnte ich leben. Wir liegen aber ca. beim Doppelten.
Ich habe schon mit varchar(1) statt Integer für den PowerState experimentiert... ohne nennenswerte Platzgewinne.

Ich sage ja: FB hat eben noch einen höheren Record-Overhead. Auch bei den Indexen ist es doch etwas mehr als die reinen Nutzdaten.

Heutzutage ist ja Performance wichtiger als Speicher und wenn das bei FB eben so ist, dann ist es doch gut.

Ich hab mal eben eine Test-DB auf einem SQL-Server erzeugt. Das verbrät mit einem Index so ziemlich genau ein GB.

werden nach dem Insert keine Änderungen an den Daten vorgenommen und keine weiteren Inserts durchgeführt? Bzw. wenn dann erst ein Delete * from... bzw. ein großer Insert mit Massendaten?

Dann könnte folgendes was bringen: Firebird speichert die Daten ja auf "Pages" die aber nicht zu 100% gefüllt werden, um Lücken für spätere Inserts zu lassen um wegen dem Index nicht alles umsortieren zu müssen.

Macht man aber nur einmal einen großen Insert und ändert die Daten hier kaum noch, kann man auch die Seiten komplett füllen und damit wir die Datei an sich kleiner.

Mach mal ein gstat -data <Database>. Dann sollte so was raus kommen:

markieren

Code:

CONFIGREVISIONSTORE (213)
    Primary pointer page: 572, Index root page: 573
    Data pages: 2122, data page slots: 2122, average fill: 82%
    Fill distribution:
         0 - 19% = 1
        20 - 39% = 0
        40 - 59% = 0
        60 - 79% = 79
        80 - 99% = 2042

Wenn hier viele Seiten nur 60-80% gefüllt sind, verlierst Du entsprechend Platz.

Ändern kannst Du das über gfix:

http://www.firebirdsql.org/manual/gfix-pagespace.html

gfix -use FULL database_name

[edit]: Vorteil ist, dass im Grunde die Lesegeschwindigkeit steigt, da weniger Pages gelesen werden müssen, nachteil: Inserts dauern auf grund der Index-Optimierung länger. Bei großen Inserts daher besser den Index deaktivieren und anschließend wieder neu aufbauen...

Weiterhin kann die PageSize an sich auch ein Problem sein, wenn diese nicht mit der Sektorengröße auf der Platte zusammen passt - hier sollte aber der Windows-Explorer in neueren WIndows-Versionen die entsprechenden Informationen auch ausgeben können.

@Lemmy: Das würde ich nur bei einer Read-Only Datenbank machen.