En el post anterior se ha hablado sobre como crear y gestionar índices así como la forma de realizar búsquedas con el endpoint “_search”, lo cual es el punto de entrada para comprender el funcionamiento de ES. Probablemente las características más complejas de este producto están precisamente relacionadas con las búsquedas, ya que como se verá en este post, existen varias maneras de aplicar filtros sobre índices y documentos.
En primer lugar, el endpoint “_search” no solamente admite peticiones GET, también es posible ejecutar una petición POST y en el cuerpo de la petición enviar filtros un poco más específicos que los que se podrían incluir en una petición GET. Por ejemplo:
POST /indice/tipo/_search
{ “query”: { “match”: { “title”: {
“query”: “palabra1 palabra2”,
“operator”: “and”}
}
}
“size”: 2,
“from”: 0,
“_source”: [ “campo1”, “campo2”, “campo3” ],
“highlight”: { “fields” : { “title” : {} } }
}
Se trata de una búsqueda más compleja, en la que se incluye el campo “query” que a su vez admite una estructura muy concreta para realizar la búsqueda. Con “match” se especifican los filtros, que en este caso aplican únicamente al campo “title”, es decir, que todos los documentos que tengan dicho campo serán objeto de búsqueda. Luego, se repite nuevamente el campo “query” pero en esta ocasión será útil para indicar un texto libre. Es posible utilizar operadores como “or” y “and”, de tal manera que dicha operación lógica se aplicará sobre las palabras especificadas en el campo “query”. En el ejemplo anterior, al aplicar el operador “and”, significa que la búsqueda devolverá solamente aquellos documentos que tenga en el campo “title” las palabras “palabra1” y “palabra2”. Luego, se puede apreciar en el cuerpo de la petición otros campos adicionales, tales como “size” y “from”, los cuales permiten devolver resultados en bloques, algo ideal para implementar búsquedas paginadas. Finalmente, los campos “_source” y “highlight” sirven para indicar aquellos campos del documento que devolverá la búsqueda, en este caso “campo1”, “campo2” y “campo3”. Si el documento tiene más campos estos no son incluidos en los resultado de la búsqueda.
El resultado de una búsqueda como la anterior es una estructura en formato JSON que contiene algunos campos interesantes, como por ejemplo “_source” y “score”. En el caso del primero, se trata de la estructura JSON con los resultados de la búsqueda, es decir, todos los documentos que han coincidido con los filtros especificados y el segundo, es el factor de coincidencia y es aquí en donde ES se complica un poco más, ya que ES internamente realiza una serie de calculos para asignar a cada resultado de las búsquedas un valor de coincidencia, esto es un indicativo que permite ubicar cada documento en un orden concreto en el listado de resultados. Pensad por ejemplo en Google, los enlaces a páginas externas que arroja cada búsqueda enseñan en las primeras posiciones aquellos que tienen mejor page rank, aquellos que pueden ser más interesantes para el usuario. ES hace lo mismo partiendo de los filtros que se incluyen en las búsquedas. Por ejemplo, en el caso anterior, cuantas más veces aparezca en un documento las palabras “palabra1” y “palabra2”, el documento tendrá mejor score y por lo tanto aparecerá en mejores posiciones dentro del resultado de la búsqueda. En la documentación oficial de ES podéis ver algunos ejemplos de búsquedas de este tipo para que quede un poco más claro, aunque desafortunadamente en mi opinión, la documentación oficial de ES es una de las más escuetas, poco claras y con más errores que me he encontrado hasta ahora en un producto de software, desafortunadamente es lo que hay y muchas veces toca pegarse con el producto para aprender realmente cómo funciona y ver las cosas que han cambiado, que ya no funcionan o que funcionan de forma diferente entre diferentes versiones. Los siguientes enlaces pueden ser útiles:
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-body.html https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html
Por otro lado, algunos de los campos que se han incluido en el cuerpo de la petición (los más simples) también se pueden incluir como parámetros en la URL del endpoint “_search”, por ejemplo:
GET /_search?size=5
Enseña los 5 primeros resultados de la búsqueda.
GET /_search?size=5&from=5
Enseña los resultados del 5 al 10.
GET /_search?size=5&from=10
Enseña los resultados del 5 al 15.
como se ha explicado anteriormente, ES se encarga ordenar los resultados de las consultas antes devolverlos basándose en el campo “_score”, por lo tanto es común y recomendable utilizar los mecanismos de paginación para evitar problemas de rendimiento en las consultas.
Operaciones sobre índices y documentos.
Es importante conocer la forma en la que ElasticSearch interpreta los documentos almacenados en un índice concreto, ya que es posible que algunos de los campos no contengan la estructura esperada, tal como se ha visto en el post anterior a este, es posible crear documentos que no siguen ninguna estructura referente a los campos. Para ver el “mapeo” que tienen los documentos (parecido a la definición de una tabla en una base de datos relacional) es necesario utilizar el endpoint “_mapping” disponible en el índice.
GET /index/_mapping
A la hora de crear un índice es posible incluir el campo “mappings” y especificar cómo será la estructura de los campos que podrán ser heredados por los documentos creados en el índice, por ejemplo:
PUT my_index
{ “mappings”: { “properties”: {
“campo”: { “type”: “keyword”}
}}}
Es recomendable echarle un vistazo a lo que se explica en la documentación oficial sobre los mapeos en índices: https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-params.html
Los índices pueden estar abiertos o cerrados, lo que significa que es posible trabajar con ellos para operaciones de lectura/escritura o no. No es posible indexar documentos o realizar búsquedas sobre índices cerrados. Cuando un índice está cerrado, ES no mantiene las estructuras de datos internas para la búsqueda, es decir, los documentos no se indexan y por lo tanto, el consumo de memoria es menor. No obstante, dependiendo del tamaño de los documentos de dicho índice, un índice cerrado puede suponer un consumo considerable de disco duro ya que como resulta evidente, la información de dichos documentos se debe guardar de forma persistentemente en disco en el caso de que el índice se abra nuevamente. Abrir o cerrar un índice es muy sencillo tal como se muestra a continuación. (obviamente, “my_index” corresponde al nombre del índice).
* Abrir un índice: POST /my_index/_open
* Cerrar un índice: POST /my_index/_close
Alias sobre índices.
Una forma rápida y sencilla de obtener todos los índices disponibles en ES es por medio del endpoint “_aliases” el cual devuelve un listado de todos los alias disponibles para cada uno de los índices. Con este endpoint también es posible crear o eliminar alias (etiquetas) sobre los índices creados.
POST /_aliases {
“actions” : [ { “add” : { “index” : “test1”, “alias” : “alias1” } },
{ “remove” : { “index” : “test1”, “alias” : “alias2” } } ] }
En el caso anterior, las acciones utilizadas son “add” y “remove”. Se ha creado un alias el nombre “alias1” sobre el indice “test1” y además, se ha eliminado el alias “alias2” sobre el índice “test1”. Un índice puede tener múltiples “alias” sin que esto afecte a los documentos o estructura del índice.
Probablemente una de las características más potentes de los alias es que permiten crear vistas sobre los índices partiendo de los filtros, por ejemplo:
POST /_aliases {
“actions” : [ {“add” : {“index” : “test1”, “alias” : “alias2”,
“filter” : { “term” : { “campo” : “valor” } } } } ] }
Como se puede apreciar, se ha creado un alias con nombre “alias2” sobre el índice “test1”. Cuando se intente consultar dicho alias, ES aplicará el filtro indicado en el campo “filter” y devolverá los documentos que coincidan con la búsqueda. Esto en el mundo de las bases de datos relacionales es similar a las vistas, lo cual simplifica mucho las consultas que se pueden realizar contra un índice concreto. Para consultar el alias, se accede directamente al endpoint “_search”, por ejemplo:
GET /alias1/_search
GET /alias2/_search
Al realizar una petición como la anterior ES se encargará de buscar dicho alias, ver el índice al que apunta y si hay algún filtro, aplicarlo.
Los alias también se pueden utilizar como vistas de escritura, es decir, una forma de simplificar la creación de documentos con el atributo “is_write_index”.
POST /_aliases
{ “actions” : [
{ “add” : {“index” : “test”, “alias” : “alias1”, “is_write_index” : true } }
]}
Como se puede apreciar, para crear un alias en modo escritura, basta simplemente con incluir el campo “is_write_index” con el valor “true” a la hora de crearlo. Para utilizar el índice en modo de escritura se podrá realizar una petición POST o PUT de la siguiente forma.
PUT /alias1/_doc/1
{
“campo”: “valor”
}
En donde “_doc” es un endpoint que le permite a ES saber que se intenta acceder a la estructura de documentos que se encuentran almacenados en el índice al que apunta el alias “alias1”, luego en el cuerpo de la petición viene el JSON con el documento propiamente dicho.
Consultas interesantes en ES
Antes de finalizar este post, es conveniente conocer algunos de los endpoints disponibles en el producto para realizar consultas directas sobre el estado del nodo o cluster. Para ello existen varios endpoints interesantes que son muy sencillos y aportan información valiosa. Por ejemplo:
GET /_cat/master?v
GET /_cat/nodes?v
GET /_cat/indices?v
GET /_cat/plugins?v
GET /_cat/shards?v
GET /_cat/health?v
GET /_cat/master?help
GET /_nodes/node1,node2
GET /_nodes/process
GET /_nodes/_all/process
GET /_nodes/node1,node2/jvm,process
GET /_nodes/plugins
GET /_nodes/stats/indices
GET /_nodes/stats/os,process
GET /_nodes/192.168.1.101/stats/process
GET /_nodes/usage
GET /_nodes/nodeId1,nodeId2/usage
GET /_nodes/hot_threads
Son peticiones fáciles de entender y que permiten extraer información relevante sobre una instancia de ES en ejecución, de hecho, complementos como “cerebro”, “elasticsearch-HQ” o el propio Kibana hacen uso de estos endpoints de forma directa para enseñar la información en un formato amigable para el usuario.
En el próximo artículo de la serie se hablará sobre configuración de una instancia de ES y algunas consideraciones de seguridad que se entenderán mucho mejor después de haber leído la parte 1 y la parte 2 de la serie.
Un saludo y Happy Hack.
Adastra.