通过使用indexAPI ,文档可以被索引 —— 存储和使文档可被搜索。 但是首先,我们要确定文档的位置。正如我们刚刚讨论的,一个文档的_index、_type和_id唯一标识一个文档。 我们可以提供自定义的_id值,或者让indexAPI 自动生成。

使用自定义的 IDedit

如果你的文档有一个自然的标识符 (例如,一个user_account字段或其他标识文档的值),你应该使用如下方式的indexAPI 并提供你自己_id:
PUT /{index}/{type}/{id} { "field": "value", ... }
举个例子,如果我们的索引称为website,类型称为blog,并且选择123作为 ID ,那么索引请求应该是下面这样:
PUT /website/blog/123 { "title": "My first blog entry", "text": "Just trying this out...", "date": "2014/01/01" }
Elasticsearch 响应体如下所示:
该响应表明文档已经成功创建,该索引包括_index、_type和_id元数据, 以及一个新元素:_version。
在Elasticsearch 中每个文档都有一个版本号。当每次对文档进行修改时(包括删除),_version的值会递增。 在处理冲突 中,我们讨论了怎样使用_version号码确保你的应用程序中的一部分修改不会覆盖另一部分所做的修改。

Autogenerating IDsedit

如果你的数据没有自然的 ID, Elasticsearch 可以帮我们自动生成 ID 。 请求的结构调整为: 不再使用PUT谓词(“使用这个 URL 存储这个文档”), 而是使用POST谓词(“存储文档在这个 URL 命名空间下”)。
现在该 URL 只需包含_index和_type:
POST /website/blog/ { "title": "My second blog entry", "text": "Still trying this out...", "date": "2014/01/01" }
除了_id是Elasticsearch 自动生成的,响应的其他部分和前面的类似:
自动生成的 ID 是URL-safe、 基于 Base64 编码且长度为20个字符的 GUID 字符串。 这些 GUID 字符串由可修改的 FlakeID 模式生成,这种模式允许多个节点并行生成唯一 ID ,且互相之间的冲突概率几乎为零。