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

[Fischer, Thomas]

Hallo Herr Eversberg!

> 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.

Der Artikel http://jimbojw.com/wiki/index.php?title=Understanding_Hbase_and_BigTable erläutert etwas anschaulicher die Struktur von "BigTable" bzw. HBase. Und siehe da, als alter Allegro-Nutzer hat man keine ernsthaften Probleme, die Struktur zu verstehen, unter anderen weil "The hardest part for me learning Hbase was unlearning what I already knew about relational databases."
Ich vermute, dass man ohne größere Anstrengungen die Datenstruktur von Allegro auch als "sparse, distributed, persistent multidimensional sorted map" beschreiben kann, wobei "multidimensional" etwas begrenzt ist (<4?) und zu "distributed" vielleicht noch etwas nachgearbeitet werden müsste (*_N.xld-Dateien auf verteilten Servern?).
Da derzeit viel über "nicht so sehr relationale Datenbanken" (Stichwort: NoSQL, z.B. http://de.wikipedia.org/wiki/NoSQL) geredet wird: wäre es an der Zeit, sich dort mal mit Allegro einzubringen?

> 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.

Ich habe immer noch so etwas wie ein A99 als Client im Hinterkopf, da müsste aber wohl die Interaktion mit den Daten optimiert werden; bei Avanti zeigt sich jedenfalls eine sehr starke Abhängigkeit der Reaktionszeit von der Zugriffszeit auf die Daten.
Konzeptionell merke ich, dass ich ein Programm brauche, mit dem ich die Datenbank pflegen kann: neue Einträge erzeugen, eventuell mit Querverweisen, vielleicht neue Normtabellen einfügen, globale Ersetzungen auf irgendwelchen Ergebnismengen durchführen...
Völlig unabhängig davon kann ich die Suche auf dem Datenbestand sehen, da leistet solr schon sehr gute Dienste (wenn man die richtigen Umsetzungen für Umlaute wählt und einen passenden Stemmer...).

> 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.

Naja, nicht ganz. Was erwartet wird, ist oft ein "facettiertes Browsen", da muss man sich schon ein paar zusätzliche Gedanken machen. Und das ist so weit von den Registern dann auch nicht mehr entfernt.

Mit freundlichen Grüßen
Thomas Fischer