Elasticsearch Difference Between Indices and Types Dynamically creating an Index with a Type

Example

Example uses basic HTTP, which translate easily to cURL and other HTTP applications. They also match the Sense syntax, which will be renamed to Console in Kibana 5.0.

Note: The example inserts <#> to help draw attention to parts. Those should be removed if you copy it!

DELETE /my_index <1>

PUT /my_index/my_type/abc123 <2>
{
  "field1" : 1234, <3>
  "field2" : 456,
  "object1" : {
    "field1" : 7.8 <4>
  }
}

1. In case it already exists (because of an earlier example), delete the index.
2. Index a document into the index, my_index, with the type, my_type, and the ID abc123 (could be numeric, but it is always a string).
   • By default, dynamic index creation is enabled by simply indexing a document. This is great for development environments, but it is not necessarily good for production environments.
3. This field is an integer number, so the first time it is seen it must be mapped. Elasticsearch always assumes the widest type for any incoming type, so this would be mapped as a long rather than an integer or a short (both of which could contain 1234 and 456).
4. The same is true for this field as well. It will be mapped as a double instead of a float as you might want.

This dynamically created index and type roughly match the mapping defined in the first example. However, it's critical to understand how <3> and <4> impact the automatically defined mappings.

You could follow this by adding yet another type dynamically to the same index:

PUT /my_index/my_other_type/abc123 <1>
{
  "field1": 91, <2>
  "field3": 4.567
}

1. The type is the only difference from the above document. The ID is the same and that's okay! It has no relationship to the other abc123 other than that it happens to be in the same index.
2. field1 already exists in the index, so it must be the same type of field as defined in the other types. Submitting a value that was a string or not an integer would fail (e.g., "field1": "this is some text" or "field1": 123.0).

This would dynamically create the mappings for my_other_type within the same index, my_index.

Note: It is always faster to define mappings upfront rather than having Elasticsearch dynamically perform it at index time.

The end result of indexing both documents would be similar to the first example, but the field types would be different and therefore slightly wasteful:

GET /my_index/_mappings <1>
{
  "mappings": {
    "my_type": { <2>
      "properties": {
        "field1": {
          "type": "long"
        },
        "field2": {
          "type": "long" <3>
        },
        "object1": {
          "type": "object",
          "properties": {
            "field1" : {
              "type": "double" <4>
            }
          }
        }
      }
    }
  },
  "my_other_type": { <5>
    "properties": {
      "field1": {
        "type": "long"
      },
      "field3": {
        "type": "double"
      }
    }
  }
}

1. This uses the _mappings endpoint to get the mappings from the index that we created.
2. We dynamically created my_type in the first step of this example.
3. field2 is now a long instead of an integer because we did not define it upfront. This may prove to be wasteful in disk storage.
4. object1.field1 is now a double for the same reason as #3 with the same ramifications as #3.
   • Technically, a long can be compressed in a lot of cases. However, a double cannot be compressed due to it being a floating point number.
5. We also dynamically created my_other_type in the second step of this example. Its mapping happens to be the same because we were already using long and double.
   • Remember that field1 must match the definition from my_type (and it does).
   • field3 is unique to this type, so it has no such restriction.