这是一个创建于 3560 天前的主题，其中的信息可能已经有所发展或是发生改变。
现有需求如下
会员信息数据，用于所有移动端会员的登录和信息查询，访问频率很高，并发较高，但是数据量很小
其他业务信息数据，用于承载业务数据，访问频率，并发都较低，数据量中等偏高
现在的想法是，为了充分优化会员信息数据的访问，打算把会员信息单独放在一个库，调优；业务信息单独放另外一个库，大概缺省设置就足够了
那么就要考虑到跨库访问的实现，根据一些资料来看，似乎 fdw 无论从性能还是功能来说都超过 dblink ？是不是 fdw 以后将会彻底代替 dblink ？
很久没了解 postgre 了，所以对这些新东西比较迷糊。开发方面期望的是能够在一个 datasource 下透明、高效的访问所有数据
会员信息数据，用于所有移动端会员的登录和信息查询，访问频率很高，并发较高，但是数据量很小
其他业务信息数据，用于承载业务数据，访问频率，并发都较低，数据量中等偏高
现在的想法是，为了充分优化会员信息数据的访问，打算把会员信息单独放在一个库，调优；业务信息单独放另外一个库，大概缺省设置就足够了
那么就要考虑到跨库访问的实现，根据一些资料来看，似乎 fdw 无论从性能还是功能来说都超过 dblink ？是不是 fdw 以后将会彻底代替 dblink ？
很久没了解 postgre 了，所以对这些新东西比较迷糊。开发方面期望的是能够在一个 datasource 下透明、高效的访问所有数据
 | 1 icegreen 2016 年 7 月 24 日 能不能考虑用缓存呢. |
 | 2 wander2008 2016 年 7 月 24 日 via iPhone 读写分离做了没有？如果没有，先试试再说。数据量不大，查询多，读写分离。 |
 | 3 ecloud OP @wander2008 因为想着把会员数据库单独拿出来就不需要读写分离了，因为会员数据跟业务逻辑没有太大相关性，这样以后维护起来也方便 |
| 4 wander2008 2016 年 7 月 25 日 via iPhone @ecloud 你这个就是分库行为了。 |
Select Language