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