Rund um den Index: Vertiefende Infos, Teil II

Im letzten Blog-Beitrag zum Thema Enterprise Search hatte ich schon einen kurzen Vorgeschmack darauf gegeben wie man Indizes so verwendet, dass ein Benutzer aussagekräftige Suchergebnisse erzielt. Man kann sogar sagen, dass es bei der unternehmensweiten Suche in erster Linie um das Erstellen, Bearbeiten und Durchsuchen des invertierten Index geht, den ich beim letzten Mal beschrieben habe. Um die Betrachtung zu vereinfachen hatte ich dabei allerdings einige Details außen vor gelassen. Dieses Mal werden wir ein wenig tiefer in das Thema eintauchen und untersuchen, wie das zugrunde liegende Modul den Index für eine sicherheitsorientierte Suche optimiert. Auf die Plätze, fertig, abtauchen!

Jenseits des Mini-Index

Die praktische Umsetzung der unternehmensweiten Suche bedeutet, dass man mit einer enormen Zahl von Indizes umzugehen hat. Ich habe den Index, der aus den Schlüsselwörtern in einer Einzeldatei erstellt wird, als Mini-Index bezeichnet. Bei der Indizierung eines typischen Dateisystems innerhalb eines Unternehmens, das Hunderttausende oder vielleicht sogar Millionen von Dateien umfasst, ist es effizienter, die Mini-Indizes zu größeren Einheiten zusammenzufassen. Bei der Open-Source-Suchmaschine Lucene werden die zusammengeführten Mini-Indizes als Segmente bezeichnet.

Der Prozess der Zusammenführung (eigentlich ein Merge-Sort-Prozess) funktioniert folgendermaßen: In der Regel gibt es einen Parameter für den Zusammenführungsfaktor – einen von sehr, sehr vielen Parametern dieser komplexen Software –, der den Indizierungsprozess für die Zusammenfassung mehrerer Mini-Indizes in einem Segment steuert. Gehen wir beispielsweise von zehn Mini-Indizes aus. Wenn zehn Segmente gebildet werden, werden diese zu noch größeren Segmenten zusammengefasst. Und dieser Prozess setzt sich so fort, dass es nie mehr als zehn Segmente und zehn Mini-Indizes gibt.

Natürlich können die Segmente unglaublich groß werden und invertierte Indizes mit einer Größenordnung von mehreren Gigabytes enthalten. Ab einem bestimmten Punkt ist eine Optimierung, die Segmente zusammenfasst, dann nicht mehr sinnvoll. Warum? Die Verarbeitung derart großer Segmente ist äußerst rechen- und Disk-IO-intensiv. Es gibt sogar einen Parameter, der die maximale Größe eines Segments kontrolliert, um dieses Problem innerhalb des Zusammenführungsprozesses zu vermeiden.

Dieses verteilte Indizierungsschema hat einen großen Vorteil: Es ist unglaublich schnell.

Fügt man eine neue Datei hinzu, muss mithilfe der Indizierungsfunktion lediglich ein neuer Mini-Index erstellt werden. Das war’s. Die Suchsoftware durchsucht jedes Segment und jeden Mini-Index einzeln, führt anschließend die Ergebnisse zusammen und sortiert sie. Ist eine Datei geändert worden, markiert der Indexer die betreffenden Dokumente intern als gelöscht (was ebenfalls sehr schnell passiert) und erstellt einen neuen Mini-Index für die aktualisierte Datei.

Der Hauptvorteil: Bei Änderungen muss nicht gleich das ganze System neu indiziert werden. Dies bezeichnet man als „inkrementelle Indizierung“. Ein ausgesprochen effektives Konzept. In der Praxis setzt das natürlich voraus, dass sich rasch feststellen lässt, welche Dateien hinzugefügt oder verändert worden sind. Diese Informationen erhält man allerdings nicht ohne weiteres von einem Dateiserver (es sei denn…..Sie nutzen Varonis DatAdvantage).

Schnelle Suche dank verteilter Indizes

Ein weiterer Vorteil dieser Indexstruktur besteht darin, dass sie sich ausgezeichnet für eine verteilte Verarbeitung eignet. So können Sie beispielsweise auf einem Multi-Core-Rechner jedem Segment einen eigenen Thread zuweisen, sodass die Suchergebnisse in Sekundenbruchteilen dargestellt werden.

Und es gibt noch eine weitere Möglichkeit, mehr Leistung aus dieser Indizierungsstruktur herauszuholen. Dazu dient eine noch höhere Speicherschicht, die mehrere Segmente umfasst. Bei Lucene werden diese Zusammenfassungen als Shards bezeichnet.

Sie können sich das so vorstellen, dass der invertierte Index zwischen den Shards aufgeteilt wird: Wenn ein Dokument indiziert wird, wird es einem einzigen Shard zugewiesen beziehungsweise an diesen weitergeleitet. So können Sie zum Beispiel eine eindeutige Dokumenten-ID zuordnen, die den Mini-Index des Dokuments an einen bestimmten Shard weiterleitet.

Warum das sinnvoll ist? Das Dateisystem wird auf diese Weise effektiv in kleinere und effizientere Suchkategorien unterteilt. Beispielsweise kann ein Shard für Dateien aus dem Bereich „Marketing“ verwendet werden und ein anderer für Dateien aus dem Bereich „Vertrieb“ und so weiter. Bei Lucene sind Hunderte solcher Shards zulässig.

Durch die Unterteilung des Speichers in Shards lassen sich außerdem die jeweils gewünschten Inhalte herausfiltern. Mitarbeiter der Marketingabteilung sind beim Suchen nur an Marketingdateien interessiert. Daher durchsucht die Suchmaschine nicht unnötig den gesamten Index, sondern beschränkt sich auf den Marketing-Shard. Mit diesem Schema verfügen Sie zudem über ein rudimentäres System, um sicherzustellen, dass Suchergebnisse nur autorisierten Nutzern angezeigt werden: indizierte Marketinginhalte nur Mitarbeitern aus der Marketingabteilung, juristische Inhalte nur Mitarbeitern aus der Rechtsabteilung und so weiter.

Sicher suchen: keine leichte Sache

Nur bei ausgesprochen wenigen Unternehmen läuft das Ganze so einfach ab wie oben beschrieben. Im realen Leben lassen sich natürlich Dateiberechtigungen festlegen, so dass nur Nutzern aus der Marketing- und Vertriebsabteilung oder aus der Rechts- und der Finanzabteilung oder aus anderen Gruppenkombinationen ein Lesezugriff gewährt wird.

Sollen für die Suchmaschine differenziertere Berechtigungen gelten, so besteht eine Möglichkeit darin, dass der Indexer Dokumente intern mit einem Sicherheitsfeld markiert. Lucene und andere Suchmaschinen stellen diese Option bereit.

Dann muss eine Klassifizierungskonvention festgelegt werden. Dateien, auf die Mitarbeiter aus Marketing und Vertrieb zugreifen können, werden mit dem Vermerk „Marketing/Vertrieb“ markiert. Der Indexer kann so programmiert werden, dass er dem Sicherheitsfeld beim Durchsuchen des Dateisystems die richtigen Kategorien zuweist.

Die Suchmaschine erstellt im Hintergrund einen eigenen Index zum Sicherheitsfeld. Dann werden mithilfe der Algorithmen schnell und ausschließlich solche Dokumente gefunden, die die Suchbegriffe enthalten und auf die der Nutzer zugreifen darf.

Google bietet übrigens bei der erweiterten Suche eine ähnliche Funktion auf Feldebene. Dabei muss das richtige Feld bekannt sein. Wenn zum Beispiel „Autor: Max Mustermann“ hinzugefügt wird, sucht Google in der jeweiligen Newsgroup nach Schlüsselwörtern. Das aber nur in den Beiträgen, die mit Max Mustermann in Zusammenhang stehen.

Aus all dem lässt sich schließen: der Indexer kann einem Dokument Elemente wie eine Zugriffssteuerungsliste (ACL) zuweisen. Und damit erzwingen, dass nur auf einer niedrigeren Sicherheitsstufe zugegriffen werden kann.

Darauf komme ich in meinem nächsten Blog-Beitrag zurück. Außerdem wird er noch einige weitere Ideen enthalten wie man eine sichere unternehmensweite Suche implementiert.

Ein großer Nachteil solcher Ansätze mit Berechtigungen umzugehen besteht darin, dass man von einer geringen Zahl an sicherheitsrelevanten Elementen (Gruppen, Nutzer, Abteilungen) ausgeht. Und zusätzlich davon, dass Berechtigungen nicht oft geändert werden; ansonsten müsste eine erneute Indizierung auf Basis der neuen Berechtigungsdaten durchgeführt werden.

Trifft allerdings eine dieser Voraussetzungen nicht zu, kann man keine wirklich benutzerfreundliche Suche mehr anbieten.

Fazit: Die Implementierung einer sicheren unternehmensweiten Suche ist nicht ganz so einfach!

The post Rund um den Index: Vertiefende Infos, Teil II appeared first on Varonis Deutsch.