Re: [Allegro] multix klappt nicht bei großenmengen!

Di Mär 13 10:38:33 CET 2012

und es ist wieder passiert:

INDEX d1 wird bearbeitet
indexfehler Nr 233
(ich habe darüber bereits berichtet!)

diesmal sollte DIESER trick funktionieren:

verlagerung von zwei abgeschlossenen bereiche (|2 und |3) nach abx und acx.
die idee war die, daß abx und acx VOR d1 bis d11 beschrieben werden!
nur soweit ist es nicht gekommen. (s.o.)

die situation auf dem verzeichnis sieht derzeit so aus:
ii1 9,19GB
ii2 8,8GB
ii3 4,9MB(sic)
newinx 195MB
adx 290MB
stl 443MB
tbl 2,4MB

ich weiss WIRKLICH nicht weiter!

>>> Index .adx wurde zu groß. Sie müssen was rausnehmen, evtl. eins der
>>> Register zu einem weiteren zusätzlichen Index machen, das wäre kein
>>> großes Problem! Nicht zu zaghaft damit! Oder auf bestimmte Sachen
>>> ganz verzichten, die keiner braucht.
>>
>> nein, mit verlaub und entschuldigung, aber so geht das nicht!
>> wir wollen große register haben. multix MUSS das packen können. es
>> sind doch nur 6,1Mill datensätze. was soll es bei 32Mill werden?
>> wenn wir JETZT schon tricksen sollen.... nee!
>>
> Unsere Variante des BVB hat 24 Mio. Datensätze, wir haben 5 Indexdateien
> gemacht:
> cat.aex : ALL
> cat.afx : TAF   (normal |4)
> cat.avx : VLG   (normal |6)
> cat.agx : URL   (Normal |8)
> cat.adx   alles übrige

> Kann Ihnen die cat.api gerne schicken. Die lief durch mit den 24 Mio Daten.
danke, aber ich habe 6mill stammdatensätze. keine normalen TA's. oder packt die 
cat.api die auch?
ok. ich probiere es gerne mit dieser(speziellen?) cat.api....

>> wie ich h. fischer gerade antwortet habe:,
>> sieht man sehr schön, wie die ii-dateien zu groß werden!
>> ich sage: irgendwie VIEL zu !!!spät!!! greift die multixmethode, und
>> versucht was auszulageren, nur da ist das baby in den brunnen
>> gefallen, und die 2GB sind knapp überschritten.
>>
> Jede einzelne wurde nicht zu groß, die größte ist cat.aex mit
> 2.121.082.880 Bytes
s.o. bitte.

> Wir müssen uns unhaltbare Versprechungen versagen. Für die mittlere
> Sicht KÖNNEN wir nur empfehlen, große Register nicht mit allegro
> zu machen sondern mit Solr/VuFind. Kommt "draußen" auch besser an...
"draussen"? das sich unsere jungen wilden da draussen sich vor freude 
auf die hemdsärmeligen schenkel klatschen? neee... igitt.  ;-) 

gruß k.l.

> B.E.

-- 
Mit freundlichen Grüßen,
Ihr Klaus Lehmann
* http://allegronet.de * eMail: allegronet at t-online.de * phone: 03528-452 807(fax 809) * mobil: 0171-953 7843
* allegronet.de * Klaus Lehmann * D-01454 Radeberg * Kleinwolmsdorfer Str. 37
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow
* Yes we can. Only with allegro. Yes we do. Allways with allegro.
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 with VuFind
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2012: mit allegro-utf8 V3 und allegro-vufind auf der IFLA in Helsinki

Am Dienstag, 13. März 2012 um 09:02 schrieben Sie:

>>> Index .adx wurde zu groß. Sie müssen was rausnehmen, evtl. eins der
>>> Register zu einem weiteren zusätzlichen Index machen, das wäre kein
>>> großes Problem! Nicht zu zaghaft damit! Oder auf bestimmte Sachen
>>> ganz verzichten, die keiner braucht.
>>
>> nein, mit verlaub und entschuldigung, aber so geht das nicht!
>> wir wollen große register haben. multix MUSS das packen können. es
>> sind doch nur 6,1Mill datensätze. was soll es bei 32Mill werden?
>> wenn wir JETZT schon tricksen sollen.... nee!
>>
> Unsere Variante des BVB hat 24 Mio. Datensätze, wir haben 5 Indexdateien
> gemacht:
> cat.aex : ALL
> cat.afx : TAF   (normal |4)
> cat.avx : VLG   (normal |6)
> cat.agx : URL   (Normal |8)
> cat.adx   alles übrige

> Kann Ihnen die cat.api gerne schicken. Die lief durch mit den 24 Mio Daten.

>> wie ich h. fischer gerade antwortet habe:,
>> sieht man sehr schön, wie die ii-dateien zu groß werden!
>> ich sage: irgendwie VIEL zu !!!spät!!! greift die multixmethode, und
>> versucht was auszulageren, nur da ist das baby in den brunnen
>> gefallen, und die 2GB sind knapp überschritten.
>>
> Jede einzelne wurde nicht zu groß, die größte ist cat.aex mit
> 2.121.082.880 Bytes

>>> Gar kein Weg für die kurze und mittlere Sicht.
>>> Sie brauchen JETZT eine Lösung, oder?
>>> Im Prinzip können Sie JEDES Register aus .ADX in eine
>>> andere Indexdatei verlagern, mit Ausnahme des Ersetzungsregisters.
>>> Da ist ausreichend Luft für die BVB-Daten.
>>
>> verzeihung: die luft ist ganz dünn für die BVB-daten (s.o.)
>>
> Nach unserer Erfahrung nicht.

> Wir müssen uns unhaltbare Versprechungen versagen. Für die mittlere
> Sicht KÖNNEN wir nur empfehlen, große Register nicht mit allegro
> zu machen sondern mit Solr/VuFind. Kommt "draußen" auch besser an...

> B.E.
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sun250.biblio.etc.tu-bs.de/mailman/listinfo/allegro