Hi Rolf

Das wird genau so gemacht in der neuen Suche.

Aha, läuft Stufe 2 direkt auf den Archivdateien oder auch in der DB?

Weder noch.

Nein, das würde einen zusätzlichen Join bedeuten, zudem müsste eine Referenz bei uns wohl 8 Byte gross sein. Es bedeutet also speicherplatzmässig kaum Gewinn.

verstehe ich nicht, verstehe wohl auch zu wenig von DBs ...

Du willst eine Matrix aus Schlüsselwörtern und Postings aufbauen. Das bedeutet 3 Tabellen, eine mit den Schlüsselwörtern, eine mit den Postings und eine die verlinkt. Wir haben aber sehr viele Postings und sehr viele Schlüsselwörter, das bedeutet auch entsprechend grosse IDs um die beiden zu verlinken. Nehmen wir jetzt doch mal 4 Byte grosse IDs wobei ich denke das es eng werden könnte. Du hast jetzt 4 Byte in der Schlüsselworttabelle und nochmal 2 * 4 in der für die Postings. Macht allermindestens 8 Byte pro Zelle in deiner Matrix. Zusätzlich noch jeweils die erste Spalte und die erste Zeile mit den Postings resp den Schlüsselwörtern drin.

Du legst also lauter Paare (wort,posting) ab???

Paare ja, aber (wort, link auf posting). 8 Byte würden nur für Links draufgehen, sicherheitshalber bei grösseren IDs 16, das wären 8 resp 16 Buchstaben. Das ist nicht wirklich viel unter der durchschnittlichen Wortlänge. Dafür dann noch einen zusätzlichen Join... Ich denke nicht dass das ein guter Tausch wäre die ID zu benutzen anstelle dem Wort direkt.

Ein Hasharray kann erst recht nicht zwischen Gross- und Kleinschreibung unterscheiden.

Deswegen ja Stichwörter nur in klein und casesensitiv in der 2. Stufe abklären. (hei ich soll deine sourcen lesen und du ließt nicht meine Postings? ;)

Damit sparst du zwar Speicherplatz in deiner Version mit Links, nicht aber wenn du direkt das Wort benutzt. Die zweite Stufe der Suche hinzuschalten ist aber sehr teuer, vorallem da du die Datenbank auch einfach einen zusätzlichen Index auf UPPER(wort) legen lassen könntest. Ok, das braucht wieder Speicherplatz.

Dazu kommt noch, das eine Hashtabelle um effizient zu sein eigentlich komplett im Speicher gehalten werden muss.

IMHO machbar.

IMHO unmöglich. In der Hashtabelle brauchst du alle Worte. Mein Duden hat 120000 Worte drin, nehmen wir mal  an, so viele Worte haben wir auch (wir haben ja auch noch falsch geschriebene Worte, Dialekte und Fremdsprachige). Dazu müssten es den MessageIDs nach fast 600000 Postings sein, nehmen wir mal an 500000, ID-Grösse 4 Byte. Nehmen wir weiter an, das Durchschnittsposting hat 25 Wörter was auch sehr wenig ist. Wir benutzen 4 Byte Hashwerte. Damit hätten wir, unbesetzte und Doubletten und sowas ausgenommen: 500K Postings * 4 Byte für die ID * durchschnittlich 30 Worte * 4 Byte für deren ID ~= 230 MB. All das sind sehr sehr klein geschätzte Werte, überläufe und nicht gefüllte Hashwerte kommen da auch noch dazu. Ebenso dazu kommt noch Selfhtml, Featureartikel und einiges andere. Dann noch weitere, wenn auch viel kleinerer Index für die ganzen Fremdsprachen... Dazu auch noch entweder die Volltextindizes oder die Postings direkt die während dem Verarbeiten auch im Ram gehalten werden wollen

PS: Kann man das Konzept (nicht die sourcen) irgendwo nachlesen,
... zum schlauer werden nicht zum meckern.

Aktuell gibt es nichts öffentlich verlinktes, nein. Ich werde es die Tage mal nachholen, kann aber noch dauern.

Gruss Daniela