Apache Lucene 10 已发布！Lucene 硬件效率改进及其他改进

作者：来自 Elastic Adrien Grand

Apache Lucene 10 刚刚发布，重点关注硬件效率！查看主要版本亮点。

Apache Lucene 10 终于发布了！自 Lucene 9.0（于 2021 年 12 月发布，距今已有近 3 年）以来，已有 185 位独立贡献者提交了 2,000 多次提交，发生了很多事情。公平地说，这些更改中的大多数都是在 9.x 次要版本中提供的。但是，最雄心勃勃的更改通常需要一个主要版本，例如在 Lucene 6.0 中引入多维点（multi-dimensional points）、在 8.0 中引入动态修剪（dynamic pruning ）或在 9.0 中引入向量搜索（vector search ）。在 10.0 中，Lucene 的重点领域一直是硬件效率，即让 Lucene 更好地利用现代硬件。让我带你了解主要的版本亮点：

更好的 I/O 并行性

到目前为止，Lucene 将使用同步 I/O，并且每个搜索线程一次最多执行一个 I/O 操作。对于大大超过页面缓存大小的索引，这可能导致查询受限于 I/O 延迟，而主机仍远未达到 IOPS 的最大值。令人沮丧！

为了解决这个问题，Lucene 的 Directory 抽象引入了一个新的 IndexInput#prefetch API，让操作系统知道它即将读取的文件区域。然后，操作系统可以在单个 OS 线程内并行检索与这些区域相交的页面。例如，带有 TermQuery 子句的 BooleanQuery 现在将在单个执行线程内并行执行术语字典查找的 I/O，然后并行检索每个帖子列表的前几页。MMapDirectory 是 Lucene 的默认 Directory 实现，它使用 Linux 和 Mac OS 上的 madvise 的 MADV_WILLNEED 建议实现此 prefetch API。

我们对这一变化感到非常兴奋，它已经被证明有助于快速本地 NVMe 磁盘，并且将进一步帮助具有更差延迟同时保持良好并行性的存储系统，例如网络附加磁盘（GCP 持久存储、Amazon EBS、Azure 托管磁盘）甚至对象存储（GCP 云存储、Amazon S3、Azure blob 存储）。

通过稀疏索引提高 CPU 效率和存储效率

Lucene 10 引入了对稀疏索引的支持，在其他数据存储中有时称为主键索引（primary-key indexing）或区域索引（zone indexing）。这个想法很简单：如果你的数据按排序顺序存储在磁盘上，那么你可以将其组织成块，记录每个块的最小值和最大值，你的查询将能够利用这些信息跳过与查询不相交的块，或完全匹配查询包含的块。只有与查询部分相交的块才需要进一步检查，挑战在于选择最佳索引排序以最小化此类块的数量。

Lucene 的稀疏索引目前通过 4 个级别的块实现，每个级别分别具有 4k、32k、256k 和 2M 文档。

如果做得正确，这种索引形式非常节省空间（每个块只有几个字节）和 CPU 效率（只需几个 CPU 指令就可以决定数千个文档是否匹配）。缺点是索引只能以单一顺序存储在磁盘上，因此并非所有字段都能从中受益。通常，索引会根据数据的主要维度进行排序。例如，对于包含产品的电子商务目录，这些维度可能是产品的类别和品牌。