En el artículo anterior tuvimos una breve introducción a esta herramienta del stack, la cual es básicamente el core de donde nuestra información va a ser guardada y consultada. Es hora de ver en más profundidad como accedemos a esos datos de una manera rápida y fácil. Allá vamos...
Api de Elasticsearch
Para facilitar el acceso a datos Elasticsearch nos provee de una API HTTP, endpoints REST para consulta de los datos almacenados. En este caso comenzaremos viendo las APIs mas utilizadas y con una breve descripción de su uso.
API de cluster
Este API lo que nos provee es una serie de endpoints que nos brindan información acerca del cluster, de su funcionamiento y como se encuentra éste en un momento concreto del tiempo.
Como bien mencione en el párrafos anteriores el API utiliza el protocolo HTTP por lo que los métodos con los que podemos consultar las APIS son los métodos HTTP (GET, POST, PUT, DELETE). Además la información que nos devuelve se encuentra en formato JSON.
Todo se encuentra muy bien documentado en la página oficial de Elastic.
Documentación: API de Cluster
API de catálogo
Este API es muy parecida a la anterior con la diferencia de que nos devuelve la información en un formato un poco más legible para un ser humano. Es decir es una API de consulta rápida que nos provee la misma información que la API de cluster.
Documentación: API de Catálogo
API de índices
Nos permite gestionar nuestro índices, es decir, crear nuevos, borrarlos, obtener información, abrir y cerrar índices, que significa poder limitar la asociación de documentos para un índice.
Documentación: API de Índices
API de documentos
Este API nos da la posibilidad de crear documentos y gestionarlos ya sea de manera individual como trabajar con un grupo de documentos.
Documentación: API de Documentos
API de búsqueda
Es el API más potente, ya que nos permite hacer búsquedas complejas sobre los documentos guardados en Elasticsearch.
Documentación: API de Búsqueda
Tipos de Queries
Ahora bien basándonos en esta última API, vamos a dar un par de ejemplos de como se hacen diferentes tipos de queries:
Full Text Queries
Este tipo de query es analizada por Elasticsearch para proveernos de un resultado.
GET /<indice>/_search
{
"query": {
"match": {
"<campo>": "<Texto de búsqueda>"
}
}
}
Term Queries
Son aquellas en las que la query no es analizada si no evaluada tal cual se envia.
GET /<indice>/_search
{
"query": {
"term": {
"<campo>": "<Texto de búsqueda>"
}
}
}
GET /<indice>/_search
{
"query": {
"wildcard": {
"<campo>": "<Texto de búsqueda>"
}
}
}
Podemos utilizar el asterisco para no poner el termino exacto a buscar, por ejemplo en el texto de búsqueda podríamos poner "*ERROR".
GET /<indice>/_search
{
"query": {
"fuzzy": {
"<campo>": "<Texto de búsqueda>"
}
}
}
Nos permite búsquedas por aproximación, ejemplo si buscáramos JAVA_ERROR pero tipeamos mal y ponemos JOVA_ERROR igualmente nos encontrará los resultados.
Boolean Queries
GET /<indice>/_search
{
"query": {
"bool": {
"<must/must_not/should>": [
{"term": {"type": "LOGIN"}}, ---> es una query de ejemplo
{"match": {"responseText": "bloqueado}} ---> es una query de ejemplo
]
}
}
}
Nos permite concatenar 1 a n queries al realizar una búsqueda.
GET /<indice>/_search
{
"query": {
"bool": {
"filter": [
{}
]
}
}
}
A diferencia del caso anterior en los filtros no se analiza relevancia de los resultados, por lo que la búsqueda es más rápida. Pero en el caso de que necesitemos esa relevancia por ejemplo si tenemos un buscador y el cliente hace una búsqueda, los algoritmos de ordenamiento de elasticsearch son muy útiles, así que todo depende de que necesitemos.
GeoDistance Queries
GET /<indice>/_search
{
"query": {
"geo_distance": {
"distance": "<distancia|m|km>",
"geoip.location": {
"lat": <latitud>,
"lon": <longitud>
}
}
}
}
Nos permite buscar resultados cercanos a un punto con latitud y longitud.
Para seguir investigando te dejo la documentación sobre las queries existentes en Elasticsearch, esto fue solo una introducción a los tipos de queries mas utilizados.
Documentación: Documentación Query DSL
Sin más que agregar aquí finaliza este artículo, nos vemos en el próximo.