POSTGRESQL 高可用最后一篇下周一发布（共六篇）。
正文
——————————————————————————————
写这篇文字的起因是众多的DB们投入到学习PG数据库，遇到了一些困难，其实提出这个题目的时候，其实我也在想，每种数据库都有自己的适合的管理方法，有些是管理方法实则是无奈。最近有人问 POSTGRESQL 使用的方式是更贴近ORACLE 还是 MYSQL。
为什么会提出这样一个话题，
1 使用PG 前，提出问题的人使用的或管理的数据库已经深入骨髓，很愿意用原来的管理方法来管理新的数据库，这是很正常的事情，我们都愿意用已有的经验去套用在新的事务上，加快对新事物的理解和使用。
2 低估了新事物与原有经验的之间的冲突，如同比如去了国外做公交车，如果你不按STOP 的按钮，公交车是到站不停的，而国内这样的情况是不会出现的，更有意思的是，如果你按错了按钮，也是要下车的，因为不好意思，别问我怎么知道的。
所以今天的题目还算有点意思，有点讨论性，将三个数据以及使用者的经验来一个MIX 本来就是挺有意思的话题。
1 ORACLE 中没有DATABASE 的概念 （类似 MYSQL SQL SERVER），ORACLE 中是有SCHEMA的概念的，在ORACLE 的世界中可以看做一个SCHEMA 就是一个 DATABASE.
2 在MYSQL 中是没有SCHEMA的概念的，他是通过不同的DATABASE 来分割逻辑，或物理上的数据信息。
3 类似 POSTGRESQL 和 SQL SERVER 这样的数据库就属于比较，怎么都行的，这两者既有 SCHEMA 的概念，也有DATABASE 的概念。你想用任何的方式来分割都是OK 的。但SQL SERVER 历史原因，习惯使用DATABASE 来分割的是常见的。
说到这里问题是PG 怎么办，PG 中的SCHEMA 和 ORACLE 概念无差， 而不幸的是，他的DATABASE 的概念也和 MYSQL 无差。貌似 PG 属于脚踩两只船的那位。
那我们在使用PG的时候是更倾向于将所有的表都塞到一个数据库里面，然后用SCHEMA 用户 权限的方式来管理好。
还是使用MYSQL 或 SQL SERVER 那种创建多个数据库在一个INSTANCE 的方式，每个DATABASE 有不同的用户的方式来管理，更符合PG的性格。
如果我们以ORACLE的方式管理 PG ，在一个DATABASE 里面创建多个SCHEMA ，也就是放弃PG 的多DATABASES 的概念，仅仅使用一个数据库，我们会遇到另一个问题，autovacuum worker ， 根据下面的一段官方的文字
经过推敲清理线程是一个个数据库来进行清理的，那如果将所有的表都塞入到一个数据库，那我是否能推断出，即使设置了多个WORKS 一个数据库也只能使用一个清理线程（如果这样理解有误，请告知谢谢）。
这就引出另一个不同的概念，在ORACLE 有 UNDO LOG 有清理的线程，但PG 的原理是没有REDO UNDO LOG ，通过表本身来实现，就会有DEAD 的元祖。而不能及时清理死的元祖就会引起一系列的问题。
所以我暂时只能理解，如果你想用ORACLE的方式来管理PG 的数据库，则最好表不要特别大，并且数量也不要太多。
那换一个思路我用 MYSQL的方式来管理，总能避过上面的担心，但PG 对其他库的数据的访问，并不如MYSQL 简单，select * from 库名.表名
，就能跨库查询，而是要走dblink的方式来连接在同一个INSTANCE （PG 官方的叫法应该叫 cluster）不同的数据库。这又是 MYSQL 数据库管理员所不能理解的，并且也觉得比较麻烦的。
此时就陷入了，PG 不好用的一个思维模式中去了，对比ORALCE ，对比 MYSQL ，SQL SERVER 都有不同。在既定的模式下，都不能理解这个PG 怎么这么怪。站着不行，坐着也不行。
其实我倒是不这么想，学习一个新事物，一定不要抱着原有的思维模式去学，那样可能每件事都觉得，还不如我的那个方便。但实际上，如果你深入到PG 的学习中，会发现除了这样的事情以外， PG 的扩展性，多态性，也是其他数据库无法进行比拟的。
那我们对上面的问题既然有了一定的认知，我们就能避开某些可能会出现问题的地方，例如，我可以使用ORACLE的方式来管理PG ，建立多个SCHEMA， 但如果一组表与另一组都是无关联的， 那我就在PG的CLUSTER 上新建一个数据库，将这些无关逻辑的表，放到另外一个DATABASE中，或者有关联我可以创建跨库VIEW ，来解决需要 DBLINK 的方式的烦恼，以适合PG的方式来管他，忘记用ORACLE 还是MYSQL的方式来管理PG，因为PG 就是PG 一个不一样的烟火。
