Elasticsearch
Diferencia entre índices y tipos

Es fácil ver el type s como una tabla en una base de datos SQL, donde el index es la base de datos SQL. Sin embargo, esa no es una buena manera de abordar el type s.

Todo sobre los tipos

De hecho, los tipos son, literalmente, solo un campo de metadatos agregado a cada documento por _type : _type . Los ejemplos anteriores crearon dos tipos: my_type y my_other_type . Eso significa que cada documento asociado con los tipos tiene un campo adicional automáticamente definido como "_type": "my_type" ; Esto se indexa con el documento, lo que lo convierte en un campo de búsqueda o de filtro , pero no afecta al documento sin formato, por lo que su aplicación no necesita preocuparse por ello.

Todos los tipos viven en el mismo índice y, por lo tanto, en los mismos fragmentos colectivos del índice. Incluso a nivel de disco, viven en los mismos archivos. La única separación que proporciona la creación de un segundo tipo es una lógica. Cada tipo, ya sea único o no, debe existir en las asignaciones y todas esas asignaciones deben existir en su estado de agrupación. Esto consume memoria y, si cada tipo se actualiza dinámicamente, consume el rendimiento a medida que cambian las asignaciones.

Como tal, es una buena práctica definir solo un tipo a menos que realmente necesite otros tipos. Es común ver escenarios donde son deseables múltiples tipos. Por ejemplo, imagina que tienes un índice de autos. Puede ser útil para usted descomponerlo en varios tipos:

• BMW
• caza
• honda
• mazda
• mercedes
• nissan
• guardabosques
• toyota
• ...

De esta manera puede buscar todos los autos o limitarlos por fabricante a pedido. La diferencia entre esas dos búsquedas es tan simple como:

GET /cars/_search

y

GET /cars/bmw/_search

Lo que no es obvio para los nuevos usuarios de Elasticsearch es que la segunda forma es una especialización de la primera forma. Literalmente se reescribe a:

GET /cars/_search
{
  "query": {
    "bool": {
      "filter": [
        {
          "term" : {
            "_type": "bmw"
          }
        }
      ]
    }
  }
}

Simplemente filtra cualquier documento que no haya sido indexado con un campo _type cuyo valor fue bmw . Dado que cada documento está indexado con su tipo como el campo _type , esto sirve como un filtro bastante simple. Si se proporcionó una búsqueda real en cualquiera de los dos ejemplos, entonces el filtro se agregará a la búsqueda completa según corresponda.

Como tal, si los tipos son idénticos, es mucho mejor suministrar un solo tipo (p. Ej., manufacturer en este ejemplo) e ignorarlo de manera efectiva. Luego, dentro de cada documento, proporcione explícitamente un campo llamado make o el nombre que prefiera y filtre manualmente cada vez que quiera limitarlo. Esto reducirá el tamaño de sus asignaciones a 1/n donde n es el número de tipos separados. Añade otro campo a cada documento, en beneficio de un mapeo simplificado.

En Elasticsearch 1.xy 2.x, este campo debe definirse como

PUT /cars
{
  "manufacturer": { <1>
    "properties": {
      "make": { <2>
        "type": "string",
        "index": "not_analyzed"
      }
    }
  }
}

1. El nombre es arbitrario.
2. El nombre es arbitrario y podría coincidir con el nombre de tipo si lo deseara también.

En Elasticsearch 5.x, lo anterior seguirá funcionando (está en desuso), pero la mejor manera es usar:

PUT /cars
{
  "manufacturer": { <1>
    "properties": {
      "make": { <2>
        "type": "keyword"
      }
    }
  }
}

1. El nombre es arbitrario.
2. El nombre es arbitrario y podría coincidir con el nombre de tipo si lo deseara también.

Los tipos deben usarse con moderación dentro de sus índices, ya que aumentan las asignaciones de índice, generalmente sin mucho beneficio. Debe tener al menos uno, pero no hay nada que diga que debe tener más de uno.

Preguntas comunes

• ¿Qué sucede si tengo dos (o más) tipos que son en su mayoría idénticos, pero que tienen algunos campos únicos por tipo?

En el nivel de índice, no hay diferencia entre un tipo que se usa con unos pocos campos que se utilizan poco y entre varios tipos que comparten un grupo de campos no dispersos con unos pocos no compartidos (lo que significa que el otro tipo ni siquiera usa el campo). (s)).

Dicho de otra manera: un campo poco utilizado es escaso en todo el índice, independientemente de los tipos . La escasez no beneficia, o realmente perjudica, al índice solo porque está definido en un tipo separado.

Simplemente debe combinar estos tipos y agregar un campo de tipo separado.

• ¿Por qué tipos separados necesitan definir campos exactamente de la misma manera?

Debido a que cada campo realmente solo se define una vez en el nivel de Lucene, independientemente de cuántos tipos haya. El hecho de que existan tipos es una característica de Elasticsearch y es solo una separación lógica.

• ¿Puedo definir tipos separados con el mismo campo definido de manera diferente?

No. Si logra encontrar una manera de hacerlo en ES 2.x o posterior, debe abrir un informe de error . Como se señaló en la pregunta anterior, Lucene los ve a todos como un solo campo, por lo que no hay manera de hacer que esto funcione adecuadamente.

ES 1.x dejó esto como un requisito implícito, lo que permitió a los usuarios crear condiciones en las que las asignaciones de un fragmento en un índice realmente diferían de otro fragmento en el mismo índice. Esto fue efectivamente una condición de carrera y podría llevar a problemas inesperados.

Excepciones a la Regla

• Los documentos padre / hijo requieren tipos separados para usarse dentro del mismo índice.
  • El padre vive en un tipo.
  • El niño vive en un tipo separado (pero cada niño vive en el mismo fragmento que su padre).
• Los casos de uso de nichos extremos en los que la creación de toneladas de índices no es deseable y el impacto de campos dispersos es preferible a la alternativa.
  • Por ejemplo, el complemento de monitoreo de Elasticsearch, Marvel (1.xy 2.x) o X-Pack Monitoring (5.x +), monitorea a Elasticsearch en busca de cambios en el clúster, nodos, índices, índices específicos (el nivel del índice), e incluso los fragmentos. Podría crear más de 5 índices cada día para aislar los documentos que tienen asignaciones únicas o podría ir en contra de las mejores prácticas para reducir la carga de clústeres al compartir un índice (nota: la cantidad de asignaciones definidas es efectivamente la misma, pero la cantidad de índices creados). se reduce de n a 1).
  • Este es un escenario avanzado, pero debe tener en cuenta las definiciones de campos compartidos entre los tipos.