If you have been reading my previous posts of ELK stack, you should now be comfortable on
- How to setup Elasaticsearch Node.
- What options do we have to ingest data into Elasticsearch database.
- Elasticsearch uses an entity called “INDEX” to store data.
- Every message that’s gets stored is a “Document” at Elasticsearch.
- And even we know that using Kibana it is possible to view those data back for analysis.
In this post, I am going to cover the native Query language that Elasticsearch use to search data. It is DSL (Domain Specific Language).
REST API:
9200/tcp is one of the network communication socket that Elasticsearch use. And when running, Elasticsearch expose its REST API on this port for external communication and that is what we can connect with to perform these DSL queries. This API is build on top of HTTP protocol, so its aware any http calls, for example, GET, POST, PUT..
If you are wondering on which client that will support executing these queries, well, there are 3rd party applications, such as “Postman”. However, since we already have Kibana Installed, let’s check that on how to access the REST API.
- Since Kibana is aware the Elasticsearch node url, it is not required to mention in the query itself, like if you are working on 3rd party tool.
match_all Query:
If we don’t know what to search, but we need to see every document inside of a INDEX, this query comes handy.
GET 192.168.0.1:9200/index_name/_search
{
"size": 1,
"query": {
"match_all": {}
}
}
- index_name => on which index that perform the query
- _search => one of the API endpoint that elasticsearch exposes. _search of course is what provide the search facility.
- {} => everything inside of the curly braces will be HTTP body
- size => number of matched document that need to filter out.
- match_all => this is a catch all statement where anything inside the “index_name” INDEX we would be able to see.
exists Query:
We know that Elasticsearch is a Json store, so if we know the exact FieldName that the document we are searching upon, this query comes handy.
GET 192.168.0.1:9200/index_name/_search
{
"query": {
"exists": {
"field": "firstName"
}
}
}
- field => We are searching any document inside the “index_name” INDEX, but each document should have a filed named called “firstName”
term Query:
This query is best when If we know the exact field name and we also want to limit the search result only on documents that have filed value of exactly what we are searching.
GET 192.168.0.1:9200/index_name/_search
{
"query": {
"term": {
"userName": "john"
}
}
}
Note that this query should be perform on Fields within a document that has single term, not on Fields that has many terms inside of it, for example;
“userName”: “don john mcalister”
match Query:
If “term” query is not best for search multiple terms, then which query is best of doing the task. This is where match query comes into play which does full-text search at it’s best.
GET 192.168.0.1:9200/index_name/_search
{
"query": {
"match": {
"userCommnet": "Sri Lanka beautiful country"
}
}
}
Note that even in the actual document’s “userComment“: contains “Sri Lanka is one of the best beautiful countries in the world” the above query get you that document out of the result search result.
query_string Query:
If you are looking at AND/OR operators to match document, this would do it for you.
GET 192.168.0.1:9200/index_name/_search
{
"query": {
"query_string": {
"query": "city:(new york) OR (new-york)"
}
}
}
Note that “city” is the field name & rest will be the search text that we are looking..
For basic operations, these type of queries are best for getting task done, but like any other database query, DSL also has many powerful options that leverage to narrow down the search result as to the best of requirement. Once you get these basics covered, you can comment on more for such advanced queries.
“I hope this has been informative for you.”
