Elasticsearch actuaciones esperables

Question

estoy trabajando en portar un motor de búsqueda a partir de una base de datos SQL para Elasticsearch. La principal razón para hacerlo es ser capaz de calcular las facetas fácilmente.

Actualmente tenemos facetas en el SQL mediante la generación de tablas de precálculo. Funciona bien pero es difícil de mantener y las facetas solo se admiten en un subconjunto de datos.

Ahora el prototipo ES está funcionando, estoy evaluando las dos soluciones, y parece que la versión ES está un poco por debajo de la versión sql en términos de rendimiento (en términos de mantenibilidad es mucho mejor).

He utilizado exactamente las mismas configuraciones de máquina, una plataforma de 64 bits, 32 gigas de memoria RAM, un disco ssd y un Intel Xeon de cuatro núcleos a 3 ghz para comparar el sql y el ES.

El documento no es pequeño, hay alrededor de 200 campos, dependiendo de la solicitud, se utiliza la clasificación basada en script, y las facetas siempre se calculan en 8 campos del documento.

El índice contiene 3 millones de documentos, si no me equivoco, es relativamente pequeño para lo que ES puede manejar.

En términos de consulta, utilizo una consulta filtrada, y para algunas solicitudes, una consulta custom_filters_score para calcular el puntaje y usarlo para ordenar.

Algunos de los filtros son globales debido a las facetas, pero siempre hay algunos filtros en la consulta filtrada, por lo que se debe reducir el número de documentos escaneados (no se escanea todo el índice).

Utilizo dos medidas en mis pruebas: el tiempo pasado en el servidor para ejecutar la búsqueda y el número de consultas por segundo ejecutadas por el cliente ejecutando 100 hilos en paralelo.

Para elasticsearch, el tiempo promedio pasado en el servidor es de alrededor de 500 ms para cada consulta (para 100 consultas en paralelo), y las consultas promedio por segundo en el cliente son alrededor de 160 (algunos ms se pierden al generar la consulta , enviándolo, recibiendo resultados y analizándolos). Y esto es con un índice que tiene de 1 fragmento y 0 réplicas, cuando aumento el número de fragmentos/réplicas, actuaciones caen significativamente.

para SQL, el tiempo medio para ejecutar una consulta es de alrededor de 360 ​​ms (idem, con 100 consultas en paralelo), y las consultas promedio por segundo en el cliente es de alrededor de 200.

Sé que es Es difícil de comparar, pero como no tengo idea de los resultados que puedo esperar, me pregunto si alguien puede comentar sobre estas medidas.

Quizás me perdí algo y debería ser un orden de magnitud más rápido, o tal vez estos son los resultados típicos de entornos similares a los míos, no lo sé.

¿Qué puedo esperar en mi caso? ¿Qué observó en circunstancias similares con ES? ¿Soporta bien las solicitudes simultáneas? caso de que el tiempo para ejecutar una consulta esté en el intervalo de 500 ms al hacer 100 consultas al mismo tiempo? ¿Hay formas de mejorar los resultados de búsqueda?

Cualquier información o comentario son bienvenidos, esta es una parte importante para la decisión de industrializar el prototipo o no.

Gracias.

Answer 1

Esto no es una pregunta; esto suena más como una discusión.

Dicho esto, no muchos pueden comentar porque todos nuestros casos de uso son diferentes. Usted está usando esto puramente como una herramienta analítica de facetas. Uso ElasticSearch como una base de datos y una herramienta analítica en tiempo real. Así que mi punto de referencia de lo que funciona para mí será radicalmente diferente de usted.

En cuanto a la versión, todavía estoy usando 1.8.7 (debido a Logstash) pero la versión actual está en 0.19.4 en este momento de la escritura. Hay demasiados parámetros diferentes para incluso hablar sobre un punto de referencia estándar, ya que Elastic Search no es exactamente una herramienta industrial estándar que la gente usa hoy en día, así que supongo que necesitas reformular lo que preguntas para que la gente pueda comentar.

Answer 2

Es difícil darle una respuesta exacta pero sus números no suenan demasiado inesperados.

• Asegúrese de que ha optimizado su índice con número de segmentos = 1.
• Suba el tamaño del grupo de subprocesos en busca elástica.
• Asegúrate de que Xms y Xmx sean iguales, usa el bloqueo simulado.

Esto debería darle un poco de impulso en el rendimiento, aunque no estoy sorprendido de que una base de datos relacional performant con sólo 3 millones de documentos está funcionando tan bien o mejor, la diferencia es que el PP obtendrá más lenta mientras que ES llevará a cabo lo mismo con 100 de millones.