目录
初识Obase
最近了解到一款国内自主研发的分布式数据库---Obase分布式数据库，该产品由上海丛云公司研发，主页是http://obase.com.cn/，logo中同样用动物作为产品的标识，Obase的logo中有一只鲸鱼，主页如下图。
网站上的内容不多，有4个标签页可选，在右上方能看到Obase给自己的的定位是“金融级别联机交易分布式数据库”，接下来将通过产品白皮书进行了解，白皮书的位置需要通过点击主页中间“原生的分布式数据库系统”蓝色矩形区域后获取。
我获取到的白皮书封面日期是2017年8月，共14页。
引言开门见山介绍了OBASE 是一个新型的分布式数据库系统，与传统MySQL加中间件解决方案相比，Obase不需要用户进行分库分表，它没有跨节点的限制，支持多活部署的同时，还具有良好的扩展性、高可用性，并且支持关系模型及事务处理。对于用户来讲，免去分库分表的工作确实是降低了很多的运维管理成本，
系统架构
OBASE是运行于x86服务器集群上的分布式数据库系统，通过对传统关系数据库系统功能的拆分，实现了数据的分布式存储和查询的分布式处理，集群架构如下图。
4种服务角色
在进群中Obase有4个不同角色的服务进程，分别是RootServer（RS）、UpdateServer（UPS）、MergeServer（MS）和ChunkServer（CS）。
RootServer（RS）
RS是系统的控制节点，负责集群管理和数据分布。集群中可以设置多个 RS 节点（一主多备），通过Paxos协议实现自动选主，能够保证集群的高可用；
通过租约机制（Lease）来管理集群中的UPS节点，保证同一时刻只有一个UPS提供事务处理服务；
通过心跳机制（Heartbeat）来管理集群中的MS和CS节点，感知节点的上下线；
OBASE中的数据表按主键范围被划分为多个子表（称为Tablet），每个子表可以有多个副本，分别存储在不同的CS节点上。RS通过RootTable结构来记录Tablet在CS上的分布位置信息，并管理Tablet的副本数量、复制、 迁移和合并。
UpdateServer（UPS）
UPS是系统中的内存事务处理引擎。与传统数据库系统一样采用WAL（Write-Ahead Logging） 技术来保证事务的原子性和持久性；
集群中可以部署多个UPS节点（一主多备），由主RS通过租约来确定主UPS，主UPS的日志采用基于Quorum协议的方式同步到备UPS，能够保证在超过半数UPS正常的情况不丢失任何数据；
事务处理产生的增量数据被保存在UPS的内存中，通过合并操作与CS中保存的静态数据合并，产生新版本的静态数据；
支持跨表跨行的事务，不存在分布式事务，不需要两阶段提交协议；
采用多版本并发控制协议（MVCC）实现 Read Committed事务隔离级别；
MergeServer（MS）
MS实现了查询处理功能。
支持MySQL通讯协议，对SQL语句进行解析生成执行计划，并管理语句执行计划的运行；
缓存Tablet的分布位置信息，将SQL语句涉及的数据请求同时发送给对应的CS，并将所有 CS 返回的结果合并；
MS本身无状态，宕机不会对应用系统产生影响，应用可以通过其它MS获得服务；
ChunkServer（CS）
CS实现了数据的分布式存储和访问。
存储和管理Tablet副本，提供本地数据查询服务，支持数据缓存；
响应MS的数据请求时，会从UPS拉取对应的增量数据，融合后得到数据的最新状态，返还给 MS；
在启动数据合并操作后，CS将会从UPS拉取所有本地数据对应的增量数据，与本地数据合并后产生新版本的Tablet；
数据合并操作期间，CS能够正常提供数据查询服务；
了解了这4种服务进程之后，再结合前面提到的“对传统关系数据库系统功能的拆分”，我觉得可以将Obase的集群理解为一个大型的、完整的数据库，我简单整理了下Obase的逻辑架构，如下图。
4个角色的功能简单概括如下：
RS：控制管理集群、Tablet及数据分布信息，通过Paxos协议实现自动选主；
UPS：事务处理引擎，多个UPS基于Quorum提交协议工作，存储增量数据；
MS：查询处理、SQL解析，MS无状态，缓存了Tablet的位置分布；
CS：存储Tablet副本，也就是静态数据。
这样的架构设计相对比shared-nothing相比，横向的扩展会相对更灵活一些，通过部署多个CS和MS节点就可以扩展系统的存储和查询处理能力；
同Oracle RAC比较
RAC架构在金融行业中应用较广，内存融合机制是RAC的特点，经过严密部署规划的RAC系统可以说非常的健壮，从目前的了解的情况看，Obase在存储的扩展上更具有优势，直接加CS节点即可，另外如需提升计算能力，扩展MS即可。
在这里我又想起了此前在云栖社区中了解的Oceanbase系统架构，Oceanbase同样也是使用了RS、UPS、MS和CS角色（未说明Oceanbase版本），两者架构相似度很高，点击这里了解原文。
基准数据和增量数据
我们知道数据被分为基准（静态）数据和增量（动态）数据两部分，在响应应用程序的数据请求时，OBASE系统会将增量数据与基准数据融合，返回数据的最新状态。当增量数据达到一定规模时，可以通过定时或者主动发起的数据合并操作将UPS内存中的增量数据与CS磁盘上的基准数据合并，产生新版本的基准数据。在数据合并过程中，CS上的旧版本基准数据仍然可用，不影响系统对外提供服务。
以上是对Obase架构层面的理解，可以说功能拆分的设计给人眼前一亮，接下来介绍功能部分。
Obase功能说明
OBASE是一款用于管理大规模结构化数据的分布式数据库产品，能够提供与传统关系型数据库类似的数据管理功能，支持标准的SQL语言。
其他功能比如数据类型、函数、备份恢复等与其他关系型数据库类似，值得关注的是OBASE兼容MySQL协议，可以使用MySQL的JDBC驱动直接连接集群中的一个MS；
在约束与索引方面，要求每张数据表必须唯一的主键，支持二级索引，不支持主键外的唯一索引；OBASE 不支持对属性值的约束检查，不支持外键约束，不支持为属性设置缺省值。
环境与部署
软件要求操作系统为RHEL 6.2 (64bit)及以上版本，硬件建议6C、64G及以上。
为了充分发挥分布式系统的优势，白皮书中建议使用 3 台以上的物理机环境，也是之所以我讲上面的逻辑架构图中的角色都画成了3副本。
由于不同节点主要消耗的系统资源不同，在规划OBASE集群时，通常将MS和CS安装在同一台物理机上，将RS和UPS安装在同一台物理机上。
对于生产环境，应选择单机房（多RS/UPS）或多机房，可满足可用性需求。下图是白皮书中给出的多机房部署架构参考图。
特点和优势
1.良好的扩展性
Obase支持在线扩容和缩容。在不停服务的情况下，通过向集群中添加数据存储节点CS和查询处理节点MS，就可以近似线性地增加OBASE系统的存储容量和处理能力。
2.系统的高可用性
OBASE 集群中可以配置多个RS/UPS，采用Paxos协议进行RS的自动选主，实现了RS的高可用，通过WAL技术、日志强同步和租约机制保证了UPS的可靠性。
3.标准SQL语言
OBASE 采用了标准SQL语言，兼容MySQL的通讯协议，用户可以直接使用MySQL的客户端和 JDBC 驱动来访问OBASE数据库。
4.无需用户分库分表
数据的分布、复制、迁移和容灾都由系统自动完成，对用户透明。
5.硬件成本低
OBASE 数据库运行于普通的PC服务器集群上，不依赖于任何专用的硬件设备。
应用场景
下图为某大型国有银行的历史库系统的架构，采用了主备双集群的部署方式，存储和管理了 100TB的结构化历史数据，最大单表超过585亿条记录。
以上是我阅读Obase技术白皮书后整理的相关内容，从一个Oracle DBA的角度看，Obase技术架构的设计明显区别于传统数据库，对“功能”拆分的思想值得借鉴，同时在管理上也较为灵活，网络上关于Obase的资料有限，暂时总结到这里。
Tank
2019.8.9
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
