[Allegro] Blaehungen im Index?

Thomas Berger ThB at Gymel.com
Mi Apr 27 00:12:27 CEST 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

bei einer Familie groesserer Datenbanken kaempfe ich mit der 2GB-Grenze
fuer die .adx-Datei(en) [Multix ist mir bekannt, ich kaempfe aber dennoch],
und zwar verstehe ich zum einen nicht, warum die .adx-Dateien so viel
umfangreicher sind als die Summe der Groessen der ii-Dateien, aus denen
sie aufgebaut wurden und zum anderen bekomme ich bei aehnlichen Datenbanken
mit aehnlicher Indexierung unerklaerliche Groessenabweichungen im
dreistelligen MB-Bereich:

Datenbank 1:


dir /od *.adx new* ii*


a) Nach index -fi0 - at 1

26.04.2011  16:59         1.298.266 ii1
26.04.2011  16:59         1.304.271 ii2
...
26.04.2011  17:04         1.292.743 ii259
26.04.2011  17:04         1.204.204 ii260
26.04.2011  17:04           516.842 ii261
             261 Datei(en),    394.307.330 Bytes


b) Waehrend qrix -fq0:

26.04.2011  21:44       144.689.391 ii1
26.04.2011  21:44       162.632.471 ii2
26.04.2011  21:44        80.929.409 ii3
26.04.2011  21:44             2.048 newinx
               4 Datei(en),    388.253.319 Bytes


c) Nach qrix -fq0:

26.04.2011  21:45       470.720.512 xxx.Adx

Gesamtzahl Indexeintraege = 14324532
verschiedene = 14103007

Es faellt also auf, dass der Index wesentlich (30%) groesser
ist als die Summe seiner Teile, erwartet haette ich - wegen
der Aussagen ueber seine komplizierte und kompakte Struktur -
eigentlich das Gegenteil.


Datenbank 2:

a) Nach index -fi0 - at 1

26.04.2011  16:59         1.296.899 ii1
26.04.2011  16:59         1.304.179 ii2
...
26.04.2011  17:04         1.300.042 ii265
26.04.2011  17:04         1.203.675 ii266
26.04.2011  17:04           565.625 ii267
             267 Datei(en),    406.298.736 Bytes


b) Waehrend qrix -fq0:

26.04.2011  21:49       145.064.974 ii1
26.04.2011  21:49       163.940.491 ii2
26.04.2011  21:49        91.250.542 ii3
26.04.2011  21:49             2.048 newinx
               4 Datei(en),    400.258.055 Bytes

c) Nach qrix -fq0:

26.04.2011  21:49       454.402.048 yyy.Adx

Gesamtzahl Indexeintraege = 14325697
verschiedene = 14115234

Hier ist also der Effekt nicht ganz so drastisch, obwohl die
ii-Dateien im Umfang etwas mehr Speicherplatz benoetigten,
ist der resultierende Index sogar kleiner als bei Datenbank 1,
allerdings immer noch groesser als die Summe der ii-Dateien.



Der 2. Indexlauf verschaerft das Problem noch:


Datenbank 1:

a) Nach index -fi1 - at 2

26.04.2011  21:45       470.720.512 xxx.Adx
26.04.2011  21:48         1.252.958 ii1
26.04.2011  21:48         1.269.139 ii2
...
26.04.2011  23:02           848.017 ii1185
26.04.2011  23:03           806.954 ii1186
            1187 Datei(en),  2.006.532.497 Bytes


b) Waehrend qrix -fq1

26.04.2011  21:45       470.720.512 xxx.Adx
26.04.2011  23:35     1.130.289.593 ii1
26.04.2011  23:35       154.379.292 ii2
26.04.2011  23:35             2.048 newinx
               4 Datei(en),  1.755.391.445 Bytes


c) Nach qrix -fq1

26.04.2011  23:38     2.027.900.928 xxx.Adx
(also 1934,0 MB)

Gesamtzahl Indexeinträge = 92099303
verschiedene = 39765573

Der resultierende Index ist also knapp 300MB groesser, als
bis kurz vor seiner endgueltigen Generierung abzusehen gewesen
ist, insbesondere sind nur noch 120MB "Luft" bis zur 2GB-Grenze,
was stoerend wenig ist, da die .adx-Dateien scih nach einer
Indexierung bekanntlich rasch um ca. 15% vergroessern.



Datenbank 2:

a) Nach index -fi1 - at 2

26.04.2011  21:49       454.402.048 yyy.Adx
26.04.2011  21:54         1.305.799 ii1
26.04.2011  21:54         1.312.510 ii2
...
26.04.2011  23:07           873.954 ii1166
26.04.2011  23:07           475.044 ii1167
            1168 Datei(en),  1.976.624.390 Bytes


b) Waehrend qrix -fq1

26.04.2011  21:49       454.402.048 yyy.Adx
26.04.2011  23:33     1.134.035.206 ii1
26.04.2011  23:33       138.765.109 ii2
26.04.2011  23:33             2.048 newinx
               4 Datei(en),  1.727.204.411 Bytes


c) Nach qrix -fq1

26.04.2011  23:38     1.897.740.288 yyy.Adx
(also 1809,9 MB)

Gesamtzahl Indexeinträge = 89013023
verschiedene = 39617357

Hier ist die Diskrepanz zwischen Groesse des letzten Zwischen-
Ergebnisses und resultierender .adx-Datei wie auch im ersten
Indexlauf kleiner als bei Datenbank 1 und betraegt "nur" 150MB.

Der Unterschied der .adx-Groessen zwischen Datenbank 1 und 2
vergroessert sich im zweiten Indexlauf um weitere ca. 100 MB auf
insgesamt mehr als 120MB, obwohl die folgende Ueberlegung zeigt,
dass die .adx-Datei von Datenbank 1 ~eigentlich~ sogar (minimal)
kleiner sein koennte/sollte als die von Datenbank 2:

Die "Netto-Groessen" der endgueltigen ii-Dateien aus Lauf 1 und 2
(wo ja bereits viel zusammengefasst ist) ergeben zusammen:

Datenbank 1: 1.672.920.156 = 1.595,4 MB = 82% der Indexgroesse
Datenbank 2: 1.673.056.322 = 1.595,6 MB = 88% der Indexgroesse


Koennen Sie anhand dieser Messungen einschaetzen, ob die Abweichungen
innerhalb des Erwartbaren sind oder ob es Hinweise auf eine Fehlfunktion
von index oder qrix gibt?

Und eine vielleicht etwas konkretere Frage: Gibt es eine Schwelle
von Satznummern pro Schluessel, oberhalb der das eigentlich zu
begruessende Zusammenfallen zu einem sehr unguenstigen Speicherverhalten
fuehrt?

[Ich habe bislang mit folgender empirisch gewonnener Formel aus einem
Komplettabzug qrix -fd die Groesse der Indexdatei eigentlich recht
praezise abschaetzen koennen:

Fuer jeden Schluessel ist der Beitrag:

$delta_l + $CFIX + $CCNT*$cnt + $CLOG*log($cnt);

Dabei:
$delta_l die um die Uebereinstimmung mit dem vorigen Schluessel
  reduzierte Laenge des Schluessels
und Konstanten
$CCNT = 6.8;
$CFIX = 10.5 - $CCNT;
$CLOG = 24;
]

viele Gruesse
Thomas Berger


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAk23Q0oACgkQYhMlmJ6W47Og0QP/bv6/ZH/NwlXaFkBnrILBTvv8
Tj1atmj5s5MiPxuN8wACr1TYaP4PB7JAiYxkB3Y/kRTBFdD4iCQlZXpic3Y2gOQg
BKvScNHKc9WJHinuLqgTjxJ/r5BbvhQz1vsX1QTZFblZl7cWVadHlLCrqH9uQhJu
ZhHL5lN36XWFy42+t5s=
=ggdc
-----END PGP SIGNATURE-----



Mehr Informationen über die Mailingliste Allegro