software - ElasticSearch: alto rendimiento de indexación

puerto de elasticsearch (1)

Estoy evaluando ElasticSearch para fines de rendimiento de indexación muy altos.

Mi objetivo actual es poder indexar 3 mil millones (3,000,000,000) de documentos en cuestión de horas. Para ese propósito, actualmente tengo 3 máquinas con servidor de Windows, con 16 GB de RAM y 8 procesadores cada una. Los documentos que se insertan tienen una asignación muy simple, que contiene solo un puñado de campos numéricos no analizados ( _all están deshabilitados).

Puedo llegar a aproximadamente 120,000 solicitudes de índice por segundo (monitoreo usando un gran escritorio), usando esta plataforma relativamente modesta, y estoy seguro de que el rendimiento se puede aumentar aún más. Estoy utilizando una cantidad de clientes .net NEST para enviar las solicitudes masivas de índice, con 1500 operaciones de índice al por mayor.

Desafortunadamente, el rendimiento de 120k solicitudes por segundo no dura mucho, y la tasa disminuye gradualmente, cayendo a ~ 15k después de un par de horas.

El monitoreo de las máquinas revela que las CPU no son el cuello de botella. Sin embargo, el tiempo de inactividad del disco físico (no SSD) parece estar cayendo en todas las máquinas, alcanzando menos del 15% de inactividad promedio.

Configurar refresh_interval a 60 s, que a 300 s, y finalmente a 15 m, no parece ayudar mucho. Al espiar un solo translog en un solo fragmento, se mostró que el translog se enjuaga cada 30 minutos, antes de alcanzar los 200 MB.

He intentado usar dos estrategias de fragmentación:

1 índice, con 60 fragmentos (sin réplicas).
3 índices, con 20 fragmentos cada uno (sin réplicas).

Ambos intentos dan como resultado una experiencia bastante similar, lo que creo que tiene sentido ya que es la misma cantidad de fragmentos.

Mirando los segmentos, puedo ver que la mayoría de los fragmentos tienen ~ 30 segmentos comprometidos, y un número similar de segmentos de búsqueda también. El tamaño del segmento varía. En un momento dado, un intento de optimizar el índice con max_num_segments = 1, pareció tener ayuda un poco después de que se terminó (tomó un largo tiempo).

En cualquier momento, comenzar todo el proceso de ingestión desde el principio, después de eliminar los índices usados y crear otros nuevos, da como resultado el mismo comportamiento. Inicialmente, el rendimiento del índice es alto, pero disminuye gradualmente, mucho antes de alcanzar la meta de 3 mil millones de documentos. El tamaño del índice en ese momento es de aproximadamente 120 GB.

Estoy usando la versión de ElasticSearch 1.4. Xms y Xmx están configurados para 8192 MB, el 50% de la memoria disponible. La memoria intermedia de indexación se establece en 30%.

Mis preguntas son las siguientes:

Asumiendo que el disco es actualmente el cuello de botella de este equipo, ¿este fenómeno de aumentar gradualmente la utilización del disco es normal? Si no, ¿qué se puede hacer para negar estos efectos?
¿Hay algún ajuste que pueda hacer para aumentar el rendimiento de indexación? ¿Debería? o debería simplemente escalar.

Para resumir, terminé con 5 máquinas virtuales de Linux, 8 CPU, 16 GB, usando marionetas para implementar elasticsearch. Mis documentos se hicieron un poco más grandes, pero también lo hizo la tasa de rendimiento (ligeramente). Logré llegar a 150K solicitudes de índice / segundo en promedio, indexando mil millones de documentos en 2 horas. El rendimiento no es constante, y observé un comportamiento de rendimiento decreciente similar al de antes, pero en menor medida. Como usaré índices diarios para la misma cantidad de datos, esperaría que estas métricas de rendimiento fueran más o menos similares todos los días.

La transición de las máquinas de Windows a Linux se debió principalmente a la conveniencia y al cumplimiento de las convenciones de TI. Aunque no lo sé con certeza, sospecho que también se podrían obtener los mismos resultados en Windows.

En varias de mis pruebas intenté indexar sin especificar identificaciones de documentos como Christian Dahlqvist sugirió. Los resultados fueron sorprendentes. Observé un aumento significativo en el rendimiento, alcanzando 300k o más en algunos casos. La conclusión de esto es obvia: no especifique documentos ID, a menos que sea absolutamente necesario.

Además, estoy usando menos fragmentos por máquina, lo que también contribuyó al aumento del rendimiento.