该示例使用基本的HTTP，可轻松转换为cURL和其他HTTP应用程序。它们还与Sense语法匹配，该语法将在Kibana 5.0中重命名为Console。
注意：该示例插入<#>以帮助引起对零件的注意。如果您将其复制，则应将其删除！
DELETE /my_index <1>
PUT /my_index/my_type/abc123 <2>
{
"field1" : 1234, <3>
"field2" : 456,
"object1" : {
"field1" : 7.8 <4>
}
}如果已经存在（由于前面的示例），请删除索引。
将文档编入索引，my_index类型为my_type和ID的索引abc123（可以是数字，但始终是字符串）。
默认情况下，仅通过索引文档即可启用动态索引创建。这对开发环境非常有用，但对生产环境却不一定好。
该字段是整数，因此第一次看到它时必须对其进行映射。Elasticsearch始终假定任何传入类型的最大类型，因此它将被映射为along而不是aninteger或a short（两者都可以包含1234和456）。
该领域也是如此。它将映射为adouble而不是float您可能需要的a。
动态创建的索引和类型与第一个示例中定义的映射大致匹配。然而，它的关键，以了解<3>并<4>影响自动定义的映射。
您可以在此之后，通过动态地向同一索引添加另一种类型：
PUT /my_index/my_other_type/abc123 <1>
{
"field1": 91, <2>
"field3": 4.567
}类型是与上述文档的唯一区别。ID是一样的，没关系！它与其他对象没有任何关系，abc123只是它恰好位于同一索引中。
field1索引中已经存在该字段，因此它必须与其他类型中定义的字段类型相同。提交一个字符串或非整数值将失败（例如"field1": "this is some text"或"field1": 123.0）。
这将为my_other_type同一索引中的动态创建映射my_index。
注意：预先定义映射总是比让Elasticsearch在索引时动态执行映射更快。
为两个文档建立索引的最终结果将与第一个示例相似，但是字段类型将有所不同，因此有些浪费：
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"
}
}
}
}这使用_mappings端点从我们创建的索引中获取映射。
我们my_type在此示例的第一步中动态创建。
field2现在是along而不是an，integer因为我们没有预先定义它。这可能在磁盘存储中被证明是浪费的。
object1.field1double由于与＃3相同的原因，现在与＃3具有相同的分支。
从技术上讲，along在很多情况下都可以压缩。但是，double由于a是浮点数，因此无法对其进行压缩。
我们还在my_other_type本示例的第二步中动态创建。由于我们已经在使用long和，因此其映射恰好相同double。
请记住，它field1 必须匹配my_type（并且确实）来自的定义。
field3 此类型是唯一的，因此没有这种限制。