[Allegro] a99 : Entschleunigung wieder entkräftet

[Bernhard Eversberg]

Unter

   ftp://ac14@134.169.20.101/a99.zip

liegt ein a99, in dem wir die vielbeklagte Entschleunigung wieder
rückgängig gemacht haben. Sie ergab sich aus dem Einsatz eines anderen
Unterprogramms für den Indexzugriff, und zwar genauer auf den jeweils
nächsten Eintrag. Das passiert in einer Schleife viele Male
hintereinander, wenn ein Indexausschnitt präpariert wird. Das
"andere Unterprogramm" macht dabei jedesmal wieder einen kompletten
Suchzugriff, beginnend bei der Wurzel des B*-Baums (das ist die interne
logische Struktur des Index), und das sind viel mehr Aktionen als
beim älteren Unterprogramm, das im Index an der gerade vorher besuchten
Stelle weitermacht, als sei inzwischen nichts geschenen. Ist ja auch
meistens nicht, aber in Streßsituationen wie z.B. globalen Ersetzungen
und hochvolumigen update-Aktionen kann's passieren, daß an genau der
Stelle nach dem vorigen Zugriff (Millisekunden vorher) was eingeschoben
oder der Block an der Stelle geteilt wurde - das führt dann zum Abbruch
der Anzeige. (Nicht jedoch zu irgendwelchen Schäden, es sind ja nur
Lesezugriffe! Irritierend, aber ungefährlich.)

Wir könnten letzteres versuchsweise auch dadurch unterbinden, daß wir
vor dem Aufbau eines Registerabschnitts für die Anzeige eine Sperrung
der TBL ausführen lassen! Dann müßte aber a99 u.U. lange warten, bis
es anfangen kann mit der Indexanzeige, und die anderen Prozesse
(glob. Ersetzung oder Update) würden oft unterbrochen, weil ein Satz
erst gepeichert werden könnte, wenn gerade keiner im Index blättert.
Wie gesagt, das ist jetzt ein andersartiger Lösungsansatz, noch nie
ausprobiert und offenkundig ebenfalls mit Nachteilen behaftet.
(Beim Suchzugriff ist es anders als bei der Indexanzeige: da wird
der jeweilige Indexvbereich, in dem gesucht wird, kurzzeitig für
Schreibzuzgriffe gesperrt, aber das läßt sich für den Indexzugriff
nicht in derselben Weise lösen. Bei der Ergebnismengenbildung treten
daher zwar manchmal Langsamkeiten auf, aber keine Abbrüche.)

Was wir hier vor uns haben, ist im Grunde eine alte Problematik,
die schon in den 70er Jahren erkannt wurde: Eine gleichzeitige
Optimierung des schnellen Zugriffs UND der schnellen Index-
Aktualisierung in einem Datenbanksystem ist kaum zu lösen.
(Bei Pica hat man, nebenbei bemerkt, einen statischen Hauptindex,
der regelmäßig on-the-fly erneuert wird und einen kleinen, dynamischen
Zusatzindex nur für die neuen Daten. Das verkompliziert aber die
Zugriffe und das Management ganz gewaltig; es müssen zusätzliche
Serviceprozesse ständig laufen.)

Wir stellen anheim, zu testen, weil wir dann entscheiden müssen,
welches a99 in die V34.8 reinkommt.
a99a würde dann auf dieselbe Weise arbeiten, wir wollen nicht zwei
verschiedene Varianten nebeneinaner haben. Die neuere erscheint ja
momentan wirklich als die deutlich weniger akzeptable.

B.E.