初步学习分布式数据库

写本文的初衷是由于最近在看《大规模分布式存储系统》,期间有不少疑问以及一些新的认识。这里就准备把自己的疑问和认识记录一下,供以后回炉知识点。这里行文的逻辑大致是以不同的数据库产品或者技术展开,可能会显得比较乱。而且,就目前来说,我对各种分布式数据库的理解都还很肤浅,本文权当自娱自乐了,摘抄很多。

1. Hbase/BigTable

作者在书中把Hbase定义为分布式表格系统,其实也没有什么毛病。Hbase的事务支持相当有限,只支持行级事务。Hbase的系统架构图如下:

Hbase

Client:包含访问HBase的接口,并维护cache来加快对HBase的访问,比如region的位置信息

Master:为Region server分配region,负责Region server的负载均衡,发现失效的Region server并重新分配其上的region,管理用户对table的增删改查操作

Region Server : Regionserver维护region,处理对这些region的IO请求,Regionserver负责切分在运行过程中变得过大的region

Zookeeper:通过选举,保证任何时候,集群中只有一个master,Master与RegionServers 启动时会向ZooKeeper注册,存贮所有Region的寻址入口;实时监控Region server的上线和下线信息。并实时通知给Master;存储HBase的schema和table元数据

从上面的这些简单介绍就可以看出,Hbase的设计是绝对的AP设计。无论是多DataNode,还是多HRegionServer,还是引入ZooKeeper集群,都是为了Hbase的可扩展性和高可用性。

2. Spanner数据库

Google最早期的业务也是较多地使用了MySQL数据库。然而Google逐渐意识到MySQL的两个比较大的缺陷——扩展性缺失和可靠性缺失。扩展性缺失是指MySQL的主流用法仍然是单体应用,虽然业界也存在各种构建MySQL集群的中间件,但基本没有在数据一致性和完善事务支持两点上做的很好的。

Spanner相当于是BigTable以及MegaStore的升级版本。用阿里正祥前辈的说法,“Spanner在世界上首次实现了跨越地域尺度的ACID”,而且Spanner是支持水平扩展的。

spanner_architecture

Universe:一个Spanner部署实例称之为一个Universe。目前全世界有3个。一个开发,一个测试,一个线上。因为一个Universe就能覆盖全球,不需要多个。

Zones:每个Zone相当于一个数据中心,一个Zone内部物理上必须在一起。而一个数据中心可能有多个Zone。可以在运行时添加移除Zone。一个Zone可以理解为一个BigTable部署实例。

Universemaster:监控这个universe里zone级别的状态信息

Placement driver:提供跨区数据迁移时管理功能

Zonemaster:相当于BigTable的Master。管理Spanserver上的数据。

Location proxy:存储数据的Location信息。客户端要先访问他才知道数据在那个Spanserver上。

Spanserver:相当于BigTable的ThunkServer。用于存储数据。

Spanner的不同SpanServer之间是以Paxos协议联系起来了,Paxos保证了Spanner的强一致性。在这一点上,Spanner和Zookeeper很像,它们都是强一致性的。但是,Spanner的可用性其实也是非常高的。因此看来,CAP虽然不可完全兼得,但是工程进步还是可以扩充CAP的性能的。

3 OceanBase数据库

OceanBase是阿里巴巴的数据库产品,现在阿里云已经可以使用OceanBase数据库服务了。这说明OceanBase的技术已经比较成熟了。OceanBase的设计目标其实和Spanner非常相似的。

oceanbase

RootServer:管理集群中的所有服务器,子表(tablet)数据分布以及副本管理。 RootServer一般为一主一备,主备之间数据强同步。
UpdateServer:存储OceanBase系统的增量更新数据。UpdateServer一般为一主一备,主备之间可以配置不同的同步模式。部署时,UpdateServer进程和RootServer进程往往共用物理服务器。

ChunkServer:存储OceanBase系统的基线数据。
MergeServer:接收并解析用户的SQL请求,经过词法分析、语法分析、查询优化等一系列操作后转发给相应的ChunkServer或者UpdateServer。如果请求的数据分布在多台ChunkServer上,MergeServer还需要对多台ChunkServer返回的结果进行合并。客户端和MergeServer之间采用原生的MySQL通信协议,MySQL客户端可以直接访问MergeServer。

个人愚见,OceanBase和Spanner还是有很多相似之处的,尤其是在宏观结构上。OceanBase的一大特色是把数据分为基线数据 + 增量修改。

oceanbase_data

UpdateServer主要使用内存来完成更新操作(事务日志会写盘),所以并发事务处理能力非常强。然而,这样的结构存在一个问题,就是UpdateServer内存有限,不能长时间的顶住大量事务。为了应对这样的问题,OceanBase使用了多集群切换的方式,用“车轮战”的方式来应对高并发的事务。主集群顶住事务流量,其他集群则趁这个机会快速把修改增量合并到基线数据中,以准备接下来继续高效服务。

好吧!夜深了,就先写到这里。

最近又是非常的急躁、迷茫。希望自己能快点调整过来,找到属于我的出口!

发表评论