开发者学堂课程【从0到1数据库内核实战教程：OceanBase架构和研发技巧】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1083/detail/16066
OceanBase 架构和研发技巧
内容介绍：
一、OceanBase 基础架构
二、开发技巧
首先要入手开发一个内容数据库肯定要了解一个它的基础架构来掌握它的核心科技。
这次从不同的角度来分享OB的主要架构 。首先数据库其实是有些不同的需求，最重要的就是稳定性就是这个数据库本身要稳定，其次在稳定性上还有些不同的需求。比如扩展性，就是数据库可以扩展一些节点来增加性能等等；或者它的高可用性能，数据库有一定的融载能力；高性能是各性能要尽可能的好；低成本就是成本也要尽可能的低一些；兼容性就是可以兼容一些列新应用。
一、OceanBase 基础架构
1·稳定性
都知道 Ocean 是稳定的，如果出一个新的数据库有时候赶着去找一些证据。这时候我们可能只能从一些历史，或者做一些稳定测试来证明它是稳定的。所以我们来讲一下 OB 的历史。
OB其实是2010年开始立项的，当时是做淘宝；2010-2013年都是NoSQL的一个储存；2013-2016年才支持SQL到2016年蚂蚁的基本所有核心业务都跑到OB上面了；2017-2020年才变成一个分布式的数据库，数据也打了很多家银行的业务；到2021年OB开源然后开放给大家。
其实从2014年开始就阿里的双11都跑到了OB上面，有一些2016年的数据库数值每秒交易17.5万笔、每秒支付12万笔。其实有两个库，一个是交易库一个是支付库，就是可以发起一笔交易但不一定会为这笔交易付钱。交易库的一些数值就是它的QPS650万，TPS是365万，RT是延时0.7ms。
还有一些数值，第一个6100万次每秒其实是双11的一个峰值数据它其实是一个circle语句的次数巅峰6100万次circle，节点大于1000台以及3PB和3200亿行是蚂蚁的库，就难有1000个节点，蚂蚁有很多历史库都特别特别的大，比如收藏库单表就由几十亿行。后面的RPO和RTO其实是一个高科用于复制，RPO指的是每一次故障恢复后丢失的数据，它的0就是恢复后没有数据丢失，RTO是每一次故障回复到应用是恢复时间就RTO小于30秒，这个其实是无副本架构下的故障处理数值。综上可以看到OB还是比较稳定的。
2·扩展性（垂直扩展、水平扩展）
扩展性分为垂直扩展和水平扩展。垂直扩展就是比如说给一个机器加分能力，比如加CPU然后硬盘更高、转速更快，其实提升的是一个单机的能力。垂直扩展比较考验大型软件的一个对并发控制的能力，就是对这个锁的控制怎么样。所以单纯机器的增加不一定会带来性能的，就是他们不是线性的关系，所以垂直扩展非常考验一个软件的适应能力 。
水平扩展就是比如加节点，扩展性其实也是伸缩性不一定是往外扩其实也是往里缩。比如说可以减掉一些印迹或节点减少一些不必要的浪费，也是扩展性。
可能会经常看到这个图，比如官网或者OB上会经常看到，第一次看的话可能会有些看不懂。上面是Driver和OBProxy,OBProxy其实就是OB的代。它主要有两个作用一个是保持链接，第二个是它可以请求路由，就是会把请求路由到正确的节点上。
这里有三个ZONE分别是ZONE_1、ZONE_2、ZONE_3就是三个副本，ZONE的物理意义其实就是一个虚的概念，物理意义是一个机房的一些机器三个作用其实就是三个不同机房的一些机器，它其实在每个作用上可以有很多的OBServer，每一个OBServer都有单独的circle存储和实名。所以它这样的架构是一种共享架构，所以它可以比较容易的进行扩展，它的每一个点其实是根据数据分片来做的一些分区。这里的RS有一些作用，比如说DDL创建一些租户。分区组之间是通过Paxos奇艺组来实行控制。
假如说做一个垂直扩展在这个副本上加OB节点或单独给OBSever节点加它的性能，来增加OB整个集群的性能。如果横向的增加一些副本，比如再加两个或更多地副本其实并没有增加OB集群的性能，它能增加的只是可靠性。这里单机群的规模其实是做TPC-C还有1500个节点，所以基于这样的架构它的可扩展性还是比较高的。
3·高可用
高可用它支持单机房故障的，假如副本1挂了副本2 、3还可以正常运行，然后还可以带着副本1恢复回来。这样就可以做到一个滚动升级，比如想升级这篇OBServer先把副本1挂掉然后升级完副本1，然后在回来升级到副本2挂掉，依次升级副本3 ,还有一个是恢复后事务阻塞，挂掉之前有一个事务在恢复之前这个事务会继续进行。
执行自动重试就是自动请求出错的R7自动重试，然后还会主动做一些容灾处理。一个就是宕机会出现故障会把1的节点切到ZONE2或者3上。假设一个节点宕机时间比较长超过了两个小时甚至这个节点的磁盘O磁塔坏了，那这个节点就恢复不回来了，所以会查出这个数据的节点，甚至是把这个节点从列表中移除。
但是把这个往外推根据不同公司的情况其实会衍生出不同的价格，上面的比较适合蚂蚁中心比较多，往外推的时候其实很多公司没有那么多中心，有的可能只有两个甚至一个中心是一种储备库的模式。
左边是主库右边是备库，这两种库不是完全物理意义上的复制。比如DDL在左边RS传递一个库其实左边的RS会通知右边的RS它也执行一个同样的，所以两个RS其实是各为基础。分区是clog的一个异步同步。
当中心稍微多一点的时候，还有很多这种银行机构他会把这种两地三中心设置成一种检验标准，左边是主城市右边是第二城市，主城市有两个中心右边有一个中心。假设当IDC_1挂的时候其他的正常，当IDC_2挂的时候也是除了它之外的正常，依次类推。
假如是城市化故障的比如网络故障的问题，那么挂的就只剩副版本了这个副版本协议是少数派是不能维持服务的，所以这个时候做了一个储备库又拉出来一个副本，然后副本就可以正常运行了。所以这个两地三中心实际上是六个副本。
如果遇到中心比较多城市也比较多的时候，比较适合蚂蚁的情况再利用中心，当另一个中心宕机或城市故障发生的时候都是多数派。但是这个有一个要求就是左边两个中心要产生的距离近一些，他俩的时间基本小一点，比如说杭州。
还有一个在这个纵轴上不要有主，写的时候容易在主上写，还有clog同步就是所有的都是网络语请求大家会非常高。
4·高性能
高性能就是很多的角度去做一些高性能的运营化，比如说在并发上做一些优化或者在内存控制中做一些数据优化，或者应用了很多操作系统的能力，网络上也进行了一些优化。
角度非常多，就从一个读写的流程角度看一下OB的架构作用。比如这张图，读它有几种情况通过本地读取再返回，还有一个是远程读就P发送了一个错误请求就有一个错误的节点然后远程读其实这个时候逻辑下送的是直升逻辑，不会把数据送过来到右边执行。还有一个就是分布识图。就是数据在不同的节点上，协议也是有不一样的，有本地协议也有远程协议。也是推它的执行计划，还有分布实行，这种分布式就是在一个分区上进行就我的事物写多个分区，就每个事物都是不同的结构，每个分区都是一个事物。再总共提交的时候涉及多个分区的提交，所以这个时候就有两个阶段的提交协议， 这里有GTS是实验说服也是高可用的。
读操作，可以降低响应时间提高存储率，降低响应的时间有很多种方式。第一个是Obproxy很多时候部署应用是客户端和应用在Obproxy的节点，在另一个节点这个时候相当于网络有两跳，如果把Obproxy部落在本地，相当于只有一跳。PS就是剪影，协议优化。快速参数化和plan就是每次生成职业计划就会进行快速参数化去看能不能命中一些执行计划。这个和mycircle是不同的，这个是那circle的stream进行参数化的过程。还有一些就是优化器，优化器的原理很好讲，就是基于规则和待遇改写优化，但其实很多优化器它不用的都是单独拿章节来讲的，是一个慢慢打磨的过程，需要大量的试验这些规则，所以优化器就是注重改写出来的计划，到底是不是合适。接下来的是跟OB的存储引擎架构比较相关，写的时候一行一行写，读的时候是机械数据和增长数据合并下来读，所以会设置很多，然后合并row cache提高过滤。还有一个filter来提高过滤。以及静态类型，比如mycircle它的执行其实是把类型带下去，执行的时候先看看类型，解释的时候类型变量可作为一个参数带下去。然后执行的时候进行判断，但是我们先把类型编译出来然后执行的时候带的就知道类型。还有一个向量引擎，每次迭代的时候其实拿到的一个向量是一列。这样的话它就是会大大减少迭代的次数，更专注于他的计算逻辑，并行执行。
避免一些不必要的RPC，提升吞吐率基本上就是大多数数据库处理并发的状态，所以基本上大多数数据库都是用MVCC快照读。水平展开就是增加一些节点，吞吐能力增加。
这个写右边其实就是OB的主要项目，写的时候是按行写，然后读的时候是极限数据和增长数据合并。当结构非常快的时候就会有很多很多层会进行contection，所以它和储存是按页来储存，相当于写是比较优秀的，但是读的话会不如必加数。内存级写入性能，小事物执行过程中都不会落入盘中。
还有一些是根据pation来做局部索引来避免分布式事务，就是没有必要分布式事务就不要去撞这个南墙，压力大的时候就看着轮转一点点合并写入性能。最后是大杀器PDML的并行。
提升吞吐率一个是隔离基别，不同数据库它的隔离级别是不同的，不同的数据库根据自己的隔离级别会做不同的优化，没有说哪种隔离级别是比较好的。OB是行级锁和tra……结合，其实OB上写一个数据并不是单纯的一个写，它是一个又读又写的操作，先读出来一个数据进行操作然后再把这个数据写进去，这个时候就会上一个行锁，OB上做了一些优化，就是读的时候不上锁，在写的时候再持这个行锁。如果它手机是拿一个时间戳，在写之前判断这个时间戳，如果写的时候有事务进行，这个时候就写操作就会进行一次这个就叫transaction set consistency。
高效事务提交可以说的点就更多了，右边其实是两个成绩，就是两次优异的OB打码的成绩。挑几点讲一个是还是通过降低级别来尽量避免分布式事务。第二个是两阶段提交一些特别优化的，协调者其实是一种无状态的能减少一次实验和日志。还有热点提前减行数，其实我们解锁一般是写着去然后多数化完成再把这个行锁解开。OB是竖写会把这个锁解开，有点是热点并发非常高的时候，这个时候就能体现提前解行组的优势。
这个是两阶段的提交，是没有状态的。
5·低成本
低成本就比较容易，将数据传到数据库比较难以扩展，基于OB这种无共享的架构，可以通过一些比较廉价的PCA服务器把这套系统组起来，要求软件融载的能力特别高。
然后做了一些特别优化，一个是副本类型，不一定都是全功能副本有时候会比较浪费。这时候我们设置不同的副本，按需要总副本，比如说同步时有没有内存和硬盘就能够组合出不同类型的副本，然后在再根据纵的组合，能组成适用于不同场景的架构。
还有一些OB的存储引擎也做了很多的压缩处理，还有列存，在存库页上。
还有一种多租户的概念，有的时候怎么理解就怎么设置这个多租户，不同的数据库对数据的设计也不太一样。比如说有的时候云厂上一般会用到这种多租户提供不同的服务给不同的人。又有一些设计比如说通过共享表来，还有一些用户前面带着自由组合id的区分，还有多数据模式就是不同的租户提供不同的数据使用。OB多租户就是一个事例里面有多个租户，优点就是自然管理比较好管理，一个集群就能有多个租户。还有一个是升级OBSever，多租户多事例的情况下升级租户比较慢，如果一个事例有多个租户的话分布起来也比较快。
弹性成本就是双11的时候用到的，就是本来只有三个节点，g后来扩了很多的节点一直扩到最大，才开始只是一些只读副本后面就变成了写入副本。等到双11大促结束以后再把这些回收回来，其实这种扩容缩容带来的成本利益是很高的。
还有一种是云的能力，就是云有很多的能力，容器的扩缩容。如果OB如果能配合云其实能大大扩展它的弹性的能力。
6·兼容性
兼容性其实有很多的好处，比如兼容一些协议都可以用，或者兼容一些数据处理的应用之类的，就可以和很多下游消费的应用就可以使用。或者才开始OB文档比较少的时候，就没有什么特别好的文档的时候通过my circle文档来使用OB。还有一个是研发的时候说兼容my circle来设计一个全新的功能，这个数据就大大提高开发时站在巨人的肩膀上来进行开发。
开源其实是支持绝大多数的数据类型函数、语句、信息表、视图等等都是按需来增加的。
平台方案也是兼容了很多的周围架构，中间是OB的内核，后面可以对接很多消费应用OCP这边会面向一些运维，关于一些开发者的工具，比如OM框架或者连接管理之类的，所以兼容性也是非常重要的。
二、开发技巧
第二章学习一些开发者技巧首先看了一些理论、源码以后进行开发，如何部署这些难度性会分享一些技巧。这一章从外表就可以看到。比如说OBD部署、然后源码编译OB、设置开发IDE、代码编写风格、代码调试、用自己写的OB编译出来部署一个、编写mys、编写unit得出自己的代码最后向OB贡献自己的代码。
1. 使用 OBD 部署 OceanBase
如何部署，在网站上写的也比较详细。脖子安装的话在这个网站上基本都有，然后在开发部署的时候看一下OB的这个help，它会告知如何指定。
敲出的每一个指令其实都能弹出很多的东西，想知道一些指令通常都是通过这个help来敲出来,OBD的文档就比较全面可以看一下。
2.使用源代码编译OceanBase
源代码编译OB也有一个文档就是一个兼容性的列表，兼容一些主流的系统，编译指令也在这里，首先基本上分三步。第一步首先是下了很多的依赖，为了兼容很多的系统，我们把它都依赖打在安装包里下载，这样对于系统兼容性来说会比较友好。
说到编译其实在开源之前就做了很多编译上的优化，才开始编译其实很慢的，后来加了一些类型，比如一些联合编译来加快编译速度。在原来的时候编译其实还是比较慢的。
3.设置开发IDE
IDE开发其实自己喜欢的就好，其实都可以，配备一些插件来助于函数的跳转。比较推荐CCLS它其实首先生成一个jason。其实是加了一个参数指令。这个时候进行一些配置，主要是地址，jason就是Clion地址记好就可以。
4.代码编写风格与自动化风格格式工具
还有一个是自动化风格格式工具，代码风格其实是粘贴了一个网址，具体的规范可以点击去看，提供了一些格式化工具。一个是用了插件设置，编译器保存会自动修改格式，提供了一个脚本。
把jason移出来就好了，所以就直接执行。并行来看看mate这里，有一个配置文件，如果想配置时还有一个点脚本，就可以根据模式来进行特定的文件，就可以看到jason来进行配置。自己的编译器跳转起来就比较好做了。
5.代码调试
文档里有很多调试方法，比较推荐的是用GDB调试。后面有机会进行展示。
6.如何使用自己的二进制部署OceanBase
还有一个是用自己的二进制部署OceaoBase。这个有很多方法，第一个是用OBD来衬着，可以把一个集群的差点部署，也可以装一些其他的东西。根据自己的二进制打很多的镜像。后面会推荐第二种方法，这个还在放一个利于数据开发的脚本。后面的脚本放出来就比较容易。
第二个脚本，OBD点会做一个事情就是首先要做的事编译，是把它装在自己的目录下面，和刚刚用自己系统下的目录不一样，会提前装，然后通过一些指令来。之前装的两个就重新配置。
还有一个方法做测试的时候一种暴力的方式点杠直接去跑，这种方式比较暴力，通过点节点，应付比较见方的场景是没有问题的。但后期的维护不太好处理。
7.编写 mysqltest
还有一种方法就是编写mysqltest，写了一些应用或者复杂函数，需要使用新的test或者unitest来测试一下自己的编写过程中的问题。
我们来找一个test软件，它其实是有一个要写点test的软件，一些思考语句传给mysqltest，然后需要写一个result结果集。通过OBD语句来跑这个test，看结果是否对应。
这两个必须在前一个目录下面写对位置。
8.编写unittest
unittest首先编译，然后跑所有的，可以在自己相应的模式下写编译后点杠执行文件来做这件事情。
其实这里就装了两个OB，在编译的时候重新部署集群。
就会把刚才生成的二进制再复制一遍在这个目录下面重新启动集群，没事的时候可以改改就会看到产生的边缘化。或者是用工具来做代码。
9.如何向 OceanBase 贡献源代码
最后如何像OB贡献代码，大部分资源都可以签订协议，是一个依属，或者找一个现有的也可以，如果是一个比较大的想和官方讨论一下、系统变量或者一些需要申请的项目，然后OB的开发就会进行讨论，最后让一些基本的例子，最后提交，签订协议。可以关联它的评论用井号关联，没问题OB的官方就会合到内部然后一起讨论，会花一到十个工作日，放了一个链接可以看看如何向OB贡献源码。输入q
以上就是架构和开发技巧的内容。
