为何Elasticsearch被设计为近实时？缓存数据查询疑问解析

• 性能与查询复杂度的平衡：Segments是提前构建好倒排索引的优化结构，查询时能高效匹配检索条件。但内存缓存里的新文档还只是原始数据，没有建立倒排索引，如果每次查询都要遍历缓存里的所有文档去匹配条件，数据量一大，查询性能会暴跌，完全扛不住高并发场景。
• 数据一致性与可靠性：内存缓存里的文档还没完成持久化，节点一旦故障重启，这些数据就会丢失。要是直接把缓存数据对外可见，就会出现“查到了数据但实际没持久化，重启后消失”的矛盾情况，违背了数据可靠存储的基本设计。而且缓存里的文档还没走完完整的写事务流程，直接对外暴露会破坏数据一致性的语义。
• 查询结果的准确性与稳定性：Segments里的文档会经过分词、索引优化等完整处理，而缓存里的新文档可能还没完成这些步骤。如果查询包含缓存数据，可能会出现分词不完整、索引未构建导致的查询结果不准确，而且缓存内容实时变化，不同时刻的查询结果会频繁波动，没法保证稳定性。
• 实时需求已有解决方案：其实ES并非完全不支持实时查询，你可以通过refresh=wait_for参数让写操作等待刷新完成后再返回，或者手动调用_refresh接口触发Segments刷新，就能让新文档立刻被查询到。默认1秒延迟是官方在实时性和性能之间做的最优平衡。

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