分布式数据库

产品描述
>>分布式数据库的兴起
 

传统数据库遇到的瓶颈

 
互联网场景:海量的数据,超高的峰值并发量
传统数据库昂贵的软硬件和维护成本
传统数据库扩容难和扩容后如何缩容
传统的主备容灾模式可能会丢数据

国产分布式数据库的使命

 
棱镜门事件泄密人斯诺登披露,美国自2009年以来,美国国家安全局一直入侵中国内地的电脑系统,近年来出于国家信息安全的考虑,金融机构也出现了去IOE的浪潮。数据库作为金融机构的重中之重,如何通过国产分布式数据库替代传统国外数据库产品,既能提升并发性能和可维护性,又能符合国家信息安全导向,成为金融机构非常重视的解决方案。
在国产分布式数据库产品中,阿里云的OceanBase经过蚂蚁金服和十余家商业银行的业务场景锤炼,成为目前业内相对最成熟的产品之一,并被看作去Oracle的首选。
 
>>OceanBase介绍
 
OceanBase是蚂蚁金服/阿里巴巴自主研发的通用关系型数据库,不同于基于开源数据库(如MySQL、PG等)的再发行产品,OB对所有的代码,包括数据库引擎和存储引擎的核心代码拥有100%的知识产权,是完整意义上自主研发掌控的国产数据库产品。基于分布式架构和通用服务器、实现了金融级可靠性及数据一致性,没有对特定硬件架构的依赖,具备高可用、线性扩展、低成本、高性能等核心技术优势。

OceanBase产品架构:

 
1.1Paxos协议+无共享架构+分区级高可用
 
1)多副本:一般部署为三个Zone,每个Zone由多个节点(OBServer)组成。
2)全对等节点:每个节点均有自己的SQL引擎和存储引擎,各自管理不同的数据分区,完全对等
3)本地存储(无共享):OceanBase数据分布在各个节点上,不基于任何共享存储结构
4)分区级可用性:可靠性与扩展性的基本单元,自动流量路由、负载均衡、故障转移
• 全局一致性/全局索引
• 支持数据分区,在线分区分裂
• 各分区独立选主、写日志
• 多种数据分区,二级分区
5)高可用+强一致:多副本+Paxos协议,保证数据(日志)写(持久化)到三台机器中至少两台
 
 
1.2自动负载均衡+智能路由,应用透明访问
 
ObProxy:百万级处理能力的代理,路由转发,轻量级SQLParser,无状态
反向代理功能:
反向代理功能
性能需求
运维需求
IP白名单
流量控制
 

OceanBase的核心优势

 
可扩展
• 水平扩展
按需在线扩容,缩容,不停服务
单集群突破100台服务器
高性能
• 峰值6,100万次/秒(真实业务系统)
• 单表最大3,200亿行(真实业务系统)
高可用
基于Paxos协议,强一致性
少数副本故障,数据不丢,服务不停
主备自动切换,对上层业务透明
RPO=0;RTO<30s
多租户
• DBaas架构
• 资源隔离
• 自动负载均衡
兼容性
• Oracle/MySQL两种兼容模式
• 降低业务迁移改造成本
• 保护客户既有投资

OceanBase存储引擎-面向内存的设计

 
• 读写分离的架构
• 准内存处理性能-3~10倍写性能
• 消除磁盘随机写
• 全量数据=基线数据+增量数据
• 避免写入放大
• 高效存储引擎:
• 数据多版本
• 数据压缩/校验
• 支付宝某业务从Oracle迁移到OceanBase,数据由100TB压缩33TB
 

OceanBase事务引擎-AACID的实现

 
• 可用性(Availability)
• 多副本(基于paxos协议同步)
• 原子性(Atomicity)
• 使用两阶段提交,保证跨机事务的原子性
• 一致性(Consistency)
• 主键唯一等一致性约束,外键约束
• 支持全局一致性快照
• 隔离性(Isolation)
• 采用MVCC进行并发控制,实现read-committed的隔离级别
• 所有修改的行加互斥锁,实现写-写互斥
• 读操作读取特定快照版本的数据,读写互不阻塞
持久性(Durability)
• 事务日志使用Paxos协议做多副本同步(持久化)

OceanBaseSQL引擎-语法兼容性

 
1)MySQL兼容(1.x版本)
• MySQL5.6语法兼容
• 基于MySQL开发的应用系统可以无缝迁移
2)Oracle兼容(2.x版本)
• 对标Oracle,去O首选
• 基于Oracle开发的应用系统可以无缝迁移
• 第一个支持存储过程的原生分布式关系数据库系统

OB相比Oracle的优势

 
1)Oracle高可用能力有限,尤其是机房级别容灾甚至城市级别容灾场景下,只能通过DataGuard来实现,是有损容灾。OB提供机房级别甚至城市级别的RPO=0容灾能力,对于重要系统,例如对客的CRM系统,可以保障数据无损的前提下容灾自动切换
2)Oracle扩展能力受限,只能通过不停的扩容共享存储、升级单机配置来扩容,不灵活且有局限性,对单机硬件升级过程中还可能会要求停止业务。对于分布式数据库OB来讲,可以随时动态扩容、扩容普通x86服务器,扩容无数量限制,且对在线业务无影响
3)Oracle并发能力受限,只能通过不停追加RAC来提升计算能力,但RAC机制有一个很大的问题,就是会造成全局等待事件,例如globalenqueue、globalcache等,RAC越多爆发的概率就越大。OB是sharenothing架构,每个节点都提供独立的SQL引擎、计算引擎、存储引擎、事务引擎,因此不会发生全局等待这样的情况
4)Oracle在国产化软硬件支持上受限,OB目前已经UOS、中标麒麟、银河麒麟,国产化芯片已经支持鲲鹏、飞腾、海光
5)Oracle构建在高端硬件上的设计成本高昂,特别是Oracle一体机,硬件和网络(InfiniBand)都要求很高,且维修、扩容、升级都及其复杂,运费高昂。OB只需要普通的x86服务器,对硬件和无特殊要求,硬件运维简单,客户可自行运维

OceanBase的部署方式

 
多副本多机房安装部署
• PC服务器(Q5O1.2256c,384G,12*960GSSD,万兆网卡)和主流Linux操作系统。
1)同城三机房部署
 
• 同城多个核心机房延迟一般在0.5~2ms之间
• 机房级灾难时,能保证RPO=0
2)两地三中心部署
• 正常情况下和同城三中心部署的延迟一致
• 不推荐使用,容灾场景下延迟上升
 
 
• 一台ObServer宕机不影响延迟
• 深圳一个机房宕机会短暂影响延迟,通过五副本降级三副本恢复正常延迟
3)三地三中心五副本部署
• 上海或杭州宕机一台ObServer不影响延迟
• 任意一个地区宕机RPO=0
 
>>用户案例
 
未找到相应参数组,请于后台属性模板中添加
下一个