Hello everybody,

For few days I've got assigned to work with Elastic search. As faithful to my principles before doing any activity I'd like to familiarize myself with instrument that I had to use. In ordre to use it more effectively.

So, first of all I want to mention terminology. As a lot of developers I have expereince of working with databases, so I will use analogies from relational db world.

First of all Kibana has indexes. It has nothing in common with indexes in relational db. Index in terms of relational db would be named database. 

So each Kibana has one or more indexes ( databases ).

Each index has one or more types. Types in terms of relational db would be named table.

In any relational database tables need to be somehow described. Description in database is named with word schema. In Elastic search schema is named mapping.

Take a look at this quick drawing:

For working with Elastic search you can use plenty of tools. One of the tools that I'll describe here is Kibana. If to put simply Kiban is like SQL Server Management Studio for MS SQL.

At this picture you can see some comments about what each element stands for.

Now I want to describe some commands.

GET /_all/_mapping - allows to see which types ( aka tables in SQL terms ) are created in db

GET /_all/_mapping/dashboard - allows you to see maping ( aka schema definition ) of some particular type

GEt _cat/indices - allows you to see indexes of your elastic search ( aka all databases )

POSt x/y

{

       "key 1" : "value 1",

       "key 2" : "value 2",

       "key 3" : "value 3"

}

Create type instance y ( remember type stands for table ) at index ( remember index = database ) x according to fields "key 1", "key 2", "key 3".

GET x/y/_search - search for type y in index x.

GET x/y/id - get type instance by id

DELETE x - deletes index x ( you should be careful with this command. You can delete entire db with it )

Data types

Elastic search has following data types:

• String
• Number
• Boolean
• Date
• Binary

I propose following analogy:

string = varchar. If you don't know how to store something in elastic search, then choose string. 

Number can ve of following types: fload, double, byte ( 8 bit), short ( 16 bit ), integer (32 bit), long. Pretty similar to C#.

Date by default is stored in UTC format. Also elastic search allows you to have different formats. 

Binary can represent some stream. It can be image, stream etc. It is stored in Elastic Search as base64 strings and by default they are not indexed.

Storing configuration

Sometime you can have desire not to index all data in Elastic search. Consider following configuarion:

{

      "mappings":{

         "someType" : { 

             "_source" : {

                  "enabled":false

              },

           "properties": {

                "column1" : {

                         "type":  "integer",

                          "store": "true"

                 },

                "column2" : {

                         "type":  "string"

                 },

                "column3" : {

                         "type":  "date",

                           "format" : "YYYY-MM-DD"

                 },

           }

   }

  }

}

In presented case column1 will be stored and indexed in elastic search, but column2 and column3 will be indexed only. Also it means that you'll be able to search those fields but not to retrieve them from Elastic Search.

Consider another code:

{

      "mappings":{

         "someType" : { 

             "_all" : {

                  "enabled":false

              },

           "properties": {

                "column1" : {

                         "type":  "integer",

                          "store": "true"

                 },

                "column2" : {

                         "type":  "string"

                 },

                "column3" : {

                         "type":  "date",

                           "format" : "YYYY-MM-DD"

                 },

           }

   }

  }

}

by default Elastic search will have internal field _all that will be chaining of all data in type. In our case column1.ToString() + column2.ToString() + column3.ToString(). I suppose you agree that this option is good to have if you don't know exactly on which field you search on.