ric*_*res 10 postgresql distributed cassandra
我在postgresql中有一个数据库,用于作为服务的软件,有数百个客户,目前每个客户都有一个postgresql模式,但我喜欢最好的解决方案,因为客户迅速增加.我读到了cassandra,但我不想失去主要,外键和支票的完整性.另请阅读分布式系统中的postgresql,但我不知道目前实现此目的的最佳方法是什么
kgr*_*ttn 10
您可以将客户分为四个级别:
为每个客户运行单独的PostgreSQL集群.这提供了最大的分离; 每个客户端都在一个单独的端口上,它有自己的一组系统表,事务日志等.
将每个客户放在同一群集中的单独数据库中.这样它们每个都有一个单独的登录,但在相同的端口号上,它们共享全局表,如pg_database.
在同一个数据库中为每个客户提供单独的模式.如果它们仅通过您的软件连接,则不需要单独的用户ID,因为您只需设置search_path即可.当然,如果您愿意,可以使用单独的用户ID.
使customer_id成为每个表的主键的一部分,并确保在您的软件中限制.这可能比为数百个用户中的每个用户提供重复表更好地扩展,但您必须非常小心,始终通过customer_id限定您的查询.
已知有些人将这些技术结合起来,例如,将每个群集限制为100个数据库,每个客户都有一个单独的数据库.
没有更多细节,很难知道哪种配置最适合您的情况,除非要说如果您想让用户直接访问数据库而不通过您的软件,您需要考虑系统表中可见的内容每个选项.从用户角度查看pg_database,pg_user和pg_class,以查看公开的内容.
我不想失去主要,外键和支票的完整性
像Cassandra这样的系统的一点是,一旦你的数据集或工作负载不适合单个机器,你就必须放弃那些东西,即使你留在postgresql上也是如此.(我覆盖在谈话的细节,我强烈建议:http://blip.tv/pycon-us-videos-2009-2010-2011/pycon-2010-what-every-developer-should-know-about-database -scalability-21-3280648).
所以Cassandra是对这个问题的回答,"如果我们知道我们将不得不放弃外键和连接,我们可以通过重新思考我们如何设计数据库来构建什么？"
如果你从来没有达到这一点,卡桑德拉就有点矫枉过正了.(但你仍然应该看那个话题.:)