在数据库选型过程中，为确保能够灵活应对数据规模的不断扩大和处理需求的日益复杂化，企业和技术人员会借助POC测试来评估不同数据库系统的性能。在测试过程中，性能、并发处理能力、存储成本以及高可用性等核心要素通常会成为大家关注的焦点，以确保所选产品能够满足特定的业务需求和性能标准。

那么，针对OceanBase数据库，我们该如何进行测试，才能更好的感知分布式数据库的特性呢？

敬请关注4月17日（周三）晚7点半的《DBA从入门到实践》第三期，我们将了解到：

1. 结合OceanBase数据库的特性，了解POC测试中常见的测试点
2. 介绍影响 OceanBase 性能的因素，常见的Benchmark如何跑出较优的性能
3. 常用Benchmark工具的测试模型、测试方法，性能问题排查的基本思路
4. 如何对OceanBase进行并行导入、数据压缩、高可用测试

点击下方链接报名学习~

【DBA从入门到实践】第三期

内容抢 “鲜” 知

（一）OceanBase测试概述

• 性能测试

数据库性能测试是业务选型和PoC测试中的重点关注指标，涉及多种评估标准和测试工具。OceanBase作为一款实时HTAP数据库，同时支持在线实时交易及实时分析两种场景。一方面，为了评估数据库OLTP（联机事务处理）的性能，我们常用标准化测试工具如Sysbench和TPC-C来衡量数据库在处理高并发事务、维持数据完整性及快速响应查询请求方面的能力。另一方面，为了评估数据库OLAP（联机分析处理）的性能，我们通常会通过TPC-H这样的工具来模拟多维数据集的复杂查询和分析操作，检验系统对于大数据量的处理和响应能力。本期教程将介绍这些常用Benchmark工具的测试模型、测试方法。

• 并行导入测试

在OLAP场景下，大量数据的并行导入，即数据批处理能力也是PoC测试中不可或缺的一环，数据批量写入操作的速度和稳定性，对于需要处理大量数据迁移或同步任务的用户来说至关重要。OceanBase 数据库的并行执行框架能够将 DML 语句也通过并发的方式进行执行，对于多节点的数据库，能够实现多机并发写入，并且保证大事务的一致性。本期教程将为大家介绍OceanBase常用的并行导数方式和测试方法。

• 数据压缩测试

在完成业务数据导入后，数据压缩也是用户经常关注的测试点。随着存储成本的持续上升和对高效数据访问的不断追求，低成本存储及高效处理海量数据信息已成为提升数据库产品竞争力的重要因素，数据库压缩技术也成为优化数据库性能和降低总成本的关键手段。进行数据压缩测试旨在量化数据压缩前后对存储空间的节省，评估压缩数据对查询和事务处理性能的具体影响，以及验证数据的完整性和恢复过程的可靠性。本期教程将举例介测试绍OceanBase数据压缩比的测试方式。

• 高可用测试

数据库系统在应用架构中承担了数据存储和查询的重要角色，企业数据的高可用对保障业务连续性至关重要。高可用也是数据库测试中重点考察的因素。OceanBase 数据库基于 Paxos 协议实现了多副本容灾方案，对用户提供少数派故障时 RPO = 0 (Recovery Point Objective，数据恢复点目标) ，RTO < 8s (Recovery Time Objective，恢复时间目标) 的高可用能力。本期教程将为大家带来容灾场景下高可用测试的基本方案。

（二）影响 OceanBase 性能的因素

数据库的性能往往受到多个方面因素的影响，包括数据库软件、操作系统参数、资源分配、数据库参数调优，以及合并与统计信息收集等。从数据库软件层面来看，代码的优化、算法的选择，以及系统架构的设计，都直接影响着数据库的性能。OceanBase作为一款高性能的HTAP数据库，在版本的迭代过程中，也一直持续致力于提升数据库性能并降低资源消耗。

在本期教程中，将为大家介绍以下几个对OceanBase数据库性能的影响因素：

• 操作系统参数。
• 资源分配，包括磁盘划分、Primary Zone、分区表、表组、局部索引与分区索引。
• OLTP和OLAP场景下，数据库的参数调优。
• 合并与统计信息收集。

（三）Benchmark性能问题排查的基本思路

在我们性能测试的过程中，有时候会遇到性能不符合预期的场景，OceanBase数据库是原生分布式数据库系统，根因分析通常是比较繁琐的，因为涉及的因素较多，比如机器环境、配置参数、运行负载等。我们整理了OLTP和OLAP场景下性能不符合预期时，基本的排查思路。

首先，我们推荐使用obdiag工具对给OceanBase做个体检，检查集群整体的健康状态。

OLTP场景：

• 排查问题时，通常可以先设置primary为单zone，运行sysbench中oltp_point_select的case，观察observer的cpu是否可以跑满，简化基本的问题场景。
• 检查client -> proxy -> observer链路上硬件资源的瓶颈，包括各个链路组件的cpu、内存、网络带宽、磁盘、网络延迟等。
• 检查测试步骤是否与官网标准步骤一致，比如运行oltp_read_write和oltp_write_only场景下时，如果用户不设置-rand-type=uniform，或者table-size和tables的范围比较小，会导致性能测试中id或表名的取值过于集中，容易触发死锁。
• 通过top –H –p pid观察cpu使用情况，小规格场景下，可以关注MINI_MERGE、MINOR_EXE（转储合并线程）的开销。

OLAP场景：

• 检查租户资源配置，评估相对测试的数据量，租户cpu、内存配置是否充足。
• 观察并行执行下机器的cpu水位、磁盘I/O负载。
• 检查测试步骤是否与官网标准步骤一致， AP场景下关键的Observer参数配置，ob_sql_work_area_percentage、 parallel_servers_target等。
• 通过查询视图CDB_OB_MAJOR_COMPACTION中， STATUS字段是否为IDLE，判断合并任务是否正常结束。
• 通过查看视图DBA_OB_TASK_OPT_STAT_GATHER_HISTORY， STATUS字段是否为SUCCESS，判断统计信息收集是否正常进行。
• 检查执行计划是否正常，关注执行计划中dop的值，观察sql查询是否正常。

更多精彩内容请锁定4月17日《DBA从入门到实践》第三期～