nicht angemeldet
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.
Ich sprach an dieser Stelle nur vom Schwanzabschneider. Daß der erstaufbau der Index-Files nicht nach diesem Prinzip arbeiten kann, ist klar. Der startet im Idealfall aber nur ein einziges mal.
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.
Hierüber grübele ich nun schon den ganzen Tag. Irgendwas hatte mich heute morgen noch gestört. Aber die Arbeit geht vor. Inzwischen hat es allerdings 'Klick' gemacht. Bei der Berechnung gehst Du davon aus, für jedes Wort, den gesamten Inhalt des Postings zu integrieren. Das ergibt natürlich solch imense Datenmengen. Aber so ist das gar nicht gedacht. Die Indexfiles enthalten ausschließlich Schlagworte. und die Verweise auf die entsprechenden Archivdateien, in denen das Wort enthalten ist. Damit dürfte der Index
vielleicht auf die doppelte Größe anwachsen, aufgeteilt auf viele Files. Aber mehr auch nicht.
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.
Jepp. Aber da die Index-Files sehr klein sind, sind sie auch schnell geladen. <Behauptung> Der Effekt dürfte sich be der derzeitigen Größe von 40 MB bereits sofort bemerkbar machen. </Behauptung>
Viele Grüße
Kess