Index oder nicht Index?

Der Anfang: Ein Problem aus den 90ern

In den frühen neunziger Jahren saß ein junger freiberuflicher Fernsehjournalist in einer kleinen Bürogemeinschaft vor einem sensationellen PC. Mit 40 MHz Prozessor, 40 Megabyte Festplatte und einem Modem, das direkt aus dem Rechner heraus Faxe verschicken konnte. Und wenn die Initialisierungsdateien von DOS richtig geschrieben waren, konnte man sogar mit den beiden angeschlossenen Laptops (damals noch schwer und groß) Daten austauschen.

Mit Windows 3.0 wählte er sich kostenpflichtig in wissenschaftliche Datensammlungen ein und zog Fachliteratur auf seine Festplatte. Über CompuServe hatte er eine erste Mail-Adresse und die Vorzüge von Newslettern und online einsehbaren Zeitungsartikeln entdeckt. Und dann saß er eines Tages vor seinem Computer, wusste genau: "Zu diesem Thema hatte ich doch vor ein paar Monaten noch einige spannende Texte abgespeichert!"

Aber halt: Damals konnten Dateinamen nur 8 Buchstaben lang werden, die waren oft mehr als kryptisch. Und selbst wenn man versucht hatte, die irgendwann angesammelten, hunderten, tausenden Dateien in einer sinnvollen Ordnerstruktur zu sortieren: Wie sollte man nun unter den Dateien genau die finden, in denen das Gesuchte stand?

Lösung: Einfach selbst programmieren

Der junge Journalist hatte auf einem sehr guten Gymnasium in den siebziger Jahren (kaum zu glauben, aber wahr) die Gelegenheit, am ersten jemals gebauten Personal Computer, einem Commodore PET, die Grundzüge der Programmierung zu erlernen. Er erinnerte sich an so etwas wie Dir All oder Read all oder If Instr("dieswort", "istinjenemsatz") then...

Er setzte sich hin, schrieb ein Script und fand, was er suchte. Und weil er das öfter brauchte, entwarf er sogar eine einfache Benutzeroberfläche dafür. Und klar, wenn man seine inzwischen 100 Megabyte Daten auf diese Weise durchsuchen wollte, dauerte es eine Zeit bis das Ergebnis vorlag - trotz inzwischen gut 100 Megahertz im Hauptprozessor. Aber endlich konnte man finden, was man suchte!

Programmieren war damals übrigens harte Arbeit. So ein Programm bestünde ausgedruckt aus hunderten Seiten Text, mit unzähligen speziellen Aufrufen, Variablen, Subs - kein winzigster Tippfehler wird verziehen. Harte Arbeit für Hirn und Finger, aber auch entspannende Knobelei... und über die Jahre auch ein immerwährender Nebenerwerb zur journalistischen Arbeit.

Die Index-Revolution... oder doch nicht?

Die Zeit verging, und es gab neue Entwicklungen. Im neuen Windows sollte zur Dateisuche ein Index vorhanden sein, mit dem man Dateien schnell findet! Ein Index? Irre Idee! Einfach eine Art Inhaltsverzeichnis für jede Datei, in dem genau aufgelistet ist, in welcher Datei welche Worte stehen. Schluss mit mühsamer Einzelsuche durch alle Dateien. Genial. Oder?

Die Realität der Index-Systeme

Die ersten Indexe waren Monster:

Aber Index-basierte Systeme wurden immer besser, setzten sich größtenteils durch. Trotz einiger Komplikationen und des immensen Aufwandes, den die Pflege eines Index erfordert:

Weil direkte Suche ohne Index aber eindeutige Vorteile bietet, blieb die Nachfrage nach klassischer Oldschool-Volltextsuche bestehen. Im Lauf der Jahre und Jahrzehnte entstanden immer neue Versionen von FINDIT. Genutzt auch von Konzernen wie der Siemens AG, Behörden, Mittelständlern, Freiberuflern, ambitionierten Privatnutzern. Doch es blieb eine Nischenlösung für besondere Aufgaben.

Der Durchbruch: Sommer 2025

Dann kam der Sommer 2025. Der nicht mehr ganz so junge Journalist musste eine Weile das Büro hüten und hatte da so ein kleines Zusatztool im Blick: Er hatte es mal geschrieben, weil er leise Rechner mag, und kann in einem winzigen Widget nun alle Zustände aller Komponenten seines PC auf einen Blick erkennen. Dort sah er regelmäßig, dass die 6 Prozessorkerne seines mittelkräftigen AMD Ryzen sich die meiste Zeit langweilten. Textverarbeitung? Videos gucken? Im Internet surfen? Die Prozessorlast zuckt kaum. Ausgenommen zum Beispiel Video-Renderer - wenn die ein Video rechnen, nutzen die heutzutage alle Kerne.

Und FINDIT? Ja, das brachte so zwei bis drei der Kerne in Zuckung, aber auch nicht so wirklich. Warum also nicht... mal probieren... den Suchauftrag von FINDIT auf viele sogenannte Threads aufspalten und gleichzeitig laufen lassen, so schnell wie die SSD die Daten liefern kann...

Der erste Versuch: Satz mit X

Und siehe da: Beim ersten Start erlebte der programmierende Journalist eine unglaubliche Geschwindigkeit - bis nach allerkürzester Zeit der Rechner komplett einfror.

Satz mit X, das bringt so nichts. 💥

KI-Unterstützung

Also: Diese modernen KI, die können doch coden - mal die eine oder andere Frage stellen. Und siehe da, die kannten jeden Trick, der diesbezüglich schon mal probiert worden ist, jeden Mechanismus, den moderne Programmiersprachen zur Kontrolle von Multithreading eingebaut haben.

Und mit Hilfe einer KI namens Claude, und immer wieder dritten Meinungen von Perplexity, ChatGPT und Co wurde gebastelt und probiert. Mit frustrierendem Ergebnis. Irgendwann liefen alle Prozessorkerne während eines Suchlaufs auf knapp unter 100 Prozent, aber die Suche wurde nicht annähernd so schnell wie vor dem Absturz beim allerersten Versuch - eher enttäuschend.

Die KI waren sich einig: Die Verwaltung so vieler Threads, das regelmäßige Synchronisieren - all diese Prozesse erfordern selbst so viel Rechenpower, dass man einfach nicht jede Aufgabe beliebig parallelisieren kann.

BI mit einer Idee:

Am folgenden Tag war FINDIT 10 mal so schnell wie sein Vorgänger - kaum noch langsamer als ein Index-basiertes System.

• Normale Datenbestände eines Journalistenbüros: In Sekunden durchsucht
• Größere Archive: Bevor deren Ergebnisse da sind, schafft man vielleicht noch einen kurzen Gang in die Kaffeeküche...

Und das Beste: All das völlig selbstreguliert, ohne Gefahr, den Rechner zu blockieren - selbst wenn man 10 Suchläufe gleichzeitig laufen lässt und noch ein Video rendert. FINDIT teilt sich mit allen anderen einvernehmlich den Prozessor.

FINDIT 6: Features ohne Kompromisse

Und wenn das Ding jetzt SO schnell ist, dann kann man ihm noch jede Menge Features einbauen, an die man vorher kaum zu denken wagte. OCR in PDF? Fuzzy search? Ja warum nicht?

Zumal: Wo ein einzelner Programmierer sich früher monatelang die Finger wund tippte und mühsam nach Lösungen für auftauchende Probleme suchen musste, kann er heutzutage mit Claude kurz die geplante Struktur und einige Besonderheiten diskutieren - und Claude schreibt in Sekunden viel Code. Nicht nur die Kölner Phonetik. Und wenn ein Problem auftaucht? Wurde irgendwo auf der Welt so ein Problem schon mal in einem Fachforum diskutiert? Kein Problem, ... gefunden! Wobei: Häufig sieht eine KI vor lauter Code die einfachsten Lösungen nicht mehr - dann ist die BI gefragt. Aber klar: auch Design und Feinstruktur der Online-Hilfe hätte ohne KI Wochen der Programmierarbeit benötigt. Anstelle einiger Tage, die sich dann doch zu Monaten addierten.

Voilà. So entstand FINDIT 6.

Das Fazit: Ein neuer Champion

Und das Rennen zwischen "Index oder kein Index" ist nicht nur neu eröffnet - es hat einen neuen Champion, zumindest wenn man die Relation zwischen Aufwand und Nutzen betrachtet. Und es nicht um Datenbestände großer Rechenzentren geht.

Allerdings nicht, weil die Indexer (wie in Ihrer Anfangszeit) extreme Ressourcen beanspruchen. Als Findit 6 fertig war, haben wir alle uns bekannten Wettbewerber in einem so fair wie nur möglich angelegten Vergleich getestet. Und haben festgestellt – siehe Vergleichstest – auf moderner Hardware ist die Index-Erstellung kein echtes Problem mehr. Das eigentliche Problem liegt woanders: Wer einen Index aufbauen will, muss für jedes Dateiformat ein Softwaremodul entwickeln, das den Inhalt aus genau diesem Format extrahieren kann. Das klingt einfach, ist es aber nicht: Jeder Parser muss die exakte technische Struktur des Formats kennen und die relevanten Textinhalte von Formatierungsinformationen, Metadaten und binären Strukturen trennen. Jeder Index ist nur so gut wie seine Parser. Und ein Parser muss für jede Dateiformat-Variante explizit programmiert werden. Eine ältere Word-Version? Ein lokaler Format-Dialekt? Eine HTML-Datei mit Formatierungsfehlern? Eine minimal beschädigte PDF? Ein exotisches Format? Der Parser scheitert – und die Datei bleibt im Index unsichtbar.

Findit verfolgt einen grundlegend anderen Ansatz: eine fehlertolerante, adaptive Textextraktion. Es versucht nicht, die perfekte technische Struktur zu verstehen, sondern durchsucht den tatsächlich vorhandenen Inhalt – auch wenn er nicht perfekt oder aus eigentlich unbekannten Formaten stammt. Wo nötig und problemlos möglich, benutzt es dann auch Parser. Wo die Extraktion wirklich für live-Suche zu aufwendig wird nutzt es einen kleinen schnellen Cache, der dann doch fast einem Index entspricht. Aber: beschädigte Dateien, alte Formate, unkonventionelle Strukturen: Findit findet trotzdem, was drin steht und inzwischen eben vergleichbar schnell!

Aspekt	Index-basiert (FileLocator, DocFetcher, etc.)	FINDIT 6 (Pragmatischer Hybrid)
Ansatz	Starre Parser für definierte Formate	Flexibel: Parser wo eindeutig, Rohdaten-Extraktion wo nötig
Format-Varianten	Nur explizit unterstützte Versionen	Auch alte, exotische, beschädigte Formate
Vorbereitung	Minuten bis Stunden für Index	Keine - sofort einsatzbereit
Wartung	Index-Aktualisierung bei Änderungen	Keine Wartung nötig
Abdeckung	48-59% der Dateien (siehe Tests)	Nahezu 100% – pragmatisch statt perfektionistisch
Archive (ZIP, RAR)	Oft nicht oder schlecht unterstützt	Vollständig durchsuchbar, auch verschachtelt
Mail-Anhänge	Meist nicht separat durchsuchbar	Vollständig, auch in Archiven
Geschwindigkeit	Sehr schnell (mit fertigem Index)	Auch schnell – trotz Live-Suche dank Optimierung
Flexibilität	Begrenzt durch Index-Struktur	Beliebige Suchlogik, Fuzzy, OCR

Der entscheidende Unterschied

Index-Systeme sagen: "Ich kann nur lesen, was ich kenne." FINDIT sagt: "Ich lese, was auf der Platte steht – in den wahrscheinlichsten Codierungen, mit pragmatischer Format-Erkennung, notfalls auch als Rohdaten."

An Stellen, wo die Nutzung eindeutig ist, verwendet auch FINDIT spezialisierte Parser und Formatierungsfilter. Aber wenn ein Format unbekannt, beschädigt oder exotisch ist, gibt FINDIT nicht auf – sondern versucht pragmatisch, Text zu extrahieren.

Und dank moderner Hardware und extrem optimierter Arbeitsweise ist dieser pragmatische Weg heute ohne Index möglich – bei alltagstauglicher Geschwindigkeit.

Wann was verwenden?

Happy End :-)

Die Kombination aus:

• Jahrzehntelanger Erfahrung in praktischer Dateisuche
• Moderner Hardware (Multi-Core-Prozessoren, SSDs)
• Cleveren Optimierungen (adaptives Load-Balancing)
• Pragmatischem Ansatz statt Parser-Perfektionismus

...hat ein Werkzeug geschaffen, das den Spagat schafft: Fast so schnell wie Index-Systeme, aber mit nahezu 100% Abdeckung statt 50-60%. Flexibel wie klassische Volltextsuche, einfach wie eine Google-Suche.

Siehe auch

• Erste Schritte mit FINDIT
• Volltextsuche
• Automatisierte Suchläufe
• Hinweise an Administratoren