[Allegro] Sehr große Dateien : Neubeginn statt permanenten Aufbohrens?

[Bernhard Eversberg]

Am 09.03.2012 11:19, schrieb Thomas Berger:
>
> Etwas konkreter ist es so: Es ist zwar bereits einmal eine Umstellung
> erfolgt, naemlich von 16bit auf 32bit, diese aber nicht unbedingt
> aktuell mit srch32.exe etc., sondern vor allem bei der Entwicklung
> der Klassenbibliothek ab 1997(?), und damit war auch der Umstieg
> von C auf C++ als Programmierplattform verbunden. Es ist extrem
> unwahrscheinlich, dass die derzeitigen C- und C++-Programme sich
> durch einfaches Umlegen eines Schalters sauber fuer 64bit-Plattformen
> compilieren lassen. Es ist aber durchaus /moeglich/, dass eine
> Umstellung auf 64bit dennoch einfacher sein wird als die Umarbeitung in
> Richtung 32bit plus Support fuer grosse Dateien. Oder dass eine
> Umstellung auf 64bit-Faehigkeit den Code insgesamt so saeubert, dass
> die Erweiterung unter 32bit deutlich einfacher wird. Und letztlich
> ist durch 32bit erweitert die irgendwann faellige Umstellung auf
> 64bit ja nicht unbedingt abgewendet...
>
Und danach wird 128bit fällig, dann 256, dann 1024. Warum nicht gleich
mit der letzteren anfangen?

Aber im Ernst, das allegro-Indexmodell wird denn doch für einen
aufhaltsamen Aufstieg sorgen. Die Zeit für das Ermitteln von
Ergebnismengen wird irgendwann prohibitiv, besonders wenn man auf
die Abschaffung von Stoppwörtern dringt und immer mehr
Anreicherungsstoff reinbringt, der natürlich dann auch wort- und
phrasenweise zu indexieren sein wird. Es würden folglich noch
weit mehr Umbauten und Revisionen fällig, als Berger mutmaßt, und das
an einer schon jahrzehntealten Software. Ist das realistisch? Und
träfe es den Bedarf und die Erwartungen?

Nein, eher über kurz als über lang muß ein anderes Grundkonzept her
und ein Neubeginn. Da bietet sich ein Blick über den Tellerrand an.
Google's berühmtes BigTable hat einerseits gewisse Ähnlichkeiten mit
allegro, es ist z.B. ebenfalls entschieden nichtrelational,
andererseits ist es hinsichtlich Skalierung unschlagbar. Allerdings ist
BigTable proprietär:
   http://en.wikipedia.org/wiki/BigTable
Zum Glück aber ist es hinreichend dokumentiert, so daß die Apache
Foundation einen Klone basteln konnte, namens HBase:
   http://en.wikipedia.org/wiki/HBase
Diese zwei Artikel sind hochinteressant und sollten auf jeden Fall
zuerst rezipiert werden, bevor man sich auf die nächste Migration
begibt um zum nächsten Bit-Gipfel hochzuhecheln. Nur um da wieder
ein Schild vorzufinden: Sorry, das reicht noch nicht.

Zwingend wäre bei Übergang auf so etwas wie HBase eine Client-Server-
Arbeitsweise, monolithisch geht dann nicht mehr. Aber der Vorteil wäre
natürlich die viel strengere und sauberere Trennung von Datenbank
und Oberfläche. Für letztere käme immer noch a30 in Frage, weil es
diesem ja egal ist, von woher es seinen Datenstrom bekommt, wenn er
nur seinem sehr einfachen Protokoll genügt.

Andererseits, wenn man so radikal doch nicht vorgehen will, dann wäre
da noch Solr. Konsequent genutzt, könnte man auf einen Haufen Index-
einträge, die man jetzt hat, verzichten und die Suche danach dann
Solr überlassen. Dessen Suchkonzept ist ohnehin das, was intuitiv
erwartet wird, statt des Blätterns in alphanumerischen Registern.

B.E.