database - ver - uso de indices en oracle

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

Question

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

• ¿Es mejor utilizar índices múltiples, uno para cada modelo o 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 esto.

• ¿Existen diferencias en el 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 buenos datos de muestra para ese propósito.

Answer 1

¡Ambas respuestas 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 pocas preguntas para hacerle al propietario de la Biblioteca,

Preguntas:

1. ¿Cuántos libros planea almacenar?

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

3. ¿Cómo vas a buscar libros?

Respuestas

1. Planeo almacenar libros de 50 k a 70 k (aproximadamente)

2. Tendré libros relacionados con la tecnología de 15 k -20 k (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. Busque por nombre de 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 algo 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 puede tener varios tipos.

Índice: Libro

Tipos: Ciencia, Artes

(O puede crear muchos tipos, como Tecnología, Ciencias Médicas, Historia, Lenguaje, 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 la información total que está almacenando.

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

Answer 2

Aunque la respuesta de Jonathan fue 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 dejar de recibir soporte para varios tipos:

Dónde queremos llegar: queremos eliminar el concepto de tipos de Elasticsearch, mientras seguimos apoyando padres / hijos.

Por lo tanto, para nuevos proyectos, usar solo un tipo por índice hará que la eventual actualización a ElasticSearch 6.x sea más fácil.

Answer 3

Hay diferentes implicaciones para ambos enfoques.

Suponiendo que está utilizando la configuración predeterminada de Elasticsearch, tener 1 índice para cada modelo aumentará significativamente el número 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 utilizar 5 fragmentos.

Implicaciones para tener cada modelo de datos como índice:

• Eficiente y rápido de 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á gastos generales, ya que la consulta tendrá que enviarse a más fragmentos entre los í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 tiempo en procesarse, ya que los fragmentos dedicados están almacenando sus datos específicos y será más fácil de procesar por parte de Elasticsearch.

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 menos problemas de sobrecarga cuando consulta en diferentes modelos de datos, pero el tamaño del fragmento será significativamente mayor.
• Más datos dentro de los fragmentos tomarán más tiempo para que Elasticsearch busque, ya que hay más documentos para filtrar.
• No se recomienda si sabe que está atravesando 1 terabyte de datos y no está distribuyendo sus datos entre diferentes índices o fragmentos múltiples en su asignación de 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 está preguntando ¿qué es demasiada información contra 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 ralentizará significativamente su tiempo de respuesta. No hay una respuesta directa a esto y deberá comparar según sus necesidades.

Answer 4

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

• número de fragmentos se puede personalizar por solución que seleccione. Puede tener un índice con 15 fragmentos primarios, o dividirlo en 3 índices para 5 fragmentos: la perspectiva de 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 un índice (es) en particular, pero los tipos tienen que ser filtrados en el tablero
• retención de datos: para el registro de aplicaciones / datos métricos, utilice índices diferentes si necesita un período de retención diferente