Zum 70-jährigen Jubiläum des Bundestages hat ZEIT ONLINE alle Reden des Parlaments verarbeitet und nach Worthäufigkeiten geordnet. Eine solche Menge von Texten bezeichnet man als Textkorpus. In diesem Fall lag das Korpus in einer strukturierten digitalen Form vor und war daher leicht zu verarbeiten. Für unseren Zweck haben wir die Texte in einzelne Wörter zerlegt und für jedes Wort ein neues Dokument erzeugt, welches neben der absoluten Häufigkeit auch die Häufigkeit pro Jahr enthielt. Diese Dokumente haben wir mithilfe von Elasticsearch (ES) indexiert. Dabei handelt es sich um eine weit verbreitete Open-Source-Suchtechnologie, die prinzipiell jedem zur Verfügung steht. ES bietet nicht nur schnelle Suchmöglichkeiten für Texte, sondern hat selbst etliche Features, um diese Texte zu zerlegen (tokenizing) und zu analysieren. So realisierten wir beispielsweise unsere Wortvorschläge bei der Eingabe mit dem sogenannten Completion Suggester.
Während Elasticsearch für uns als Content-Anbieter bewährte Technologie ist, haben wir in Hinblick auf dessen Betrieb bei diesem Projekt neue Wege beschritten. Üblicherweise wird Elasticsearch in einem Rechnerverbund, einem sogenannten Cluster, betrieben. Ein solches Cluster ist darauf ausgelegt, kontinuierlich neue Daten entgegenzunehmen, zu indexieren und redundant zu verteilen. Hierfür ist eine umfangreiche Koordination der einzelnen Knoten des Verbundes nötig, was zwar viele Vorteile, aber auch Komplexität und damit Aufwand beim Aufbau des Clusters mit sich bringt.
Im konkreten Fall ging es jedoch darum, mit überschaubarem Projektaufwand einen nicht mehr veränderlichen Datenbestand nach festen Kriterien hochperformant durchsuchbar zu machen und die dafür benötigte Rechenkapazität punktgenau zur Verfügung zu stellen.
Die pragmatische Lösung lag in einer auf das Wesentliche reduzierten Nutzung von Elasticsearch. Hierfür haben wir den Elasticsearch-Suchkern inklusive der fertig indexierten Daten in einen sogenannten Docker-Container verpackt. Derartige Container sind kleine Einheiten startbereiter Software. Sie sind leicht zu betreiben, weil sie nur wenige, aber klar definierte Anforderungen an die Umgebung stellen, in der sie laufen. Außerdem starten sie vergleichsweise schnell, was sie sehr gut skalierbar macht. Die grobe Idee: Wenn ein Container 200 Requests in einer bestimmten Zeit verarbeiten kann, dann schaffen zwei Container 400 und zwanzig Container 4.000 Requests.
Das stimmt grob, aber abstrahiert ein wesentliches Detail: Ebenso wenig wie in der analogen Welt Schiffscontainer aus eigener Kraft von Hafen zu Hafen kommen, laufen digitale Container ohne zugrunde liegende Infrastruktur nicht. Sie benötigen mindestens Rechenkapazität und Netzwerkanbindung, und diese bekommen sie in unserem Fall (was naheliegend und üblich ist) aus der Cloud. Was es als recht schwammiger Begriff schon vor einigen Jahren ins öffentliche Bewusstsein geschafft hat, bedeutet hier: Angebote für Rechenkapazität, Speicher und Netzwerkanbindung, die in kleinsten Einheiten und praktisch unbegrenzter Menge buchbar sind von Anbietern wie Google, Amazon und Microsoft.
Und in genau dieser Kombination liegt der Clou: Container als Laufzeiteinheit, die sich auf Knopfdruck innerhalb weniger Sekunden erzeugen und wieder stoppen lassen. Und die Cloud als Betriebsumgebung, in der die genutzte Kapazität minuten- beziehungsweise bytegenau abgerechnet wird. Für Projekte wie dieses heißt das: Die Budgetplanung rückt weiter nach hinten und die technische und journalistische Planung weiter nach vorn. Das schafft Raum zum Ausprobieren und beseitigt Hürden, Projekte in ihrem Verlauf größer werden zu lassen. Vor einigen Jahren wäre es notwendig gewesen, für mehrere Wochen oder Monate die maximale Rechenleistung zu buchen, die – möglicherweise nur für wenige Stunden – für ein bestimmtes Projekt benötigt wird. Mit der heute verfügbaren Technologie ist es per Knopfdruck möglich, die benötigte Kapazität kurzfristig und passgenau abzurufen.