阿里高性能数据库OceanBase架构初探
OceanBase（中文名"海钡云"）是阿里巴巴/蚂蚁金服自主研发的面向云时代的关系数据库，目前，OceanBase已经应用于蚂蚁金服会员、交易、支付、账务、计费等核心系统和网商银行等业务系统，同时也支撑着双11用户每一笔订单背后的数据和事务处理，在阿里电商、金融、云服务领域大放异彩。
- 可扩展，分布式系统，支持ACID、无缝扩容，兼具分布式系统与关系型数据库的优点。
- 高可用，具备多可用区部署能力， 可抵御少数可用区失败。
- 兼容MySQL协议。MySQL用户可以无缝切换。
- 支持多租户，在数据库进程层面作资源隔离，极高的资源整合度。
- 高性能，内存型数据库，充分利用SSD等新硬件。
- 诞生
随着淘宝业务的飞速发展，数百亿条记录、数十TB、数万TPS、数十万QPS这样的压力让传统关系数据库不堪重负，单纯的硬件升级以无法使问题得以解决，分表分库也总不是奏效，分库后分布式事务一致性性能低下等一系列问题。。
设计思路
思路1
常见的做法根据业务特点对数据库进行水平拆分，路由取模到不同数据库服务器上，这种思路的弊端：
1、节点动态伸缩很被动，操作复杂，往往需要人工介入；
2、多表关联查询、写入效率低下；
3、目前广泛的关系型数据库存储引擎是针对机械硬盘特点设计，无法发挥SSD（固态硬盘）高性能能力（传统硬盘包 含有一个物理读写头，一次可以跨多个物理盘片读取数据流。如果数据可以顺序读取（大的多媒体应用这种模式比较适合）如果读取数据要搜索盘片的多个扇区，那么传统硬盘读写头的性能会急剧下降。
与此相反，闪存驱动的物理构成就是成百上千个可以随机访问的块，是由分散的许多芯片组成的，读取哪一块的数据不会影响访问性能。随着SSD价格不断降低，容量和性能不断提升，SSD取代磁盘只是个时间问题。）
思路2
参考分布式表格系统做法，例如Google的Bigtable，HBase这种底层基于分布式文件存储架构的设计思路，将大表分为几十万、几百万个子表，子表之间按照主键有序，服务节点的动态伸缩对于调用者是透明的，解决了可扩展性问题，和范围查询问题。弊端是无法支持事务，Bigtable、HBase支持行锁级别保证原子性，不支持跨表跨行事务。如果在此基础上引入基于二阶段提交的分布式事务则会导致性能低下，这种思路在Google的Percolator系统中得到了体现，其平均响应时间2-5s！。
新的设计思路：
写操作放在updateServer单服务上，优先基于内存存储作为增量数据保存，由于一天的写操作不会很多，巧妙的支持了高并发下事务，同时ChunkServer保存全量基线历史数据，MergerServer合并数据，在读操作时，ChunkServer会和UpdateServer上数据合并再返回，同时，夜间低峰期主动和UpdateServer增量数据合并，保证UpdateServer服务高性能数据不会积压太多。
和传统关系数据库比较：
1、高可用方面：
高可用，具备多可用区部署能力， 可抵御少数可用区失败。强一致性同步，不丢失数据，满足了CA，基于分布式选举算法在故障节点出现后自动剔除选出新节点，分3机房部署。（Google Chubby系统的发明者说过一句话，这个世界上所有的高可用强一致的协议都是Paxos或者Paxos的变种）oracle RAC不支持跨机房部署。
2、数据库引擎:
第一类是传统关系数据库引擎。关系数据库本质上是面向磁盘设计的，它把数据分成很多很多的页面，通过页面缓存机制来管理页面，底层的索引是B+树。这种引擎发展得非常成熟，但是写入性能差，原因是关系数据库的写入放大效应。用户数据是按行写入的，但是关系数据库却是按页面管理的，有时只写了一行数据，却不得不把整个页面刷入磁盘。另外一类互联网公司流行的引擎是LSM树。Google里面有一个很有名的开源系统LevelDB，Facebook基于它又开发了一个类似的系统RocksDB。这种引擎采用基线加增量的设计，数据首先以增量的形式写入到内存中，当增量达到一个阀值时统一写到磁盘。这种做法的好处是解决了关系数据库写入放大的问题，但是它的合并代价会比较大，可能出现合并速度赶不上内存写入的情况。
经验&思考
第一点关于高可用。首先，强一致加高可用可能是未来云数据库的标配。我们以前做应用架构和存储选型的时候会谈很多东西，比如数据库异步复制提高性能，或者CAP理论导致一致性和高可用不可兼得，等等。然而，通过OceanBase的实践我们也已经得出一个结论，实现强一致相比实现弱一致性能开销不是那么大，性能的损耗比较低，而且可以获得非常多的好处，这一定是以后的趋势。另外，实现云数据库级别的高可用底层一定要用Paxos协议，回避该协议的实现方案本质上都是耍流氓。目前我们已经从各大互联网公司，包括Google、Amazon以及Alibaba的云数据库实践看到了这一趋势。
第二点关于自动化。以前传统的关系数据库规模往往比较小，只有少数几台机器，有一个DBA运维就够了。然而，在云数据库时代，一定要做规模化运维，一个DBA对几千甚至上万机器，达到这个量级一定要做自动化。强一致是自动化的前提，没有强一致很难自动化，主库故障备库会丢数据，自动化是很难的。虽然每次宕机概率很低，但是规模上来概率就高了。
另外云数据库设计的时候也会有很多不一样的考虑，尽可能地减少人工干预。例如数据库配置项，或者比较流行的SQL Hint，在云数据库时代一定需要尽可能减少。系统设计者需要在服务端自己消化，不要把灵活性留给运维的人员，因为运维的人要做的就是规模化运维。
最后一点关于成本。成本是云的关键，很多用户上云就是为了节省成本。首先，性能不等于成本。性能虽然很重要，但是成本需要考虑更多的因素，性能、压缩比、利用率、规模化运维，等等。以利用率为例，云数据库的一个成本节省利器就是提高机器利用率。在云数据库中，可以通过分布式方案把整个利用率提高来，即使单机性能类似，但是利用率提上来以后，成本会特别的低。