PostgreSQL 培训视频
视频下载地址
PostgreSQL TODO & 软肋,
大多数软件都有坑, 如果把握不好, 那就掉坑里去了, PostgreSQL亦如此, 为避免初次接触PostgreSQL的朋友掉坑里去, 这里罗列了一些PostgreSQL的软肋和TODO, 大家可以参考一下.
todo
1. http://wiki.postgresql.org/wiki/Todo
2. 基于WAL的多主复制(9.4可能会实现)
3. 多CPU资源利用, 如并行查询
4. shared nothing 架构(目前需要插件来实现如plproxy, pgpool-ii)
5. 基于块的增量基础备份(目前只有基于WAL的增量备份)
6. query cache, 如count(*)性能提升
7. toast 阈值可配置(目前只能在编译时指定)
8. 使用ssd作为二级缓存
9. PostgreSQL 目前一个集群只支持1个block_size, 这种不利于复杂场景的使用, 例如我们在同一个数据库中有大量的OLTP请求, 同时还有大数据的频繁导入需求的情况下, 选择小的block_size或者大的block_size都不合适, 如果能针对每个表指定不同的block_size的话可以很好的解决这一的问题. 当然如果数据库中存在不同大小的block_size, 那么随之而来的改动是非常大的, 例如shared buffer也必须兼容不同大小的block size.
在Oracle 9中, 支持一个数据库中存在不同的数据块大小.
10. PostgreSQL的配置文件是直接编辑的, 没有像oracle这样的spfile, 当然9.4会支持alter system来修改, 但是<=9.3的没有, 修改文件容易出错, 不安全, 错误的话会导致数据库集群无法启动.
11. 目前开源的postgresql不支持函数加密. 安全性较低.
12. 目前移动表空间(如alter table tbl set tablespace newtbs;)会产生大量的XLOG, 这个应该是可以优化的.
13. 流复制异步模式下, failover后, 可能因为主备xlog的差异需要重做standby. 目前可以通过rsync减少网络传输, 或者zfs snapshot来将OLD PRIMARY回退到以前的状态达到切换成standby的目的.
14. 没有表空间配额限制, 目前只能通过文件系统使用配额来简单的限制.
15. 没有rotate table, 类似mongoDB的capped collection. 限制记录条数, 空间, 或记录时长, 超过限制就覆盖最早的记录 .
16. pg-xc, pg-xl的数据重分布需要将数据从所有的数据节点加载到coordinator后, 在按照重分布算法分发到新的所有节点.
17. 同步流复制的一点可能可以改进的地方, 例如只有一台standby时, 如果standby异常或网络原因导致XLOG无法同步复制到standby并返回feedback的话, 那么在同步提交队列中等待提交的xact将处于等待状态, 一般的做法是使用2个或2个以上的standby来防止1个STANDBY故障时可以自动将同步standby节点向下转移, XACT不需要等待. 那么是不是可以有得选择, 例如在等待多少秒之后自动切换成异步模式.
18. 目前没有比较好的读写分离或shared-nothing解决方案, 例如
1. 通过中间件pgpool-II构建读写分离, 但是pgpool-II目前稳定性, 性能(tps)都不尽人意.
2. 使用pg-xc构建的shared-nothing, 性能(TPS)损耗太大, 同时全局一致性还原(PITR)目前还只有停留在创建barriers, 粒度无法达到gxid的粒度(因为每个节点各管各自的XID).
3. 使用plproxy构建shared-nothing, 性能损失小, 但是没有跨节点事务能力, 当然如果应用层愿意使用 2PC来实现的话, 也是可以的. 另外, 接口必须是PLPROXY函数, 所以对应用来说适配较差.
软肋
1. 读写并发管理通过新增行版本实现, 会带来垃圾数据, 对于非HOT更新的话, 还会引起索引更新, 导致索引更容易膨胀.
2. 显然这种MVCC机制不利于频繁更新的应用场景, 同一条记录被更新10次的话, 会产生10个版本的写xlog和heap page的IO, 同时在VACUUM的时候还需要写xlog以及heap page的IO. 这10个版本可能并不会同时存在, 但是却实实在在的产生了这些写IO.
3. 通过xid来识别版本, 且xid是32位存储, XID是需要复用的, 所以经过一定的事务分配后需要freeze, 当然此MVCC机制的好处也是有的, 例如锁粒度很小, 容易实现repeatable read和ssi. 会话层可实现跨越会话的一致性镜像等.
4. 同样MVCC带来的问题, 在大数据库中使用逻辑备份时(), 备份开始后产生的垃圾数据都无法被回收, 如果备份时间很长, 将导致数据库膨胀比较厉害, 同时也会影响对象的freeze. 所以对大库建议使用pitr备份方式.
海翔老师发来一些互联网上收集到的问题, 我谨表明下个人观点.
对PostgreSQL数据库有一定了解, 或者尝到甜头的朋友大多都会有这样的疑问, 为什么PostgreSQL好用却没有MySQL流行呢?
1 PG没MySQL流行的原因
因为没有使用过MySQL, 所以不太好回答.
2 PG的优势有哪些？（请例举您认为的最优优势的5条，降序排列）
1. 社区活跃(每天都有commit, 每年全球大会, 每年全球地方性会议等), 运作稳定(主要贡献者来自全球的诸多行业的诸多企业, 不会出现一家独控的局面), git版本管理, wiki知识库管理, BSD许可.
2. 血统纯正, 以及丰富的第三方插件. PostgreSQL的分支只有1个, 不会出现分支众多, 版本不统一的情况. 第三方插件非常多, 基本上都来自实际的需求.
postgreSQL插件的使用非常简单, 因为是模块化形式的, 安装好后, 加载到动态链接库即可. (包括性能, 功能扩展, 融合, 管理等方面的插件.)
3. 流复制, 外部表接口, MPP, shared nothing
PG的流复制是基于块的变更, 速度极其之快, 局域网内能实现毫秒级的延迟, 广域网也不需要担心网络稳定性, 因为是续传的. 流复制可用于HA,容灾, 读写分离等场景.
9.4版本还会引入逻辑流复制, 可用于multi master的场景.
PG支持外部表接口, 在PG中可以直接读写其他数据源的数据, 如Oracle, MySQL. 适合混杂场景的使用, 或者数据迁移场景的使用.
MPP, PostgreSQL的第三方插件或者第三方商业软件可以实现MPP的功能, 例如GreenPlum, PgPOOL-II, pg-xc, citusDB, postgres-xl等,还可以结合HADOOP来使用.
shared nothing, postgresql第三方插件可以方便的实现shared nothing的功能, 例如plproxy, pgpool-ii, pg-xc等.
4. 数据类型丰富, 索引类型丰富, 可动态加载的模块, 丰富的服务端函数
PG的数据类型非常的丰富, 同时支持自定义类型. 除了传统的数据类型之外, 还支持例如range类型, IP类型, HSTORE类型, JSON类型,
PG的索引访问接口也非常丰富, 例如支持btree, hash, gist, gin, spgist等诸多索引访问接口.
可动态加载的模块, 用户可自定义一些库, 在需要使用时动态加载. 同时PG支持自定义钩子应用的场景(_PG_init()).
丰富的服务端函数, 例如plpgsql, plpython, plperl, pltcl, pl-R, pljava, plv8, C等. 适用各种开发人员使用.
5. 兼容性, 稳定性, 可靠性, 性能, 后期维护, 审计需求等.
PG的兼容性非常好, 支持几乎所有的硬件架构和操作系统.
稳定, 可靠, 性能卓越.
维护简单, 诸多功能可以满足审计需求.
3 PG在互联网/传统行业（有事务需求）/或其它行业的未来？
国内PG圈子越来越活跃, 包括传统行业, 金融行业, 运营商, 互联网行业, 政府都有使用.
由于数据库在业务系统中的重要性, 一般曾经未使用PG的公司会从不太重要的新项目着手尝试使用PG, 尝到甜头后才会有后续大规模应用的动作.
老的项目, 从其他数据库迁移到PG的, 肯定是这些已有的数据库无法满足现阶段或未来的需求. 例如可能是迫于成本的考虑, 又或者项目中依赖PG的一些特性.
