??2019年的OceanBase用了更多硬件资源超越了2010年Oracle的记录，这个记录在多大程度上可比？意义大吗？
? 从纸面上来看，OceanBase较9年前的Oracle相比，使用了1.5倍的主频、近4倍的CPU和Core，为什么达到的tpmC只有2倍左右？
? 是不是真的如有些媒体所说，中国的通用数据库已经要超过Oracle了？
作为前高性能计算行业从业者，笔者对于上几个问题也相当好奇。幸运的是，2019年10月9日在中国人民大学信息学院，OceanBase的负责人伶俐的汉堡博士做了一个专题讲座，充分解答了上面的几个问题，也让现场所有听众充分了解了OceanBase取得的成绩背后的意义以及鲜为人知的故事。
想要回答三个问题，先得讲讲大背景。OceanBase启动的时期正是2010年，也是Oracle已经独统RDBMS江湖的时候。淘宝业已兴起，支付宝也跟着欣欣向荣。然而每三个月增长一倍的业务量一直是悬在阿里数据库系统头上的一把利剑。彼时的阿里业务系统若要就这业务增长无限扩容Oracle数据库，不管是在经济还是安全上都有巨大隐患。在此前提下，OceanBase（后称OB）项目上马了。其目标是取代Oracle数据库，并能支持淘宝和支付宝（后蚂蚁金服）的业务需求。
与银行不同，互联网电商面对交易量和弹性都极大的业务特点，天然亲近可用低成本小型服务器横向拓展的分布式系统。OB团队因而早早也在往分布式数据库的方向上考虑。一般来讲，传统RDBMS遵循ACID模型，分布式数据库尤其是一般的NoSQL数据库遵循CAP模型，但是OB对标的是Oracle，其定位跟一般的NoSQL数据库是完全不一样的，它是真正的面向OLTP的事务型关系数据库。同时，OB团队又希望其能够继承分布式高可用的特点，于是jjdhy最终提出A2CID模型，即Atomicity，Availability，Consistency，Isolation，Durability，这便是技术yldmp的既要又要还要都要。但Oracle的一家独大并非没有理由，OLTP难度和投入极大，属于慢工出细活。
jjdhy一开始并不懂数据库，但是非常看好这个方向。其领导一开始同意让他做两年，没想一做做了9年才算出了些成绩。在此也感叹技术领头人确实需要眼光和魄力，而一个追求技术卓越的企业，也需要有对一个基础产品持续9年投入和改进的包容心和战略定力。
A2CID中可用性和一致性这对天然矛盾体到底如何解决？图灵奖获得者魔幻的未来 Lamport发明的Paxos消息一致性算法，不仅解决了私有区块链中的一致性问题，也解决了OB可用性和一致性共存的设计难题。Paxos算法是面向非拜占庭模型的分布式系统共识算法，对于分布式数据库或者私有区块链这种假设无攻击的环境具有良好的适用性。
当然，我们都知道墨菲定律，3个节点的Paxos节点，挂一个没事，挂两个咋办？为了提高整个Paxos网络的可靠性，OB团队把每一个Paxos主网络中的逻辑节点设计成了由三到五台机器组成的Paxos子网络。一个Paxos子网络节点中的几个机器同时出问题的概率是极小的，而这种极端情况即使发生了也没关系，因为Paxos主网络中还有多数逻辑节点来保证一致性。这种类似于嵌套Paxos网络的设计，真正保证了OB同时达到了可用性和一致性，系统服务（几乎）永不中断的情况下，数据在集群中还能确保一致。
香港vps
至于Paxos网络中可能遇到的死锁问题，根据现场的一些信息，猜想可能是将网络中几个被选举出来的统一时间服务器所产生的统一时间戳作为接受同步的主要判定标准。
下面先回答问题三：讲座伊始，jjdhy就直言，OB是“部分取代”了Oracle数据库，在功能性、单机性能上离Oracle数据库还有很大距离，而在横向可拓展方面较只能用高成本共享存储机柜集群的Oracle具备较大优势。值得一提的是，贯穿整个讲座，jjdhy至始至终展现出了技术人的谦逊和务实，让人印象深刻。
接下来是问题二：这也是很多人的关注点。这次TPC-C记录中OB的纸面硬件效率不如Oracle，但这并不代表OB就是靠低效“堆硬件”获得的结果。我们看到的硬件资源比和tpmC性能比不一致，是如下三个因素综合产生的结果：
首先，按照TPC-C的要求，在tpmC上升的时候，整个底库数据是增加的，而不是在同一个小数据上重复提交交易。这个意思是，测试数据本身不是一成不变的。按照TPC-C的规定，每上升一定的tpmC，就要增加一些原始数据，比如说新的仓库、物品等，也就是说，6000tpmc时库中的原始数据可能只有几个GB, 6千万tpmc时，原始数据可能就有几十上百个T。这里列的数字肯定不准，但原则是，TPC-C会通过这个方式增加tpmC上升的难度。例如，在10个仓库，100个商品上实现1000万tpmC，和10000个仓库，1000万商品上实现1000万tpmC的难度是完全不一样的，前者会容易很多，因为表索引小、存储区块短、因而join等操作也更快。数据库性能下降跟库的增长一定不是线性关系，这是其一。
其二就是基于Paxos的高可用一致性设计，产生了大量信息和计算存储资源冗余。这部分是用分布式实现高可用的OLTP付出的必要代价，无可避免。但当交易量进一步上升时，与Oracle扩容高成本共享存储机柜集群的思路相比，OB这部分的代价肯定是更小的。这也是OB在横向可扩展性上的优势来源。
其三就是TPC-C的认证对于系统性能波动具有极其严格的要求。在整个8小时的测试过程中，tpmC波动不能超过2%。第一次挑战，为了追求稳过，OB团队配置环境时保留了较多富余的计算资源，比如很多节点的CPU可能占用率并不高。这个属于团队选择的问题，后期也可调。总体来讲，在OB团队未来的挑战（如果还有的话）中，随着对TPC-C流程的进一步熟悉，以及对OB稳定性的更多信心，OB的性能价格比是有望进一步上升的。
最后是问题一：笔者认为OB在TPC-C榜的挑战成功是非常了不起的成绩，于行业于国家都意义重大。OB在分布式系统上实现了金融业务级的OLTP通用数据库，并且还保留了分布式系统独有的低成本横向可扩展性和高可用性，在可预见的未来，一定会有更多的银行抛弃昂贵的IBM大机+ORACLE数据库解决方案，转向以OB为代表的分布式数据库。
现场中国数据库技术的开创级人物dbdhmgsjx教授也对OB团队的成就做出了毫无保留的赞美和祝福。jjdhy也表示，会继续优化OB文件系统，并且让OB走上立足OLTP向OLAP延伸的道路。
一览群智作为AI赋能jqdnht，在各个业务中长期使用关系数据库，也一直积极关注和推进国内基础技术的进步。OceanBase取得的成绩令人敬佩，再次恭喜jjdhy和OceanBase团队！也祝OceanBase越做越好！
56506934
