Blog der SHI GmbH

Duplizierte IDs identifizieren mit Solr 6

Veröffentlicht am 16.02.2016 von Patricia Kaufmann

Eine Identifikationsnummer, eine ID, sollte schon dem Namen nach ein unverkennbares Merkmal sein mittels dessen man eine Person oder ein Objekt eindeutig von anderen abgrenzen kann. Dies gilt insbesondere für die Inhalte von Datenspeichern, seien es klassische relationale Datenbanken oder nicht-relationale Speicher, wie Apache Solr sie verwendet.

Jedes Dokument in einem Solr-Index besitzt eine einmalige, eindeutige ID. Wird ein neues Dokument mit einer bereits vergebenen ID indexiert, so wird das alte Dokument schlichtweg ersetzt. Damit ist sichergestellt, dass jede Identifikationsnummer ihrem Namen gerecht wird und nur genau einmal pro Index vorhanden ist. Pro Index. Gemeint ist hier der physische Index. Die einzelnen Shards einer SolrCloud-Collection haben voneinander getrennte physische Indexe, teilen sich aber den logischen Index der Collection. Und genau an dieser Stelle verbirgt sich eine Sicherheitslücke, denn die Eindeutigkeit von Identifikationsnummern kann lediglich für einen physischen, nicht aber für einen logischen Index garantiert werden. Unter Umständen kann es so zu duplizierten IDs kommen.

Wurde erst einmal erkannt, dass manche IDs mehrfach in einer Collection vorkommen, so ist das Interesse daran groß, alle doppelt vorhandenen IDs zu identifizieren, um die damit verbundenen Dokumente aus dem Index entfernen zu können. Jedoch ist ein händisches Aufspüren der Duplikate gerade bei großen Datenmengen mühsam bis unmöglich.

Da gewiss ist, dass zwei Dokumente mit derselben Identifikationsnummer auf unterschiedlichen Shards einer Collection liegen müssen, liegt es nahe, die Join-Funktion von Solr heranzuziehen und die Dokumente zweier Shards über ihre ID zu verknüpfen:

solr/shard1/select?q={!join from=id to=id fromIndex=shard2}*:*

Die Eingabe dieser Suchabfrage wird allerdings lediglich zu einer Fehlermeldung führen, welche dem Nutzer mitteilt, dass „multiple shards“ noch nicht unterstützt werden. „Noch nicht“ ist erfreulicherweise eine Aussage der Vergangenheit, denn Solr 6 bietet genau diese Art der verteilten Joins an. Die neu hinzukommende Streaming API eröffnet neue Möglichkeiten der Verknüpfung von Dokumenten über Joins. Eine (für bessere Lesbarkeit unvollständige) Suchabfrage

stream?expr=innerJoin(search(collection1, q=*:*, fl=id), search(collection1, q=*:*, fl=id), on=”id=id”)

listet alle Identifikationsnummern von Dokumenten innerhalb der Collection auf. Befinden sich duplizierte IDs im Index, so wird die Ergebnismenge, welche aus der oben genannten Anfrage resultiert, diese enttarnen. Eine ID, welche in der Trefferliste mehrfach vorkommt, ist auch im Index mehrfach vorhanden.

Beispiel Ergebnisliste mit duplizierten IDs

Dem Beispiel liegt eine Collection mit zwei Shards zugrunde. In der Abbildung ist die Ergebnisliste oben genannter Suchabfrage zu sehen. Diese deckt auf, dass die Identifikationsnummern „6H500F0“, „GB18030TEST“ und „SP2514N“ mehrfach vorhanden sind. Zur Sicherung der Konsistenz sollten die zugehörigen Dokumente von einer der beiden Shards gelöscht werden.

Die beschriebene Methode dient lediglich der Identifizierung von duplizierten IDs und ist damit nur ein Diagnose-Werkzeug. Die passende Symptom- und Ursachenbehandlung muss für jeden Fall individuell durchgeführt werden. Da die Tests mit der neuen Funktionalität nur auf dem Developer-Snapshot ausgeführt wurden, kann mit Spannung erwartet werden, was Solr 6 zum Zeitpunkt der eigentlichen Veröffentlichung darüber hinaus zu bieten haben wird.

Patricia Kraft, Bereichsleitung Search & Analytics

Patricia Kraft

..., studierte Informatik und Multimedia an der Universität Augsburg. Nach dem Erreichen des Masters in diesem Fach stieg sie unmittelbar in die Suchbranche ein und begann 2015 ihre Karriere bei der SHI als Consultant für Search & Big Data. Durch das heterogene Arbeiten an Projekten – sowohl in der Beratung als auch in der Konzeption und Implementierung – erlangte sie einen umfassenden Überblick über viele verschiedene Einsatzmöglichkeiten von Such- und Analysewerkzeugen. Für den SHI-Blog teilt sie ihre Erfahrung aus zahlreichen Projekten in unterschiedlichen Branchen sowohl aus technischer als auch als aus unternehmerischer Sicht. Lieblingsdateiformat: JSON