在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。

\n\n

由于您将对数百万个文档建立索引，因此您将面临的唯一主要性能问题是 while bulk indexing。您必须确保sequential pattern您的 s 中有一个_id。来自文档

\n\n

\n

\n
• 如果您没有每个文档的自然 ID，请使用 Elasticsearch\xe2\x80\x99s 自动 ID 功能。它经过优化以避免版本查找，因为自动生成的 ID 是唯一的。
\n
• 如果您使用自己的 ID，请尝试选择对 Lucene 友好的ID 。示例包括零填充顺序 ID、UUID-1、\n 和 nanotime；这些 ID 具有一致的连续模式，\n 可以很好地压缩。相比之下，诸如 UUID-4 之类的 ID 本质上是随机的，其压缩率很差，并且会降低 Lucene 的速度。
\n

\n

\n\n

在该博客中，Lucene 的长期提交者 Michael McCandless 比较了不同的_id生成方式，在我看来，这是我读过的最好的文章之一。

\n\n

希望这可以帮助！

\n