[Allegro] beachtenswerte Punkte bei sehr großen Datenbanken. an was man alles denken könnte/sollte....

[Klaus Lehmann]

Guten Tag allerseits,

ich will mal zusammentragen, was mir so einfällt, passiert ist, ...
wenn es um (sehr große) Datenbanken geht.


grundlage der erfahrungen:
die beiden projekte allegro-zdb und allegro-imd
(auf meinen webseiten gibt es ein paar weitere infos dazu...)


was ist eine große datenbank?
die antwort ist gar nicht so einfach.
es hat schon recht viele "große" datenbanken mit allegro gegeben.
zuerst fällt mit der ÖB-katalog ein, aus berlin, auf einer CDROM.
waren das 'ne knappe mill TA's?!
dann gabs/gibts da nen verbundzettelkatalog, der von BS gemacht
wurde(?)[ich weiss den korrekten namen nicht mehr... 18 mio's?]

allen diesen "großen" allegro-katalogen ist eines gemein:
sicherlich viele, viele datensätze.
aber es gibt keinen sprengstoff!
sie sind normal strukturiert: 20-50 felder. wenig inhalte. ein
verfasser, wie lang kann er sein? eine reihe? 200 zeichen, prust. dat
iss nicks. bei technikfragen technik fragen!



der sprengstoff liegt hier:
===========================

a. GROSSE dateninhalte (pro datenfeld sind mehr als
16KB inhalt gewünscht.) ODER/UND

b. viele (sehr) viele datenfelder: tausende! (stichwort: hfm)

c. GROSSE (sehr) große Datensätze, die jenseits(sic) von 120kb größe
sind. (rechnen wir mal: 8 datenfelder mit je maximal 16KB inhalt, ist
schön größer als der größte der erlaubten datensätze!

d. die tools von allegro. sie sind manchmal etwas "zickig".
stichworte: größe der logdatei; primärschlüssel (größe und exaktheit
desselben)

nur mal so, um bildlich zu werden: was sind 16kb? ne Menge!
man stelle sich 1dina4-seite mit text ohne ende vor! das sind 4kb!
also 4 eng beschriebene seiten; das müsste doch reichen. für einen
bibliothekskatalog! nein, reicht nicht!



was habe ich alles "erfahren".
anfang 2015 dachte ich so ganz naiv: naja 1-2 monate, dann ist allegro-imd "färdsch" (=sächsisch für ?).
es sollte schlimm kommen. die Eiger-Nordwand ist ein Dünenhügel im
Treibsand dagegen ;-)



kleine anmerks zu den obigen aufgeführten punkten:
==================================================

a. man muss aufpassen, wenn man "unbekanntes" material bekommt. man
muss sich der strukturen "erwissen". man muß potientiell lange inhalte
splitten, ehe sie mit update reingefegt werden.
ich hatte eine biographie (=1 datenfeld) von Gaston Rivero, die umfasste 640kb. Die
nächstgrößere BIO (ich meine 1 Datenfeld!) umfasst nur 240kb.....


zu a. ohne das das mit "großen" datenbanken zu tun hat: in einem evang.
archiv krachte es laufend. ich brauchte stunden, um herauszubekommen,
daß der "kollege" megatonnenweise aus der PND in einen datensatz
reinkopiert hatte. allegro gab keine fehler von sich, nur noch
"pffffff" (als wenn die luft ausgeht....)


b. ohne hfm wäre ich "am popo". damals war's: vor ca 7 jahren, als ich
mich mich um ersten male umfrug zum thema imdb. vielleicht erinnert sich
der/die/das eine?
nach der entdeckung von "Kap Horn" (das erinnert mich irgendwie an "hfm"), standen die segel auf "Freie Fahrt"!
anfang 2015 fing ich mit allegro-imdb an. ca 35 Mill. datenfelder
wollen zueinander finden! und sie werden finden!
wenn man hfm !geschickt! anwendet, kann man wahre wunder erwirken.
trotzdem: man denke an die 120kb-regel.!


c. da startet man den update.job. lässt ca 1.000.000 (=1 Mio)
datensätze pro Tag(!) in einer ramdisk zu einander finden!
.-. intermezzo. mal bitte flugs rechnen: 35 Millio's benötigen 30-35
Tage, um fertig zu werden. uff!  .-.
wenn, wenn man nicht die 120kb-regel beachtet. der update.job zeigt
IHNEN den vogel, und bricht sangundSTIMMLos ab! in der logdatei, die
ich DANK an BS, mit UPRO-eigenem namen anlegen kann, steht wenigstens
die satznummer des letzten datensatzes drin, mit ein wenig suchen kann
ich heraus, wo hat der job "pffffff" gemacht.
achja: und neu anfangen darf ich wieder!? nö. man schneidet sich mit
einem editor DAS weg, was in der upzudatenden datei schon upgedated
wurde, und beginnt von neuem: "Rienne va plus".
ups? ja ups! wer kennt einen editor, mit dem ich in 1,5GB (kleine)
dateien reingehen, und mal so 20-40% des ersten inhalts rauschschneide?
klaro: mit ner ald kannst dat nich machen! aber mit ner alg!
wörklöch? da gehst mal mit notepad++ inne alg, und machst. abgesehen,
daß die datei nicht größer als 200-400MB sein sollte (sonst macht n++
leise "pffffff" ;-)   das hatte wir schon!). machste mit n++ deine
datei ganz leise ("pffffff") KAPUTT! alles schon erlebt. die letzten
(drecks)versionen von n++ ersetzen einem das hex00 mit hex20. na dann
prost! radeberger? oder ein riesling? letzteres! ;-)


da hatten wir nebenbei: das NEUE thema "e."
die wahl der wahl! merkel oder was? häh?
ich meine: das richtige werkzeug!
"wir schaffen das!" [das meine ich nämlich, was das unsere
kandisbunzlerin angeht: TOTernst: und ohne ";-" WIR SCHAFFEN DAS!
deutschland wird SEHR dankbar sein, wenn es 1 Millio neue Bundesbürger
gibt! gebährfreudige frauen. facharbeiter und kinder! die
bevölkerungspyramide wird sich freuen! und nicht mehr diese auswüchse
zeigen im bereiche der hüfte!]
OKEEH: weiter!
entweder benötigen wir GROSSE editoren, oder wir benötigen werkzeuge,
die aus GROSSEN dateien kleine machen. (100MB ald-größe ist prima! mit
einem wichtigen nebeneffekt, der in d. noch besprochen wird...)
mit perl,sed,awk usw sollte man gut umgehen können....
und perfekte skriptkenntnisse sind gefordert! auf basis "dos". die
windowsshell ist weniger kompatibel ;-) . es muß alles ab WXP laufen,
sowie 32bit/64bit-unabhängig sein!


d: kommen wir zur "zicke".
ja, allegro ist manchmal eine zicke.  manchmal kräht sie ganz laut, da
weiss man nicht, was der fehler ist. manchmal ist sie wie ein kleiner
luftballon, der mit "pffffff".... da weiss man nicht, war das der
fehler? warum steht das da nicht? errorlevel sind ein fremdes wort.
ups: die fehlermeldung ist aber lustitsch. die gibts ja gar nicht.
aus der praxis: obwohl es die 120kb-grenze gibt, lebten einige (alle?)
meiner 160kb-großen datensätze lustitsch weiter. in ein datenfeld
konnte man schonmal 25kb reinstopfen. allet wurde hübsch angezeigt.
(oder angezickt?) ;-)
aber wehe, wenn man indexte... "pffffff" (dat kennen wir schon!)
ächt passiert: update.job nimmt sich ne datei zur brust. schaufelt sie
rein. bei "the amazing race" knalls#s leise. "pffffff"....
keiner bekommt mit, das acon sicht wert, update.job wird nicht
weitergeführt. "pffffff" eben. keine chance, einen .job kontrolliert
zu beenden oder aufzufangen. derzeit KEINE lösung! (problem: wie sag
ich's meinem skript, daß acon "pffffff" gemacht hat..... wer putzt die
"kaka" weg?
ERGO (da bin ich auch versichert, durfte als guter firmenkunde leider
nie mit nach UNGARN... ;-(              oooooh.....)
im ernst: gogito ergo sum. (mein latein habe ich aus asterix)

also ergo: wir müssen GANZ genau wissen, was wir da reinholen!
das können wir nicht: bei jedem fehler von NEUEM anfangen? 30-35 tage
für einen durchlauf reichen ihm schon.
ihm=eine lenovo workstation mit mittlerweile 82GB ram (KEIN witz!),
allegro-imd werkelt blitzschnell in einer 50GB-ramdisk....
für alle fälle: alles und jeden (einzuspielenden) datensatz CHECKEN!
wenn was den regeln nicht enspricht: einen "automatiseur" einbauen!
so nach dem motto: trenne das Bio-feld von madonna in 10 externe
teile. damit haben ich kein problem, was diwe 120kb-grenze angeht.
[WER es geschafft hat, aufmerksam mitzulesen, wird auf/ausrufen: wat
iss mit de PS chef? jetzt haste 11 PS!

weiter in d: unterwejens:
der PS!
er ist problematisch.
man muss dazu einiges wissen!
-> keine sonderzeichen! in meinen PS lasse ich an die 140 zeichen NICHT
rein. diese werden codiert. würde sie im PS verbleiben, gäbe es
"pffffff"..... nein, im ernst. ich könnte den PS nicht nutzen. es kann
nicht "gematcht" werden.
also: den PS von den nicht normalen acsii-werten entflöhen.

noch wat: prokolldateien dürfen NIE größer als 2GB werden. man denke
dadran! also spiele man eben NICHT mal so 1 mio regisseure in die
filmdatenbank rein. wenn sie das mit UPRO (aus update.job)
mitprotokollieren, haben SIE ein problem! dat wird nich' lustitsch!
"pffffff" ....

noch wat: (frei nach "Angkor Wat"). adx (also a?x)-dateien dürfen NIE
größer als 2Gb werden. und dat jeht sowat von fix, nich? da muß man
ein großer api-kinstler sein! "~x" ist dein freund!
wenn > 2GB, dann beim indexieren ist "pffffff" angesagt.....


e. wurde etwas weiter oben zufällig abgehandelt.



auch nicht verkehrt:
f. wie fissenswertes ;-)

mein allegro hat PS. PS=primärerschlüssel.
hat man mio's an datensätzen, will man sie alle zusammenbringen.
dazu braucht man nen "PS".
ja. der PS muss eineindeutig sein. das ist er auch.
naja. nun habe ich nicht gerade buchtitel in der imd-datenbank
zuverwursten, es sind filmtitel. und die können verdammt LANG sein.

hier mein lieblingsfilmtitel:
20 Gertrude Stein hätte Chaplin gerne in einem Film geseh
en, in dem dieser nichts anderes zu tun hätte, als eine Straße entlang
 und dann um eine Ecke zu gehen, darauf die nächste Ecke zu umwandern und s
o weiter von Ecke zu Ecke (1979)

noch'n'jedicht (frei nach heinz erhardt!)
20 "Ladykracher"x (2002) {Ferngesteuert"Falsches Bett"Maniküre ohne Grenzen"Versaute Kassiererin"Diagnose: Ärztin"6
Jahre"Arschloch/Allergie/Der Dilettant/Fahrstuhlführerin"Damenbindenmaskottchen (#6.1)}

ich habe NOCH nicht herausbekommen, warum diese hauptsachtitel(#20)
NICHT-PS-fähig sind. NOCH muss ich es nicht. ich habe wenige solcher
PS-verweigerer  wie anke engelke (=ladykracher). ca 50-100 filmtitel,
die sich weigern, ein anständiger PS zu sein. es gibt auch
hauptsachtitel, die sind länger alswie 250 zeichen!
auch diese zählen zu den verweigerern. WICHTIG dazu ist: habe ich
einen PS > 250 zeichen, taugt er zu keinem PS mehr. autsch. auch das
problem wird schon noch gelöst werden....



man könnte noch viel schreiben, was mir noch aufgefallen ist, beim
bau, bei der konstruktion von "wirklich großen datenbanken"...
ja, doch noch eins,zwei,drei:
EINS: hätte ich die grenze von 16kb pro datenfeld NICHT, hätte ich ein
großes problem NICHT!
ZWEI: hätte ich die grenze von 120kb pro datensatz NICHT, hätte ich ein
großes problem NICHT!
DREI: hätte ich die grenze von 250 zeichenlänge des PS NICHT, hätte ich ein
kleines problem NICHT! dazu gehört: hätte ich die zeichenbeschränkung
auf wenige&saubere zeichen zur gestaltung des PS NICHT, hätte ich ein
großes problem NICHT! aaah, ich könnte platz sparen, und ich könnte so
manches der anderen probleme nicht erleben.
es greift alles in eins über.



resümierend: mir ist klar, daß einiges von dem da oben geschildertem
aus (alten) dos-zeiten abzuleiten ist. z.B.: die 2GB grenze!
die oft erwähnten 16kb und 120kb sind auch dos bestimmt anzulasten.
MEIN resumme: weg von dos! dos, also 16bit, ist sowas von tot!
hin zu einer 64bit-version von allegro!
die auch dann FREI ist von dem NICHTMEHRBENÖTIGTEN braunen bodensatz
des "dos"-ascii-zeichensatzes!
habe ich ein 64bit-allegro, kann es die fesseln sprengen, die mysql
längst abgelegt hat!


viele grüße
Ihr Klaus Lehmann


ps: die bibliothekare, die sich für allegro-imd und allegro-zdb
interessieren, schreiben mich bitte direkt an.


-- 
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 * Bahnhofstr. 1
zuständiges Finanzamt: FA Hoyerswerda; zuständige Kammer: IHK Dresden;
zuständige Aufsichtsbehörde: Gewerbeamt Radeberg; USt-IdNr: DE247550760
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow. Yes we can!
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 mit VuFind
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2012: mit allegro-utf8 V3 und allegro-vufind auf der IFLA in Helsinki
* 2013: Bolero 64bit. Fußige Noten aufgeblättert (=Die Fußnotendoku)
* 2014: allegro-zdb: endlich. Die Wiedervereinigung! + eBooks
* 2015: allegro-vufind. Endlich! Noch moderner! Web2 auch für Ihren Katalog?