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

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.

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.

Aunque la respuesta de Jonathan era correcta en ese momento, el mundo ha avanzado y ahora parece que las personas detrás de ElasticSearch tienen un plan a largo plazo para abandonar el soporte para múltiples tipos:

A dónde queremos llegar: Queremos eliminar el concepto de tipos de Elasticsearch, sin dejar de admitir padre / hijo.

Entonces, para nuevos proyectos, el uso de un solo tipo por índice hará que la actualización final a ElasticSearch 6.x sea más fácil.

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

¡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 :-)