ElasticSearch 6.x/7.x - 索引设计

Question

我们确实有一个 3 节点的 ElasticSearch 集群
(每个节点 HDD:50TB，RAM:128 GB，核心:22)，每天插入 500.000.000 个文档。

集群存在太多打开的索引、堆大小等问题。
每个节点的分片太多。

由于不应再使用 ES v6 文档类型，因此您应该为每个类型使用单独的索引。
所以我从每日索引更改为 9 个不同的子索引，每天内容大小非常不同:

例如

biggest sub-Index per day: 156.9m

medium sub-index per day: 17.6m

smallest sub-index per day: 2k

拆分成许多子索引是明智的/最佳实践还是会产生很大的堆影响？

提前致谢

Answer 1

在我们的日志记录/监控场景中，我们每天摄取约 30TB。这是我在过去几年中学到的:不是文档数量很重要，分片大小是基本的!

完美的索引大小取决于主分片的数量和大小。索引大小和主分片计数有一个最佳点。如何找到它？测试!

设置没有副本的单个分片索引。尽可能快地填充它(使用真实文档)并监控写入/索引性能。根据您的 SLA 并行搜索。索引和搜索时间应该随着数据量的增加而线性增长，直到延迟突然呈指数增长。这是您的机器/设置的最大分片大小。
如果您不想测试，根据经验，每个分片的目标是 10-40gb。

因此，如果您的集群由三个节点和每个索引三个分片组成(因为您可能希望将写入分布在节点上)，那么您的“完美”索引可能在 30-120gb 左右。如果您需要更快的写入速度，请添加更多主分片 - 但每个分片不要低于 10gb。在这种规模下，分片管理和 lucene 开销的成本要大于额外分片的好处。

只想说:

为了防止 JVM 中出现 64 位指针，您永远不应创建堆大于 32gb 的实例，并为 lucene 留出额外的 32gb。

防止慢速(网络连接)存储。本地存储为王，SSD(或更快)为王。但是使用连接的快速光纤 channel ，SSD/NVME 支持的 SAN 应该可以像我们一样工作。

在您的情况下，估计填充“完美”大小和分片索引需要多长时间。然后在这个区间内旋转。如果需要，监视并增加/减少主分片数。

为了提高写入性能，还有很多很多其他选项，但这将是一个非常好的起点。

干杯!