Solr Cloud Dokumenten-Routing
Übersicht Solr Cloud Dokumenten-Routing wurde in Solr 4.1 veröffentlicht. Diese Funktion erweiterte das einfache hashbasierte Routing, das in Solr 4.0…
Übersicht
Solr Cloud Dokumenten-Routing wurde in Solr 4.1 veröffentlicht. Diese Funktion erweiterte das einfache hashbasierte Routing, das in Solr 4.0 verfügbar war, durch die Einführung eines neuen Dokumenten-Routers namens compositeId-Router.
Der CompositeId-Router ermöglicht das Hinzufügen eines Shard-Schlüssels zur eindeutigen Dokument-ID. Dieser Shard-Schlüssel bestimmt, in welchem Shard das Dokument indiziert werden soll. Zur Abfragezeit kann ein Shard-Schlüssel angegeben werden, der die Abfrage auf einen bestimmten Shard beschränkt.
Anwendungsfälle
Es gibt zwei Hauptanwendungsfälle für die Weiterleitung von Dokumenten.
Mandantenübergreifend
Die Weiterleitung von Dokumenten kann verwendet werden, um eine effizientere mandantenübergreifende Umgebung zu schaffen. Dies kann erreicht werden, indem die Mandanten-ID zum Shard-Schlüssel gemacht wird, wodurch alle Dokumente desselben Mandanten auf demselben Shard zusammengefasst werden.
Bei der Abfrage kann die Mieter-ID dann als Shard-Schlüssel angegeben werden, um die Abfrage auf den Shard zu beschränken, in dem sich die Daten des Mieters befinden. Dieser Ansatz bedeutet, dass nicht jeder Shard in der Sammlung durchsucht werden muss, um die Daten eines einzelnen Mandanten zu finden.
Gemeinsamer Standort
Bestimmte Solr-Funktionen wie die ngroups-Funktion von Grouping und Joins erfordern, dass sich die Dokumente im selben Core oder Vm befinden. Um z.B. die ngroups-Funktion in der Gruppierung zu nutzen, müssen die Dokumente durch den Gruppierungsschlüssel gemeinsam lokalisiert werden. Das Dokument-Routing erledigt dies automatisch, wenn der Gruppierungsschlüssel als Shard-Schlüssel verwendet wird.
Einrichten des CompositeId Routers
Der Solr Cloud CompositeId-Router wird standardmäßig verwendet, wenn eine Sammlung mit dem Parameter „numShards“ erstellt wird. Wenn der Parameter numShards bei der Erstellung der Sammlung nicht angegeben wird, wird der Sammlung der „implizite“ Dokumenten-Router zugewiesen. Der implizite Dokumenten-Router indiziert Dokumente auf dem Shard, an den sie gesendet werden. Es gibt viele interessante Anwendungsfälle für den impliziten Router, aber in diesem Blog geht es hauptsächlich um den compositId-Router.
Sie können in der clusterstate.json sehen, welcher Router jeder Sammlung zugewiesen ist, indem Sie das Attribut „router“ überprüfen.
Shards werden dem 32 Bit Hash Space zugewiesen
Wenn eine Solr Cloud-Sammlung mit dem Parameter numShards erstellt wird, weist Solr jedem Shard einen Bereich des 32-Bit-Hashspace zu.
In clusterstate.json hat jeder Shard ein Range-Attribut, das den Bereich anzeigt, der dem Shard zugewiesen wurde. Die Bereiche werden in Hexadezimal angegeben. Nachfolgend finden Sie die dezimale Übersetzung der Hex-Bereiche für eine Sammlung mit 4 Shards:
Scherbe1 : 2147483648-3221225471
Scherbe2 : 3221225472-4294967295
Scherbe3 : 0-1073741823
Scherbe4 : 1073741824-2147483647
Einfaches Dokumenten-Routing nur mit einer Dokumenten-ID
Jedem in Solr Cloud indizierten Dokument muss eine eindeutige Dokument-ID zugewiesen werden. Zum Beispiel:
doc50
Wenn der CompositeId-Router eine Dokument-ID erhält, berechnet er einen 32-Bit-Murmurhash3 für die ID. Der compositeId-Router leitet das Dokument dann an den Shard weiter, dessen Bereich den Hash-Wert für die Dokument-ID enthält.
Composite Id Document Routing
Ein Shard-Schlüssel kann an die eindeutige Dokument-ID angehängt werden, um eine Composite Id zu erstellen. Die zusammengesetzte ID wird mit der folgenden Syntax gebildet:
shard_key!document_id
Das ! ist das Trennzeichen.
In einem Multi-Tenant-System könnte dies so aussehen:
Mieter1!doc50
Wenn ein Shard-Schlüssel angegeben wird, berechnet der CompositeId-Router den 32-Bit-Hash sowohl für den Shard-Schlüssel als auch für die Dokument-ID.
Dann wird ein zusammengesetzter 32-Bit-Hash erstellt, indem 16 Bits aus dem Hash des Shard-Schlüssels und 16 Bits aus dem Hash der Dokument-ID genommen werden.
Die oberen Bits des Hashwerts werden aus dem Shard-Schlüssel und die unteren Bits aus der Dokument-ID entnommen.
Der CompositeId-Router leitet das Dokument dann an den Shard weiter, dessen Bereich den Hash-Wert für die CompositeId enthält.
Die oberen Bits, die aus dem Shard-Schlüssel stammen, bestimmen, in welchem Shard das Dokument abgelegt wird.
Die unteren Bits des Hashwerts, die von der eindeutigen Dokument-ID stammen, platzieren das Dokument innerhalb eines 65536-Slice des Shards.
Dieses Szenario ermöglicht es, Tenants bei Bedarf in mehrere Shards aufzuteilen, und zwar durch Shard Splitting, das in Solr 4.3 eingeführt wurde.
Verteilen von Mietern auf mehrere Shards
Wenn ein Tenant zu groß ist, um auf einen einzigen Shard zu passen, kann er auf mehrere Shards verteilt werden, indem die Anzahl der zu verwendenden Bits des Shard-Schlüssels angegeben wird.
Die Syntax hierfür lautet:
shard_key/num!document_id
Die /num ist die Anzahl der Bits des Shard-Schlüssels, die in dem zusammengesetzten Hashwert verwendet werden sollen.
Zum Beispiel:
Mieter1/4!doc50
Dazu werden 4 Bits aus dem Shard-Schlüssel und 28 Bits aus der eindeutigen Dokument-ID verwendet, wodurch der Mieter auf 1/16 der Shards in der Sammlung verteilt wird.
3 Bits würden den Tenant über 1/8 der Kollektion verteilen.
2 Bits würden den Tenant über 1/4 der Kollektion verteilen.
1 Bit würde den Tenant über 1/2 der Kollektion verteilen.
0 Bits würden den Tenant über die gesamte Kollektion verteilen.
Zur Abfragezeit
Bei der Abfrage kann der Parameter shard.keys verwendet werden, um die Abfrage auf einen bestimmten Scherben oder einen Bereich von Scherben zu beschränken. Sie geben mit dieser Syntax an, welcher Shard abgefragt werden soll:
shard.keys=Mieter1!
oder mehrere Tasten:
shard.keys=Mieter1!,Mieter2!