下载文档原格式
OceanBase概述一、介绍OceanBase是一款分布式关系型数据库管理系统（RDBMS），由中国阿里巴巴集团自主研发并维护。
它致力于为全球用户提供高性能、高可用、高可靠的数据存储服务，以满足企业级应用对数据的存储和管理需求。
OceanBase的出现，填补了我国在数据库领域的空白，标志着我国在数据库核心技术上的重大突破。
二、发展历程OceanBase的发展历程可以追溯到2010年，当时阿里巴巴集团为了解决“双十一”购物狂欢节期间的大规模数据处理问题，开始研发一款全新的数据库系统。
经过多年的发展和完善，OceanBase已经成为了全球领先的分布式关系型数据库管理系统之一。
三、技术特点1. 分布式架构：OceanBase采用分布式架构，可以横向扩展，支持海量数据的存储和处理。
2. 高可用性：OceanBase具有高可用性，通过数据复制和故障切换技术，确保数据的可靠性和业务的连续性。
3. 高性能：OceanBase具有高性能，通过优化的数据存储和查询算法，提供快速的数据处理能力。
4. 多租户支持：OceanBase支持多租户模式，可以为多个用户提供独立的数据空间，保证数据的安全性和隐私性。
四、应用场景OceanBase广泛应用于各种场景，包括电商、金融、物流、教育、医疗等领域。
例如，它可以作为电商平台的后台数据库，支持每秒处理数百万笔交易；也可以作为金融机构的数据中心，存储和处理大量的金融交易数据；还可以作为物流公司的订单管理系统，支持实时的订单处理和追踪。
五、未来展望随着大数据和云计算技术的发展，OceanBase将继续发挥其分布式数据库的优势，提供更加强大和灵活的数据存储和处理能力。
同时，OceanBase也将积极探索新的技术领域，如人工智能、物联网等，以推动数据库技术的进一步发展。
六、总结OceanBase作为我国自主研发的分布式关系型数据库管理系统，不仅在技术上具有领先优势，而且在实际应用中也展现出了强大的能力。
oceanbase 级别定义
OceanBase是阿里巴巴开发的一种分布式关系型数据库管理系统。
在OceanBase中，有几种不同的级别定义，包括事务级别、隔离级别和日志级别。
首先，让我们来看看事务级别。
在OceanBase中，事务级别定义了事务的隔离程度和并发控制的方式。
OceanBase支持四种事务级别，分别是READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。
每种级别都有不同的特点和适用场景，可以根据实际业务需求进行选择。
其次，隔离级别是指在并发执行的事务中，一个事务对数据的修改在另一个事务中是否可见。
OceanBase支持的隔离级别包括READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。
不同的隔离级别对并发控制有不同的要求和影响，可以根据业务需求和性能要求进行选择。
最后，日志级别是指数据库系统记录和输出日志的详细程度。
在OceanBase中，日志级别包括ERROR、WARN、INFO和DEBUG。
不同的日志级别对系统性能和故障排查有不同的影响，可以根据实际
情况进行配置和调整。
总的来说，OceanBase的级别定义涵盖了事务级别、隔离级别
和日志级别，通过合理的配置和调整可以满足不同业务场景的需求，并提高系统的性能和稳定性。
oceanbase案例1. OceanBase是什么？OceanBase是一个完全自主研发的分布式关系型数据库系统，由中国互联网巨头阿里巴巴集团旗下的阿里云计算公司研发。
它主要基于阿里巴巴自研的分布式系统技术，并在此基础上融合了MySQL和Oracle等关系型数据库的特点，提供了高性能、高可用、高扩展性的数据库解决方案。
2. OceanBase的历史发展OceanBase的研发始于2015年，最初是为了满足阿里巴巴内部的大规模交易场景需求而开发的。
2017年，阿里云将OceanBase推向市场，并逐步推广至更广泛的用户群体。
截至目前，OceanBase已经成为了阿里云数据库的核心产品之一，并在金融、电商、物流等众多领域得到了广泛应用。
3. OceanBase的特点OceanBase具有以下特点：（1）高性能：OceanBase采用多副本、多节点的分布式架构，能够支持百万级的并发请求，并具备线性扩展性，能够轻松应对高并发的业务场景。
（2）高可用：OceanBase提供了多副本、自动分区、数据冗余等多种机制，保证了数据的高可用性，能够在节点故障或网络中断等情况下保证系统的正常运行。
（3）高扩展性：OceanBase支持线性扩展，可以根据业务需求动态扩容或缩容，从而满足企业快速发展的需求。
（4）全球分布：OceanBase支持全球数据分布，能够实现多地域数据备份和异地容灾，提高了数据安全性和可靠性。
（5）免费：OceanBase提供了免费版和企业版两种版本，免费版可以满足小型企业的需求，企业版则提供了更为完善的功能和技术支持。
4. OceanBase的应用场景OceanBase主要应用于以下场景：（1）电商：海量商品数据，高并发的交易场景，对数据库的性能和可靠性要求非常高，OceanBase能够满足这些需求。
（2）金融：金融领域对数据的安全和可靠性要求非常高，OceanBase提供了多副本、数据冗余、自动容错等多种机制，能够保证数据的高可用性和安全性。
如何基于OceanBase构建应用和数据库的异地多活OceanBase是一个通用的分布式的关系型数据库，有很多独特的特点。
比如数据库的多租户、高可用、极致弹性伸缩能力。
如果把OceanBase当作单库使用，就没有把OceanBase的分布式优势发挥到极致。
本文主要分享一个基于分布式架构的应用把OceanBase数据库的分布式优势发挥到极致所需要了解的OceanBase基础，这也是理解蚂蚁金服的基于OceanBase构建的三地五中心异地多活架构的基础。
分布式数据库开发相关问题好的性能首先是设计出来的，应用如果追求极致的性能，就需要关注OceanBase里数据的相关事情。
如：•数据如何分布？•数据如何读写？•存储容量瓶颈怎么办？•访问性能瓶颈怎么办？•数据库出故障时数据可用性和可靠性具体怎样？应用需要做什么特殊处理么？•数据库扩展时应用需要迁移数据么？数据迁移的时候对应用有什么影响？这些问题对理解OceanBase的分布式特点很有帮助。
后面我们逐步看看OceanBase是如何应对。
OceanBase集群外观首先简介一下OceanBase集群的外观。
图 1 OceanBase集群外观OceanBase是以集群形式运行的，由一堆服务器组成。
上图是「三副本」部署，机器会分为三组，每组一个区域（称为Zone），各个机器通过网络互相访问。
没有光纤交换机、共享存储以及直连网线等。
服务器通常建议CPU、内存和磁盘尽可能的大，磁盘建议用普通SSD盘。
普通服务器的好处是便宜，劣势是可靠性和性能可能不如小型机那么高。
也就是说OceanBase可以部署在一组可靠性和性能不是特别高的普通服务器上，却提供了高性能、高可用和高可靠、弹性伸缩等多项能力。
以上是一个OceanBase集群的外观和能力，但是提供给业务的并不是这个集群的全部资源和能力，而是其子集，即租户（T enant）。
OceanBase多租户特性OceanBase定义了一些基本的资源规格（Resource unit config，如4CPU8Gmem500Gdisk等），然后选取某类资源规格创建一组资源池（Resource Pool），此时集群资源就有一部分被分配出去了。
OceanBase 云平台（产品名称） 声明 产品版本：V1.0.0（软件版本）文档版本：20150122（发布日期）OBCP 实验指导手册｜产品版本：V 0.8.8声明蚂蚁集团版权所有 © 2020 ，并保留一切权利。
未经蚂蚁集团事先书面许可，任何单位、公司或个人不得擅自摘抄、翻译、复制本文档内容的部分或全部，不得以任何方式或途径进行传播和宣传。
商标声明及其他蚂蚁集团相关的商标均为蚂蚁集团所有。
本文档涉及的第三方的注册商标，依法由权利人所有。
免责声明由于产品版本升级、调整或其他原因，本文档内容有可能变更。
蚂蚁集团保留在没有任何通知或者提示下对本文档的内容进行修改的权利，并在蚂蚁集团授权通道中不时发布更新后的用户文档。
您应当实时关注用户文档的版本变更并通过蚂蚁集团授权渠道下载、获取最新版的用户文档。
如因文档使用不当造成的直接或间接损失，本公司不承担任何责任。
目录声明 (I)1.实验概述 (1)2.实验准备 (3)2.1.实验架构 (3)2.2.设备需求 (3)3.实验：OB分布式架构高级技术 (4)3.1.OB负载均衡 (4)4.实验：OB存储引擎高级技术 (21)4.1.内存管理 (21)4.2.合并与转储 (27)5.实验：OB SQL引擎高级技术 (31)5.1.SQL 引擎 (31)5.2.SQL 执行计划 (38)5.3.执行计划缓存 (47)6.实验：OB SQL调优 (54)6.1.分区 (54)6.2.索引、局部索引与全局索引 (60)6.3.Hint (65)6.4.SQL 性能监控 (68)7.实验：OB分布式事务高级技术 (72)7.1.全局快照与分布式一致性读 (72)8.实验：OBProxy 使用与运维 (78)8.1.OBProxy基础运维 (78)8.2.OBProxy 路由配置与运维 (80)9.实验：OB备份与恢复 (84)9.1.（逻辑）备份与恢复 (84)9.2.（物理）备份与恢复 (91)10.实验：OB 运维、监控 (98)10.1.用户管理 (98)10.2.日志管理 (103)10.3.日常运维操作 (108)10.4.数据监控 (113)10.5.灾难恢复 (117)3.实验：OB分布式架构高级技术3.1.OB负载均衡3.1.1.实验目的在这一章节的实验中，学员能够体验和理解OB负载均衡的主要特性，如下： ²表组特性下的资源分配²自动负载均衡²集群扩容²租户扩容²PrimaryZone 的设置3.1.2.实验准备进行负载均衡实验，每个 OB ZONE 中至少有两台 observer.步骤 1：完成基础的OB集群搭建，每个 Zone 先只有一个 observer3.1.3.实验步骤3.1.3.1 表组特性下的资源分配步骤 1：租户 obcp_t1下创建表分区mysql登录obcp_t1 租户，选择 test数据库use testcreate table t1 (c1 int,c2 int ) ;create table t2 (c1 int,c2 int ) primary_zone='zone2' ;create table t3 (c1 int,c2 int ) partition by hash (c1) partitions 3;查看表分区副本分布情况的统计：mysql> select tenant.tenant_name, zone, svr_ip,casewhen role=1 then 'leader'when role=2 then 'follower'else NULLend as role,count(1) as partition_cntfrom__all_virtual_meta_table meta inner join __all_tenant tenant onmeta.tenant_id=tenant.tenant_idinner join __all_virtual_table tab on meta.tenant_id=tab.tenant_id andmeta.table_id=tab.table_idwheretenant.tenant_id=<obcp_t1 ID>group by tenant.tenant_name,zone, svr_ip, 4order by tenant.tenant_name, zone, svr_ip, role desc;注： 实验环境中，创建的表分区的分布开始未必如以上这样均衡的， 负载均衡需要一些时间，待系统检测并自动分布。
oceanbase sql 执行计划解读OceanBase 是一个分布式关系数据库，其 SQL 执行计划是查询优化的核心。
执行计划描述了如何以最高效的方式执行 SQL 查询。
下面我将简要介绍OceanBase SQL 执行计划的解读。
1、执行计划概述执行计划是一个数据结构，它描述了数据库如何执行 SQL 查询。
执行计划由一系列操作组成，每个操作描述了数据库如何处理查询的一个部分。
执行计划是查询优化器生成的最佳执行计划，它旨在以最小化时间和资源消耗的方式返回查询结果。
2、执行计划的结构执行计划通常由多个操作组成，每个操作都有一个名称和一组属性。
操作名称描述了要执行的操作类型，例如选择、连接、排序、扫描等。
属性提供了有关操作的更多信息，例如要扫描的表、要连接的表等。
3、解读执行计划解读执行计划需要理解每个操作的意图和代价。
以下是一些常见的操作和它们的解读：（1）选择操作：选择操作用于过滤查询结果。
它基于指定的条件过滤行，并返回满足条件的行。
解读选择操作时，需要关注条件表达式和过滤的行数。
（2）连接操作：连接操作用于将两个或多个表中的行组合在一起。
它基于指定的连接条件将行匹配在一起。
解读连接操作时，需要关注连接类型（内连接、左外连接等）和连接条件。
（3）排序操作：排序操作用于对查询结果进行排序。
它根据指定的列或表达式对结果进行排序。
解读排序操作时，需要关注排序顺序（升序或降序）和使用的列或表达式。
（4）扫描操作：扫描操作用于读取表中的数据。
它可以是有索引扫描或全表扫描。
解读扫描操作时，需要关注要扫描的表、扫描方式（使用索引或全表）以及返回的行数。
4、评估执行计划评估执行计划是确定查询的效率和资源消耗的关键步骤。
评估执行计划时，需要考虑以下因素：（1）操作的顺序和类型：理解操作的顺序和类型有助于确定查询的复杂性和资源消耗。
（2）操作的代价：每个操作都有一个代价，包括CPU时间、I/O开销等。
了解操作的代价有助于确定查询的性能瓶颈。
oceanbase 并发参数
（原创版）
目录
1.介绍 OceanBase
2.OceanBase 的并发参数
3.结论
正文
1.介绍 OceanBase
OceanBase 是一个分布式关系型数据库，其设计目标是为了满足高并发、高可用性和低延迟等需求。
在金融、电商等对数据一致性和可用性要求高的场景中，OceanBase 都有着广泛的应用。
2.OceanBase 的并发参数
OceanBase 的并发参数主要包括以下几个：
- 并发度：这个参数决定了一个事务在执行过程中，可以同时执行的并发事务的数量。
并发度越高，系统的并发能力越强，但是过高的并发度可能会导致事务冲突，影响系统的可用性。
- 事务间隔：这个参数决定了一个事务在执行过程中，需要等待其他事务执行完成的时间间隔。
事务间隔越短，系统的并发能力越强，但是过短的事务间隔可能会导致事务冲突，影响系统的可用性。
- 锁等待时间：这个参数决定了一个事务在等待锁的时候，可以等待的最长时间。
锁等待时间越长，系统的并发能力越强，但是过长的锁等待时间可能会导致事务冲突，影响系统的可用性。
- 提交间隔：这个参数决定了一个事务在提交后，需要等待其他事务提交完成的时间间隔。
提交间隔越短，系统的并发能力越强，但是过短的提交间隔可能会导致事务冲突，影响系统的可用性。
3.结论
总的来说，OceanBase 的并发参数是一个重要的调节手段，可以通过合理设置并发参数，达到提高系统并发能力，保证系统可用性的目的。
OceanBase设计规范与数据架构指南文档修订历史1OceanBase1.0 简介自从E.F.Codd于1970年首次提出关系数据库模型后，关系数据库便以其易于使用的接口、完善的功能和生态而成为了IT领域必需的基础设施，广泛应用在各行各业，包括金融、电信、房地产、农林牧渔、制造业等等。
关系数据库经过了40多年的发展，涌现了Oracle、SQL Server、DB2等优秀的商业数据库产品，开源领域也不乏MySQL、PostgreSQL这样的精品。
但是，随着互联网行业和大数据的兴起，数据量和并发访问量呈现指数级的增长，囿于关系数据库的架构，原先运行良好的关系数据库遭遇了严峻的挑战：极度高昂的总体拥有成本、捉襟见肘的扩展能力、荏弱无力的大数据处理性能等等。
于是NoSQL应运而生，Hbase、Cassandra等系统如雨后春笋般冒出，这些系统多采取分布式架构，易于扩展及容灾，结合大数据处理系统如Hadoop 等，可以很容易处理量级非常大的数据，这一时让NoSQL风光无两，大有取代SQL之势，让人看不清NoSQL系统的边界。
很多公司尝试将核心系统迁移到新兴的NoSQL系统上，比如Facebook就尝试将部份核心系统迁移到Cassandra。
在迁移过程中，人们发现NoSQL所获得针对SQL的优势其实是以牺牲一些非常重要的功能来获取的，如NoSQL一般不支持事务或只支持非常有限的事务，这极大的增加了业务系统的复杂度，在传统的OLTP领域采取NoSQL系统基本上是不可以接受的。
阿里巴巴/蚂蚁金服的关系数据库使用场景极其严苛，有着全球最大的并发量需求，在可靠性方面需要做到单机、机架、机房甚至是地区级别的容灾恢复能力。
早期使用共享存储、小型机等高端硬件也只能部分满足我们在性能和可靠性上的需求，而且随着业务的发展，这种IOE架构很快就成为瓶颈。
我们能不能结合新兴分布式系统和传统关系型数据库的优点，既拥有传统关系型数据库在功能上的优势，同时具备分布式系统的可扩展性、高可靠性等特征？OceanBase即是以此为出发点，开始打造一个分布式关系型数据库。
OceanBase分布式技术架构分析目录OceanBase作为金融级分布式数据库一直备受瞩目 (3)1. 分布式存储&事务 (3)2. 分布式查询 (13)3. 经验&思考 (15)OceanBase作为金融级分布式数据库一直备受瞩目OceanBaseOceanBase 1.0项目从2013年初开始做总体设计，2014年开始编码、测试，2015年底正式上线并无缝迁移部分集团MySQL业务，直到2016年中才正式上线蚂蚁核心业务，包括会员视图、花呗、账务，等等，最后“丝般柔顺”地通过了2016年双十一大考。
从技术架构的角度看，一个分布式数据库主要就是两个部分：一个部分是怎么做存储，怎么做事务；另外一个部分是怎么做查询。
首先我们看第一个部分，主要是三个关键点：可扩展、高可用以及低成本，它们代表了OceanBase的核心技术优势。
1.分布式存储&事务第一我们怎么理解数据，如何把数据划分开来从而分布到多台服务器？这个问题其实传统关系数据库已经帮我们解决好了。
无论是Oracle还是MySQL，都支持一个叫做两级分区表的概念。
大部分业务都可以按两个维度划分数据：一个维度是时间，数据是按照时间顺序生成的；另外一个维度，对于互联网业务来讲，往往就是用户。
不同的用户生成不同的数据，不同用户之间的数据相关度比较低，而同一个用户的数据往往会被同时访问。
图1 OceanBase数据分布如图1，通过时间和业务主键两个维度将表格划分为P1~P8总共8个分区。
OceanBase 跟传统数据库不一样的地方在哪里呢？传统数据库所有的分区只能在一台服务器，而OceanBase每个分区可以分布到不同的服务器。
从数据模型的角度看，OceanBase可以被认为是传统的数据库分区表在多机的实现。
对于常见的分布式系统，要么采用哈希分区，要么采用范围分区。
OceanBase的数据划分方案和这些系统有较大的差别，通过两级分区表，我们可以把不同的用户，以及在不同时间点生成的数据全部融合到统一的表格里面。
无论这些分区在在多台服务器上是如何分布的，甚至可以对在线数据采用内存计算，对历史数据采用更高压缩率的压缩算法或者执行预计算，整个系统对使用者呈现的都是一张表格，后台实现对使用者完全透明。
当然，这里面还会有很多的工作要做。
第二点是我们底层的分布式架构。
图2 OceanBase整体架构图2是OceanBase整体架构图。
OceanBase架构图往往都是三个框框。
为什么这样呢？这是基于高可用考虑的。
为了实现机房故障无损容灾，OceanBase需要部署到三个机房。
每个机房又会有很多服务器，每台服务器又会服务很多不同的分区。
如图2， P1到P8代表不同的分区，每个分区有3个副本，分布在三个机房内。
用户的请求首先发给ObProxy。
ObProxy是一个访问代理，它会根据用户请求的数据将请求转发到合适的服务器。
ObProxy的最大的亮点在于性能特别好，我们对它做了非常多的针对性优化，使得它可以在非常一般的普通服务器上达到每秒百万级的处理能力。
ObServer是OceanBase的工作机，每台工作机服务一些分区。
与大多数分布式系统不同的地方在于，OceanBase这个系统没有单独的总控服务器/总控进程。
分布式系统一般包含一个单独的总控进程，用来做全局管理、负载均衡，等等。
OceanBase没有单独的总控进程，我们的总控是一个服务，叫做RootService，集成在ObServer里面。
OceanBase会从所有的工作机中动态地选出一台ObServer执行总控服务，另外，当总控服务所在的ObServer出现故障时，系统会自动选举一台新的ObServer 提供总控服务。
这种方式的好处在于简化部署，虽然实现很复杂，但是大大降低了使用成本。
接下来我们看整个数据库最核心的部分。
数据库最基础，也是最核心的部分是事务处理，这点对于多机系统尤其重要。
如果只是操作单个分区，因为单个分区一定只能由一台服务器提供服务，本质上是一个单机的事务，OceanBase的实现机制和Oracle、MySQL这样的传统数据库原理类似，也是多版本并发控制。
不同点在于，OceanBase做了一些针对内存数据库的优化，主要有两点：1.日志同步。
因为要做高可用，一定要做日志的强同步。
OceanBase之所以既能做到高可用，又能做到高性能，是因为我们做了很多针对日志强同步的优化，包括异步化、并行，等等；2.内存数据库。
OceanBase借鉴了内存数据库的设计思路，实现了无锁数据结构、内存多版本并发控制、SQL编译执行等优化手段。
如果操作多个分区，这又分成两种情况：1.多个分区在同一台服务器。
由于多个分区在一台服务器，本质上也是单机事务，实现方案与之前提到的单分区事务类似。
2.多个分区分布在多台服务器上。
由于多个分区跨ObServer，OceanBase内部通过两阶段提交实现分布式事务。
当然，两阶段提交协议性能较差，OceanBase内部做了很多优化。
首先，我们提出了一个表格组的概念，也就是说，我们会把多个经常一起访问，或者说访问模式比较类似的表格放到一个表格组里面。
与此同时，OceanBase后台会将同一个表格组尽可能调度到一台服务器上，避免分布式事务。
接下来的优化手段涉及到两阶段提交协议的内部实现。
两阶段提交协议涉及多台服务器，协议中包含协调者、参与者这两种角色，参与者维护了每台服务器的局部状态，协调者维护了分布式事务的全局状态。
常见的做法是对协调者记日志来持久化分布式事务的全局状态，而OceanBase没有这么做。
如果协调者出现故障，OceanBase通过查询所有参与者的状态来恢复分布式事务。
通过这种方式节省了协调者日志，而且只要所有的参与者都预提交成功，整个事务就成功了，不需要等协调者写日志就可以应答客户端。
OceanBase里面高可用是基于Paxos协议实现的。
Google Chubby系统的发明者说过一句话，这个世界上所有的高可用强一致的协议都是Paxos或者Paxos的变种，我们也认为一切不是Paxos协议实现的高可用机制都是耍流氓。
图3 OceanBase高可用原理如图3，OceanBase最底层的技术就是通过Paxos协议实现的分布式选举和多库多活。
Paxos协议的好处在于节点是多活的，当服务节点出现故障时，其它正常的节点可以在几秒内替代这个故障的节点，很快恢复服务，而且完全不丢数据。
Paxos协议同时实现了高可用和强一致，这是很牛的。
当然除了最底层核心的Paxos协议，OceanBase还会通过分布式调度将同一个分区的不同副本调度多多个机房，而不是在一个机房或者一个机架里面。
当服务器出现故障，OceanBase客户端能够很快自动感知到，并把服务切到没有故障的服务器上。
通过这一系列组合拳，OceanBase真正做到了持续可用。
图4 高可用：OceanBase VS Oracle图4是OceanBase和Oracle的高可用能力对比。
1.单个节点故障，相比Oracle RAC，OceanBase单个节点故障的影响会小一些，为什么？因为OceanBase的集群规模往往会比较大，单个节点的故障只影响很小一部分数据。
另外，OceanBase的恢复速度也会更快。
OceanBase采用基线加增量的存储引擎，最热的增量数据都是全部在内存的。
当主库出现故障，备库只需要把最后一部分未完成的日志回放出来就能够提供服务，非常快。
而Oracle底层存储是基于页面的，它需要逐步恢复页面，这个过程相对更长。
2.机房整体故障。
OceanBase在蚂蚁都是三机房部署的，当一个机房出现故障，OceanBase也能够做到几十秒恢复，和单个节点故障的恢复速度基本相当。
但是，传统的关系数据库，即使是Oracle也做不到，Oracle RAC不太可能部署到多个机房的。
接下来我们看看OceanBase的性能。
长远来看，性能取决于底层的引擎如何设计，而OceanBase的引擎跟传统数据库的引擎有较大的差别。
图5：两类数据库引擎在互联网里面能够看到各种各样的存储系统，引擎非常多，我认为基本可以分为两个大类。
如图5，第一类是传统关系数据库引擎。
关系数据库本质上是面向磁盘设计的，它把数据分成很多很多的页面，通过页面缓存机制来管理页面，底层的索引是B+树。
这种引擎发展得非常成熟，但是写入性能差，原因是关系数据库的写入放大效应。
用户数据是按行写入的，但是关系数据库却是按页面管理的，有时只写了一行数据，却不得不把整个页面刷入磁盘。
另外一类互联网公司流行的引擎是LSM树。
Google里面有一个很有名的开源系统LevelDB，Facebook基于它又开发了一个类似的系统RocksDB。
这种引擎采用基线加增量的设计，数据首先以增量的形式写入到内存中，当增量达到一个阀值时统一写到磁盘。
这种做法的好处是解决了关系数据库写入放大的问题，但是它的合并代价会比较大，可能出现合并速度赶不上内存写入的情况。
图6 OceanBase存储引擎OceanBase本质上是一个基线加增量的存储引擎，跟关系数据库差别很大，但是我们借鉴了传统关系数据库的优点对引擎进行了优化。
如图6，第一个优化就是合并性能的优化，传统数据库把数据分成很多页面，我们也借鉴了传统数据库的思想，把数据分成很多2MB 为单位的宏块。
执行合并时，如果只有一部分数据修改，那么，只需要合并那些修改过的宏块，而不是把所有没有修改的宏块也一起合并。
通过这个方式，OceanBase的合并代价相比LevelDB和RocksDB都会低很多，这是第一点。
第二，我们会利用OceanBase的分布式机制做优化。
在多机系统中，数据一定是存在多个副本。
OceanBase实现了一个称为轮转合并的机制。
当主副本提供服务时，其它副本可以执行合并；等到其它副本合并完成以后，原来的主副本接着合并，并把流量切到已经合并完成的副本。
通过这种方式，OceanBase把正常服务和合并时间错开，使得合并操作对正常用户请求完全没有干扰。
由于OceanBase采用基线加增量的设计，一部分数据在基线，一部分在增量，原理上每次查询都是既要读基线，也要读增量。
为此，OceanBase做了很多的优化，尤其是针对单行的优化。
OceanBase内部把很多小查询的结果缓存在内存里面，以行为单位，而不是以块为单位。
行缓存包括两个部分，如果这个行存在，缓存这个行的原始数据；否则，缓存布隆过滤器。
OLTP业务大部分操作为小查询，通过小查询优化，OceanBase避免了传统数据库解析整个数据块的开销，达到了接近内存数据库的性能。
另外，由于基线是只读数据，而且内部采用连续存储的方式，OceanBase可以采用比较激进的压缩算法，既能做到高压缩比，又不影响查询性能，大大降低了成本。
