论文部分内容阅读
【摘要】 自21世纪以来，多种OLTP（（on-line transaction processing）数据库产品如雨后春笋般涌现，国产数据库不断成长壮大，多款数据库产品相继进入移动通信的IT系统，各数据库产品形态各不相同。面对新形势，大家都希望在商用前通过测试来评价一款数据库的优劣，国产数据库的测试评价标准成为一项大家重点关注的焦点。同时，如何通过测试来判断某数据库是否符合IT系统的需求也是一个重要的命题。本论文从测试的角度，提出了如何评价分析一款国产数据库的功能、性能、稳定性、健壮性、安全性、兼容性，作为各移动业务系统的数据库选型参考依据，同时也为软件系统的技术发展路线给出指引。
【关键词】 国产数据库 OLTP 测试 评价标准 选型
一、OLTP数据库测试简介
软件系统发展到一定规模，就离不开数据库，对于传统实时交易系统更加离不开OLTP数据库。OLTP数据库的特点是可以及时处理高并发的交易请求，多线程管理， 是传统的关系型数据库，主要是基本的、日常的事务处理，例如银行交易、移动通讯业务交易。
既然有OLTP数据库产品的存在，就有该产品的测试和验证。对于只接触过国外一线品牌的软件工作者来说，对国产OLTP数据库产品还处于认识的初期，如何通过一系列的测试验证方法，可以相对快速地了解国产OLTP的产品能力，是一件非常有意义的事情。
对于熟悉软件测试理论的测试工程师来说，评价一款软件产品的优劣，一般从功能齐备性、兼容性、性能、稳定性、健壮性、安全性、操作维护性等角度来开展。数据库产品也不例外，本文将分别从上述角度来展开阐述，如何评价国产OLTP数据库的优劣。另外，OLTP数据库从部署形态来看，主要分为主备式和分布式，本文主要从主备式产品的角度来描述，部分数据库厂商把主备成为集中式数据库。
二、国产数据库的分类评价测试
2.1基本功能测试
首先，我们先从功能上来看一看，摸一摸，捏一捏。当我们站在水果摊前，选择合适自己的水果前，首先肯定是观察水果的外表，例如颜色、形状、纹路等。评价数据库也不例外，我们都会先检查一下数据库的常用功能是否齐备。我们先看看国产主备机产品一般都具备些什么功能：
前面是常见的安装卸载和升级，接着是4种常见的分区方式，每种分区都有自己的应用场景，这里不重复了。这里稍微提及一下二级分区，例如我们要存储每个多个城市不同日期的天气记录数据，第一级分区就是按照城市来划分，第二级分区就是按照日期来划分，这个功能在国外一线数据库也比较常用。
同时，强调一下存储过程，对于习惯使用国外一线品牌的应用开发，存储过程的使用确认是一个偏爱，所以，国产的主备式数据库也常常开发了此功能。另外，还有一个小功能，“支持FOR UPDATE子句允许锁定所选行”，也是部分应用开发人员的使用偏好，因为这样可以避免同一时间大家更新某行记录，提高了一致性。再者，這里没有列举rowid和rownum的伪列功能，大家也留意一下，部分应用系统有这个使用要求，大家评估对比时也考虑一下。
说明：rownum和rowid都是伪列，但是两者的根本是不同的，rownum是根据sql查询出的结果给每行分配一个逻辑编号，所以你的sql不同也就会导致最终rownum不同，但是rowid是物理结构上的，在每条记录insert到数据库中时，都会有一个唯一的物理记录。
关于字符集的支持，国产的数据库产品一般支持UTF-8，GBK，ASCII字符集，而且是初始化安装时进行配置，一般是不支持在线修改的，若使用过程中修改服务器端字符集要跟数据库厂商确认。
关于支持故障恢复，一般可以支持恢复到指定时间点，个别数据库可以做到闪回，例如表级别的、分区级别，根据自己的业务系统情况进行测试评估。
关于MVCC多版本的控制，一般国产数据库都具备，测试时，要注意是否为不同的用户保存了自己版本的数据，读的数据不是最新的，有可能是历史的，这是测试的关键点。MVCC存在就是因为数据库的专家们不满足悲观锁这种性能不佳的解决读写冲突的方案，提出了在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能。
关于支持ACID基本特性时，这里有一个持久性的检查，应该重点关注重启数据库，操作系统后，数据是否还存在。
2.2数据迁移测试
关于数据库的迁移，在测试时，要关注是否提供了从oracle、mysql等异构数据库的全量或者增量的迁移工具，另外测试时要选取一定的数据量进行验证，例如10G的历史记录。检查迁移是否成功，计算搬迁的速率。
2.3数据同步测试
对于数据同步的功能，主要存在于容灾或者双中心的应用场景，一般指同构数据库之间的数据同步。同步工具是需要单向还是双向要根据业务使用场景来选择验证，有的场景，例如主备容灾，备节点只需要读和备份功能，那么单向同步就足够了。若选择双向同步，要从应用侧保证同步双方在同一个表没有出现相同记录。目前双向同步的功能对国产数据库来说，还是处于起步阶段，不是特别成熟。另外，双向同步的使用也有一定场景限制。
2.4兼容性
首先是考虑oracle的兼容度。因为部分业务系统是从oracle迁移过来，所以对oracle的常用功能的兼容度，可以作为测试检查点。包括兼容oracle的语法Explain plan，Create Profile，HINT，还有oracle的高级包：包括
DBMS_JOB.SUBMIT，DBMS_JOB.RUN，DBMS_SQL.RETURN_RESULT ，DBMS_DEBUG.INIT，DBMS_LOB.GETLENGTH，DBMS_OUTPUT.PUT_LINE，DBMS_RANDOM.VALUE，DBMS_STATS.AUTO_DEGREE，DBMS_UTILITY.GET_TIME等。 除了考虑oracle兼容性测试外，还要考虑数据库跟服务器架构、存储、操作系统的兼容度，这里列举一下常见的兼容性测试点：
服务器架构：x86，ARM架构。
存储：HDD，SATA，SSD，Nvme，SAN存储。
操作系统：CentOS系列，BCLinux（中国移动研发），UOS，麒麟OS。
2.5数据库性能测试
关于数据库性能的验证，可以从两个角度来考虑，一个角度是采用行业常见评价标准，一个角度是使用业务应用的性能场景。首先看看行业的常用标准，TPCC测试模型。此方法提出的是TPC委员会，是一个国际组织，全称是Transaction Processing Performance Council，事务处理性能委员会。此模型使用的是经过抽象后的电商系统模型，在地理分布的多个区域有业务，并且使用仓库管理。当业务扩展的时候，公司将添加新的仓库。每个仓库维护100000种商品，每个仓库负责十个区域的供货，每个区域3000个客户服务，平均每个客户的一个订单有10项产品。所有订单中约1%的产品在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。
性能由tpmC（transactions per minute，tpm）衡量，单位是每分钟，取tpmC NewOrders值，C指TPC中的C基准程序。整个业务模型如图 1。
使用TPCC模型来测试OLTP数据库的性能，优点在于测试模型的标准性，可以被多数的用户接受，有一定的对比价值。当我们使用TPCC的测试值来做性能对比，要注意使用统一的施压测试工具及版本，配置要保持一致例如仓库数，业务比例值，测试时长周期，是否使用外键等。同时，使用的施压机器默认是不跟数据库放在同一服务器的，个别测试团队把施压工具安装在数据库服务器上，减少网络带宽和延时，虽然可以提升测试结果值，但是这种方法不被行业专家所接受。
现在，我们看看另外一种性能测试角度，使用实际业务系统的业务模型来测试。这种方法，常常是选择应用系统中高并发处理模块，作为一个模拟工具来发起并发请求，也可以直接把應用程序跟数据库集成在一起，模拟相对真实的性能测试场景。测试时，采集此时数据库的TPS，响应时间，数据库服务器的磁盘IO读写速率，CPU使用率，内存使用率。同时，也采集业务全流程的TPS，响应时间等指标，最后对比同款数据库的测试结果指标，可以分析出测试对象数据库的性能水平。
关于事务型的数据库，我们还可以测试以下几种常见场景的性能表现指标。
例如，纯写入的高并发场景，纯更新的高并发，写入加更新，写入加查询等场景，这些使用场景跟实际业务应用场景比较接近，可以体现出OLTP数据库在写，读，更新，查询等几个动作，及动作组合的效率情况。另外，这里稍微提及一下查询的性能测试，对于事务型的应用系统，一般聚合查询，跨表查询的场景不多，但是不代表了OLTP数据库就没有分析型的语句使用需求和场景，一些实时交易类的系统，也是需要每天做统计分析，出报表的，在做数据库性能评估时，可以适当增加一些聚合查询、跨表查询、关联查询的性能测试用例。这样，面向数据库的性能评价会更加全面。
另外，在性能度量方面，从运维角度考虑，还可以考虑一下数据导入导出的效率测试。导入的测试，主要是批量地导入文件，文件格式和内容可以参考业务模型来设计。统计导入的数据量大小和耗时，计算导入的TPS。对于导出操作，常见是导出为CSV格式的文件，每个文件大小约100M，统计导出的数据量大小和耗时，计算导出的TPS。
三、结束语
对国产数据库的评价，需要结合我们的应用系统使用场景来测试。当然，采用国际标准的TPCC测试模型来验证OLTP数据库的事务处理效率是可行的，有一定的参考价值和对比意义。对于国内的应用系统，需要从对数据库的功能、兼容度、性能、迁移能力、数据同步能力等方面来进行测试评价。另外，所有能力的评价是基于一定的软硬件环境的，即在同样的服务器架构、操作系统和存储下进行，记录此条件下的功能和性能表现。
参 考 文 献
[1]《中国移动主备式数据库测试规范》，2020：5 - 6
【关键词】 国产数据库 OLTP 测试 评价标准 选型
一、OLTP数据库测试简介
软件系统发展到一定规模，就离不开数据库，对于传统实时交易系统更加离不开OLTP数据库。OLTP数据库的特点是可以及时处理高并发的交易请求，多线程管理， 是传统的关系型数据库，主要是基本的、日常的事务处理，例如银行交易、移动通讯业务交易。
既然有OLTP数据库产品的存在，就有该产品的测试和验证。对于只接触过国外一线品牌的软件工作者来说，对国产OLTP数据库产品还处于认识的初期，如何通过一系列的测试验证方法，可以相对快速地了解国产OLTP的产品能力，是一件非常有意义的事情。
对于熟悉软件测试理论的测试工程师来说，评价一款软件产品的优劣，一般从功能齐备性、兼容性、性能、稳定性、健壮性、安全性、操作维护性等角度来开展。数据库产品也不例外，本文将分别从上述角度来展开阐述，如何评价国产OLTP数据库的优劣。另外，OLTP数据库从部署形态来看，主要分为主备式和分布式，本文主要从主备式产品的角度来描述，部分数据库厂商把主备成为集中式数据库。
二、国产数据库的分类评价测试
2.1基本功能测试
首先，我们先从功能上来看一看，摸一摸，捏一捏。当我们站在水果摊前，选择合适自己的水果前，首先肯定是观察水果的外表，例如颜色、形状、纹路等。评价数据库也不例外，我们都会先检查一下数据库的常用功能是否齐备。我们先看看国产主备机产品一般都具备些什么功能：
前面是常见的安装卸载和升级，接着是4种常见的分区方式，每种分区都有自己的应用场景，这里不重复了。这里稍微提及一下二级分区，例如我们要存储每个多个城市不同日期的天气记录数据，第一级分区就是按照城市来划分，第二级分区就是按照日期来划分，这个功能在国外一线数据库也比较常用。
同时，强调一下存储过程，对于习惯使用国外一线品牌的应用开发，存储过程的使用确认是一个偏爱，所以，国产的主备式数据库也常常开发了此功能。另外，还有一个小功能，“支持FOR UPDATE子句允许锁定所选行”，也是部分应用开发人员的使用偏好，因为这样可以避免同一时间大家更新某行记录，提高了一致性。再者，這里没有列举rowid和rownum的伪列功能，大家也留意一下，部分应用系统有这个使用要求，大家评估对比时也考虑一下。
说明：rownum和rowid都是伪列，但是两者的根本是不同的，rownum是根据sql查询出的结果给每行分配一个逻辑编号，所以你的sql不同也就会导致最终rownum不同，但是rowid是物理结构上的，在每条记录insert到数据库中时，都会有一个唯一的物理记录。
关于字符集的支持，国产的数据库产品一般支持UTF-8，GBK，ASCII字符集，而且是初始化安装时进行配置，一般是不支持在线修改的，若使用过程中修改服务器端字符集要跟数据库厂商确认。
关于支持故障恢复，一般可以支持恢复到指定时间点，个别数据库可以做到闪回，例如表级别的、分区级别，根据自己的业务系统情况进行测试评估。
关于MVCC多版本的控制，一般国产数据库都具备，测试时，要注意是否为不同的用户保存了自己版本的数据，读的数据不是最新的，有可能是历史的，这是测试的关键点。MVCC存在就是因为数据库的专家们不满足悲观锁这种性能不佳的解决读写冲突的方案，提出了在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能。
关于支持ACID基本特性时，这里有一个持久性的检查，应该重点关注重启数据库，操作系统后，数据是否还存在。
2.2数据迁移测试
关于数据库的迁移，在测试时，要关注是否提供了从oracle、mysql等异构数据库的全量或者增量的迁移工具，另外测试时要选取一定的数据量进行验证，例如10G的历史记录。检查迁移是否成功，计算搬迁的速率。
2.3数据同步测试
对于数据同步的功能，主要存在于容灾或者双中心的应用场景，一般指同构数据库之间的数据同步。同步工具是需要单向还是双向要根据业务使用场景来选择验证，有的场景，例如主备容灾，备节点只需要读和备份功能，那么单向同步就足够了。若选择双向同步，要从应用侧保证同步双方在同一个表没有出现相同记录。目前双向同步的功能对国产数据库来说，还是处于起步阶段，不是特别成熟。另外，双向同步的使用也有一定场景限制。
2.4兼容性
首先是考虑oracle的兼容度。因为部分业务系统是从oracle迁移过来，所以对oracle的常用功能的兼容度，可以作为测试检查点。包括兼容oracle的语法Explain plan，Create Profile，HINT，还有oracle的高级包：包括
DBMS_JOB.SUBMIT，DBMS_JOB.RUN，DBMS_SQL.RETURN_RESULT ，DBMS_DEBUG.INIT，DBMS_LOB.GETLENGTH，DBMS_OUTPUT.PUT_LINE，DBMS_RANDOM.VALUE，DBMS_STATS.AUTO_DEGREE，DBMS_UTILITY.GET_TIME等。 除了考虑oracle兼容性测试外，还要考虑数据库跟服务器架构、存储、操作系统的兼容度，这里列举一下常见的兼容性测试点：
服务器架构：x86，ARM架构。
存储：HDD，SATA，SSD，Nvme，SAN存储。
操作系统：CentOS系列，BCLinux（中国移动研发），UOS，麒麟OS。
2.5数据库性能测试
关于数据库性能的验证，可以从两个角度来考虑，一个角度是采用行业常见评价标准，一个角度是使用业务应用的性能场景。首先看看行业的常用标准，TPCC测试模型。此方法提出的是TPC委员会，是一个国际组织，全称是Transaction Processing Performance Council，事务处理性能委员会。此模型使用的是经过抽象后的电商系统模型，在地理分布的多个区域有业务，并且使用仓库管理。当业务扩展的时候，公司将添加新的仓库。每个仓库维护100000种商品，每个仓库负责十个区域的供货，每个区域3000个客户服务，平均每个客户的一个订单有10项产品。所有订单中约1%的产品在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。
性能由tpmC（transactions per minute，tpm）衡量，单位是每分钟，取tpmC NewOrders值，C指TPC中的C基准程序。整个业务模型如图 1。
使用TPCC模型来测试OLTP数据库的性能，优点在于测试模型的标准性，可以被多数的用户接受，有一定的对比价值。当我们使用TPCC的测试值来做性能对比，要注意使用统一的施压测试工具及版本，配置要保持一致例如仓库数，业务比例值，测试时长周期，是否使用外键等。同时，使用的施压机器默认是不跟数据库放在同一服务器的，个别测试团队把施压工具安装在数据库服务器上，减少网络带宽和延时，虽然可以提升测试结果值，但是这种方法不被行业专家所接受。
现在，我们看看另外一种性能测试角度，使用实际业务系统的业务模型来测试。这种方法，常常是选择应用系统中高并发处理模块，作为一个模拟工具来发起并发请求，也可以直接把應用程序跟数据库集成在一起，模拟相对真实的性能测试场景。测试时，采集此时数据库的TPS，响应时间，数据库服务器的磁盘IO读写速率，CPU使用率，内存使用率。同时，也采集业务全流程的TPS，响应时间等指标，最后对比同款数据库的测试结果指标，可以分析出测试对象数据库的性能水平。
关于事务型的数据库，我们还可以测试以下几种常见场景的性能表现指标。
例如，纯写入的高并发场景，纯更新的高并发，写入加更新，写入加查询等场景，这些使用场景跟实际业务应用场景比较接近，可以体现出OLTP数据库在写，读，更新，查询等几个动作，及动作组合的效率情况。另外，这里稍微提及一下查询的性能测试，对于事务型的应用系统，一般聚合查询，跨表查询的场景不多，但是不代表了OLTP数据库就没有分析型的语句使用需求和场景，一些实时交易类的系统，也是需要每天做统计分析，出报表的，在做数据库性能评估时，可以适当增加一些聚合查询、跨表查询、关联查询的性能测试用例。这样，面向数据库的性能评价会更加全面。
另外，在性能度量方面，从运维角度考虑，还可以考虑一下数据导入导出的效率测试。导入的测试，主要是批量地导入文件，文件格式和内容可以参考业务模型来设计。统计导入的数据量大小和耗时，计算导入的TPS。对于导出操作，常见是导出为CSV格式的文件，每个文件大小约100M，统计导出的数据量大小和耗时，计算导出的TPS。
三、结束语
对国产数据库的评价，需要结合我们的应用系统使用场景来测试。当然，采用国际标准的TPCC测试模型来验证OLTP数据库的事务处理效率是可行的，有一定的参考价值和对比意义。对于国内的应用系统，需要从对数据库的功能、兼容度、性能、迁移能力、数据同步能力等方面来进行测试评价。另外，所有能力的评价是基于一定的软硬件环境的，即在同样的服务器架构、操作系统和存储下进行，记录此条件下的功能和性能表现。
参 考 文 献
[1]《中国移动主备式数据库测试规范》，2020：5 - 6