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

Question

我们有一个3节点的ElasticSearch集群(每个节点硬盘: 50TB，内存: 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

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

提前感谢

Answer 1

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

完美的索引大小取决于主分片数量和大小。索引大小和主分片计数是最佳选择。如何找到它？测试！

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

因此，如果您的集群由三个节点和每个索引三个分片组成(因为您可能希望跨节点分配写操作)，那么您的“完美”索引可能在30-120 30左右。如果您需要更快的写入速度，可以添加更多的主分片-但每个分片不要低于10 go。在这种大小下，分片管理和lucene开销的成本大于额外分片的收益。

我只想说：

为了防止在JVM中出现64位指针，您不应该创建堆大于32 to的实例，并为lucene.

• Prevent慢速(网络连接)存储留出额外的32 to空闲空间。(
• )本地存储是王后，固态硬盘(或更快)是王道。但是，使用连接的快速光纤通道，固态硬盘/NVME支持的SAN应该可以像我们一样工作。

在您的案例中，估计填充“完美”大小和分片的索引需要多长时间。然后在此间隔内旋转。监控并根据需要增加/减少主分片数量。

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

干杯!