nicht angemeldet
Je genauer die Suche eingegrenzt wird, d.h. mit je mehr Suchbegriffen das gewünschte Ergebniss eingegrenzt wird, desto länger dauert die Suche.
Das ist auch bisher schon so.
Allerdings: Wenn der erste Suchbegriff gut projeziert, dann werden die zusätzlichen Vergleiche mit weiteren Suchbegriffen nur noch für die Treffer des ersten Suchbegriffs durchgeführt.
Und da nach meiner Erfahrung *kein* Suchbegriff mehr als 20% Treffer erzielt, sind die zusätzlichen Abfragen ziemlich erträglich. Will sagen: Niemand sollte Angst davor haben, seine Suche so exakt wie möglich zu spezifizieren!
Doch auf die Faulheit der Menschen bauend, gehe ich davon aus, daß niemals mehr als eine Handvoll Suchbegriffe eingegeben werden.
Aber wenn es dort passiert, dann ist mir das lieber, als wenn der Anwender sich erst mit vielen nacheinander durchgeführten Suchvorgängen an sein Ziel herantasten und die Treffermenge einschränken muß. *Das* dauert nämlich noch länger, und es frustriert außerdem die Anwender.
Also kurz gesagt, mit einem gescheiten Hash steht und fällt alles. Dabei muß von vorneherein vor allem auf Zukunft gebaut werden.
Yep. Ich würde so etwas auf 3-5 Jahre dimensionieren, also für Faktor 5-10 des heutigen Archiv-Volumens. (Stefan: Wie lange reicht denn der teamone-Server überhaupt noch, wenn wir einfach gar nichts ändern? Wieviel Platz hast Du dort?)
Mit geschickter Codierung kann man natürlich erreichen, daß während der Archivierung jedes Indexfile nur einmal angefaßt wird.
Darüber habe ich mir schon eine Weile den Kopf zerbrochen.
Bei einem Vollindexer geht es einfach nicht (der müßte entweder alles im Speicher halten oder tausende von file handles parallel bedienen dürfen - für beides ist der Server wohl zu klein); bei einem inkrementellen Indexer wie im Schwanzabschneider ist Methode 1 (alles im RAM) machbar.
Trotzdem werden die vielen Filezugriffe Zeit kosten. Während dieser Zeit muß das Forum unbedingt gegen Schreibzugriffe geperrt sein.
Das ist auch heute schon so - Zitat: "Bahnschranke". Ansonsten würden verschiedene Prozesse gleichzeitig in der Forumshauptdatei herumschreiben ...
Das Problem sehe ich vielmehr im Plattenplatz. Mal eben ein paar GB werden Stefan mit Sicherheit nicht zur Verfügung stehen.
Eben deshalb habe ich ja versucht, den vielen Speicherplatz "billig" zurück in Zeit zu tauschen, auf Kosten von vielen, vielen Dateizugriffen.
Wenn man
1. das, was bisher in einer Zeile der Indexdatei steht, in eine Datei eines Hash-Verzeichnis-Baums schreibt,
2. in der bisher angedachten neuen Index-Hash-Struktur nur einen *Verweis* auf diese Datei einfügt und
3. pro Indexzeilenlesen also eine zusätzliche (kleine) Datei einliest,
dann belegt diese kombinierte Lösung 'nur unwesentlich' mehr Platz als die bisherige (also jedenfals nicht 200 mal so viel):
a) Die Postings werden wieder nur einmal abgelegt,
b) zusätzlich entsteht eine separate Indexstruktur mit Verweisen, die Posting nur ca. 30 Bytes groß ist, aber jedes Posting ca. 100 mal referenziert.
Bei 50000 Postings wäre diese Struktur derzeit insgesamt 150 MB groß und würde im selben Tempo weiter wachsen wie das (etwa halb so große) Archiv.
Vielleicht kann man diese 30 Bytes durch effiziente Kompimierung auf 20 oder so drücken - wiederum auf Kosten von Zeit zur Codierung (Indexer) und Decodierung (Sucher), natürlich ...
Dies wäre dann äquivalent zu CREATE INDEX in SQL. Insgesamt würden wir Faktor 5 an Speicherplatz bezahlen, um näherungsweise logarithmische Suchzeiten zu erhalten - das sieht rentabel aus.
(Nebenbei: Etwa dieselben Größenwerte würden wir auch mit einer SQL-Datenbank erhalten - die kann ja auch nicht zaubern, sie würde uns lediglich die Codierung der ganzen Indexzugriffe abnehmen.)
Durch die vielen zusätzlichen Dateizugriffe existiert ein hoher "Sockeleffekt", d. h. der relative Gewinn der Suchzeit wird zwar mit zunehmender Größe des Archivs immer größer, aber erst ab einer bestimmten "kritischen Masse" überhaupt eintreten.
Ich wollte, ich könnte auch nur annähern abschätzen, für welche n
sockelfaktor * O(log (n)) <= O(n)
ist ... davon hängt nämlich *alles* ab.
Wenn n für eine "Datenbanklösung" so groß sein muß, daß der Server darunter dann in jedem Fall zusammenklappt, dann haben wir einfach verloren.