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

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

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

考虑到其他潜在的优点/缺点，我可能还会继续编辑此答案。

好吧，这实际上取决于架构，数量等。商店究竟存储了什么？与存储约50,000只猫或50,000种产品或50,000个蝶形螺母的数据有何不同？

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

• 如果一个客户超出了应用程序的范围，就没有简单的方法来提取他们的数据并将其移动到另一个实例，服务器等以进行扩展，除非您事先计划并在诸如CustomerID50,000个文件组的分区上进行分区（这是有限的）最多可以有15,000个分区，如果使用的是旧版SQL Server，则为1,000 个分区，并且文件组过多可能会造成灾难性的后果）。另请注意，分区需要企业版。

• 如果事实证明您的所有客户对于此实例而言都太大了，那么向外扩展就意味着需要购买新硬件并在其中移动整个数据库（并且有可能再次这样做）。

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

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

• 您所有的客户都必须遵守完全相同的SLA和HA / DR计划。您要么使整个数据库处于具有n分钟日志备份的完全恢复模式，要么处于简单状态，并且依赖于full + diff备份。如果由于客户错误而必须还原，或者需要将数据库恢复到某个时间点，那么这会影响每个客户。

• 数据检索中存在错误的可能性-例如，where子句中的错误可能导致一个客户看到另一位客户的数据，或者看到另一位客户的所有数据。

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

• 如果任何一个客户数据的安全性都很重要，那么使用数据库分离比在表中分离要容易得多。

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

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

一些缺点：

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