?Postgres-XL：基于PostgreSQL的开源可扩展数据库集群

浏览数：20 / 时间：2015年06月12日

?Postgres-XL：基于PostgreSQL的开源可扩展数据库集群

最近这一年业界去“IOE”越叫越响，很多传统企业也把去“IOE”计划摆上了桌面。我老是想不明白这些非互联网企业（比如：银行）做这种事的动力何在？高大上的“自主可控”、“振兴民族科技”等空洞口号先不去管，真正的动力在哪里？ “安全”、“成本”、“互联网架构”.......等等、等等，唯一看起来靠谱是互联网架构的技术先进性。废话咋这多呢，大势所趋你管的了吗！

言归正传，前段时间也在考虑有什么可”拿来主义“的数据库，能替代Oracle数据库做为业务系统的数据存储。这个数据库系统必须是开源的、支持SQL、支持ACID，而且业务应用移植的工作量要小。框来框去，最后发现PostgreSQL符合要求，从应用移植上讲工作量远小于使用MySQL。

最近微博上MySQL党人又开始与PostgreSQL党人纷争，讲到Oracle移植到PostgreSQL工作量小时，M的拥趸者叫喊道：“其实，去o不见得要大规模重写应用啊，完全取决于对数据库专有特性的依赖程度，一般来说，对规模较大的互联网应用来说，因为考虑规模的伸缩性，不会使用很复杂的特性，换个数据库远没有一般企业应用那么难。就算是重写的部分”。我想说得的：哥！你见过嵌SQL的C程序文件么？见过大量使用PL/SQL存储过程的应用么？很多老系统都是这么写业务程序的。恰恰MySQL在这方面暂时还不给力，重构业务系统那量那责任亚力山大，不是什么企业都能承受的。

昨天阅读了浙江移动在中国数据库技术大会上的主题演讲《运营商去O浅析》公开版，觉得里面所讲的去O关键点与困难很到位，当然是站在传统企业的角度，不代表BAT等互联网公司高大上视角。

又扯远了，转回来接着说PostgreSQL替代O的事。

国外也有专门使用与扩展PostgreSQL、提供替代Oracle解决方案服务的公司，比如：EnterpriseDB ：

”EnterpriseDB is the leading worldwide provider of Postgres software and services that enable enterprises to reduce their reliance on costly proprietary solutions and slash their database spend by 80 percent or more.

With powerful performance and security enhancements for PostgreSQL, sophisticated management tools for global deployments and database compatibility, EnterpriseDB software supports both mission and non-mission critical enterprise applications. More than 2,500 enterprises, governments and other organizations worldwide use EnterpriseDB software, support, training and professional services to integrate open source software into their existing data infrastructures.

Based in Bedford, MA, EnterpriseDB is backed by strategic private investors.“

另外在网上还看到一个关于日本电信公司（NTT）使用PostgreSQL去O成功案例的PPT：https://www.pgcon.org/2011/schedule/attachments/203_NTT_Case_307.pdf

但新的问题又来了，PostgreSQL能否横向扩展以应对高并发大交易量系统的数据库操作压力？于是乎继续在网上耕耘，这两天找到一个看上去不错的开源实现：Postgres-XL。（具体性能上是否能满足需求，还没有实际测试暂不可知）

现在，就用稍加整理后的网上资料，简单介绍下Postgres-XL。

?Postgres-XL功能特性

开放源代码：www.postgres-xl.org
Postgres-XL 全称为 Postgres eXtensible Lattice，是TransLattice公司及其收购数据库技术公司–StormDB的产品，是StormDB核心部分重塑后开源。
开源协议使用宽松的“Mozilla Public License”许可，允许将开源代码与闭源代码混在一起使用。
完全的ACID支持
可横向扩展的关系型数据库（RDBMS）
- 支持OLAP应用，采用MPP（Massively Parallel Processing：大规模并行处理系统）架构模式
- 支持OLTP应用，读写性能可扩展（注意，排在第一位的是OLAP！！！）
- 集群级别的ACID特性
- 多租户安全
- 也可被用作分布式Key-Value存储
事务处理与数据分析处理混合型数据库
支持丰富的SQL语句类型，比如：关联子查询
支持绝大部分PostgreSQL的SQL语句
分布式多版本并发控制（MVCC：Multi-version Concurrency Control）
支持JSON和XML格式

?Postgres-XL缺少的功能

内建的高可用机制
- 使用外部机制实现高可能，如：Corosync/Pacemaker
- 有未来功能提升的空间
增加节点/重新分片数据（re-shard）的简便性
- 数据重分布（redistribution）期间会锁表
- 可采用预分片（pre-shard）方式解决，在同台物理服务器上建立多个数据节点，每个节点存储一个数据分片。
  数据重分布时，将一些数据节点迁出即可
某些外键、唯一性约束功能

?Postgres-XL架构

基于开源项目Postgres-XC
- XL增加了MPP，允许数据节点间直接通讯，交换复杂跨节点关联查询相关数据信息，减少协调器负载。
多个协调器（Coordinator）
- 应用程序的数据库连入点
- 分析查询语句，生成执行计划
多个数据节点（DataNode）
- 实际的数据存储
- 数据自动打散分布到集群中各数据节点
- 本地执行查询
- 一个查询在所有相关节点上并行查询
全局事务管理器（GTM：Global Transaction Manager）
- 提供事务间一致性视图
- 部署GTM Proxy实例，以提高性能

协调器（Coordinator）

处理客户端网络连接，是数据库的接入点
分析查询语句，生成执行计划，并将计划传递给数据节点实际执行
对数据节点返回的查询中间结果集执行最后处理
管理事务两阶段提交（2PC）
存储全局目录（Global Catalog）信息

数据节点（DataNode）

存储表和索引数据
只有协调器连接到数据节点
执行协调器下传的查询
两个数据节点间可建立一对一通讯连接，交换分布式表关联查询的相关信息

全局事务管理器（GTM）

处理必须的MVCC任务
- Transaction IDs 事务ID
- Snapshots 数据快照，MVCC使用
管理全局性数据值
- Timestamps 时间戳
- Sequences 序列对象
全集群只有一个GTM节点，会有单点故障问题。解决方案：配置StranBy热备节点保证高可用

通过部署GTM Proxy，解决可能的GTM性能瓶颈

GTM Proxy

与协调器（Coordinator）和数据节点（DataNode）在一起运行
后端（协调器、数据节点）用它替代GTM，直接与它交互，它做为后端与GTM间的中间人
将对GTM的请求分组归集，多个请求一次提交给GTM
获取transaction ids（XIDs）范围
获取数据快照
比如： 10个进程分别请求一个transaction id
- 它们每一个都连接到本地的GTM Proxy
- GTM Proxy发送请求到GTM，一次申请10个XID
- GTM锁定procarray数据结构，分配10个XID
- GTM返回XID范围
- GTM解除进程互斥锁