最近这一年业界去“IOE”越叫越响，很多传统企业也把去“IOE”计划摆上了桌面。我老是想不明白这些非互联网企业（比如：银行）做这种事的动力何在？ 高大上的“自主可控”、“振兴民族科技”等空洞口号先不去管，真正的动力在哪里？ “安全”、“成本”、“互联网架构”.......等等、等等， 唯一看起来靠谱是互联网架构的技术先进性。废话咋这多呢，大势所趋你管的了吗！
言归正传，前段时间也在考虑有什么可”拿来主义“的数据库，能替代Oracle数据库做为业务系统的数据存储。这个数据库系统必须是开源的、支持sql、支持ACID，而且业务应用移植的工作量要小。 框来框去，最后发现Postgresql符合要求，从应用移植上讲工作量远小于使用MysqL。
最近微博上MysqL党人又开始与Postgresql党人纷争，讲到Oracle移植到Postgresql工作量小时，M的拥趸者叫喊道 ：“其实，去o不见得要大规模重写应用啊，完全取决于对数据库专有特性的依赖程度，一般来说，对规模较大的互联网应用来说，因为考虑规模的伸缩性，不会使用很复杂的特性，换个数据库远没有一般企业应用那么难。就算是重写的部分”。我想说得的：哥！ 你见过嵌sql的C程序文件么？见过大量使用PL/sql存储过程的应用么？ 很多老系统都是这么写业务程序的。恰恰MysqL在这方面暂时还不给力，重构业务系统那量那责任亚力山大，不是什么企业都能承受的。
又扯远了，转回来接着说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
现在，就用稍加整理后的网上资料，简单介绍下Postgres-XL。
Postgres-XL功能特性
- 开放源代码：www.postgres-xl.org
Postgres-XL 全称为 Postgres eXtensible Lattice，是TransLattice公司及其收购数据库技术公司–StormDB的产品，是StormDB核心部分重塑后开源。
开源协议使用宽松的“Mozilla Public License”许可，允许将开源代码与闭源代码混在一起使用。 - 完全的ACID支持
- 可横向扩展的关系型数据库（RDBMS）
- 事务处理与数据分析处理混合型数据库
- 支持丰富的sql语句类型，比如：关联子查询
- 支持绝大部分Postgresql的sql语句
- 分布式多版本并发控制（MVCC：Multi-version Concurrency Control）
- 支持JSON和XML格式
Postgres-XL缺少的功能
Postgres-XL架构
- 基于开源项目Postgres-XC
- 多个协调器（Coordinator）
- 多个数据节点（Datanode）
- 全局事务管理器（GTM：Global Transaction Manager）
- 提供事务间一致性视图
- 部署GTM Proxy实例，以提高性能
协调器（Coordinator）
全局事务管理器（GTM）
- 处理必须的MVCC任务
- Transaction IDs 事务ID
- Snapshots 数据快照，MVCC使用
- 管理全局性数据值
- Timestamps 时间戳
- Sequences 序列对象
- 全集群只有一个GTM节点，会有单点故障问题。解决方案：配置StranBy热备节点保证高可用
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）。
CREATE TABLE my_table (…)DISTRIBUTE BYHASH(col) | MODULO(col) | ROUNDROBIN | REPLICATION[ TO NODE (nodename[,nodename…])]
复制表（Replicated Table）
- 益用于只读和读多写很少的表
- 有时益用于数据仓库的维度表
- 如果协调器与数据节点一对一部署在同一台服务器，就会是本地数据读取，减少网络传送
- 对写入频繁的表严重不适用
- 每行记录复制到集群中所有的数据节点，每节点一份
分布表（Distributed Table）
- 益用于写入频率的表
- 益用于数据仓库的事实表
- 每行记录只存于一个数据节点
- 可用的分片策略方式
- Hash
- Round Robin
- Modulo
Postgres-XL可用性
- 不存在单点故障
- 全局事务管理器采用热备方式（有热备就不叫单点故障了吗？）
- 多个协调器间负载均衡
- 数据节点使用流式复制，复制数据到备节点
- 但，但是，这一切目前都是手工的........... （主要是讲流式复制？手工的，讲个毛啊~）
Postgres-XL性能
事务处理型（OLTP Transaction）性能
