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

Question

我打算在 Elasticsearch 中存储事件。它在任何时候都可以有大约 1 亿个事件。为了消除重复事件，我计划通过连接以下字段来创建长度为 100 个字符的 _id 列entity_id - UUID(37 个字符)+event_creation_time(30 个字符)+事件类型(30 个字符)

此存储将具有正常的读写以及聚合查询(无更新/删除)您能否告诉我使用如此长的字符串 _id 列而不是默认 ID 是否会对性能产生任何影响或任何其他副作用。

谢谢，哈里什

Answer 1

_id默认情况下，字段未编入索引且未存储，因此在存储方面不存在性能问题。

由于您要为数百万文档编制索引，因此您将面临的唯一主要性能问题是批量索引。您必须确保您的 _id 有一个顺序模式。来自Docs

• If you don’t have a natural ID for each document, use Elasticsearch’s auto-ID functionality. It is optimized to avoid version lookups, since the autogenerated ID is unique.
• If you are using your own ID, try to pick an ID that is friendly to Lucene. Examples include zero-padded sequential IDs, UUID-1, and nanotime; these IDs have consistent, sequential patterns that compress well. In contrast, IDs such as UUID-4 are essentially random, which offer poor compression and slow down Lucene.

在那篇博客中，Lucene 的长期贡献者 Michael McCandless 比较了 _id 生成和 IMO 的不同方式，这是我读过的最好的文章之一。

希望这对您有所帮助!