社区版最新V4.2.2_CE，商业版最新V4.3.0 Beta，
1.社区版V4.2对AP的支持能力怎么样(最近可能升级到4.2)
2.行存和列存一体化 ，是定长部分(列存储)变长部分(行存储)混存，还是行和列各存一份数据
链接里面说到HTAP两种方案，OB用的应该第一种，目前轻量AP应该没问题吧。
今天，业内都在谈论 HTAP，众所周知 OLTP 需要行存，OLAP 需要用列存，如何设计一套一体化的存储引擎能够把行存和列存完全融合到一套系统里面，有两种比较经典的设计思路。
第一种设计思路，OceanBase 是一个 Shared-Nothing 的多副本架构，每个副本仍然采用相同的存储格式，都采用行存或者都采用行列混合式存储，所有的 OLAP 和 OLTP 的请求都直接由主副本提供服务，这种方式的好处很明显，它没有任何一致性的问题，也没有任何数据延时的问题，但是它的问题在于因为没有支持列存，所以 OLAP 能力相对来讲差一些，比较适合 OLTP+非常轻量的 OLAP 的场景，比如跑批，或者 OLTP 场景里面的复杂查询。
第二种设计思路，OceanBase 的多个副本可以采用不同的存储格式，主副本支持行存支持OLTP，某一个备副本用列存来支持 OLAP。这种方式的好处在于通过引入列存大幅度提升了 OLAP 的处理能力。但是，问题在于主副本与备副本之间会额外引入毫秒级的延迟，有短暂时间的数据不一致，比较适合简单的 OLTP 的场景加上中等的 OLAP 的场景。当然，今天讲的 HTAP 无法解决百分之百的 OLTP+OLAP 融合到一套系统里面的问题。
应该说两种都有， ob 4.3 版本用户建表可以指定设置, 基线数据可以有行存, 列存, 行存列存冗余三种模式.
OceanBase 数据库从诞生起就一直坚持 LSM-Tree 架构，不断打磨功能支持了各类典型的 TP 类型业务，持续优化性能满足各种极限负载压力，积累了大量的工程实践经验，打造出一套纯自主研发且具备充分特色的业界领先 LSM-tree 存储引擎。在 V4.3.0 版本，基于原有技术的积累，OceanBase 数据库的存储引擎继续扩展，实现了对列存的支持，实现存储一体化，一套代码一个架构一个 OBServer，列存数据和行存数据完美共存，真正实现了对 TP 类和 AP 类查询的性能的兼顾。
收到，感谢！