oracle group by用法_从OceanBase TPCC测试报告看ORACLE兼容性进展

概述

2019年10月2日，TPC委员会在官网(tcp.org)发布了 TPC-C榜单的最新测试报告：OceanBase数据库TPC-C测试披露报告。下载地址：http://www.tpc.org/results/fdr/tpcc/ant_financial~tpcc~alibaba_cloud_elastic_compute_service_cluster~fdr~2019-10-01~v01.pdf 。

此次OceanBase集群使用了207台云服务器，客户端压测程序使用了64台云服务器。结果跑到6088万tpmc，并且8小时持续运行性能抖动不超过0.5%。

当然本文不是来介绍OB的TPC-C性能，而是从披露的测试报告里看看OceanBase新增的几个功能。如视图、复制表、存储过程等。

复制表功能

分布式数据库的痛点

不管是哪种架构的分布式数据库，当集群规模变大的时候，不同业务表的数据很大概率会在不同的节点上。此时如果这两个表要做表连接,在分布式数据库内部就会是一个跨节点的请求。相比节点内部的表连接，跨节点的表连接性能会有明显下降。尤其是非拆分表和拆分表做表连接时，这种跨节点请求很难避免。

分布式数据库中间件使用小表广播方案，将非拆分表冗余到所有分库内部，这样把这个分布式表连接下推到各个分库内部变成本地表连接，性能有明显提升。小表广播的原理是中间件自动在各个分库内部创建这个表，内部组件会解析底层源表所在数据库增量日志(多是MySQL)并生成sql应用到所有分库内的表上。这个数据同步是独立于底层数据库外部做的逻辑同步。所以理论上它并没有很好的高可用能力，节点故障时也不能保证数据强一致。尽管理论上不完美，但由于小表通常是配置表，记录变化少，而其带来的好处却非常明显，导致小表广播非常受开发欢迎，成为分布式数据库中间件产品的基本标配。

在OceanBase内部，水平拆分的方案是使用分区。分区是数据迁移、高可用的最小单元。OceanBase为了避免某些分区跨节点连接，使用了表分组(tablegroup)的技术，将业务上联系紧密的分区约束在一个节点内部。但对于非分区表和分区表的表连接，以前就没有好的办法规避跨节点请求了。OceanBase 2.2.x 新增了表的复制表属性。当表是复制表的时候，OceanBase会保证主副本到其他所有副本的同步为全同步。

复制表功能

复制表的语法就是在普通建表语法通过locality在租户所有节点创建只读副本(其中 F就是默认的全功能副本，R就是只读副本，后面是描述其分布范围)，同时通过duplicate_scope指定复制表属性应用范围。如果是复制表，则主副本到所有备副本的Redo同步为全同步，性能上比Paxos协议同步Redo可能会更慢一些。不过由于用于复制表的数据变更通常不多，这点影响可以忽略。

下面创建2个表结构一致的表，一个是复制表，一个是普通表。下面的sql是在tpc-c的测试schema做了一些细微的改动，方便这里演示。

DROP tablegroup tpcc_group;
create tablegroup tpcc_group binding true partition by hash partitions 8;

DROP TABLE ordr;
create table ordr (
    o_id number not null,
    o_d_id number not null,
    o_w_id number not null,
    o_c_id number,
    o_entry_d date,
    o_carrier_id number,
    o_ol