Auswahl der Anzahl der Shards

Nachdem Sie die Speicheranforderungen kennen, können Sie über Ihre Indizierungsstrategie nachdenken. Standardmäßig ist in OpenSearch Service jeder Index in fünf primäre Shards und ein Replikat (insgesamt 10 Shards) unterteilt. Dieses Verhalten unterscheidet sich von Open Source OpenSearch, bei dem standardmäßig ein primärer und ein Replikat-Shard verwendet werden. Da Sie die Anzahl der primären Shards für einen vorhandenen Index nicht leicht ändern können, sollten Sie die Anzahl der Shards festlegen, bevor Sie Ihr erstes Dokument indizieren.

Das übergeordnete Ziel bei der Auswahl der Shard-Anzahl ist es, einen Index gleichmäßig über alle Knoten im Cluster zu verteilen. Diese Shards sollten jedoch nicht zu groß oder zu zahlreich sein. Als allgemeine Richtlinie gilt, dass die Shard-Größe bei Workloads, bei denen die Suchlatenz ein wichtiges Leistungsziel ist, zwischen 10 und 30 GiB und bei schreibintensiven Workloads wie der Protokollanalyse zwischen 30 und 50 GiB liegen sollte.

Große Shards können die Wiederherstellung OpenSearch nach einem Ausfall erschweren. Da jedoch jede Shard eine gewisse Menge an Speicher beansprucht, können zu viele kleine Shards zu Leistungsproblemen CPU und Speicherproblemen führen. Mit anderen Worten, Shards sollten klein genug sein, dass die zugrunde liegende OpenSearch Service-Instanz sie verarbeiten kann, aber nicht so klein, dass sie die Hardware unnötig belasten.

Angenommen, Sie haben 66 GiB Daten. Sie gehen nicht davon aus, dass diese Anzahl mit der Zeit zunimmt, und Sie möchten Ihre Shards mit je 30 GiB beibehalten. Die Anzahl der Shards sollte deshalb ca. 66 * 1,1/30 = 3 betragen. Sie können diese Berechnung wie folgt verallgemeinern:

(Datenquelle + Wachstumspotenzial) * (1 + Indizierungsaufwand)/Gewünschte Shard-Größe = Ungefähre Anzahl der primären Shards

Diese Gleichung hilft Daten-Wachstum im Laufe der Zeit auszugleichen. Wenn Sie davon ausgehen, dass sich dieselben 66 GiB Daten innerhalb des nächsten Jahres vervierfachen, ist die ungefähre Anzahl der Shards (66 + 198) * 1,1 / 30 = 10. Beachten Sie jedoch, dass Sie diese zusätzlichen 198 GiB Daten noch nicht haben. Stellen Sie sicher, dass bei dieser Vorbereitung für die future nicht unnötig kleine Scherben entstehen, die in der CPU Gegenwart riesige Mengen an Speicherplatz verbrauchen. In diesem Fall sind 66 * 1,1/10 Shards = 7,26 GiB pro Shard, was zusätzliche Ressourcen verbraucht und unterhalb des empfohlenen Größenbereichs liegt. Sie könnten eher den middle-of-the-road Ansatz von sechs Shards in Betracht ziehen, sodass Sie heute 12-GiB-Shards und in future 48-GiB-Shards haben werden. Auch hier könnten Sie bevorzugen, mit drei Shards zu beginnen und Ihre Daten neu zu indizieren, wenn die Shards über 50 GiB zunehmen.

Ein weitaus weniger häufiges Problem ist die Begrenzung der Shard-Anzahl pro Knoten. Wenn Sie Ihre Shards entsprechend dimensionieren, geht Ihnen in der Regel schon lange vor Erreichen dieser Grenze der Datenträger-Speicherplatz aus. Beispielsweise verfügt eine m6g.large.search-Instance über eine maximale Datenträgergröße von 512 GiB. Wenn Sie unter 80 % der Datenträgernutzung bleiben und die Größe Ihrer Shards bei 20 GiB liegt, können ungefähr 20 Shards untergebracht werden. Elasticsearch 7. x und höher sowie alle Versionen von OpenSearch haben ein Limit von 1.000 Shards pro Knoten. Um die maximalen Shards pro Knoten anzupassen, konfigurieren Sie die cluster.max_shards_per_node-Einstellung. Ein Beispiel finden Sie unter Cluster-Einstellungen.

Durch eine angemessene Dimensionierung der Shards bleiben Sie fast immer unter dieser Grenze, Sie können jedoch auch die Anzahl der Shards pro GiB des Java-Heaps prüfen. Auf einem vorgegebenen Knoten sollten Sie nicht mehr als 25 Shards pro GB des Java-Heaps haben. Eine m5.large.search-Instance verfügt bspw. über einen 4-GiB-Heap, sodass jeder Knoten nicht mehr als 100 Shards haben sollte. Bei dieser Anzahl an Shards ist jeder Shard etwa 5 GiB groß, was weit unter unserer Empfehlung liegt.