Elasticsearch 要变成列式数据库了，这次是真的
Elasticsearch 马上要多一个"索引模式"，叫Columnar Mode（列式模式）。数据只存一份，按列组织，不该建的索引不建。9.5 技术预览，9.6 GA。https://www.elastic.co/search-labs/blog/elasticsearch-columnar-storage
这不是又一次"底层重构画大饼"。这次改的是很多人日常最头疼的两件事：存储成本和分析类查询的速度。先搞清楚，为什么要折腾这个
用过 Elasticsearch/Easysearch 做日志和可观测性的都知道一个矛盾：文档模式（doc 模式）天生是为搜索优化的，一份数据要建正排、倒排、doc values，还经常有字段级的多份拷贝（比如 keyword + text）。但日志、指标、安全事件这类数据，写进去以后基本不会改（append-only），查询大部分是"按列聚合、按时间过滤"，根本用不上全文检索的那一套。结果就是：为了搜索场景设计的存储结构，硬套在分析场景上，存储翻倍，索引白建，钱花了，性能还上不去。Columnar Mode 就是来解决这个"没苦硬吃"的问题的。Columnar Mode 到底改了什么
不是新起一个产品，也不是要淘汰文档模式，而是在现有的 Elasticsearch 上，多给你一个"索引模式"的选项。你可以按索引维度选，这个索引是文档模式还是列式模式，两者并存，互不打架。适合上 Columnar Mode 的场景，官方给的是这五类，其实也是大部分做可观测性和安全的团队天天在碰的：反过来，如果你的场景是搜索优先、有大量事务型更新、文档结构又复杂，那文档模式依然是默认选项，没必要跟风换。判断标准也很直接：数据是不是 append-mostly（基本只增不改）、查询是不是分析型、访问是不是按列——三条占得越多，Columnar Mode 越适合。什么变了，什么没变
成本明显下降。
2. 读写更快。
3. 模型更简单。
4. 迁移没有悬崖。
文档模式没有被放弃，还在持续投入，不是"过渡方案"。
老的索引模式只会更快，不会变慢，doc values 的优化是共享的。
API 不变。这只是一个索引级别的设置项，不是分叉出一个新产品。
搜索和向量检索的能力还在，不存在"换了列式就不能搜索"这回事。
这个设计思路其实挺聪明的：不是让用户在"搜索"和"分析"之间二选一，而是同一个平台，同一份数据，按场景选存储方式。老杨的一点看法
做 Elasticsearch 这几年，被问得最多的问题之一就是："日志这么大的量，索引能不能少建点，能不能再省点钱？"以前的答案是：靠 mapping 优化、靠字段裁剪、靠冷热分层，一点一点抠。Columnar Mode 相当于官方把这条路正式铺开了——不是让你去抠字段，而是从索引模式上就给你一个更贴近分析场景的默认选项。对国内做 Easysearch/Elasticsearch 运维的同学，这个方向值得关注，尤其是日志规模已经到 TB/天级别、又同时要做安全溯源和 AIOps 分析的场景。等 GA 版本落地，我会找个真实的日志集群实测一下存储和查询延迟的变化，到时候单独写一篇实测数据出来。时间线
9.5：Tech Preview（技术预览）
9.6：GA（正式发布）
