最近这一年业界去“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解除进程互斥锁

Postgres-XL数据分布

Postgres-XL数据分布有两种模式： 复制表（Replicated Table）、分布表（Distributed Table）。

（这两个名词很熟悉啊，貌似基于MySQL的开源列存MPP数据库InfoBright也是这两种方式，某个基本概念与InfoBright相似度很高的国产MPP数据库也一样。）

CREATE TABLE my_table (…)

DISTRIBUTE BY

HASH(col) | MODULO(col) | ROUNDROBIN | REPLICATION

[ TO NODE (nodename[,nodename…])]

            

复制表（Replicated Table）

• 益用于只读和读多写很少的表

• 有时益用于数据仓库的维度表

• 如果协调器与数据节点一对一部署在同一台服务器，就会是本地数据读取，减少网络传送

• 对写入频繁的表严重不适用

• 每行记录复制到集群中所有的数据节点，每节点一份

分布表（Distributed Table）

• 益用于写入频率的表
• 益用于数据仓库的事实表
• 每行记录只存于一个数据节点
• 可用的分片策略方式
  • Hash
  • Round Robin
  • Modulo

Postgres-XL可用性

       

• 不存在单点故障
  • 全局事务管理器采用热备方式（有热备就不叫单点故障了吗？）
  • 多个协调器间负载均衡
  • 数据节点使用流式复制，复制数据到备节点
• 但，但是，这一切目前都是手工的........... （主要是讲流式复制？手工的，讲个毛啊~）

Postgres-XL性能

事务处理型（OLTP Transaction）性能

**
**

• 测试使用针对电子商务应用的TPC-W（DBT-1）基准测试模型。

• 协调层增加了30%的开销：在单节点（CPU4核）上，与简单地直接使用PostgreSQL相比，只有PostgreSQL性能的70%。

• 集群规模扩大到10个节点时，与单节点PostgreSQL相比，理论上应获得7倍性能提升，实际上达到6-6.4倍。

• 随着集群节点数的增加，打开的事务数、快照空间占用、可见性检查都会随之增长。