淘宝研发的 OceanBase 相比其他开源的 noSQL 数据库有什么独特的优点？ 第1页

每年刷新的双十一交易量，对任何技术人员来说都是全新的挑战。资料显示，Visa最新的实验室测试数据是5.6万笔/秒，另一家全球性支付清算平台MasterCard的实验室测试数据为4万笔/秒，在实际应用中，Visa处理的峰值为1.4万笔/秒。而淘宝2015年双十一最高8.5万笔/秒的交易量，就已经刷新交易峰值世界记录。

在这些成绩的背后，阿里巴巴云数据库OceanBase功不可没。

那么，什么是OceanBase？▼

OceanBase是阿里巴巴自主研发的一个支持海量数据的高性能分布式数据库系统。与其他数据库系统不同，OceanBase诞生之际就面临一个与众不同的挑战：互联网企业的并发访问量非常大。

传统商业企业、银行，用户需要通过收银台、银行终端、ATM柜员机、POS机等专用设备开展业务并访问数据库，几百和几千的数据库并发访问比较常见，几万以上的并发访问相当少。

互联网商务和互联网金融则呈现明显的草根特征，每个使用者都会直接导致数据库的访问，各种促销活动更是使得几十万、几百万甚至千万的用户在较短时间内去购买商品并支付，从而产生几十万、几百万、甚至几千万的数据库并发访问。

由于单一共享存储的约束，传统数据库通过增加数据库主机而得到的扩展能力有限且对应的成本十分高昂，无法满足互联网商务和互联网金融对数据库的容量和性能的需求。

OceanBase又是如何解决这些问题？小智尝试从扩展性、成本、可靠性、性能、数据一致性五个方面，对OceanBase的相关信息进行一次全面梳理。

一、高扩展性

传统关系型数据库，比如Oracle或者MySQL功能已经很完善，但数据库本身不可扩展，随着数据量的增大和业务内容的丰富，需要拆库拆表，然后再进行访问路由，将相应的SQL解析路由到指定的数据库中。数据库的运维人员需要花费大量的时间来做数据库扩容，包括读写分离、垂直拆分、水平拆分等等。

OceanBase使用了分布式技术和无共享架构，来自业务的访问会自动分散到多台数据库主机上。在相关技术的支持下，OceanBase还能够采用廉价的PC服务器作为其数据库主机。通过这两个方面的变革，运维人员可以愉快地通过增加服务器数量来增加系统的容量和性能。（PC服务器的价格也比小型机、大型机低很多）

即使是遇到双十一这种并发访问量超级高的需求，阿里也可以通过“买买买”的方式，确保数据库系统拥有足够的容量和性能。

退一万步说，就算马老板不同意为新的服务器买单，技术团队也可以通过提前调度阿里云服务器资源的方式，储备足够的应对能力。双11过后，又能快速归还，避免资源的闲置浪费。

二、低成本

传统商业企业采用的“IOE”体系，实际上代表了一种高成本、高维护费、很不互联网(不擅长处理大规模高并发的互联网行为)的商用数据库系统。特别是阿里盘子越来越大，所需要付出的升级硬件和维护的代价也会越来越惊人，阿里巴巴采用数据切分的策略，将部分海量数据应用从集中式Oracle切换到分布式集群，从纵向扩展到水平扩展，解决了数据库扩展性的问题，并用PC服务器替换了小型机。

由此带来的一个重要变革，就是成本的极大降低。与传统数据库公司的产品相比，OceanBase的升级维护不需要昂贵的共享存储、高可靠的服务器、数据库软件的许可费，可以将商业数据库成本降到一半以下。

伴随着去IOE运动的全面开展，收入方面也诞生了新的机会：为应对海量高并发业务而采购的PC服务器资源，在低峰可以打包成云计算产品出租给中小企业，在一定程度上抵消了一部分日常运维成本，甚至还有可能带来盈利，真正意义上实现开源、节流的双向拓展。

三、高可靠性

数据库系统通常由数据库软件、运行数据库软件的数据库服务器硬件以及保存数据库数据的数据库存储硬件(即共享存储)组成。数据库系统的稳定可靠，也取决于这三个部分。使用PC服务器能够带来高扩展性、降低成本的同时，其硬件的可靠性却对应有些下降。

如何保证系统的可靠性？OceanBase的一个基本假设就是硬件(服务器、存储、网络等)是不可靠的，因此，OceanBase必须保证任何时刻出现的少量硬件(服务器、存储、网络等)异常不影响业务。

为此，OceanBase引入了Paxos协议，每一笔事务，主库执行完成后，要同步到半数以上库(包括主库自身)，例如3个库中的2个库，或者5个库中的3个库，事务才成功。这样，少数库(例如3个库中的1个库，或者5个库中的2个库)异常后业务并不受影响。

分布式事务一致性协议paxos主要用于保证一个数据在分布式系统里是可靠的。当在机器里多数派都成功了之后，只要坏的机器是少数派，三个里少数派是一个，多数派是两个。三个机器里面有两个成功了，那就可以告诉用户这个数据保证不会丢了。这个时候机可能会损坏，但是损坏任何一台机器，至少还有另外一台机器恢复过来，这是在系统内部自动去做容灾。任何一台机器坏了，或者有一台机器落后，比如三个及其是一主拖着另外两个成功了之后，就会把数据补上，肯定会保证另外两份是OK的，最终三份是OK了，坏一台机器都不会有问题。

软件层面，OceanBase区别于传统数据库的一个关键特征是软件版本的灰度升级。

主备方式的传统数据库是“单活”的，只有主库可执行写事务，尽管维护升级时可以先操作备库，操作完成后备库变成主库并且接受用户访问是一步到位的，如果新版本有问题，则业务受到影响：

传统数据库：升级前

传统数据库：升级中

传统数据库：升级后只能一次性地引入全部读写流量

OceanBase则是“多活”设计，即多个库（3个，5个等）每个都可以有部分读写流量，升级时先把要升级的库的读写流量切走，升级后先进行数据对比，正常后逐步引入读写流量，一切正常并运行一段时间后再升级其他的库：

OceanBase之3机群(3库)部署：升级前

OceanBase之3机群(3库)部署：切走读写流量，准备升级

OceanBase之3机群(3库)部署：升级一个机群(库)

OceanBase之3机群(3库)部署：升级一个机群(库)后切回部分读写流量

OceanBase之3机群(3库)部署：升级一个机群(库)后切回全部读写流量

基于硬件不可靠的假设并且能够容忍少量服务器的故障，OceanBase使用了相对廉价的PC服务器代替高可靠服务器并且不再使用昂贵的共享存储，从而不仅提供了比使用高可靠服务器和共享存储低得多的成本，容忍少数服务器乃至少数机群故障意味着比传统数据库更高的可靠性。

通过灰度升级，OceanBase避免了传统数据库的“一锤子买卖”的升级，极大地降低了数据库维护升级的风险。

四、数据准确性

许多的互联网服务可以允许有一定的数据差错，但是电子商务(如交易、金融领域等)与一般的互联网公司不太一样，它对于数据的一致性要求非常高，比如要确保钱的进入与流出要对得上账，不能丢失任何一条支付数据（阿里巴巴将OceanBase用于支付宝系统）。

OceanBase设计与经典关系数据库有所不同，其读事务基本是分布式并发执行的，写事务目前是集中式串行执行的，即serializable，且任何一个写事务在commit之前对其他读写事务都是不可见的，因此OceanBase是强一致的。这样，在设计方案上能够保证不丢数据。

几种常见的一致性类型有：

强一致性：系统中的某个数据被成功更新(事务成功返回)后，后续任何对该数据的读取操作都得到更新后的值。这是传统关系数据库提供的一致性模型，也是关系数据库深受人们喜爱的原因之一。

弱一致性：系统中的某个数据被更新后，后续对该数据的读取操作得到的不一定是更新后的值，这种情况下通常有个“不一致性时间窗口”(inconsistency window)存在：即数据更新完成后在经过这个“不一致性时间窗口”，后续读取操作就能够得到更新后的值。

最终一致性：属于弱一致性的一种，即某个数据被更新后，如果该数据后续没有被再次更新，那么最终所有的读取操作都会返回更新后的值。（如果主备库数据同步存在时间差，一旦主机出现异常，恢复无法实时进行，同样有可能会出现数据一致性问题）

如图，上述三个机群构成一个数据库，其中一个是主机群，所有事务都由主机群的UpdateServer(称为主UpdateServer，其他UpdateServer称为备UpdateServer)执行，事务的redo log同步到3个UpdateServer中的超过半数(即至少2个，包括主UpdateServer自己)，则事务成功并应答客户。由于集群中只有一台主UpdateServer提供写服务，因此，OceanBase也很容易地实现了跨行跨表事务。

如果3个UpdateServer中有一个故障： *主UpdateServer故障：剩余的两个UpdateServer会自动选举出一个新的主UpdateServer(参见后文“OceanBase分布式选举的实现”)，由于旧的主UpdateServer数据至少在一个活着的UpdateServer中存在，因此数据不会有任何丢失，两个活着的UpdateServer经过很短时间(通常是毫秒级)的相互同步后就可以继续对外服务，保证了数据的一致性和服务的高可用。 *单个备UpdateServer故障：主UpdateServer有全部数据，剩余两个UpdateServer仍然超过半数，数据一致性和服务都不受任何影响。

（如果把上述三个机群部署出于三个不同的机房，那么即使一个机房出现电源、网络或者空调等故障，剩余两个机群仍然能够继续工作，数据一致性和服务可靠性都不受影响。）

然而，TCP协议传输、磁盘读写都可能出现数据错误，程序Bug则更为常见。为了防止各种因素导致的数据损毁，OceanBase采取了以下数据校验措施：

数据存储校验。每个存储记录（通常是几KB到几十KB）同时保存64位CRC校验码，数据被访问时，重新计算和比对校验码。

数据传输校验。每个传输记录同时传输64位CRC校验码，数据被接收后，重新计算和比对校验码。

数据镜像校验。UpdateServer在机群内有主UpdateServer和备UpdateServer，集群间有主集群和备集群，这些UpdateServer的内存表（MemTable）必须保持一致。为此，UpdateServer为MemTable生成一个校验码，MemTable每次更新时，校验码同步更新并记录在对应的操作日志中。备UpdateServer收到操作日志并重放到MemTable时，也同步更新MemTable校验码并与接收到的校验码对照。UpdateServer重新启动后重放日志恢复MemTable时也同步更新MemTable校验码并与保存在每条操作日志中的校验码对照。

数据副本校验。定期合并时，新的子表由各个ChunkServer独立地融合旧的子表中的SSTable与冻结的MemTable而生成，如果发生任何异常或者错误（比如程序bug），同一子表的多个副本可能不一致，则这种不一致可能随着定期合并而逐步累积或扩散且很难被发现，即使被察觉，也可能因为需要追溯较长时间而难以定位到源头。为了防止这种情况出现，ChunkServer在定期合并生成新的子表时，也同时为每个子表生成一个校验码，并随新子表汇报给RootServer，以便RootServer核对同一子表不同副本的校验码。

五、高性能

OceanBase架构的优势在于既支持跨行跨表事务，又支持存储服务器线性扩展。当然，这个架构也有一个明显的缺陷：UpdateServer单点，这个问题限制了OceanBase集群的整体读写性能。为了在高扩展性、低成本、高可靠性、数据一致性的基础上实现高性能，OceanBase在数据访问方面与传统数据库有很大的不同。

和很多行业一样，虽然数据总量非常大，但是淘宝业务一段时间 (例如小时或天)内数据的增删改是有限的(通常一天不超过几千万次到几亿次)，根据这个特点，OceanBase把一段时间内的增删改等修改操作以增量形式记录下来，这样也使得了主体数据在一段时间内保持了相对稳定(称之为基准数据)。

由于增量数据相对较小，通常情况下，OceanBase把它保存在独立的服务器UpdateServer的内存中。以内存保存增删改记录极大地提高了系统写事务的性能。不仅如此，由于冻结后的内存表不再修改，它也可以转换成sstable格式并保存到SSD固态盘或磁盘上。转储到SSD固态盘后所占内存即可释放，并仍然可以提供较高性能的读服务，这也缓解了极端情况下UpdateServer的内存需求。

为什么要做这件事情呢？现在的存储，不管是磁盘或SSD，顺序写的性能远远大于随机写。现在SSD稍微好一些，随机写也可以相对高一些，但是无论如何都跟顺序写这样的硬件属性在性能上有数量级的差别。OceanBase用磁盘存储数据库，但用内存数据库、SSD(普通磁盘最怕随机读，但SSD很适合)来存储修改数据。还消除了随机写磁盘，批量来写入。实现扬长避短，最大化发挥了硬件的特性。

数据分成基准数据和增量数据之后，增量数据每天都在增加，必须合到基准数据里面去。OceanBase每天一次真正同步修改到磁盘上修改增量融合也采用了多库异步的方式，同时会选择一个低负载时段进行数据的合并操作，避免了对业务的影响。（淘宝数据很明显，因为用户都是在一个地域之内的，所以他有一个明显的高峰和低谷）

在每日数据合并上，OceanBase也做了优化，采用了更细粒度的分片，把数据分块，如果某块数据发生更改，只对这条数据进行重写即可。以块为单位来设计的数据库则很难做到这一点的。

六、总结一下

传统DBMS提供了强大的事务性、良好的一致性和很短的查询修改响应时间，但数据规模受到严重制约，缺乏扩展性;现代云计算提供了极大的数据规模、良好的扩展性，但缺乏跨行跨表事务、数据一致性也较弱、查询修改响应时间通常也较长，OceanBase的设计和实现融合了二者的优势：

UpdateServer：类似于DBMS中的DB角色，提供跨行跨表事务和很短的查询修改的响应时间以及良好的一致性。

ChunkServer：类似于云计算中的工作机(如GFS的chunk server)，具有数据多副本(通常是3)、中等规模数据粒度(tablet大小约256MB)、自动负载平衡、宕机恢复、机器plug and play等特点，系统容量及性能可随时扩展。

MergeServer：结合ChunkServer和UpdateServer，获得最新数据，实现数据一致性。

RootServer：类似于云计算中的主控机(如GFS master)，进行机器故障检测、负载平衡计算、负载迁移调度等。

上述的DBMS和云计算技术的优势互补使得OceanBase既具有传统DBMS的跨行跨表事务、数据的强一致性以及很短的查询修改响应时间，还有云计算的海量数据管理能力、自动故障恢复、自动负载平衡以及良好的扩展性。

目前来看，制约OceanBase能力发挥的因素，已经从服务器、数据库软件、存储转变为是高昂的网络带宽成本和数据中心PUE（Power Usage Effectiveness，大量PC服务器负载的能耗量十分庞大），尤其是实现OceanBase实现异地多活的情况下，每天的数据调度、合并需要占用大量的网络资源。

你们猜，下一步阿里会不会自己搞一个量子通信网络，或者开发一两套数据中心能耗管理系统？

*本文根据阳振坤博士等人演讲内容或网络公开资料整理而成，作为学习之用。如有疏漏，敬请指正。