¿Búsqueda elástica, múltiples índices versus un índice y tipos para diferentes conjuntos de datos?


161

Tengo una aplicación desarrollada usando el patrón MVC y me gustaría indexar ahora varios modelos, esto significa que cada modelo tiene una estructura de datos diferente.

  • ¿Es mejor usar índices múltiples, uno para cada modelo o tener un tipo dentro del mismo índice para cada modelo? Ambas formas también requerirían una consulta de búsqueda diferente, creo. Acabo de empezar con esto.

  • ¿Existen diferencias de rendimiento entre ambos conceptos si el conjunto de datos es pequeño o enorme?

Yo mismo probaría la segunda pregunta si alguien pudiera recomendarme algunos datos de muestra buenos para ese propósito.

Respuestas:


184

Hay diferentes implicaciones para ambos enfoques.

Suponiendo que está utilizando la configuración predeterminada de Elasticsearch, tener 1 índice para cada modelo aumentará significativamente la cantidad de fragmentos, ya que 1 índice usará 5 fragmentos, 5 modelos de datos usarán 25 fragmentos; mientras que tener 5 tipos de objetos en 1 índice todavía va a usar 5 fragmentos.

Implicaciones para tener cada modelo de datos como índice:

  • Eficiente y rápido para buscar dentro del índice, ya que la cantidad de datos debe ser menor en cada fragmento ya que se distribuye a diferentes índices.
  • La búsqueda de una combinación de modelos de datos de 2 o más índices generará una sobrecarga, ya que la consulta tendrá que enviarse a más fragmentos a través de índices, compilarse y enviarse de vuelta al usuario.
  • No se recomienda si su conjunto de datos es pequeño, ya que incurrirá en más almacenamiento con cada fragmento adicional que se crea y la ganancia de rendimiento es marginal.
  • Recomendado si su conjunto de datos es grande y sus consultas tardan mucho en procesarse, ya que los fragmentos dedicados almacenan sus datos específicos y Elasticsearch lo procesará más fácilmente.

Implicaciones para tener cada modelo de datos como un tipo de objeto dentro de un índice:

  • Se almacenarán más datos dentro de los 5 fragmentos de un índice, lo que significa que hay menores problemas de sobrecarga cuando realiza consultas en diferentes modelos de datos, pero el tamaño de su fragmento será significativamente mayor.
  • Elasticsearch tardará más tiempo en buscar más datos dentro de los fragmentos, ya que hay más documentos para filtrar.
  • No se recomienda si sabe que está pasando por 1 terabytes de datos y no está distribuyendo sus datos a través de diferentes índices o fragmentos múltiples en su mapeo Elasticsearch.
  • Recomendado para pequeños conjuntos de datos, ya que no desperdiciará espacio de almacenamiento para obtener un rendimiento marginal, ya que cada fragmento ocupa espacio en su hardware.

Si se pregunta qué es demasiados datos frente a datos pequeños. Por lo general, depende de la velocidad del procesador y la RAM de su hardware, la cantidad de datos que almacena dentro de cada variable en su asignación para Elasticsearch y sus requisitos de consulta; El uso de muchas facetas en sus consultas reducirá significativamente su tiempo de respuesta. No hay una respuesta directa a esto y tendrá que comparar según sus necesidades.


8
Esta respuesta no es completa sin la información de elasticsearch.org/guide/en/elasticsearch/guide/current/...
AndreKR

55
Para agregar a la excelente respuesta, cito el documento ES 5.2 que explica por qué no se recomienda mantener una gran cantidad de fragmentos: " By default elasticsearch rejects search requests that would query more than 1000 shards. The reason is that such large numbers of shards make the job of the coordinating node very CPU and memory intensive. It is usually a better idea to organize data in such a way that there are fewer larger shards. In case you would like to bypass this limit, which is discouraged, you can update the action.search.shard_count.limit cluster setting to a greater value."
olvido


13

La respuesta de Jonathan es genial. Solo agregaría algunos otros puntos a considerar:

  • se puede personalizar la cantidad de fragmentos por solución que seleccione. Puede tener un índice con 15 fragmentos primarios, o dividirlo en 3 índices para 5 fragmentos: la perspectiva del rendimiento no cambiará (suponiendo que los datos se distribuyan por igual)
  • pensar en el uso de datos. Es decir. si usa kibana para visualizar, es más fácil incluir / excluir índices particulares, pero los tipos deben filtrarse en el tablero
  • retención de datos: para el registro de la aplicación / datos métricos, use diferentes índices si necesita un período de retención diferente

¿Qué se entiende por período de retención? ¿Te refieres al campo de tiempo de vida? Eso se establece por documento.
Kshitiz Sharma

No, aquí el período de retención se entiende como retención de documentos / índices: cuánto tiempo almacenar esos datos. Según la calidad, el tamaño y la importancia de los datos, utilizo para especificar diferentes políticas de retención. Algunos datos / índices se eliminan después de 7 días, otros después de 6 w, y algunos después de 10 años ...
Marcel Matus

2

¡Ambas respuestas anteriores son geniales!

Estoy agregando un ejemplo de varios tipos en un índice. Supongamos que está desarrollando una aplicación para buscar libros en una biblioteca. Hay algunas preguntas para hacerle al propietario de la Biblioteca,

Preguntas:

  1. ¿Cuántos libros planeas almacenar?

  2. ¿Qué tipo de libros vas a almacenar en la biblioteca?

  3. ¿Cómo vas a buscar libros?

Respuestas:

  1. Estoy planeando almacenar 50 k - a 70 k libros (aproximadamente)

  2. Tendré 15 k -20 k libros relacionados con la tecnología (informática, ingeniería mecánica, ingeniería química, etc.), 15 k de libros históricos, 10 k de libros de ciencias médicas. 10 k de libros relacionados con el idioma (inglés, español, etc.)

  3. Búsqueda por nombre del autor, apellido del autor, año de publicación, nombre del editor. (Esto le da la idea de qué información debe almacenar en el índice)

De las respuestas anteriores, podemos decir que el esquema en nuestro índice debería verse más o menos así.

// Esta no es la asignación exacta, solo para el ejemplo

            "yearOfPublish":{
                "type": "integer"
            },
            "author":{
                "type": "object",
                "properties": {
                    "firstName":{
                        "type": "string"
                    },
                    "lastName":{
                        "type": "string"
                    }
                }
            },
            "publisherName":{
                "type": "string"
            }
        }

Para lograr lo anterior, podemos crear un índice llamado Libros y podemos tener varios tipos.

Índice: Libro

Tipos: ciencia, artes

(O puede crear muchos tipos, como Tecnología, Ciencias médicas, Historia, Idioma, si tiene muchos más libros)

Lo importante a tener en cuenta aquí es que el esquema es similar pero los datos no son idénticos. Y la otra cosa importante es el total de datos que está almacenando.

Espero que lo anterior ayude a elegir diferentes tipos en un índice; si tiene un esquema diferente, debe considerar un índice diferente. Pequeño índice para menos datos. gran índice para grandes datos :-)

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.