本文讨论了单节点复现脚本与命令记录，基于Lucene和Elasticsearch的官方文档与源码。建议在Linux或WSL2环境中运行Elasticsearch 8.x或Lucene示例工程，并提供了具体的实验步骤和版本号，以确保实验结果的准确性。

本文探讨了全文检索引擎的架构，重点分析了Lucene和Elasticsearch的设计与实现，包括倒排索引、文档模型、分析链、BM25打分机制和近实时刷新等关键概念，适合搜索引擎工程师和研究生深入理解搜索系统的内部运作。

本文是「全文检索引擎」系列的第一篇，探讨了倒排索引的架构与实现，分析了Lucene与Elasticsearch的关系，阐述了文本如何处理成可搜索的词项，以及查询在倒排列表中的执行方式。文章还区分了不同类型的搜索引擎，强调了全文检索引擎在文本与查询处理中的复杂性和重要性。

本文讨论了Lucene中的近实时搜索（NRT）机制，重点介绍了IndexWriter的文档缓冲、flush和Segment管理。文档通过addDocument进入RAM缓冲，flush后生成不可变Segment，查询时可通过DirectoryReader.open(IndexWriter)访问已flush的文档。NRT允许在未commit的情况下进行搜索，并强调flush与refresh的区别，以及Elasticsearch在此基础上的实现。

本文讨论了Elasticsearch中的性能问题及解决方案，包括写入拒绝、搜索慢、内存高和结果不全等症状，分析了可能的原因并提供了决策树以帮助排查。强调了电路断路器和刷新频率对性能的影响，建议通过合理配置和监控来优化集群性能。

本文探讨了Elasticsearch和Lucene中DocValues的使用，强调其在排序和聚合中的重要性。DocValues以列式存储优化字段访问，适合高效的排序和聚合操作，而stored字段则用于获取原文。使用DocValues可以提高查询性能，避免对分析文本字段进行聚合的误区，并讨论了设计时的注意事项和未来的开放问题。

本文讨论了Elasticsearch 8.x的查询机制，重点介绍了协调节点在查询过程中的角色，包括查询的分发、归并和获取阶段。查询分为局部查询和全局排序与聚合两个阶段。可选的DFS模式提供全局统计以提高BM25评分的准确性，但会增加延迟。此外，文章还探讨了查询优化和深度分页策略。

本文讨论了在Elasticsearch和Lucene中结合稀疏BM25与稠密kNN进行混合检索的策略，重点分析了两种索引的共存、查询策略及其对性能的影响。混合检索需同时利用BM25和kNN信号，以确保候选文档的一致性和可比性。文章还探讨了写入路径、代价模型及与专用向量引擎的边界问题，强调了统一Segment生命周期的重要性。

本文总结了全文检索引擎的选型决策，强调在不同场景下的最佳实践。针对企业知识库、订单库和日志分析，提供了决策树和场景分析，建议根据数据量、事务需求和查询模型选择合适的引擎，如Elasticsearch、PostgreSQL GIN或ClickHouse。选型应基于具体问题，而非产品热词。

本文讨论了BM25算法在全文检索中的应用，分析了其公式、参数及与TF-IDF的区别。BM25通过饱和TF和长度归一解决了传统TF在长文档中的失效问题，并提及了Lucene和Elasticsearch的实现细节，强调了BM25在召回和可解释性方面的重要性。此外，文章探讨了BM25与学习排序的关系及其在实际应用中的工程边界。

本文探讨了Elasticsearch中的近实时搜索（NRT）、刷新（refresh）、持久化（flush）和事务日志（translog）之间的关系。刷新使新写入的数据可搜索，持久化确保数据安全存储，事务日志用于崩溃后的恢复。实验验证了不同刷新设置对搜索可见性的影响，强调了三者的独立性和调参的重要性。

本文探讨了Elasticsearch、OpenSearch和Solr三种全文检索引擎的核心差异，重点在许可、社区和部署形态。Elasticsearch与OpenSearch共享Lucene内核，但在许可和插件生态上有所不同。Solr作为独立搜索服务器，主要服务于政企和Hadoop生态。选择发行版时应考虑许可和运维团队的需求，而非仅比较性能。

本文讨论了Elasticsearch中动态映射导致的字段爆炸问题及其对聚合性能的影响。动态映射在遇到新键时会创建新字段，可能导致索引无法打开。建议使用有界模式（如dynamic: false）以避免字段数量过多，从而影响集群状态和性能。聚合操作主要依赖DocValues而非倒排索引，以确保高效的数据处理。

本文探讨了Elasticsearch 8.x中的索引、主分片、副本及其与Lucene的关系，强调了分片数对集群状态更新的影响，主分片和副本的读写机制，以及通过哈希路由优化数据分布的重要性，最后讨论了分片规划的重要性，以避免过多分片导致的性能问题。

本文探讨了Lucene 9.x/10.x中的索引结构，重点介绍了Document、Field、docID及其在倒排和正排索引中的作用。Lucene通过独立的开关管理字段的索引、存储和DocValues，支持多种查询方式。同时分析了Elasticsearch与Lucene的映射关系，以及文档的业务主键和排序聚合的处理方法。

在将Elasticsearch集群迁移到无服务器时，发现密集向量在文档源中未显示。Elasticsearch为了节省存储，故意省略向量字段。要显示向量字段，需要在搜索API中添加参数：`{ "_source": { "exclude_vectors": false } }`。