Verhalten des Speicherplatz/Datenlänge Bedarfs von Integer/BIGINT bei 64 Bit Maschinen

Hallo

gegeben eine 64 Bit Maschine unter Linux mit einer InnoDB Engine

Laut Doku belegt ein INT 4 bytes ein BIGINT 8 bytes
Jetzt gab es die Aussage das auf 64 Bit Versionen im Zusammenhang mit
einem Index auf dem entsprechenden Datenfeld ein INT und Bigint sich
identisch (also mit 8 bytes Platzbedarf) verhalten.

Tests mit einer Spalte mit integer Werten (40.Mio rows plus eine int
Spalte mit Werten <10) ergaben:

int ohne Index = 1,4 GB
BIGint ohne Index = 1,6 GB

int mit Index = 1,2 GB
BIGint mit Index = 1,4 GB

das Argument gleich verhalten ist somit erst mal nicht mehr haltbar.
Das der Index dann wieder Platz spart erklärt sich ja durch den
optimierten Tree

Merkwürdig ist allerdings wieso sich das durch den Bigint nicht
verdoppelt hat (was ich erst mal angenommen habe).

Kann das wer erklären (nicht spekulieren ;)???

Danke & Grüße
Thomas Butz

Re: Verhalten des Speicherplatz/Datenlänge Bedarfs von Integer/BIGINT bei 64 Bit Maschinen

Thomas Butz schrieb:

> Laut Doku belegt ein INT 4 bytes ein BIGINT 8 bytes

Korrekt.

> Jetzt gab es die Aussage das auf 64 Bit Versionen im Zusammenhang mit
> einem Index auf dem entsprechenden Datenfeld ein INT und Bigint sich
> identisch (also mit 8 bytes Platzbedarf) verhalten.

Wo gab es diese Aussage?

> Tests mit einer Spalte mit integer Werten (40.Mio rows plus eine int
> Spalte mit Werten <10) ergaben:
>
> int ohne Index = 1,4 GB
> BIGint ohne Index = 1,6 GB

Also eine Differenz von ungefähr 200 MB. Passt.

> Merkwürdig ist allerdings wieso sich das durch den Bigint nicht
> verdoppelt hat (was ich erst mal angenommen habe).

Warum sollte sich das verdoppeln? Du hast Doch nur eine (BIG)INT-Spalte.

> Kann das wer erklären (nicht spekulieren ;)???

Da gibt es nichts zu spekulieren. Da kommt man auch mit einer simplen
Rechnung drauf: Ein INT belegt 4 Byte, ein BIGINT 8 Byte (alles netto).
Demzufolge belegen 40 Millionen INTs 4 * 40 = 160 MB und 40 Millionen
BIGINTs 8 * 40 = 320 MB. Differenz: 160 MB.

Gruß. Claus

Re: Verhalten des Speicherplatz/Datenlänge Bedarfs von Integer/BIGINT bei 64 Bit Maschinen

Hallo Claus
> Wo gab es diese Aussage?
nicht im Web und nicht so wichtig ;)


>> Tests mit einer Spalte mit integer Werten (40.Mio rows plus eine int
>> Spalte mit Werten <10) ergaben:
>> int ohne Index = 1,4 GB
>> BIGint ohne Index = 1,6 GB
> Also eine Differenz von ungefähr 200 MB. Passt.
>> Merkwürdig ist allerdings wieso sich das durch den Bigint nicht
>> verdoppelt hat (was ich erst mal angenommen habe).
> Warum sollte sich das verdoppeln? Du hast Doch nur eine (BIG)INT-Spalte.
> Da gibt es nichts zu spekulieren. Da kommt man auch mit einer simplen
> Rechnung drauf: Ein INT belegt 4 Byte, ein BIGINT 8 Byte (alles netto).
> Demzufolge belegen 40 Millionen INTs 4 * 40 = 160 MB und 40 Millionen
> BIGINTs 8 * 40 = 320 MB. Differenz: 160 MB.
So ganz kann ich das nicht bestätgien - deshalb das ganze noch mal OHNE
weitere Spalten:
20. Mio records ein Feld

INT -> ~462,9 MB ~24 Byte
BIGINT -> ~546 MB ~28 Byte

die Differenz von 4 Byte kann auch Zufall sein 20 Byte "Verwaltungs"
overhead??? Die einzige Aussage bisher die ich mich getraue zu treffen:
BIGINT macht definitiv 10-20 % mehr aus.
Alles andere bleibt ein Rätsel. (Liegts an den 16k Innodb pages?)

Grüße
Thomas

Re: Verhalten des Speicherplatz/Datenlänge Bedarfs von Integer/BIGINT bei 64 Bit Maschinen

Thomas Butz wrote:
....
>> Da gibt es nichts zu spekulieren. Da kommt man auch mit einer simplen
>> Rechnung drauf: Ein INT belegt 4 Byte, ein BIGINT 8 Byte (alles netto).
>> Demzufolge belegen 40 Millionen INTs 4 * 40 = 160 MB und 40 Millionen
>> BIGINTs 8 * 40 = 320 MB. Differenz: 160 MB.
> So ganz kann ich das nicht bestätgien - deshalb das ganze noch mal OHNE
> weitere Spalten:
> 20. Mio records ein Feld
>
> INT -> ~462,9 MB ~24 Byte
> BIGINT -> ~546 MB ~28 Byte
>
> die Differenz von 4 Byte kann auch Zufall sein

Nö. Das sind genau die 4 Bytes, die ein BIGINT mehr benötigt
als ein INT.

> 20 Byte "Verwaltungs" overhead???
> Die einzige Aussage bisher die ich mich getraue zu treffen:
> BIGINT macht definitiv 10-20 % mehr aus.
> Alles andere bleibt ein Rätsel. (Liegts an den 16k Innodb pages?)

InnoDB speichert Daten nicht dicht. Pages werden nur zu einem
bestimmten Prozentsatz gefüllt (u.a. abhängig davon, in welcher
Reihenfolge Records eingefügt werden und wieviele auf einmal).
Außerdem gibts *immer* einen PK - notfalls einen versteckten -
und die Transaktion-Nr. in der der Record zuletzt geändert wurde
steht auch im Record.

Noch weniger aussagekräftig wird das, wenn du nur einen globalen
Tablespace hast (statt --innodb-file-per-table).


XL

Re: Verhalten des Speicherplatz/Datenlänge Bedarfs von Integer/BIGINT bei 64 Bit Maschinen

Hallo Axel
> Nö. Das sind genau die 4 Bytes, die ein BIGINT mehr benötigt
> als ein INT.

Hast recht habe noch einen weiteren Versuch mit einer DB mit 55 Mio
Records um die 15 GB gefahren auch hier der Zuwachs um genau die 55Mio*
4Byte...

> InnoDB speichert Daten nicht dicht. Pages werden nur zu einem
> bestimmten Prozentsatz gefüllt (u.a. abhängig davon, in welcher
> Reihenfolge Records eingefügt werden und wieviele auf einmal).
> Außerdem gibts *immer* einen PK - notfalls einen versteckten -
> und die Transaktion-Nr. in der der Record zuletzt geändert wurde
> steht auch im Record.

Auch mit PK speichert innodb alles andere als dicht... das war auch
genau der Pferdefuß an der Sache.
Da ich zuerst auf die Gesamtgröße und nicht auf den Zuwachs geschaut habe.

> Noch weniger aussagekräftig wird das, wenn du nur einen globalen
> Tablespace hast (statt --innodb-file-per-table).
so fahren wir die DB nicht.

Danke für den Stups in die richtige Richtung
Grüße
thomas