多租户数据库架构

Question

我正在开发一款SAAS应用程序，我们正在讨论每个客户一个数据库还是共享数据库的问题。我已经阅读了很多资料，包括这里的一些主题，但我仍然有很多疑问。

我们的平台应该是高度可定制的，以适应每个客户的需求(他们应该能够拥有自定义表并向现有表中添加自定义字段)。在这种情况下，多个数据库方法似乎很不错。

问题是：我的“用户”表应该在主数据库还是在每个客户端的数据库中呢？一个用户可能会有一个或多个组织，因此它将存在于多个数据库中。此外，像国家表等通用表怎么办？

在主数据库中使用它们是有道理的。但我有许多带有“created_by”字段的表，它们具有对用户的外键。同时也有一些客户相关的权限表。

如果使用多个数据库，我将失去外键的作用，这意味着需要向数据库进行更多的查询。我知道如果它们在同一服务器上，可以使用跨数据库连接，但这会导致可扩展性降低（未来可能需要多个数据库服务器）。我曾考虑过联合表，但对于性能并不确定。

我正在使用php和symfony 2框架以及mysql数据库技术。另外，我也担心这样一个系统的维护。我们可以创建一些脚本来自动化所有数据库中的模式更改，但如果我们有10k个客户，那将意味着10k个数据库。

你对此有什么看法吗？我的应用程序的主要特点应该是灵活性，因此如果客户需要比基本平台更具体的东西，应该可以为他完成。

- brpaz

---

请阅读此链接：http://msdn.microsoft.com/zh-cn/library/aa479086.aspx - Neil McGuigan

@Moderators - 这种问题应该发到哪个StackExchange上？毕竟这是一个好的讨论话题，可以让人们学到东西。 - David Robbins

又一个封闭的问题，太好了。 - slier

Answer 1

这里有一些经典问题。你去过http://highscalability.com/吗？那里有一些好的案例研究。

从个人经验来看，如果你试图在一台服务器上共享客户端，你会发现一个非常成功/活跃的用户会随着时间的推移占用机器的所有资源。我们在SAAS中有一个客户在共享服务器上崩溃了，我们不得不将他移到其他地方。

我会将全局枚举拆分成服务。你可以创建一个集中的数据库，用于存储国家列表、州份列表等信息，并将其放置在Web服务层后面。此外，在该数据库中，您可以进行用户管理/管理哪个服务器属于哪个用户等操作。您可以创建一个管理门户，从而读取/写入此数据库以管理您的用户群体。

如果我再次做SAAS，我会从小做起，等待疼痛来临。您真正需要的是在出现扩展性问题时解决它们的好工具。准备好一些脚本，以便在多台服务器出现后在这些服务器间执行滚动架构更改。有脚本可用于在修改模式时关闭机器。有脚本可以将用户从共享服务器迁移到专用服务器。

考虑从中央数据库设置复制。这将不需要您编写大量代码而将全局信息传输到每个用户分区/数据库所需。

但是我看到的并且亲身经历的最重要的建议是 - 不要过于努力地构建下一个适合扩展的Facebook。首先从简单的开始，看看实际发生了什么，然后再担心主要的可伸缩性问题。随着用户群体的增长，你可能会惊讶地发现什么可以很好地扩展和什么不行。

- ryan1234