在Elastic Search中使用长度为100个字符的字符串作为_Id列的性能影响

Question

我打算将事件存储在弹性搜索中。它可以在任何时间点拥有大约1亿个事件。为了重复删除事件，我计划通过连接下面的字段来创建长度为100个字符的_id列 entity_id - UUID（37个字符）+ event_creation_time（30个字符）+ event_type（30个字符）

这家商店将有正常的阅读和与聚合查询一起写入（无更新/删除） 如果使用这种冗长的字符串_id列而不是默认ID，会对性能产生什么影响或任何其他副作用，请告诉我。

谢谢， 哈里什

Answer 1

默认情况下，_id字段未编入索引且未存储，因此不会出现性能问题storage。

由于您将索引数百万个文档，因此您将遇到的唯一主要性能问题是bulk indexing。您必须确保sequential pattern的{​​{1}}。来自Docs

  

  
• 如果您没有每个文档的自然ID，请使用Elasticsearch的自动ID功能。它被优化以避免   版本查找，因为自动生成的ID是唯一的。
  
• 如果您使用的是自己的ID，请尝试选择friendly to Lucene的ID。示例包括零填充顺序ID，UUID-1，   和纳米;这些ID具有一致的顺序模式   压缩好。相反，诸如UUID-4之类的ID本质上是   随机，压缩性差，Lucene减速。
  

在那篇博客中，很长一段时间Lucene的提交者Michael McCandless比较了_id代的不同方式和IMO，这是我读过的最好的文章之一。

希望这有帮助！