Notas de acabado de Elasticsearch (5)

Nota para versiones superiores a es6:

1. Elasticsearch-head informará un error 406 cuando se conecte a versiones superiores a 6.x:

Content-Type header [application/x-www-form-urlencoded] is not supported

razón:

La versión 6.x de ES controla estrictamente el problema del tipo de contenido. application/x-www-form-urlencoded no admite el cuerpo del contenido en formato JSON, por lo que debe modificarse.

Solución:

Ingrese al directorio de instalación del complemento principal -> carpeta elasticsearch-head -> archivo vendor.js

Modificar dos lugares:

1. 6886行 contentType: "application/x-www-form-urlencoded"
    改成 contentType: "application/json;charset=UTF-8" 
2. 7574行 var inspectData = s.contentType === "application/x-www-form-urlencoded" && 
    改成 var inspectData = s.contentType === "application/json;charset=UTF-8" &&

 

2.tipo

Desde el primer lanzamiento de Elasticsearch, cada documento se almacena en un índice separado y se le asigna un tipo, un tipo de asignación que representa el tipo de documento o entidad que se indexa, por ejemplo, un índice de Twitter. Puede haber un tipo de usuario y un tipo de tweet. .

Cada tipo de asignación tiene sus propios campos, por lo que un tipo de usuario puede tener un campo de nombre completo, un campo de nombre de usuario y un campo de correo electrónico, mientras que un tipo de tweet puede tener un campo de contenido, un campo tweet_at y un campo de nombre de usuario como el tipo de usuario.

Cada tipo de documento tiene un metacampo _type para almacenar el nombre del tipo, y la consulta (búsqueda) está limitada a uno o más tipos (tipo) según el nombre del tipo especificado en la URL

GET twitter/user,tweet/_search
{
  "query": {
    "match": {
      "user_name": "kimchy"
    }
  }
}

El campo _type se usa para combinar con el campo _id del documento para generar el campo _uid, por lo que pueden existir documentos de diferentes tipos con el mismo _id en el mismo índice. Los tipos también se utilizan para establecer relaciones padre-hijo entre documentos, por lo que un documento de tipo pregunta puede ser el documento padre de un documento de tipo respuesta.

Al principio dijimos que "índice" y "biblioteca" de una base de datos relacional son similares, y "tipo" y "tabla" son equivalentes.
Este es un contraste incorrecto, que conduce a suposiciones incorrectas. En una base de datos relacional, las "tablas" son independientes entre sí, y las columnas de una "tabla" no tienen relación con las columnas del mismo nombre en otra "tabla" y no se afectan entre sí. Pero este no es el caso de los campos en los tipos.

En un índice de Elasticsearch, todos los diferentes tipos de campos con el mismo nombre utilizan el mismo almacenamiento de campo lucene internamente. Es decir, en el ejemplo anterior, el campo nombre_usuario del tipo de usuario y el campo nombre_usuario del tipo tweet se almacenan en un campo, y el nombre_usuario en los dos tipos debe tener la misma definición de campo.

Esto puede causar problemas, por ejemplo, si desea que el campo "eliminado" en el mismo índice almacene un valor de fecha en un tipo y un valor booleano en otro tipo.

Finalmente, en el mismo índice, almacenar documentos con solo una pequeña cantidad de campos que son iguales o todos los campos son diferentes dará como resultado datos escasos y afectará la capacidad de Lucene para comprimir datos de manera efectiva.

Entonces 6.X impone que un índice solo puede tener un tipo, mientras que 7.X elimina directamente el concepto de tipo.

Pero hay un problema . En la versión ES5.X, los documentos padre-hijo se utilizan para realizar la asociación de múltiples tablas, similar a la función de Unión en la base de datos; el núcleo de la implementación es admitir múltiples tipos bajo un índice ( índice) con la ayuda de ES5.X. En la versión ES6.X, solo se admite un único tipo en cada índice. ¿Cómo realizar la asociación de múltiples tablas similares a mysql? ——Elasticsearch 6.X nuevo tipo Unirse

Para obtener más información, consulte el documento oficial: https://www.elastic.co/guide/en/elasticsearch/reference/current/parent-join.html

3. Consulta de caracteres especiales y palabras clave

En la versión es5, puede usar directamente términos, comodines, etc. para consultar los campos sin segmentación de palabras, pero encontrará que la consulta no es válida después de es 6. Los caracteres especiales como "+" no pueden participar en las condiciones de búsqueda y escapan también son inválidos.

{
	"query": {
		"bool": {
			"filter": [{
				"term": {
					"user_id":"user-x"
				}
			}]
		}
	}
}

La consulta anterior no puede encontrar el valor de "user-x" en el campo "user_id".

{
	"query": {
		"bool": {
			"filter": [{
				"term": {
					"user_id":"user"
				}
			}]
		}
	}
}

En cambio, la consulta anterior puede encontrar el usuario-x.

razón:

A partir de la versión 5.0 de es, el tipo de cadena se divide en dos tipos: texto y palabra clave, el primero se segmentará primero y luego se indexará, mientras que el segundo no, y la cadena completa se convertirá directamente en el índice.

Descripción oficial:

Keyword datatype
A field to index structured content such as email addresses, hostnames, status codes, zip codes or tags.
They are typically used for filtering (Find me all blog posts where status is published), for sorting, and for aggregations. Keyword fields are only searchable by their exact value.
If you need to index full text content such as email bodies or product descriptions, it is likely that you should rather use a text field.

No sé por qué, pero este no es el caso de las palabras clave posteriores a la versión 6.x. Los datos del texto original aún se procesarán mediante la segmentación de palabras, pero se creará un atributo de palabra clave adicional para conservar los caracteres completos.

Cuando buscamos datos originales sin segmentación de palabras, debemos agregar .keyword después de la clave original y comparar key.keyword para lograr una coincidencia precisa.

{
	"query": {
		"bool": {
			"filter": [{
				"term": {
					"user_id.keyword":"user-x"
				}
			}]
		}
	}
}

Este diseño es simplemente antihumano, y no esperaba ninguna ventaja de tal diseño. Y habrá una gran cantidad de datos de segmentación de palabras inútiles que desperdiciarán recursos, entonces, ¿es necesario usar es si no se requiere la segmentación de palabras? Esta es una pregunta profunda del alma.