基于客户端的网站的最佳数据库策略(Ruby on Rails)

Question

我已经建立了一个很好的网站系统,以满足小型利基市场的需求.去年我通过使用Capistrano将软件副本部署到我的网络服务器来销售这些网站.

在我看来,这些网站的唯一区别是数据库,CSS文件以及用于单个客户端图形设计的一小组图像.

其他一切都完全一样,或者应该是......现在我已经部署了大约20个这样的站点,用相同的代码保持它们全部更新变得很麻烦.这个问题只会变得更糟.

我想我应该重构这个系统,这样我就可以使用一组部署的ruby代码,通过传入请求的URL动态选择正确的数据库等.

似乎有两种处理数据库的方法:

• 使用多个数据库,每个客户端一个
• 使用一个数据库,每个表中有一个client_id字段,以及一个额外的"客户"表

多数据库方法对我来说是最简单的,因为我不必重构应用程序中的每个模型来将client_id字段添加到所有CRUD操作中.

但是,每次我想要迁移数据库时,必须为数十个或数百个不同的数据库运行"rake db:migrate"是一件麻烦事.显然这可以通过脚本完成,但它闻起来不太好.

另一方面,每个客户在'items'表中将有20K-50K项目.当items表中有五十万或几百万个项目时,我担心全文搜索的速度.即使在client_id字段上有索引,我怀疑如果将项目分成不同的客户端数据库,搜索会更快.

如果有人对解决这个问题的最佳方法有了明智的意见,我非常希望听到它.非常感谢...

- 约翰

Answer 1

使用单独的数据库（包括您已经列出的数据库）有以下优点：

• 当您有数百万个大型文本 blob 需要搜索时，全文搜索将变得很慢（取决于服务器的功能）。
• 分离数据库将使每个客户端的表索引速度更快。特别是，如果您接受一个新的大客户，可能会令一些早期采用的客户感到不安。突然之间，他们的应用程序将因为（对他们）没有明显原因而受到影响。同样，如果您的硬件容量不超过您的硬件容量，这可能不是问题。
• 如果您删除了某个客户端，那么只打包其数据库比通过 client_id 删除所有关联行要干净一些。如果他们以后改变主意，也同样可以干净地恢复它们。
• 如果任何客户要求他们愿意付费的附加功能，您可以分叉他们的数据库结构，而无需修改其他任何人的数据库结构。
• 对于悲观主义者来说：您意外地破坏所有客户端数据而不是仅破坏一个客户端数据的可能性较小。;)

话虽如此，单一数据库解决方案可能更好：

• 您的数据库服务器的功能使大型单个表不再是问题。
• 您客户的数据库保证保持相同。
• 您不必担心是否能够为了存档/恢复或发生灾难而对每个人的数据进行划分。