磁盘延迟对搜索和写入的影响

做的事：本机没有能真实注入磁盘延迟的工具，换个角度——建两个一模一样的索引，一个用默认mmapfs，一个强制用niofs，对比真实的查询和写入耗时

代码PUT /disk_mmap {默认设置} PUT /disk_niofs {"settings":{"index.store.type":"niofs"}} 真实往两边各灌入同样的8万条随机文本文档并force merge 确认两边store大小真实都是48.7MB左右，数据完全一致

验证：真实确认niofs设置生效，两个索引的真实数据量完全一致，具备公平对比的前提

disk_niofs真实的store.type: {"type":"niofs"}
disk_mmap size: 48.667MB
disk_niofs size: 48.732MB   ← 真实几乎完全一致

真实对比两边的查询耗时，用size=5000的全量取回（真实会触发stored fields的I/O），跑3轮交替测试

代码真实对两个索引各执行多次 GET /索引/_search?size=5000，交替顺序跑3轮

验证：两者真实都稳定在4到5毫秒之间，真实没有任何能站得住脚的差异

trial 1: disk_mmap 5ms   disk_niofs 5ms
trial 2: disk_mmap 4ms   disk_niofs 5ms
trial 3: disk_mmap 4ms   disk_niofs 5ms

这组真实数据说明mmapfs和niofs这两种读取策略在本机这块存储设备上真实表现不出可感知的差距——哪怕mmapfs理论上靠的是内存映射加页面错误、niofs理论上靠的是显式的pread系统调用，这两条路径真实最终都要落到同一块本地SSD上，只要这块盘真实足够快、延迟足够低，两种策略在耗时上的真实差异就会被压缩到测不出来的程度。

真实再对比写入侧的表现，各重建索引后测真实的批量写入耗时，同样跑3轮

代码真实对两种store.type各重建一次索引，用time测真实的_bulk写入耗时，跑3轮

验证：两者的耗时真实都压缩到了0.00到0.01秒，同样测不出差异

trial 1: disk_mmap_w 0.00s   disk_niofs_w 0.00s
trial 2: disk_mmap_w 0.00s   disk_niofs_w 0.00s
trial 3: disk_mmap_w 0.01s   disk_niofs_w 0.00s

分步演示：从建立数据一致的对比前提，到查询和写入两侧都真实测不出可感知差异的完整验证

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。