先交代一个场景。
客户的库里有张表，二十多列，几百 GB。报表只要其中五列做个聚合，磁盘读得风扇狂转，结果半天不出来。DBA 抱怨的话我记到现在：我就要那五列，凭什么把整行都搬一遍？
他没说错。行式存储就是这么工作的，数据按行堆在磁盘上，哪怕查询只碰一列，引擎也得把整行捞出来再扔掉多余的部分。分析型负载里这种浪费天天在发生。列存反过来，把同一列的数据物理上挨着放，查哪列读哪列，天生就是给扫描和聚合用的。
所以这次翻 KES 的文档，我直奔列存储那页。
一、列存是个插件，装上就能用
KES 的列式存储靠 cstore_fdw 这个扩展实现，一条 CREATE EXTENSION 的事，不另收费也不另装产品。
底层格式是 ORC。这个格式不是金仓拍脑袋发明的，它在大规模数据系统里被磨了十来年，该踩的坑前人都踩完了。文档里列了三条优点，我掰开说。
第一条，只读相关列。就是上面那位 DBA 想要的。二十多列取五列，I/O 直接砍到零头。
第二条最有意思，叫跳跃索引。数据切成一个一个行组，每个行组把各列的最大值、最小值都记下来。查询带着范围过滤进来，引擎先翻行组的 min/max，对不上的整组跳过，解压这道工序都省了。我举个具体的例子：查销售额十万以上的记录，那些最大值都不到十万的行组，一个字节都不会被碰。几百 GB 的表，实际扫描的可能就一小角。
第三条是压缩。同一列的数据类型一致、取值相近，压起来比行存那种大杂烩凶得多。官方给的数字是 6 到 10 倍，ORC 格式本身在设计上就有 2 到 4 倍的空间缩减打底。
压缩算法四个档位：none、pglz、zstd、还有字典压缩。zstd 能调级别，0 到 9，默认 1。备份表可以压狠一点，查询频繁的表留些余量，选择权给用户，这个设计我认同。
图 1：行存与列存的读写差异，以及 cstore_fdw 依赖 ORC 格式获得的三个机制
二、两个默认值，暴露了设计者的取舍
建列存表有两个可调参数，我盯着看了挺久。
stripe_row_count，一个 stripe 装多少行，默认 15 万。调大，批量加载和扫描的吞吐往上走，内存开销也跟着涨。调小，省内存，性能往下掉。
block_row_count，一个列数据块装多少行，默认 1 万。压缩、建索引、读磁盘，全都以块为最小单元。块大，压缩率高，磁盘寻址少；块小，跳跃索引过滤得细，跳过无关数据的概率高。
一对跷跷板。哪个默认值都不是全赢的选择，只是设计者押了个中间态，剩下的让你按自己的场景去拧。
导入就两条路：COPY 从文件、程序、标准输入灌数据，或者 INSERT INTO 加 SELECT 从别的表搬。搬完跑一次 ANALYZE，统计信息有了，优化器才知道怎么选计划。
文档里有两段加粗的备注，我把它们当宝贝看。不支持 UPDATE 和 DELETE。不支持单条插入，也不支持字段约束。为什么？每次导入至少形成一个数据块，要是放开单条插入，一个 INSERT 造一个块，块数量一多，列存的性能基础就塌了，跳跃索引和压缩全都白搭。
也就是说，cstore 表从出生那天起就定了性——批量进，查询用，整体替换。频繁改写的业务数据别往这放。工具的脾气写在说明书里，比产品页面的花言巧语实在得多。
三、把镜头拉远：列存只是拼图一角
看完 cstore 我冒出个疑问。现在都在讲 HTAP，一张表又要扛交易又要扛分析，列存不能更新，怎么混？
答案藏在 KES 整个产品的设计里。文档管这叫多模数据一体化存储，关系、文档、时序、向量、GIS、文本，六种模型装进一个库，能混合访问，模型之间还能转。行存扛交易，列存扛分析，时序模型接物联网那种高频写入。各干各的活，但数据在一个体系里，不用为了不同负载架几套库再互相倒腾。
图 2：KES 技术架构图（来源：官方文档），数据存取引擎一层里，"列存储"与行存储、内存存储并列出现，六种数据模型在最右侧
产品资料里有句话概括得挺准，"一份数据、两类负载"。交易和分析同时撑着，中间不用 ETL 搬砖，自然也没有搬砖的延迟。金融核心系统、能源计量、计费结算这类又急又重的场合，说的是这个。
顺着这个思路看 KES 的其他几个"一体化"，就能串成一条线。
多应用场景一体化。事务、分析、时序、AI 四类场景在一个产品里，不是四个产品贴牌拼盘。AI 那块是这两年的新功课，向量数据的存储、实时更新、相似度检索都有，对着大模型检索的需求去的。
多语法体系一体化。这是国产库最要命的功课。KES 内核按 SQL 标准打底，语法层做成插件式架构，往外兼容 Oracle、MySQL、SQL Server、Sybase、DB2 的方言。兼容到什么深度？文档点了名：物化视图增量刷新、reference 分区、内存级本地临时表、批量加载的行级回滚。懂 Oracle 的都知道，这几样恰恰是老系统重度依赖、普通兼容方案最容易翻车的地方。应用代码不大改就能迁，兼容性的唯一验收标准就这一条。
集中分布一体化。集中式撑 RWC、RAC 集群，分布式在集中式上加分片管理、分布式事务、全局一致性，撑 TDC、Sharding、ADC。业务量从小涨到大，不用中途换产品。
图 3：KES 产品体系（来源：官方文档），从单实例到 RAC、RWC、Sharding、TDC、ADC 集群形态，底部由 KFS 异构数据同步软件对接外部数据源
开发运维一体化。全生命周期管理平台，安装、开发、监控、诊断都在里面。文档宣称管理零人工介入，这种话打个对折听，但 AI 辅助故障定位、SQL 优化、健康报告确实是往这个方向走的。
四、性能的功夫在内核里
语法兼容决定能不能迁，性能决定迁完之后骂不骂娘。KES 的性能优化分三层说。
存储层动过刀的地方包括事务处理、可见性判断、各级日志、缓冲区锁。外行看着平平无奇，内行知道可见性判断是多版本引擎的命门，每条查询都得过一遍，这里省下的每一纳秒都是全局收益。
算法层，聚集、连接、表达式这些执行算子重写过，各种操作能并行。
硬件层，NUMA、RDMA 做了适配。NUMA 架构下访问远端内存的代价能吃掉大量性能，肯沉到这一层做改造的国产库不算多。读写分离的负载均衡再配上，高并发业务能摊到多个副本上。
五、高可用不是口号，是一张分级表
KES 文档里有个概念叫 MAA，最大可用性架构，把容灾方案分成三级，每级对应不同的 RTO 和 RPO。
初级是单实例加自动重启，硬件靠冗余，备份恢复用 sys_rman 工具，大部分维护得停机。小系统够用，花钱也少。
中级上读写分离集群（RWC）加 Clusterware，实例和主机故障自动切换，常见维护可以滚动着做，不停机。
高级是跨可用区、跨地域的实时复制，灾难切换实时完成，数据不丢或者丢得极少。金融级玩法。
这页文档最让我有好感的地方是一张特性矩阵：哪一级用哪个组件，白纸黑字。连异构数据同步软件 FlySync 都标清楚了，中级可选、高级必配。企业拿自己的 RTO、RPO 对号入座就行，不用陪销售听故事。
图 4：MAA 三级保护架构阶梯，对应不同的组件组合与 RTO/RPO 承诺
可用性承诺写在产品简介里：满足金融行业 6 级标准，99.999%。换算一下，全年停机不许超过五分钟。数据保护那侧，永久增量备份、坏块修复、逻辑对象恢复，目标是零丢失。敢把 99.999% 印在文档里的厂商，背后多少得有真项目撑着，这话我信一半，留一半等用户反馈。
六、安全这块，认证比功能难造
功能可以宣传，认证造不了假。
KES 符合国家标准 GB/T 20273-2019 结构化保护级的要求，也就是俗称的第四级。产品资质清单里有涉密信息系统检测认证、商用密码产品认证、网络安全专用产品认证，一水儿的硬证书。
具体功能上，透明加密、数据脱敏、数据库审计、传输安全，文档里各有一章。军队、军工、政府、金融这些把安全资质卡得死的行业，看认证清单比看功能清单管用。
图 5：KES 生态适配全景（来源：官方文档），覆盖开发 IDE、中间件、备份工具、操作系统、国产 CPU 等上下游
七、收尾说两句观感
以列存为入口把 KES 的文档翻一遍，我记下两个印象。
头一个，诚实。cstore 不能更新、不能单条插入，文档直接写出来还把原因讲透；高可用分三级，每级能干什么不能干什么列成表。敢画边界的文档，说明写文档的人心里有数。
第二个，成体系。列存不是孤立卖点，往上是多模存储和混合负载的设计意图，往外是语法兼容和迁移工具的落地路径，往下是内核和硬件的基本功。单点功能谁都能堆，互相咬合的完整度才是数据库这种基础软件真正的门槛。
列存这个功能本身，我给的评价是：设计成熟，ORC 加跳跃索引加多档压缩，该有的都有；限制也明摆着，用在分析场合是利器，塞错地方就是坑。工具无所谓好坏，用对地方才是本事。
