Wir verwenden elasticsearch für den folgenden Anwendungsfall.
Elasticsearch Version: 5.1.1
Hinweis: Wir verwenden AWS Managed ElasticSearch
Wir haben ein System mit mehreren Mandanten, in dem in jedem Mandanten Daten für mehrere Dinge gespeichert werden und die Anzahl der Mandanten von Tag zu Tag zunimmt.
exa: Jeder Mieter wird folgende Informationen haben.
%Vor%Aktuelle Indexierungsstrategie ist wie folgt:
indexname:
tenant_id (GUID) exa: tenant_xx1234xx-5b6x-4982-889a-667a758499c8
Typen:
%Vor%Probleme, vor denen wir stehen:
1] Konflikte für Zuordnungen von allgemeinen Feldern exa: (id, name, userId) in Typen (tickets, sw_inventory, hw_inventory)
2] Da die Anzahl der Mieter steigt, kann die Anzahl der Indizes auch bis zu 1000 oder 2000 betragen.
Wird es eine gute Idee sein, wenn wir die Indexierungsstrategie umkehren?
exa: Indexnamen:
%Vor%Typen:
%Vor%Also wird es nur 3 riesige Indizes mit N Typen als Mieter geben.
Die Frage ist also in diesem Fall, welche Lösung besser ist?
1] Viele kleine Indizes und 3 Arten
ODER
2] 3 große Indizes und viele Arten
Grüße
Kein Ansatz würde funktionieren. Wie andere bereits erwähnt haben, kosten beide Ansätze die Performance und würden Sie davon abhalten, ein Upgrade durchzuführen.
Betrachten Sie einen Index und Typ für jeden Datensatz, z. sw_inventory und dann ein Feld innerhalb der Zuordnung, die zwischen jedem Mandanten unterscheidet. Sie können dann Sicherheit auf Dokumentebene in einem Sicherheits-Plug-in wie X-Pack oder Search Guard verwenden, um zu verhindern, dass ein Mandant die Datensätze eines anderen sieht (falls erforderlich).
Ich schlage einen anderen Ansatz vor: Ссылка
Bedeutet benutzerdefiniertes Routing, bei dem jedes Dokument ein tenant_id oder ähnliches hat (etwas, das für jeden Mandanten einzigartig ist) und das sowohl für das Routing als auch zum Definieren eines Alias für jeden Mandanten verwendet. Wenn Sie dann nur Dokumente für einen bestimmten Mandanten abfragen, verwenden Sie den Alias.
Sie werden einen Index und einen Typ auf diese Weise verwenden. Abhängig von der Größe des Indexes berücksichtigen Sie die vorhandene Indexgröße und die Anzahl der Knoten und versuchen, eine Anzahl von Shards so zu erstellen, dass sie gleichmäßig auf alle Knoten verteilt werden, die die Daten halten, und auch auf Ihre testet die Leistung ist akzeptabel. Wenn der Index in Zukunft zu groß wird und Shards zu groß werden, um die gleiche Leistung beizubehalten, sollten Sie einen neuen Index mit mehr primären Shards erstellen und alles in diesem neuen Index neu indizieren. Es ist kein Ansatz, der unerhört oder nicht benutzt oder nicht empfohlen wird.
1000-2000 Aliase ist nichts in Bezug auf die Fähigkeit, behandelt zu werden. Wenn Sie knapp 10 oder mehr als 10 Knoten haben, empfehle ich auch dedizierte Master-Knoten mit einer Speichergröße von 4-6 GB und mindestens 4 CPU-Kernen.
In Elasticsearch 6.0.0 oder höher erstellte Indizes dürfen nur einen einzigen Mapping-Typ enthalten, was bedeutet, dass doc_type (_type) veraltet ist.
Ausführliche Erklärung finden Sie hier aber Zusammenfassend gibt es zwei Lösungen:
Index pro Dokumenttyp
Dieser Ansatz hat zwei Vorteile:
Feld für benutzerdefinierten Typ
Natürlich gibt es eine Grenze dafür, wie viele primäre Shards in einem Cluster vorhanden sein können, sodass Sie möglicherweise nicht einen ganzen Shard für eine Sammlung von nur einigen tausend Dokumenten verschwenden möchten. In diesem Fall können Sie ein eigenes benutzerdefiniertes Typfeld implementieren, das ähnlich wie der alte _type funktioniert.
%Vor%Sie verwenden eine ältere Version von Elastic, aber die gleiche Logik kann auch angewendet werden, und es wäre einfacher für Sie, zu einer neueren Version zu wechseln, wenn Sie sich dazu entschließen, also sollten Sie mit einer separaten Indexstruktur oder mit anderen Worten 3 riesigen Dateien arbeiten Indizes und viele Typen aber Typen als ein Feld im Mapping nicht als _Typ.
Ich denke, beide Strategien haben Vor- und Nachteile:
Mehrere Indizes:
Vorteile : - Mieterdaten sind von den anderen isoliert und keine Abfrage würde Ergebnisse von mehr als einem zurückliefern. - Wenn die Gesamtzahl der Dokumente sehr groß ist, können verschiedene kleinere Indizes eine bessere Leistung erbringen.
Nachteile : Schwieriger zu verwalten. Wenn jeder Index wenige Dokumente enthält, verschwenden Sie möglicherweise eine Menge Ressourcen.
EDITED: Vermeiden Sie mehrere Typen im selben Index wie in den Kommentaren o Leistung und Abwertung des Features
Tags und Links elasticsearch