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