将文档写入磁盘时，ElasticSearch(lucene) 段是必须的吗？

Question

我想知道将文档写入磁盘时是否需要 Lucene 段。 以下是文档如何从 ElasticSearch 写入磁盘的简要过程 首先，将ElasticSearch文档写入内存缓存（参考LSM-tree memTable） 其次，一堆文档作为不可变的Lucene段刷新到页面缓存（每1s）（参考LSM-tree不可变的memTable） 最终，该段将“fsync”到磁盘上。

看来我们完全可以绕过“页面缓存”部分，也就是说，第一步，当我们想在内存缓冲区中创建一个文档时，elasticsearch 会为其创建一个段。然后，如果我们想要更新该文档，elasticSearch 会为更新后的文档创建另一个段。 现在我们总共有 2 个部分。 1 秒后，这两个段将合并并刷新在磁盘上。

你知道Lucene段的优势在这里吗？

Answer 1

页面缓存旨在通过将数据存储在物理内存中（否则需要磁盘访问）来最大程度地减少磁盘 I/O。
缓存一般支持不同的策略，不写、直写缓存和回写。页缓存是一种回写策略。页面会定期刷新到磁盘中。
这种机制加速了数据访问并减少了 I/O 数量。
Lucene写页缓存来提高系统I/O吞吐量。
当然，页面缓存会消耗更多内存，并且可能会丢失缓存中的数据。

Answer 2

听起来您的提案的行为类似于在索引 API 上设置

refresh=true

，以立即为更新插入构建分段。

不幸的是，文档还指出：

true

创建效率较低的索引构造（小段），稍后必须将其合并到更高效的索引构造（较大的段）中。这意味着

true

的成本在索引时支付以创建小段，在搜索时支付以搜索小段，并在合并时支付以生成更大的段。

根据您的用例，搜索时的成本可能是提到的三个“成本”中最重要的。 Elasticsearch 在搜索时必须读取所有段，并且当每个段仅包含一个文档时，这相当于暴力搜索。