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.
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.
