« GS-00001 - GaussDB 100 OLTP第一号错误的诊断和解决 | Blog首页 | ORA-00600 KGLDELETEALLPINSONOBJ1 一个横贯10g/11g/12c的BUG »
笔记：从点滴讨论中看 OceanBase 的设计理念和架构
链接：https://www.eygle.com/archives/2019/11/oceanbase_design.html
说明：在知乎上看到关于 OceanBase 早期设计思想的讨论，整理和记录于此，是我的学习笔记。出处写在最前面。
来源：https://www.zhihu.com/question/19841579
以下一段是来自 阳振坤 老师的描述，时间是 2016-11-18，当年的双11购物节之后：
OceanBase分布式关系数据库渡过了一个成功的双十一：支持了支付宝核心的交易、支付、会员和账务等，并且创造了新的纪录：交易创建17.5万笔/秒、交易支付12万笔/秒、全天累计支付10.5亿笔！
其实，虽然不是刻意设计的，但OceanBase确实比传统数据库更适合像双十一、聚划算、秒杀以及银行国库券销售等短时间突发大流量的场景：
- 短时间内大量用户涌入
- 短时间内业务流量非常大，数据库系统压力非常大
- 一段时间（几秒钟、几分钟、或半个小时等）后业务流量迅速或明显回落
虽然2010年设计OceanBase架构时，其实并没有特别考虑到这个突发大流量的因素。
让我们从OceanBase的架构说起。
OceanBase是"基线数据（硬盘）"+"修改增量（内存）"的架构，如下图所示：
即整个数据库以硬盘（通常是SSD）为载体，新近的增、删、改数据（"修改增量"）在内存，而基线数据在保存在硬盘上，因此OceanBase可以看成一个准内存数据库。
这样的好处是：
- 写事务在内存（除事务日志必须落盘外），性能大大提升
- 没有随机写硬盘，硬盘随机读不受干扰，高峰期系统性能提升明显；对于传统数据库，业务高峰期通常也是大量随机写盘（刷脏页）的高峰期，大量随机写盘消耗了大量的IO，特别是考虑到SSD的写入放大，对于读写性能都有较大的影响
- 基线数据只读，缓存（cache）简单且效果提升
- 线上OceanBase的内存配置是支撑平常两天的修改增量（从OceanBase 1.0开始，每台OceanBase都可以写入，都承载着部分的修改增量），因此即使突发大流量为平日的10-20倍，也可支撑1~2个小时以上。
一个问题是：修改增量在内存，大概需要多大的内存？
即使按双11全天的支付笔数10.5亿笔，假设每笔1KB，总共需要的内存大约是1TB，平均到10台服务器，100GB/台。
另一个问题是：
在类似双十一这种流量特别大的场景中，就像前面说到的，OceanBase内存能够支持峰值业务写入1~2个小时以上，之后OceanBase必须把内存中的增删改数据（"修改增量"）尽快整合到硬盘并释放内存，以便业务的持续写入。
整合内存中的修改增量到硬盘，OceanBase称为每日合并，必然涉及到大量的硬盘读写（IO），因此可能对业务的吞吐量和事务响应时间（RT）产生影响。如何避免每日合并对业务的影响呢？OceanBase通过"轮转合并"解决了这个问题。
众所周知，出于高可用的考虑，OceanBase是三机群（zone）部署：
根据配置和部署的不同，业务高峰时可以一个机群（zone）、两个机群（zone）或者三个机群（zone）提供读写服务。OceanBase的轮转合并就是对每个机群（zone）轮转地进行每日合并，在对一个机群（zone）进行每日合并之前，先把该机群（zone）上的业务读写流量切换到另外的一个或两个机群（zone），然后对该机群（zone）进行全速的每日合并。
因此在每日合并期间，合并进行中的机群（zone）没有业务流量，仅仅接收事务日志并且参与Paxos投票，业务访问OceanBase的事务响应时间完全不受每日合并的影响，仅仅是OceanBase的总吞吐量有所下降：如果先前是三个机群（zone）都提供服务则总吞吐量下降1/3，如果先前只有一个或两个机群（zone）提供服务则总吞吐量没有变化。
轮转合并使得OceanBase对SSD十分友好，避免了大量随机写盘对SSD寿命的影响，因此OceanBase可以使用相对廉价的"读密集型"SSD来代替传统数据库使用的相对昂贵的"读写型"SSD，而不影响性能。
此外由于轮转合并对服务器的CPU使用、硬盘IO使用以及耗时长短都不敏感（高峰期的传统数据库在刷脏页的同时还要优先保证业务访问的吞吐量和事务响应时间，刷脏页的CPU及IO资源都非常受限），因此OceanBase在每日合并时可以采用更加高效的压缩或者编码算法（比如压缩或编码速度略慢，但压缩率较高、解压缩很快的算法），从而进一步降低存储成本并提升性能。
在2019年10月，OceanBase 发布了 TPCC 超越 Oracle 之后，阳振坤老师发表如下声明和文章，描述 TPCC-C 测试历程。
跑TPC-C benchmark是不限制硬件的，只要你能通过其中的事务ACID测试和其他的一些测试，无论你用什么硬件，跑出好成绩就是英雄（反过来呢？恐怕只能是狗熊了）。
自从2010年Oracle以3000万tpmC登顶至今，9年时间新跑出了十几个TPC-C benchmark，但没有一个打破这个记录。
难道其他数据库厂商不想打破这个记录？
肯定有在想的。
9年时间难道硬件性能没有提升吗？
假如摩尔定律依然适用，处理器的性能应该提升了2^^6=64倍，就算摩尔定律已经失效，9年时间硬件性能的提升也小不了，怎么区区一个3000万tpmC还干不掉？
就像博尔特2009年创造的100米短跑9秒58世界记录，10年都过去了，全世界最优秀的短跑选手想不想打破这个记录？
做梦都想啊，可就是破不了啊。
为什么呢？
因为
第一，研制OLTP数据库太难了，
第二，通过TPC-C的测试也很难。比如ACID测试，全世界的分布式数据库，能够通过这个测试的，我知道的只有Google的Spanner和阿里巴巴/蚂蚁金服的OceanBase，也许还有一些我不知道的，但肯定不会多，否则Oracle的3000万tpmC早就被干翻了。
国内除了OceanBase之外没有任何一个数据库通过测试，多少也说明一些问题。所以，TPC-C benchmark是不限制硬件的，你用多好的硬件都可以。当然为了一定程度的公平性，TPC-C还要求测试者必须报告成本（被测系统3年的total cost of ownership）以便计算性价比。所以总体来看，TPC-C是首先鼓励你通过测试，其次才是披露性价比。
为了便于感兴趣的朋友进一步了解TPC-C测试，我们把OceanBase做TPC-C benchmark测试过程中的感受和体验写了出来，供大家参考。
-
定义了被测系统的功能要求而不是软件硬件本身 -
规定了被测系统的扩展准则，即性能与数据量相匹配 -
规定被测系统的事务需要在指定时间内完成（比如95%事务在1s内完成） -
把被测系统的整体成本纳入性能benchmark
- 首先，作为一个OLTP联机交易处理系统的benchmark，TPC-C要求被测数据库必须满足数据库事务的ACID，即原子性、一致性、隔离性和持久性，其中隔离性为可串行化隔离级别，持久性要求能够抵御任何单点故障等。很显然，这是对一个OLTP数据库的基本要求。在分布式环境下，TPC-C的两种主要事务，订单创建（new order）和订单支付（payment），分别有10%和15%的分布式事务（最多可能分布在15个节点上），事务的ACID对于分布式数据库是很大的挑战，尤其是可串行化的隔离级别，这也是至今鲜少分布式数据库通过TPC-C测试的主要原因之一。国内有些厂商混淆分布式数据库的概念，把多个单机数据库堆在一起而号称分布式数据库，事实上，尽管每个单机数据库都满足ACID，但这些堆放在一起的多个单机数据库作为一个整体并不满足ACID。
- 其次，TPC-C规定被测数据库的性能（tpmC）与数据量成正比，事实上真实业务场景也是如此。TPC-C的基本数据单元是仓库（warehouse），每个仓库的数据量通常在70MB左右（与具体实现相关），TPC-C要求终端用户在选择事务类型时，需要按照规定的比例选择五种事务，终端用户每个事务都有一定的输入时间（对每种事务分别固定）和一定范围的随机的思考时间（一个对数函数），根据这些要求，每个仓库所能获得的tpmC上限是12.86（假设数据库的响应时间为0）。假设某系统获得150万tpmC，大约对应12万个仓库，按70MB/仓库计算，数据量约8.4TB，而TPC-C同时要求系统具备60天、每天压测8小时的存储容量，因此系统的存储容量可能要30TB或更多，而某些厂商用几百或几千个仓库全部装入内存，无视单个仓库的最大tpmC上限，然后号称获得百万tpmC，不仅不符合大多数真实业务场景，而且明显违反了TPC-C规范，就像当年TPC组织成立之前一些公司的所作所为一样。
- 第三，TPC-C要求被测数据库能够以平稳的性能长期地运行。测试时，去掉启动预热（ramp up）和结束降速（ramp down）时间后，被测数据库至少要性能平稳地（steady state）运行8小时，其中性能采集时段（不少于2小时）内的性能累积波动不得超过2%。众所周知，各种计算机系统在极限压力下性能会产生较大的波动并可能被压垮而崩溃，为了避免被压垮，实际生产环境从来不会让系统处于极限压力，TPC-C这个规定正是从实际生产需求出发的。此外，TPC-C要求被测数据库长时间运行，同样是实际生产系统的要求。某些数据库厂商让数据库在很短时间内冲击性能的一个尖峰值，既没有保证数据库在较长时间内稳定运行，更谈不上性能波动不超过2%，但却声称自己的数据库达到了这个尖峰性能。本次benchmark测试中，OceanBase做到了8小时性能波动低于0.5%。
- 第四，TPC-C要求被测数据库的写事务的结果必须在一定时间内数据落盘（指数据库数据，不是日志，事实上redo log在事务提交前就落盘了），对于具备checkpoint功能的数据库，checkpoint的间隔不得超过30分钟，checkpoint数据持久化的时间不得超过checkpoint间隔。我们理解这是为了保证数据库系统在掉电等异常情况下有较短的故障恢复时间。传统数据库的数据以数据块(例如4KB/8KB的page/block)为基本单位，做到这个是把脏页刷盘。但OceanBase并非如此，这是因为，第一OceanBase是多副本（本次测试是3副本）的跨机器部署，单机器异常的情况下都能够立即恢复（RTO=30s）且数据无损（RPO=0），并不依赖于写事务的数据落盘；第二个原因：OceanBase是"基线数据在硬盘+修改增量数据在内存"的结构，设计上是修改增量数据一天落盘一次（即每日合并，可根据业务量的增加而自动增加每日合并次数），实际生产系统不需要也不依赖数据在较短时间（比如30分钟）内落盘。在TPC-C benchmark测试中，OceanBase设置了checkpointing，保证所有checkpoint的间隔小于30分钟，并使得checkpoint数据持久化的时间小于checkpoint间隔，以符合TPC-C规范。
- 第五，业务定向优化（profile-directed optimization，PDO）可以提升软件的性能，TPC-C也允许使用PDO，但有一些限制，比如采用PDO优化的版本需要在客户使用，数据库厂家需要对PDO优化的版本提供技术支持等。为了避免可能出现的异议，OceanBase没有使用PDO。
- 最后，TPC-C规范虽然十分严格，但依然鼓励新技术和新方法的使用，比如本次OceanBase的TPC-C benchmark测试，就没有像之前的TPC-C benchmark一样购买物理服务器和存储，而是租用了阿里云公有云的ECS虚拟机，这不仅使得扩容/缩容轻而易举，还可按需租赁而极大降低实际测试成本。
该帖子之中，还讨论了 OceanBase 如下的优点，继续记录引用：
- 1. OB的redolog是使用分布式一致性算法paxos实现的。所以在CAP理论中，虽然OB使用的是强一致模型，但是OB能在一定网络分区的情况下做到高可用（通俗点讲就是多余半数机器还活着的时候就能干活）。
- 2. OB的存储结构使用的是两级的LSM-tree。其中内存中的C0 Btree叶节点不需要和磁盘上的btree一样大小，所以能做得比较小，对cpu的cache比较友好，并且不会有写入放大的问题。使得OB的写性能有极大的提升。同时磁盘上的C1 tree不是一个传统意义上的btree（btree未经压缩可能浪费一半空间）。空间利用率大大提高。简单来说就是速度快，省成本。这里说的比较粗略，想详细理解自己去看LSM-tree的论文。
- 3. 数据库自动分片功能（支持hash/range，一级二级等等分片方式），提供独立的proxy路由写入查询等操作到对应的分片。这意味着数据量再大也不需要手动分库分表了。并且分片能在线的在各个server之间迁移，解决热点问题（资源分配不均的问题，做到弹性加机器和减机器）。每个分片（确切的说是被选为主的分片）都支持读写，做到多点写入（高吞吐量，性能可线性扩展）。
- 4. 数据库内部实现的无阻塞的两阶段提交（跨机事务）。参见论文Consensus on Transaction Commit
- 5. 数据库原生的多租户支持。能直接隔离租户之间的cpu，mem，io等资源。
- 6. 基于代价的SQL查询优化和改写功能，对于复杂的分析型SQL做得比MySQL好（目前比Oracle差，正在努力追赶中）。支持各种类型的join算法（nestloop, merge, hash），优化器会自动选择最优的join类型。支持类似Oracle的SPM功能，用户能很轻松自如的管理查询计划。
- 7. 自动化的集群管理，包括机器上下线，自动下故障盘等等。总之OB的设计理念就是只要是数据库需要解决的问题就不让用户操心。
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实现异地多活的情况下，每天的数据调度、合并需要占用大量的网络资源。
历史上的今天...
>> 2013-11-27文章:
>> 2008-11-27文章:
>> 2007-11-27文章:
>> 2006-11-27文章:
By eygle on 2019-11-27 21:57 | Comments (0) | OraNews | 3377 |