Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Selección del número de particiones
Una vez que conozca los requisitos de almacenamiento, puede investigar la estrategia de indexación. De forma predeterminada, en OpenSearch Service, cada índice se divide en cinco fragmentos principales y una réplica (10 fragmentos en total). Este comportamiento es diferente al del código abierto OpenSearch, que de forma predeterminada es un fragmento principal y uno de réplica. Como no se puede cambiar fácilmente el número de particiones principales de un índice existente, debe decidir el número de particiones antes de indexar el primer documento.
El objetivo general de la selección de un número de particiones es distribuir un índice de manera uniforme entre todos los nodos de datos del clúster. Sin embargo, estas particiones no deberían ser demasiado grandes ni demasiado numerosas. Una pauta general es tratar de mantener el tamaño de la partición entre 10 y 30 GiB para las cargas de trabajo en las que la latencia de búsqueda es un objetivo de rendimiento clave y entre 30 y 50 GiB para las cargas de trabajo con mucha escritura, como el análisis de registros.
Los fragmentos grandes pueden dificultar la recuperación en caso de un error, pero dado que cada fragmento utiliza cierta cantidad de CPU y memoria, tener demasiados fragmentos pequeños puede provocar problemas de rendimiento y errores de memoria insuficiente. OpenSearch En otras palabras, los fragmentos deben ser lo suficientemente pequeños como para que la instancia de OpenSearch servicio subyacente pueda gestionarlos, pero no tan pequeños como para que supongan una carga innecesaria para el hardware.
Por ejemplo, supongamos que tiene 66 GiB de datos. No espera que el número aumente a lo largo del tiempo y desea mantener las particiones en torno a los 30 GiB cada una. El número de particiones debería ser, por tanto, aproximadamente 66 * 1,1/30 = 3. Se podría generalizar este cálculo de la manera siguiente:
(Datos de origen + espacio para crecer) * (1 + sobrecarga de indexación) / tamaño de partición deseado = número aproximado de particiones principales
Esta ecuación ayuda a compensar el aumento de los datos a lo largo del tiempo. Si prevé que estos mismos 66 GiB de datos se cuadrupliquen a lo largo del próximo año, el número aproximado de particiones es (66 + 198) * 1,1/30 = 10. Recuerde, sin embargo, que aún no tiene esos 198 GiB de datos adicionales. Asegúrese de que estos preparativos para el futuro no creen particiones innecesariamente diminutas que consuman grandes cantidades de CPU y memoria en la actualidad. En este caso, tendrá 66 * 1,1/10 particiones = 7,26 GiB por partición, lo que consumirá recursos adicionales y queda debajo del intervalo de tamaño recomendado. Podrías considerar el middle-of-the-road enfoque más amplio de seis fragmentos, lo que te deja con fragmentos de 12 GiB en la actualidad y fragmentos de 48 GiB en el futuro. De nuevo, es posible que prefiera empezar con tres particiones y reindexar sus datos cuando las particiones superen los 50 GiB.
Un problema mucho menos común implica limitar el número de particiones por nodo. Si el tamaño de las particiones es adecuado, normalmente se queda sin espacio en disco mucho antes de alcanzar este límite. Por ejemplo, una instancia de m6g.large.search tiene un tamaño máximo de disco de 512 GiB. Si permanece por debajo del 80 % de uso del disco y el tamaño de sus particiones en 20 GiB, puede acomodar aproximadamente 20 particiones. Elasticsearch 7. x y versiones posteriores, y todas las versiones OpenSearch hasta la 2.15, tienen un límite de 1000 fragmentos por nodo. Para ajustar el máximo de particiones por nodo, establezca la configuración cluster.max_shards_per_node. A partir de la versión OpenSearch 2.17, OpenSearch Service admite 1000 fragmentos por cada 16 GB de pila de nodos de datos, hasta un máximo de 4000 fragmentos por nodo. Para ver un ejemplo, consulte Configuración del clúster
El dimensionamiento apropiado de las particiones casi siempre lo mantiene por debajo de este límite, pero también puede considerar el número de particiones por cada GiB del montón de Java. En un nodo dado, no tenga más de 25 particiones por cada GiB del montón de Java. Por ejemplo, una instancia de m5.large.search tiene un montón de 4 GiB, por lo que cada nodo no debe tener más de 100 particiones. En ese recuento de particiones, cada uno tiene aproximadamente 5 GiB de tamaño, lo que está muy por debajo de nuestra recomendación.
