Mehrstufiges Composite-id-Routing in SolrCloud

SolrCloud hat sich im Laufe des letzten Jahres zu einem ziemlich intelligenten System mit vielen interessanten und nützlichen Funktionen entwickelt.…

SolrCloud hat sich im Laufe des letzten Jahres zu einem ziemlich intelligenten System mit vielen interessanten und nützlichen Funktionen entwickelt. Eine davon ist die Arbeit an der intelligenten Weiterleitung von Dokumenten und Abfragen.

SolrCloud begann mit einem einfachen hashbasierten Routing in 4.0. Interessant wurde es dann mit der Einführung des Composite Id Routers in 4.1, der ein intelligenteres Routing von Dokumenten und Abfragen ermöglichte, um Dinge wie Multi-Tenancy und Co-Location zu erreichen. Mit 4.7 wird das 2-stufige Composite-ID-Routing auf 3 Stufen erweitert(SOLR-5320).

Einen guten Beitrag darüber, wie Dokumenten-Routing im Allgemeinen funktioniert, finden Sie hier. Schauen wir uns nun an, wie sich das Composite-ID-Routing auf 3 Ebenen ausdehnt und wie wir es wirklich nutzen können, um bestimmte Dokumente in unserem Korpus abzufragen.

Wichtig dabei ist, dass der 3-Ebenen-Router den 2-Ebenen-Router nur erweitert. Es handelt sich um denselben Router und dieselbe Java-Klasse, d.h. Sie müssen ihn nicht wirklich „einrichten“.

Wo würden Sie den mehrstufigen Composite-ID-Router verwenden wollen?

Die Multi-Level-Implementierung erweitert die Unterstützung für Multi-Tenancy und Co-Location von Dokumenten, die der bereits vorhandene Composite-ID-Router bietet. Stellen Sie sich ein Szenario vor, in dem ein einziges System verwendet wird, um Daten für mehrere Anwendungen (oder Abteilungen) zu hosten, und jede von ihnen eine Reihe von Benutzern hat. Jedem Benutzer sind außerdem Dokumente zugeordnet. Mit einem 3-stufigen Composite-ID-Router kann ein Benutzer die Dokumente zum Indexzeitpunkt an die richtigen Shards weiterleiten, ohne sich wirklich um das eigentliche Routing kümmern zu müssen. Dies würde es den Benutzern auch ermöglichen, Abfragen für bestimmte Benutzer oder Anwendungen mithilfe des Parameters shard.keys zur Abfragezeit gezielt zu steuern.

Wie funktioniert das?

Jedes Dokument in Solr, das weitergeleitet werden soll, muss eine eindeutige Dokument-ID haben.
z.B. doc1

Es wird ein Hash-Wert der ID berechnet, der dann für das Routing verwendet wird.

Diese id kann so geändert werden, dass sie auch Routing-Schlüssel für den Zweck des Composite-id-Routers enthält.
z.B. routekey1!routekey2!doc1

Bei einem Composite-ID-Router wird jedes Dokument sowohl anhand des Routing-Schlüssels (Komponenten) als auch anhand der ursprünglichen Dokument-ID weitergeleitet. Das Routing erfolgt über einen 32-Bit-Wert, der aus den verschiedenen Komponenten des Routing-Schlüssels abgeleitet wird.

Im Falle des 2-stufigen Composite-ID-Routings werden die ersten 16 Bits (MSB) des Hashes aus dem Hash des Routenschlüssels abgeleitet, während die letzten 16 Bits aus der Dokument-ID selbst stammen

Im Falle eines 3-stufigen Composite-ID-Routings bestimmen die drei Komponenten standardmäßig 8, 8 und 16 Bits des Routing-Hashes.

ID: myapp!user1!doc

Die ersten 8 Bits aus dem murmur3-Hash von myapp

2. 8 Bits aus murmur3 Hash von user1

3. 16 Bits von doc

Dies kann für benutzerdefinierte Fälle geändert werden, in denen der Benutzer vielleicht mehr (oder weniger) Bits von jeder der Komponenten beisteuern möchte. Hier ist das Beispiel:

ID : myapp/6!user1/14!doc

Die ersten 6 Bits von myapp

2. 14 Bits von user1

3. 12 (32-20) Bits von doc

Wie verwenden Sie es eigentlich in Ihrer Anwendung?

Während der Indizierung:
Fügen Sie für jedes Dokument eine Dokument-ID mit routingbezogenen Informationen hinzu. z.B. myapp!user1!doc

Zum Zeitpunkt der Abfrage:
Um alle Datensätze für myapp abzufragen: shard.keys=myapp/8!

Beachten Sie die explizite Erwähnung von 8 Bits im Falle einer Abfrage nur durch Komponente 1, d.h. der App-Ebene. Dies ist erforderlich, weil die Verwendung des Routers auf Ebene 2 oder 3 nicht implizit ist. Die Angabe von ‚8‘ Bits für die Komponente unterstreicht die Verwendung eines Routers der Ebene ‚3‘.

Um alle Datensätze von user1 für myapp abzufragen: shard.keys=myapp!user1!

Ich hoffe, dies klärt ein wenig über das Wie/Warum und Was des mehrstufigen Composite-ID-Routers auf.