分布式数据库有两大流派，NEW SQL VS POSTGRESQL -XC ，NEW SQL 的分布式主流的理论来源自 GOOGLE 的分布式数据库spanner，以及相关理论的白皮书，而令一派的分布式数据库来自于POSTGRESQL -XC， 今天我们看看到底POSTGRESQL-XC 这个流派的方式是什么，有什么特点，当下那些分布式数据库采用了POSTGRESQL -XC。
POSTGRESQL-XC 的研究自2002年开始,主要是日本的NTT公司进行相关的研究,踏实基于水平可伸缩的数据库系统share nothing无架构的方式. 最早POSTGRESQL-XC 最早的名字叫RiTaDB, 后来改名为POSTGRESQL-XC, 支持全局事务,表分区,复制以及查询计划在各个节点并行执行的shared nothing 架构.
在数据库架构中有一种独特的结构被称为星型结构,在很多的数据库仓库和OLTP的数据库结构中都可以发现其中的身影,星型的结构一般存在较少的大表和一些普通的表,或者数据量较少的表. 例如,产品目录表可能是普通表,而销售的订单表是BIG TABLE.
POSTGRES -XC 的结构主要解决的是大表的问题,将大表通过关键主键的方式来将一张大表分布在不同的数据存储节点, 主要对于写压力的释放还是通过将数据分散在不同的sharding 分片中来进行的.
而通过上面的星型结构将大数据分割,并且将小表复制到每一个节点中,通过这样的方式来进行相关的数据计算.
这就有点类似于我们将一张大表分成多个逻辑表,然后将与其产生JOIN 的小表与每一个表进行JOIN的操作,最后将结果进行UNIION的方式.
实际上POSTGRES-XC 的结构主要有3个部分组成
1 GTM, GLOBAL Transaction Manager
我们都知道POSTGRESQL的原理中每个表中会存在记录每行数据状态的文件,在POSTGRES-XC 中GTM 主要提供分布式数据库的事务一致性与行的可见性的问题, XC中GTM作为整体数据库中数据的事务管理的中心,提供整体事务状态.
2 Coordinator
Coordinator 主要是基于对应用的接口,如果要比喻的话,他可以作为POSTGRESQL backend pocess的存在, 他作为接受SQL语句, 获得全局事务ID并且获得全局SNAPSHOT,选择那些数据节点参与数据得计算,并且这些工作都是并行的,可以接受多个应用请求来并行进行数据的运算.
3 datanode
数据节点实际上存储了你的数据,将大表分割而至的归宿,就是 datanode, 在datanode中并不会有全局的数据,输入的语句通过coordinator的分解后,会产生针对不同 datanode的执行计划.通过GTM给出的GXID 全局事务ID,来使用全局snapshot 进行数据的处理.
POSTGRES-XC的核心个人认为主要在 GTM, 这里GTM主要工作的范围和关键点在于如果我们操作一个事务的操作,如果他需要操作超过一个DATANODE的情况下,那么这个操作就必须有一个全局的事务ID来对整体的操作进行把控.
通过GXID 来对事务中的SNAPSHOT的行进行把控.防止不同的事务读到本不应他读到的老的行版本的数据.
其中更深层次的原因在于2PC 两阶段协议,2PC协议强制更新每个分布式事务。但并不强制维护分布式事务更新对其事务的一致可见性. 那么急于2PC的这方面的特性, GXID 会在所有事务执行的行中打上标记,保证数据在全局事务中的可见性或隐蔽性. 那么基于这样的设计GTM 给每一个全局事务做一个全局的GLOBAL SNAPSHOT,通过这样的设计可以在分布式事务进行并行的执行.
POSTGRESQL 数据库本身有完善的分布式相关的理论和实际的产品,目前POSTGRESQL 已经有了 XC XL X2 等逐步演进的分布式方案.
