Elasticsearch读请求为何不优先查memtable实现实时查询？

你提到的memtable，对应Elasticsearch写入链路里的Indexing Buffer，也就是文档写入后、还没生成新segment前暂存的内存区域。之所以不直接读这部分数据跳过refresh，本质是架构设计上的合理取舍，核心原因有几个：

• 内存缓冲里的数据没有完成索引构建，根本无法支撑高效搜索
  Elasticsearch的搜索能力完全依赖提前构建好的倒排索引、正排索引、Doc Values等结构：写入缓冲里的文档只是原始写入内容，还没做分词、倒排拉链合并、列存结构生成这些索引化操作。如果要直接查这部分数据，等于每次查询都要对缓冲区内所有未刷入segment的文档临时做全量索引构建，写入压力大时缓冲内可能堆积数十万甚至上百万条文档，单次查询的处理延迟会直接飙到秒级以上，完全违背搜索引擎低延迟查询的设计目标。
• 直接读内存缓冲无法保证查询结果的一致性和正确性
  内存缓冲是持续写入的可变结构，没有做快照隔离：查询执行过程中不断有新文档写入、旧文档更新/删除，根本无法划定本次查询的结果边界，很容易读到半写入的脏数据。同时这部分数据还没和事务日志、删除墓碑标记做对齐，会出现查到已删除文档、读到旧版本文档的问题。而refresh操作的核心价值之一，就是把一段时间的写入批量生成只读的、数据一致的segment快照，从机制上避免了这些一致性问题。
• 给memtable加查询能力会彻底拖垮写入性能
  Indexing Buffer的设计目标就是攒批提升写入效率：批量构建索引的效率比单条文档实时建索引高1~2个数量级，这也是Elasticsearch能支撑高写入吞吐的核心设计之一。如果要让缓冲同时支持查询，就需要额外加复杂的并发锁、版本校验、临时索引结构，写入时要考虑不阻塞读、读的时候要处理动态写入的内容，并发控制的开销会直接把写入性能打垮，完全得不偿失。
• 实际上你说的“优先读内存再读磁盘”的逻辑Elasticsearch已经在用了，只是读的不是未构建索引的memtable：refresh生成的新segment最初是驻留在操作系统文件系统缓存里的，不需要读物理磁盘，查询这部分数据的速度和读内存几乎没有差别，这也是为什么默认1秒refresh周期下，Elasticsearch的查询延迟依然能稳定在毫秒级。

补充说明：如果确实需要写入后立刻能查到，也可以手动调用_refresh接口强制刷开segment，但这会显著牺牲写入吞吐，生产环境非特殊场景不建议频繁调用。

内容的提问来源于stack exchange，提问作者Jacky Wang