云原生数据库以OLTP为主，同时也支持基于OLTP数据的OLAP需求，如每日报表。在云原生数据库中，DBA可以选择为这部分表创建列存索引。创建完列存索引之后，执行器在做顺序扫描的时候，会自动选择列存索引进行数据的读取，实现快速扫描计算的能力。
云原生数据库以行存为基础，数据的增删改都先以行存的形式落到数据库中。事务、xlog等机制保障了行存的ACID特性。行存采用Inplace-update引擎，一个Tuple一旦被插入到表中，位置基本不会改变。每个Tuple可以用它的物理位置（文件页号+页内偏移，称为RowID），作为唯一标识。事务的多版本在回滚段中，可以根据RowID直接访问。
云原生数据库中的列存索引方案如下图所示：列存是根据行存构建的一个read-only的副本，每次对行存的更新操作会在元数据区域（In Memory Delta Unit，IMDU）增加一条RowID记录。列存扫描的时候会查看元数据区域，确定哪些Tuple已经失效，再去行存中根据RowID读相应的数据。后台线程会周期性地更新列存，回收元数据。如果列存索引和更新操作不在同一台机器上，使用batch模式，即把一个事务中产生的所有失效信息，统一打包到一个RPC请求中，发送给列存索引所在的实例上，从而减少对OLTP请求的影响。行存的block为8KB，列存需要较多的数据量才能实现更好的压缩、向量化操作等优化。所以一个IMCU对应多个行存的block，目前暂定为1024个，这样一个1024个block称为一个Super Block。
为了支持列存大小超过内存容量的场景，列存索引支持从内存中置换到磁盘上。但是列存本身在故障情况下并不能保证自身的一致性，故障重启之后列存需要根据行存的内容重新构建。所以这里的磁盘对于列存来说，是内存的延伸，用来缓存额外的数据。
因为DU容量小，且经常被修改，所以可以常驻内存。列存索引和行存完全是解耦开的。部署形态上，列存索引既可以与行存在一个实例中，节约物理资源；也可以与行存在不同的实例中，避免OLAP请求对OLTP请求产生影响。两种部署形态分别如下图所示：
