Elasticsearch文本查询为何速度极快？多节点并行查询说法是否正确？

你学习过程中接触到的「ES查询快是因为索引拆分到多节点并行查询」的说法只说对了一小部分，你假设的3节点各存1条数据就让GET请求速度提升3倍的结论完全不成立。
你提到的测试场景里book索引只有3条文档：

{"name": "Pinocchio"}
{"name": "Frozen"}
{"name": "Diary of A Wimpy Kid"}

针对这个场景的问题，我们拆成几个点说清楚：

• 单文档GET请求根本不会触发全节点并行查询。ES写入数据时会根据路由规则（默认是文档ID哈希值）把每条文档固定存在某一个主分片上，协调节点收到GET请求的瞬间就能算出目标文档所在的节点和分片，直接转发请求到对应节点拉取结果即可，剩下两个节点全程不会参与这次查询，根本没有并行计算的空间，自然不可能有3倍提速。
• 你认知里的多节点并行执行，只会在全索引范围的搜索、聚合场景触发，比如你要匹配所有name字段带"o"的文档，这时候协调节点才会把请求下发到所有分片，各分片在本地完成查询后，把结果返回给协调节点做汇总、排序、分页，最终返回给客户端。但就算是这种场景，也绝对做不到3个节点就提速3倍：
  • 查询全流程不只有分片本地执行这一步，节点间网络通信、协调节点结果归并都有额外开销，分片越多这部分开销占比越高
  • 这个测试场景总共只有3条数据，单节点遍历完所有数据的耗时可能连1毫秒都不到，多节点查询的网络转发开销比实际查数据的耗时高好几倍，实际跑起来只会比单节点查询更慢
  • ES每个分片本身有固定的元数据、进程调度开销，为了3条数据拆3个分片，光分片本身的资源消耗都比存这3条文档大，属于典型的负优化
• 别把分片并行当成ES查询快的核心原因，它的速度优势核心根本不来自分布式架构：底层Lucene构建的倒排索引能让关键词查询直接定位到对应文档，不需要全表扫描；再加上doc values列式存储支撑快速聚合、filter查询缓存、段机制的读写优化，这些才是查询速度快的核心，分片并行只是数据量涨到单节点存不下、扛不住之后，用来水平扩展处理能力的手段而已。

分布式系统从来不存在「节点数翻N倍性能就翻N倍」的线性缩放规律，实际性能永远受网络开销、协调成本、数据倾斜、硬件瓶颈限制，数据量没到单节点瓶颈的时候，盲目加节点拆分片只会让查询性能更差。

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