Hallo Daniela

Allgemein würde ich auch sonst Datenbankliteratur empfehlen, auch zum Thema Joins.

Da hast du sicher recht.

Ehm, nein, kann man nicht, ich würde durchaus mit einigen Megabytes mehr rechnen.

Sicher aber im Verhältnis zum quadratischen Speicheraufwand einiger zig Megabytes der Matrixwerte selbst eher zweitrangig, oder?

Wir haben aber nicht nur die Postings. Zudem nimmt die Zahl der Postings aktuell nicht linear zu sondern eher in Richtung exponentiell.

Das spräche dann aber gegen eine Lösung die so hohe Hardwareerfordernisse hat wie deine, da ansonsten die Platten künftig nicht schnell genug mitwachsen, oder?

2. Die meisten eine ausführliche Anzeige wollen, also sowieso auf die Platte zugegriffen wird.

Nein, diese Information ist direkt in der Datenbank verfügbar.

Du hinterlegst die ersten 500 bytes jedes Postings in der DB?
Das sind unkomprimiert 300MB Daten, lohnt sich das?

Das zurückführen eines Wortes auf seine lower()-Variante kann man übrigens auch als primitive und effiziente Hashfunktion interpretieren.

Aha? Mir wäre neu das dabei eine Zahl herauskommt, die entweder einen Index in einem Array darstellt oder aber direkt eine Speicheradresse.

"Hash-Funktion
aus Wikipedia, der freien Wissensdatenbank

Eine Hash-Funktion (von en. "to hash": zerhacken, dt. Bezeichnung: Streuwertfunktion) ist eine nicht umkehrbare Funktion (ein Algorithmus), die eine umfangreiche Quellmenge (i.d.R. Texte) auf eine wesentlich kleinere Zielmenge (Hash-Werte, i.d.R. natürliche Zahlen und Buchstaben) abbildet."

lower() bildet die umfangreichere Menge der Wörter aus [a-zA-Z] auf Wörter aus [a-z] ab. Kollisionen entstünden z.B. bei den Wörtern "Sein" und "sein", und würden in unserem Fall im 2.Schritt aufgelöst.

wenn wir die häufigsten 65536 Wörter des Archivs (ohne Stoppwörter) in einen optimierten² RAM-Hash legen, wäre das bereits sehr effizient und würde auch bereits mit "normaler" Hardware funktionieren.

Gerade nach den häufigsten Wörtern zu suchen, ist aber nicht sinnvoll. Möglichst gute Treffer erzielt man mit spezifischen Suchwörtern.

Da hast du wiederum recht, für eine Optimierung wären also die häufigsten Suchbegriffe besser geeignet.

Nur in dem Fall, dass eine Dublette eines selteneren Wortes vorliegt müßte dann ein Plattenzugriff erfolgen. In den 65536 zugehörigen Files könnten dann die Dubletten wieder organisiert sein (eventuell wieder Hashes oder Binärbaum oder ne simple Liste).

Wozu zugehörige Files? Du willst aber nicht pro Wort in dem Hash einfach auf ein File verweisen wo eine Liste aus den möglichen Postings drin steht? Dazu brauche ich keinen Hash, dazu reichen Namenskonventionen.

Nein, du meinst wenn man "Javascript" sucht greift man auf das File "Javascript" zu. Das wäre eine Selbstlüge weil man die Suche nach der Datei "Javascript" auf das Betriebssystem/Festplattencontroller abwälzt. Die Hashtabelle liefert stattdesen direkt das Handle der Datei.

Erklär doch mal das Konzept was du da machen willst. Was ich mir aktuell darunter vorstelle, klingt sehr sehr langsam und unsinnig, deswegen denke ich, dass da doch das eine oder andere Missverständnis liegt.

Man nimmt offenes Hashing wie in http://de.wikipedia.org/wiki/Hash-Funktion#Offenes_Hashing definiert, d.h. als Hashwert wird eine Datenstruktur möglicher Schlüssel abgelegt. Diese Datenstruktur kann sowohl Schlüssel/Werte Paare enthalten als auch die Referenz auf eine Datei mit weiteren  ausgelagerten Schlüssel/Werte Paaren.

Die Hashfkt ist auf die häufigsten Suchbegriffe hin optimiert, deren Werte weitestmöglich im RAM gehalten werden (je nach Ausbau). Filezugriffe auf ausgelagerte Schlüsselwörter werden so minimiert.

Ein Werte ist dabei eine Liste von Referenzen auf Postings, wird nach mehreren Schlüsselwörtern gesucht, duchsucht man im 2.Schritt nur die Schnittmenge dieser Listen.

Tschau
  Rolf

PS: Weißt du mit welchem Aufwand eine Teilwortsuche in der DB läuft?