北京
周三下午，监控面板突然飘红。不是查询变慢，是NVMe硬盘的I/O利用率飙到95%，平均延迟从12毫秒暴涨到340毫秒。集群堆内存充足，GC日志干净，JVM毫无压力——但iostat不会撒谎：每秒4821次读取，384MB/s吞吐，await时间18.2毫秒。健康基线本该是1200次读取、96MB/s、2.1毫秒等待。这是Elasticsearch 8.9，5亿条新闻文档，我调优了数月的索引。
拆存储结构时，数字很刺眼：60GB索引里，40GB是倒排表的postings lists——记录"词项→文档ID"映射的结构。实际存储的JSON原文反而只占一小部分。默认编解码器对存储字段用LZ4压缩，但postings基本只有增量编码+VByte，比我以为的"压缩已开启"要裸奔得多。
症结在于postings lists吃光了页缓存预算。单节点64GB内存，30GB划给堆，剩约30GB给系统缓存。40GB的postings数据，任何查询碰到非热点词项就得读盘。更糟的是URL、用户ID这类高基数字段的postings访问完全不可预测——预加载没用，持续冲刷缓存。加内存换时间？很快就得为NVMe速度的RAM买单，本质是替存储布局缺陷付账。
这里有个常被混为一谈的区别：倒排索引的"自适应压缩"是编解码器根据每条postings list的统计特征——密度、间隙分布、词频方差——动态选择编码策略。这和Elasticsearch里打开BEST_COMPRESSION（把存储字段换成DEFLATE）是两回事。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
