为 50.000 多家商店使用一个数据库是个好主意吗？

Question

我知道 Shopify 只为所有商店使用一个数据库。但是他们如何处理拥有如此大数据的数据库呢？为 50.000 多家商店使用单个数据库是个好主意吗？

Answer 1

请注意：我是从 SQL Server 的角度来回答的，所以我提到了一些特定于 SQL Server 的概念，但我相信所有这些概念在其他主要 RDBMS 平台中都有等价物，具有相似的优点和局限性。

当我想到其他潜在的利弊时，我也可能会继续编辑这个答案。

嗯，这真的取决于架构、数量等。商店存储的究竟是什么？它与存储大约 50,000 只猫或 50,000 种产品或 50,000 个翼形坚果的数据有何不同？

如果确实可以按客户完全隔离数据（不包括查找表，例如邮政编码或特定于应用程序的表，可以进入单个中央数据库）：

• 如果一个客户超过了应用程序，没有简单的方法来提取他们的数据并将其移动到另一个实例、服务器等以进行横向扩展，除非您提前计划并在类似的东西上进行分区CustomerID并拥有 50,000 个文件组（您是有限的无论如何，到 15,000 个分区，或者如果您使用的是较旧版本的 SQL Server，则为 1,000个分区，并且文件组过多可能是灾难性的）。另请注意，分区需要企业版。

• 如果事实证明您的所有客户对于这个实例来说都太大了，那么横向扩展意味着获得新硬件并将整个数据库移到那里（并且可能会再次这样做）。

• 删除客户可能同样痛苦，因为您必须从非常大的表中删除一些行，这不会很便宜。

• 您可能拥有广泛分布的客户数据（一个客户有 10 亿行，另一个客户有 5,000 行）。这可能导致诸如参数嗅探和涉及基数和计划质量的有害性能（因为您可能会针对非常不同的数据集对相同的查询重复使用相同的计划）。

• 您的所有客户都受到完全相同的 SLA 和 HA/DR 计划的约束。您要么让整个数据库处于完整恢复模式并进行 n 分钟日志备份，要么处于简单状态并依赖完整+差异备份。如果由于客户错误而必须恢复，或者需要将数据库恢复到某个时间点，这会影响到每个客户。

• 数据检索中可能会出现错误——例如，where 子句中的错误可能导致一个客户看到另一个客户的数据，或所有其他客户的数据。

• 可能会有法律影响（有些公司会严格要求您不要将他们的数据与任何其他公司，尤其是竞争对手的数据放在同一个数据库中）。

• 如果任何客户数据的安全性很重要，那么使用数据库分离比在表内分离更容易实现这一点。

将每个客户放在单独的数据库中的一些优势（或至少有多个数据库，每个数据库都用于一组客户）：

• 就大小而言，它将在磁盘上占用大约相同的大小。
• 向外扩展更容易，因为您可以将一个（或多个）数据库移动到不同的服务器。
• 删除一个客户及其所有数据大致相当于DROP DATABASE.
• 您为计划使用了更多内存（或者每个客户的缓存计划更少），但至少这些计划与其各自数据库中的数据相关，并且不太容易出现统计/参数嗅探问题。
• 您可以轻松拥有不同的 SLA 和 DR 计划，将一些数据库完整放置，而其他数据库放置简单。此外，恢复或恢复到某个时间点只会影响该客户。
• 您可以轻松地将不同的数据库（例如，您的高优先级客户）置于更快的 I/O 上。您可以在具有文件组的单个数据库中执行此操作，但管理起来要棘手得多（至少恕我直言）。

一些缺点：

• 撇开大小不谈，您可能不希望在单个 SQL Server 实例上拥有 50,000 个数据库，因此这可能意味着扩展到多台服务器。
• 启动时间会增加，因为启动每个数据库都有一些固有的开销。
• 该应用程序必须更智能一点——它必须动态连接到 CustomerID 的数据库，而不是只在 where 子句中包含 CustomerID。有了适当的中间层，这并不难，但这是一个变化。
• 是的，您有许多相同表和过程的副本，但是跨数据库的代码和模式是相同的，只是数据不同。因此，部署代码/架构更改现在只是一个循环而不是单个执行。
• 当您管理 50,000 个数据库时，维护有点不同 - 总体大小也大致相同，但过程必须改变 - 您不能一次对所有 50,000 个数据库进行碎片整理/重新索引/备份。话虽如此，在我之前的工作中，我管理了 500-1,000 个相同数据库的实例，管理 3 个相同数据库和 750 个相同数据库之间的区别只是所需的时间。