目前公司在使用OceanBase作为数据仓库的MPP产品落地方案。

结合业务需求对适配HTAP场景的方案进行探索分析。

行式存储将一整行数据的所有列值连续地存储在一起，可以理解为“打包存储”

特点：一次磁盘I/O就能读取或写入一整条记录的所有数据，非常适合需要频繁访问完整记录的场景。

列式存储将每一列的数据单独集中存放，可以理解为“归类存储”

存储示意：

特点：查询时只需读取涉及的列，避免了不必要的I/O。

同时，同列数据类型一致，压缩效率高。

索引与数据检索

InnoDB）通常使用B+树索引。

以在EmpId上创建主键索引为例：

建立索引：会创建一棵B+树，叶子节点直接存储或指向完整的行数据（即所有列的值）。

检索数据（执行

在EmpId的B+树索引中快速找到12所在的叶子节点。

因为叶子节点包含了整行数据，所以可以直接或通过指针一次获取Jones,

Mary,

列式存储（如Parquet格式）的检索方式不同：

“天然索引”：数据按列存储，只需扫描相关列文件，本身就减少了数据读取量。

此外，列式存储格式会在文件元数据中记录每个数据块（如Parquet的Row

检索数据（同样执行

取EmpId列，找到值为12的位置（比如是第二个值）。

于同一列的值顺序一致，Lastname列的第二个值是Jones，Firstname列的第二个值是Mary，Salary列的第二个值是50000。

数据库需要从各个列中分别提取对应位置的值，再“拼装”成完整的行返回。

SELECT

45000，数据库可以借助元数据信息（如块统计信息）直接跳过完全不满足条件的列数据块，只读取Salary列和Lastname列中相关的数据，极大提升了分析查询效率。

数据更新与删除

过EmpId索引快速定位到该行数据所在的磁盘位置。

直接在该位置将整行记录中的Salary值从50000修改为55000。

这个操作主要在单个物理位置完成。

除数据：类似地，直接定位到行记录所在位置进行标记删除或物理移除。

要先确定要更新的行位置（例如在EmpId列中找到12是第二个值）。

由于每列数据独立存储，数据库需要在Salary列文件中找到对应位置（第二个值）进行修改。

这个操作可能涉及多个列文件的调整。

删除数据：通常采用标记删除策略。

需要在各行数据对应的所有列文件中标记该位置的数据为已删除，后续通过压缩过程来物理清理

运维工作差异

行式数据库：要重点关注事务性能。

监控指标应包括每秒事务数（TPS）、事务延迟、锁等待和死锁频率。

你需要熟练使用数据库自带的事务和锁监控工具（如

PostgreSQL

列式数据库：要重点关注查询资源消耗。

监控复杂分析查询的内存使用、CPU

I/O。

由于列式查询经常扫描海量数据，一个不优化的查询可能耗尽集群资源。

你需要熟悉数据库提供的查询分析工具（如

ClickHouse

system.query_log），并引导用户使用高效查询语法。

容量规划与存储管理

行式数据库：容量增长通常与业务事务量相关，需要规划磁盘空间以满足短期（如几个月）需求，并设置合理的归档策略，避免数据无限膨胀影响

OLTP

式数据库：虽然压缩率高，但因其常用于存储海量历史数据，总数据量会非常庞大。

容量规划要有长远眼光，并考虑存储成本。

同时，要理解其存储结构，例如，增加一个列对写入性能和存储空间的影响相对较小。

备份与恢复策略

行式数据库：通常支持实时增量备份和时间点恢复，这对保障核心交易数据至关重要。

你需要制定严谨的备份恢复演练流程。

列式数据库：备份往往更侧重于周期性的全量或大粒度增量备份。

由于其数据仓库的特性，恢复时间目标（RTO）可能相对宽松，但方案仍需保证可靠性。

避免混用场景

这是新人最容易踩坑的地方：切勿将分析型查询（OLAP）直接运行在行式

OLTP

库上。

这类查询通常涉及多表关联和全表扫描，会严重拖慢甚至拖垮生产数据库的性能。

正确的做法是建立专门的列式分析数据库或数据仓库，通过

ETL

中创建一张表，让其同时拥有行存和列存两种数据格式，并由优化器智能地为不同查询选择最优的访问路径

核心技术架构：基于

SSTable）采用行式存储，确保高频写入和事务处理的低延迟；基线数据（合并后的

智能优化器：查询优化器具备代价模型，能自动判断并选择扫描行存还是列存数据路径。

例如，点查询（Point

Get）或需要全行数据的查询会走行存，而涉及全表扫描和聚合的分析型查询（AP）会优先选择列存

目前需要基于OceanBase搭建一套数据中台服务，需要对外提供100多个上游应用系统查询，查询的服务中既有高并发的TP类查询（QPS达到一万以上）、对查询耗时比较敏感，又有大量复杂的分析型AP分析查询需求，特别指出：只有非常少的数据表同时需要提供TP类查询以及AP类查询。

目前有两套方案：一是分别搭建两套OceanBase集群，一个是查询集群用于TP类查询（仅用于行式存储），一个是分析集群用以AP类查询（仅用于列式存储），将服务请求分开接入；二是将所有的资源集中搭建一套OceanBase集群，基于新的版本带来的行列混合存储架构，对不同的表按照查询需求进行定制化建表及优化。

基于上述方案和OceanBase的技术文档，评估如下：

方案二（单集群行列混存）的优势非常明显，能解决运维工作的核心痛点。

方案一的最大挑战在于保证数据一致性。

虽然只有少量表需要双写，但只要存在这种需求，就需要引入并维护数据同步组件（如CDC工具）。

这根“钉子”的存在，使得运维团队仍需投入精力确保同步链路的稳定性和数据一致性，架构复杂度和故障点依然存在。

方案二将运维团队从管理多套系统的复杂性中解放出来。

要确保这套架构稳定高效，运维工作需要聚焦于以下几点，这些工作更具价值：

精准的表结构设计：与开发团队紧密协作，根据每张表的查询模式（纯TP、纯AP、或极少数HTAP），在建表时精准选择存储格式。

例如：

纯TP表：CREATE

资源隔离配置是关键：必须充分利用OceanBase的多租户特性。

可以创建独立的租户分别服务于TP和AP业务，并设置不同的资源规则（unit_config），从而避免AP查询冲击核心交易业务。

id="单集群行列混存的论证">单集群行列混存的论证

方案二不仅简化了架构、降低了成本，更重要的是为运维团队带来了管理上的便利和效率的显著提升。

虽然它对运维团队的知识储备要求更高，需要掌握如何为不同的表选择最合适的存储格式，并配置好多租户资源隔离，但这些都属于一次性的、可积累的增值技能，所带来的长期运维效益是巨大的。

金融级高可用与容灾能力：可以直接引用OceanBase引以为傲的

“三地五中心”城市级容灾方案作为标杆。

您可以强调，这套架构最初就是为支付宝的核心交易链路设计的，能实现RPO=0（数据零丢失）

的极高标准。

这意味着，单个数据中心甚至单个城市的故障都不会导致数据丢失或业务长时间中断，其可靠性远超传统主备模式的MySQL集群。

对于北京这样的一线城市，具备跨地域的容灾能力是业务连续性的关键保障。

多租户资源隔离确保互不干扰：这是打消“AP查询影响TP业务”顾虑的王牌。

OceanBase的多租户机制能实现不逊于物理隔离的效果。

您可以为高并发的TP业务和复杂的AP业务创建独立的租户，并为TP租户设置较高的资源保障（MIN_CPU等）。

这样，即便AP查询消耗大量资源，也不会挤占TP业务所需的计算资源，从而确保核心交易的稳定低延迟。

这种架构实现了“鱼与熊掌兼得”。

更能满足未来技术发展趋势

在确保稳定性的基础上，您可以展现方案二的未来价值。

拥抱HTAP浪潮，避免架构性淘汰：可以引用行业报告的观点，指出“一体化数据库是中小银行应对国产升级与AI规模化落地的‘最优解’”，而HTAP正是其核心特征。

未来的业务需求必然是实时化的，纯粹的TP和AP需求将会减少，更多的将是“在交易时进行实时分析”的混合场景。

方案二的行列混存架构天生为此而生，能够用一份数据同时处理交易与分析，从根本上避免数据延迟和不一致。

而方案一（两套集群）本质上是过去技术的延续，未来可能面临重复建设和技术掉队的风险。

AI应用铺平道路，降低未来门槛：AI时代的重要技术趋势是“混合搜索”（同时处理SQL、向量等数据），而一体化数据库是实现这一目标的理想底座。

方案二让企业现在就能基于统一的OceanBase集群开始积累数据和经验。

当未来需要引入AI能力时，可以平滑地扩展向量检索等功能，用一个SQL查询就能实现结构化数据与向量数据的混合分析，极大简化未来AI应用的技术栈。

降低存储成本：OceanBase基于LSM-Tree的存储引擎和高级压缩技术，平均可节省70%-90%的存储空间。

这意味着，一套集群的存储成本可能低于原来两套集群的存储成本。

提升资源利用率：多租户架构允许将多个业务的波峰波谷错配，实现资源的削峰填谷，从而用更低的总体资源量承载相同的业务负载，避免了方案一中“两套集群均需按峰值预留资源”的浪费

利用OceanBase的多租户机制，使得方案二实现不差于方案一的性能和资源的隔离效果

OceanBase的多租户并非简单的“数据库用户”概念，而是一个个逻辑上完全独立的数据库实例

。

每个租户拥有自己的系统数据库、用户体系、事务模块和资源配额，彼此之间数据与权限严格隔离，从架构上奠定了坚实的隔离基础。

Unit）

的精细规划。

您可以像为独立服务器分配资源一样，为每个租户定义其专属的“资源容器”。

以下表格对比了为TP和AP类租户配置资源单元的侧重点：

通过这样的配置，trade_tenant租户就获得了有充分保障的专属资源，不会因为其他租户的繁忙而受到影响。

运维优势与弹性能力

多租户机制带来的不仅仅是隔离，还有运维上的巨大优势：

动态扩缩容，无需数据迁移：在业务高峰期，您可以随时在线为TP租户增加CPU或内存，例如：

ALTER

整个过程对业务透明，无需停机，也无需像独立集群方案那样进行复杂的数据迁移。

智能负载均衡与优先级控制：OceanBase集群会自动监控各节点的负载情况。

如果某个节点上的TP租户因压力过大可能影响到同节点的AP租户，系统会自动将AP租户的部分数据副本调度到负载较轻的节点上，实现自动的负载均衡。

同时，OceanBase还支持大查询降级机制，当短时延的TP查询与长时间的AP查询同时竞争资源时，系统会优先保障TP查询的响应，确保核心业务的流畅性。

为了达到最佳的隔离效果，建议您在运维中注意以下几点：

资源规划留有余地：为避免“噪声邻居”效应，建议在规划时不要将整个集群的资源100%分配完，为每个租户预留约20%的资源缓冲，以应对突发流量。

监控是关键：充分利用OceanBase提供的系统视图（如

GV$OB_UNITS,

__all_virtual_tenant_memory等），持续监控各租户的资源实际使用率、CPU等待时间等关键指标，并设置告警，以便及时调整资源配额。

根据SLA划分租户：将具有相似服务等级协议（SLA）要求的业务放入同一个租户。

例如，将核心交易、日志服务、内部报表等不同重要级别的业务分别创建不同的租户，并配置不同等级的资源保障。

我们还要解决2个问题：对于同一个表同时有TP和AP用户访问，是否需要同时创建列式存储和行式存储表呢？

OceanBase的行列混存架构是如何满足业务需求的同时，既做到隔离资源访问又减少了存储的成本？

同一个表同时被TP（事务处理）和AP（分析处理）访问的场景，OceanBase的行列混合存储架构提供了一套非常优雅的解决方案。

它并非要求您手动创建两张表，而是通过一种智能的“行列混存”模式，让一份数据同时拥有两种存储格式，并由数据库自动选择最优访问路径。

下面这个表格清晰地展示了OceanBase为解决此问题提供的三种主要存储模式，您可以根据业务需求灵活选择。

OceanBase的巧妙之处在于其基于LSM-Tree的“基线-增量”数据分离架构：

增量数据（动态）保持行存：所有最新的增、删、改操作数据首先进入内存的MemTable（行存格式），确保高频写入和事务处理的低延迟。

基线数据（静态）可转为列存：当数据通过合并（Compaction）过程沉淀到磁盘后，可以根据您的建表设置，转换为列存格式（或行列冗余），以获得高压缩率和分析性能。

当执行查询时，优化器会基于代价估算自动选择扫描行存还是列存数据路径。

例如，点查询会走行存，而涉及全表扫描和聚合的分析型查询会优先选择列存。

您可以通过

COLUMN

在资源隔离方面，OceanBase通过多租户机制实现逻辑隔离。

您可以为TP业务和AP业务创建不同的租户，并为它们配置独立的资源单元（Unit），为TP租户保障较高的

MIN_CPU和

MIN_IOPS，从而确保核心交易业务不受分析查询的资源争抢影响。

兼顾性能与存储成本

这种架构在保证性能的同时，也实现了存储成本的优化：

高压缩率降低存储成本：列存格式针对同类数据的压缩效率极高，通常可比行存节省20%左右的存储空间。

共享增量数据避免完全冗余：在“行列冗余”模式下，增量数据是行存格式，并且是行存和列存基线数据所共享的。

只有在合并后生成的基线数据才会真正存储两份（行存和列存），这相比传统“TP库+AP库”两套系统存储全量数据的两份拷贝，从架构上就减少了冗余。

对于您提到的“同一张表同时有TP和AP用户访问”的场景，最佳实践是使用OceanBase的行列混存架构，为该表选择“行列冗余”模式。

成本优化：凭借列存的高压缩率降低存储开销。

|

特性维度

class="post-meta-container">