Scelta del numero di partizioni

Dopo aver individuato i requisiti di archiviazione, è possibile esaminare la strategia di indicizzazione. Per impostazione predefinita, in OpenSearch Service, ogni indice è suddiviso in cinque shard primari e una replica (per un totale di 10 shard). Questo comportamento è diverso da quello open source OpenSearch, che utilizza per impostazione predefinita uno shard primario e uno di replica. Poiché non è possibile modificare facilmente il numero di partizioni primarie per un indice esistente, è necessario decidere il numero di partizioni prima di indicizzare il primo documento.

L'obiettivo generale della scelta di un numero di partizioni è distribuire un indice in modo uniforme su tutti i nodi di dati del cluster. Tuttavia, queste partizioni non devono essere troppo grandi o troppo numerose. Una buona regola è cercare di mantenere le dimensioni delle partizioni tra 10 e 30 GiB per i carichi di lavoro in cui la latenza di ricerca è un obiettivo chiave delle prestazioni e 30-50 GiB per i carichi di lavoro pesanti in termini di scrittura, come l'analisi dei log.

Gli shard di grandi dimensioni possono rendere difficile il ripristino in caso di guasto, ma poiché ogni shard utilizza una certa quantità di memoria, avere troppi shard piccoli può causare problemi di prestazioni CPU ed errori di memoria insufficiente. OpenSearch In altre parole, gli shard devono essere sufficientemente piccoli da consentire all'istanza di OpenSearch Service sottostante di gestirli, ma non così piccoli da sovraccaricare inutilmente l'hardware.

Ad esempio, se disponi di 66 GiB di dati. Non si prevede che il numero aumenti nel corso del tempo e si desidera mantenere le dimensioni delle partizioni attorno a 30 GiB ciascuna. Il numero di partizioni perciò deve essere circa 66* 1,1/30 = 3. Puoi generalizzare il calcolo come indicato di seguito:

(Dati di origine + Spazio per crescere) * (1 + Gestione indicizzazione)/Dimensione desiderata della partizione = Numero approssimativo di partizioni primarie

Questa equazione aiuta a compensare la crescita dei dati nel tempo. Se si prevede che quegli stessi 66 GiB di dati quadruplicheranno l'anno successivo, il numero approssimativo di partizioni sarà (66+198) * 1,1/30 = 10. Ricorda, tuttavia, che non disponi ancora di questi 198 GiB di dati aggiuntivi. Assicurati che questa preparazione per il futuro non crei frammenti inutilmente minuscoli che consumano enormi quantità di CPU memoria nel presente. In questo caso, 66* 1,1/10 partizioni = 7,26 GiB per partizione. Queste partizioni consumeranno risorse aggiuntive e sono inferiori all'intervallo di dimensione consigliato. Potreste prendere in considerazione l'idea di optare per middle-of-the-road un approccio a sei shard, che vi lascerà con shard da 12 GiB oggi e shard da 48 GiB in futuro. Quindi, si potrebbe iniziare con tre partizioni e reindicizzare i dati quando le partizioni superano i 50 GiB.

Un problema molto meno comune comporta la limitazione del numero di partizioni per nodo. Se si dimensionano le partizioni in modo appropriato, in genere si esaurisce lo spazio su disco molto prima di rispettare questo limite. Ad esempio, un'istanza m6g.large.search ha una dimensione massima del disco di 512 GiB. Se si rimane al di sotto dell'80% di utilizzo del disco e si dimensionano le partizioni a 20 GiB, può ospitare circa 20 partizioni. Elasticsearch 7. x e versioni successive, e tutte le versioni di OpenSearch, hanno un limite di 1.000 shard per nodo. Per regolare il numero massimo di partizioni per nodo, configura l'impostazione cluster.max_shards_per_node. Per un esempio, consulta Impostazioni del cluster.

Il dimensionamento appropriato delle partizioni mantiene l'utente quasi sempre al di sotto di questo limite, ma è anche possibile considerare il numero di partizioni per ogni GiB di heap Java. Su un dato nodo, non avere più di 25 partizioni per GiB di heap Java. Ad esempio, un'istanza m5.large.search ha una memoria heap di 4 GiB, quindi ogni nodo non deve avere più di 100 partizioni. A quel numero di partizioni, ogni partizione ha una dimensione di circa 5 GiB, il che è ben al di sotto della nostra raccomandazione.