26

您必须忍受我在这里可能会弄错一些术语，因为我什至不知道这属于整个“多租户”“软件即服务”类别，但在这里确实如此。

我为客户开发了一个会员系统（用 PHP 编写）。我们现在正在考虑为我们的其他客户提供一个完全托管的解决方案，提供一个子域（甚至是他们自己的域）。

就数据存储而言，我似乎有以下选择：

选项 1 - 将所有内容存储在 1 个大数据库中，并在需要它的表上有一个“client_id”字段（大约有 30 个表适用），并有一个“客户”表存储其主要设置、详细信息等以及映射到它们的域。然后，这只会设置一个包含其各自客户端 ID 的全局可访问变量 - 我显然必须修改每个查询以检查 client_id 列。

选项 2 - 有一个包含“共享参考”表和“客户”表的主表。然后有其他数据库的“块”，每个数据库都包含 10 个客户端。客户将获得他们自己的数据库表，并以他们的客户 ID 为前缀。如果真的出现问题，这会增加一点安全性，以防止看到其他客户端数据。

选项 3 - 与选项 2 完全相同，除了每个客户端都有 1 个数据库，将它们与其他客户端完全隔离，理论上提供更多保护，如果 1 个客户端的表被黑客攻击或以其他方式损坏，它不会影响其他任何人。最大的缺点是，在部署新客户端时，需要设置整个数据库、用户和密码等。这是否也可能导致相当大的开销，或者就像你让所有人都在一个一样数据库？

还有几点——其中一些客户将拥有 5000 多个“客户”以及这些客户的所有详细信息——这就是为什么选项 1 可能有点问题——如果我有 100 个客户，那可能等于1 个表中超过 50 万行。

在客户数据（和支付信息）的安全性是关键的情况下，我认为选项 3 是最好的方法，我是否正确。根据我的建议，有些人说选择选项 1，因为“它更容易”，但我真的不这么认为。我认为这是一个潜在的瓶颈，因为如果他们有自己的数据库，我可以更容易地移动客户。

（仅供参考，该系统是基于 PHP 和 MySQL 的）

4

3 回答 3

18

选项 3 是最具可扩展性的。虽然一开始它可能看起来更复杂，但它可以完全自动化，并且会为您省去未来的麻烦。您还可以通过在多台服务器上拥有客户端数据库来更有效地扩展以提高性能。

于 2012-11-10T21:26:07.397 回答
2

我同意 Ozzy 的观点——我这样做是为了一个在线数据库产品。我们有一个主数据库，它基本上有一个美化的用户表。每个客户都有自己的数据库。这样做的好处是我可以轻松地将一个客户数据库从服务器 A 移动到服务器 B [mysql]，并且可以在紧要关头使用命令行工具来完成。同样对大表进行维护，删除/添加索引真的会搞砸你的应用程序，特别是如果说添加索引会锁定表 [mysql]。它影响到每个人。使用较小的数据库，您可能会更不受此影响，并且当您需要推出模式级别更改时有更多选择。我只是喜欢灵活性。

于 2013-04-03T16:41:56.693 回答
1

多年前，当我设计一个用 PHP 构建 SaaS 应用程序的平台时，我选择了第三种选择：多租户代码和单租户数据库。

以我的经验，这是最具可扩展性的选项，但它还需要一组脚本来在更新代码、数据库方案、为租户启用应用程序等时传播更改。

因此，我花了很多精力来构建基于组件的可扩展引擎，以完全自动化所有这些任务并最大限度地减少系统管理工作。如果您想采用第三种选择，我强烈建议您构建这样的架构。

于 2015-05-20T17:41:32.583 回答