OODBMS - Objektorientierte Datenbank

[mschnell]

Willst Du die Google Suchmaschine nachprogrammieren ? Frag da doch 'mal , ob die Dir deren Software überlassen

Kommst Du denn mit ausschließlich "scharfer" Zuordnung aus, oder brauchst Du auch noch "Tippfehler" / "Schreibweise" Toleranz ?

diese Struktur hätte aber leider bei der Datenmasse nicht mehr genug Platz im Speicher

Bei einem 64 Bit System hat alles Platz im virtuellen Speicher. Ob die Speicherverwaltung des OS in diesem Fall effektiv genug arbeitet ist eine andere Frage. Es könnte aber durchaus sein, das ein Hash-System im virtuellem Speicher besser passt als eine Datenbank. (Für Texte liegen in den Hash-Tabellen beispielsweise die binären 128 Bit (16 Byte) MD5 Checksummen des Textes. Da hält sich der Speicherbedarf durchaus in Grenzen. Um den Zugriff auf die kompletten Texte nach dem eigentlichen Suchvorgang kümmert sich die virtuelle Speicherverwaltung gut genug.)

Ein Hash-System ist recht einfach zu programmieren und man kann mit sehr geringem Aufwand dynamisch zusätzliche Hash-Tabellen anlegen, wenn man neue Such-Tabellen ("Eigenschaften") braucht. Da es hauptsächlich auf schnelles Suchen und nicht auf schnelle Daten-Einfügen ankommt, ist es auch nicht schlimm, dass das Vergrößern von Hash-Tabellen (z.B. bei Füllgrad über 80 %) ein komplettes Umspeichern (mit zukünftigem Aus-Swappen der veränderten Seiten !!) erfordert.

Hashen ist für virtuellen Speicher ideal (besser als binäres Suchen) weil in vielen Fällen der gewünschte Satz mit einem oder wenigen Lesezugriffen gefunden ist, was das Swappen minimiert.

Noch (viel) langsamer beim Einfügen, aber schneller beim Suchen und Platz-Effektiver sind natürlich streng sortierte Tabellen. Aber Binärbäume (wie eine Datenbank, im virtuellen Speicher oder auf der Platte, deterministisch schnell beim Einfügen aber aufwändig zu programmieren) brauchst Du eigentlich nicht. Und referentielle Integrität (wie jede ordentliche Datenbank, kommt wohl hauptsächlich beim Löschen von Sätzen zu tragen) brauchst Du vermutlich überhaupt nicht.

Die Funktionalität einer Datenbank ist also wohl "Kanonen auf Spatzen".

In jedem Fall scheinen mir die XML- (Text-) Dateien allenfalls als Rohdaten, nicht aber als aktive Information für die Suchvorgänge sinnvoll zu sein.

-Michael

[Antrepolit]

Für das, was du da beschreibst, gocher, sind XML-Dokumente vermutlich die falsche Wahl gewesen. Für Massendaten dieser Art sind eben RDBMS vorgesehen. Dann braucht es eben 40 Tabellen und mehr. Etwas mit XML zu "machen" und im Nachhinein zu "hoffen", dass es schon irgendein DBMS gibt, das mit XML-Dokumenten umgehen kann, klingt etwas Kopf- und Fußlos. Mitunter solltest du dein Projekt halt als Dateien auf der Platte belassen. Dann brauchst du halt nur effektive Ablagesysteme. Wenn das jedoch eine kommerzielle Lösung für etwas werden soll, solltest du dir überlegen, ob du nicht auf einem Holzweg bist. Ich finde XML-Dokumente nicht optimal, da der Anteil an Meta-Daten immens ist. Und was die beschriebene Objekt-Struktur mit harten und weichen Referenzen angeht, so klingt das (beim überfliegen) nach der klassischen Normalisierungsfrage eines RDBMS.

[mschnell]

Behalte doch einfach die XML-Dateien als Rohdaten und lese sie in Deine "Suchgmaschine" ein: (1) beim Start alle, und (2) suche alle neu dazugekommenen/veränderten auf Anweisung und/oder nach "Verzeichnis-verändert" Flag des OS und/oder nach Zeitbedingung. Dann kann das Suchen komplett im (virtuellen) Speicher passieren. Die RAM-Größe kannst Du angepasst an die Chip-Preise und die Datenmenge skalieren, wenn zu viel gewappt wird. Wenn Du mehrere Client-Rechner bedienen musst, kannst Du ein proprietäres TCP/IP-Protokoll aufbauen. (Wir machen sowas mit RamOBJ: leicht zu handhabende RPC-Aufrufe, kost' aber Geld.)

-Michael

[gocher]

Die Suche ist kein Problem, die ist durch den Suchindex sehr schnell, XML-Dateien kann man recht gut indizieren! Mein Problem sind eher die Abhängigkeiten und deren Überprüfungen bei Veränderungen, und die Arbeiten die danach folgen, teilweise kann ich die natürlich in einen Daemon-Prozess auslagern, damit habe ich auch schon begonnen, dadurch wird man beim Bearbeiten nicht so sehr gebremst.
Übrigens mit einer Google-Suchmaschine hat diese Lösung nicht viel zu tun, eher mit einem Wicki, aber das Wicki-Konzept unterstützte halt nicht annähernd die Anforderungen und ist für den Anwender etwas umständlich.

[mschnell]

Auch bei der Überprüfung der Abhängigkeiten ist der Hauptsächliche Rechen-Aufwand des Algorithmus sicher das Suchen.

Wenn Du darauf bestehst, "aktive" XML-Dateien und eine Standard-Datenbank zu verwenden, dann berichte später von Deinen Ergebnissen.

-Michael