Solución:
Buena pregunta, y la respuesta es mucho más matizada de lo que cabría esperar. Puede utilizar índices para varios propósitos diferentes.
Índices de relaciones
El diseño más fácil y familiar clona lo que cabría esperar de una base de datos relacional. Puede pensar (muy aproximadamente) en un índice como una base de datos.
- MySQL => Bases de datos => Tablas => Filas / Columnas
- ElasticSearch => Índices => Tipos => Documentos con propiedades
Un clúster de ElasticSearch puede contener múltiples Indices (bases de datos), que a su vez contienen múltiples Types (mesas). Estos tipos tienen múltiples Documents (filas), y cada documento tiene Properties (columnas).
Entonces, en el escenario de fabricación de su automóvil, es posible que tenga un SubaruFactory índice. Dentro de este índice, tiene tres tipos diferentes:
PeopleCarsSpare_Parts
Luego, cada tipo contiene documentos que corresponden a ese tipo (por ejemplo, un documento de Subaru Imprezza vive dentro del Cars escribe. Este documento contiene todos los detalles sobre ese automóvil en particular).
La búsqueda y consulta toma el formato de: http: // localhost: 9200 /[index]/[type]/[operation]
Entonces, para recuperar el documento de Subaru, puedo hacer esto:
$ curl -XGET localhost:9200/SubaruFactory/Cars/SubaruImprezza
.
Índices de registro
Ahora, la realidad es que los índices / tipos son mucho más flexibles que las abstracciones de bases de datos / tablas a las que estamos acostumbrados en los RDBM. Pueden considerarse mecanismos convenientes de organización de datos, con beneficios de rendimiento adicionales según cómo configure sus datos.
Para demostrar un enfoque radicalmente diferente, mucha gente usa ElasticSearch para el registro. Un formato estándar es asignar un índice nuevo para cada día. Su lista de índices puede verse así:
- registros-2013-02-22
- registros-2013-02-21
- registros-2013-02-20
ElasticSearch le permite consultar varios índices al mismo tiempo, por lo que no es un problema:
$ curl -XGET localhost:9200/logs-2013-02-22,logs-2013-02-21/Errors/_search=q:"Error Message"
Que busca en los registros de los últimos dos días al mismo tiempo. Este formato tiene ventajas debido a la naturaleza de los registros: la mayoría de los registros nunca se examinan y están organizados en un flujo de tiempo lineal. Hacer un índice por registro es más lógico y ofrece un mejor rendimiento para la búsqueda.
.
Índices para usuarios
Otro enfoque radicalmente diferente es crear un índice por usuario. Imagine que tiene un sitio de redes sociales y cada usuario tiene una gran cantidad de datos aleatorios. Puede crear un índice único para cada usuario. Su estructura puede verse así:
- Índice de Zach
- Tipo de aficiones
- Tipo de amigos
- Tipo de imágenes
- Índice de Fred
- Tipo de aficiones
- Tipo de amigos
- Tipo de imágenes
Observe cómo esta configuración se podría realizar fácilmente en una forma RDBM tradicional (por ejemplo, índice de “Usuarios”, con aficiones / amigos / imágenes como tipos). Luego, todos los usuarios serían arrojados a un único índice gigante.
En cambio, a veces tiene sentido dividir los datos por motivos de organización y rendimiento de los datos. En este escenario, asumimos que cada usuario tiene mucho de datos y queremos que estén separados. ElasticSearch no tiene ningún problema en dejarnos crear un índice por usuario.
La respuesta de @Zach es válida para elasticsearch 5.X y versiones anteriores. Desde elasticsearch 6.X Type ha quedado obsoleto y se eliminará por completo en 7.X. Citando los documentos de elasticsearch:
Inicialmente, hablamos de que un “índice” es similar a una “base de datos” en una base de datos SQL, y un “tipo” es equivalente a una “tabla”. Esta fue una mala analogía que llevó a suposiciones incorrectas.
Además de explicar, dos columnas con el mismo nombre en SQL de dos tablas diferentes pueden ser independientes entre sí. Pero en un índice de búsqueda elástica eso no es posible ya que están respaldados por el mismo campo de Lucene. Por lo tanto, “index” en elasticsearch no es exactamente lo mismo que una “base de datos” en SQL. Si hay campos iguales en un índice, terminarán teniendo conflictos de tipos de campos. Para evitar esto, la documentación de elasticsearch recomienda almacenar índice por tipo de documento.
Consulte: Eliminación de tipos de mapeo