每个客户端一个数据库在什么时候变得不可行？

Question

对于我们的一个系统，我们拥有敏感的客户数据并将每个客户的数据存储在单独的数据库中。我们有大约 10-15 个客户用于该系统。

但是，我们正在开发一个新系统，该系统将拥有 50-100 个客户，也许更多。我认为在这种情况下每个客户端拥有一个数据库可能是不可行的（用于存储敏感记录和审计历史）。但是我不知道这是否完全正常，或者是否有另一种维护安全的方法。

对此有何想法？

Answer 1

管理 100 或 500 个数据库与管理 5 个或 10 个数据库实际上并没有什么不同 - 您只需要接受自动化并制定可扩展性计划（并且不要计划使用每个数据库的高成本功能，例如跨所有数据库进行镜像）客户）。

在我之前的工作中，我们使用了这种架构，我从来没有想过将两个客户端合并到一个数据库中，即使有些挑战可能很“困难”。

最大的好处是独立的恢复模型（a可以是简单的，b可以是完整的等），能够在不干扰其他客户端的情况下恢复到某个时间点（或完全删除）客户端，能够无缝移动资源密集型客户端到它自己的存储或完全不同的服务器，几乎没有透明度（您更新配置文件或表，告诉应用程序在哪里可以找到该客户端）。

我在这些帖子中解决了一些反对意见和/或如何解决问题：

• 在多租户数据库架构中处理越来越多的租户

• 使用 SQL Server 2008 的多租户数据库？

• 大量数据库备份自动化

话虽如此，我认为我们中的任何人都无法告诉您管理在什么时候对您来说变得不切实际——只要知道无论您遇到什么具体挑战，您都可以单独询问这些问题。

Answer 2

我建议您阅读多租户数据架构，这是一份讨论您拥有的选项以及优缺点的白皮书。总而言之，它提供了三个选项：

• 单独的数据库
• 单独的模式
• 共享模式

您现在处于单独的 DB 阶段，这提供了最好的分离（租户之间的隔离），但也是最难管理的。随着您成长为数百个租户，您会意识到管理 100 个 DB 的后勤工作绝非易事。想想备份还原（备份文件、作业、计划等的位置）。想想您将如何监控和管理数百个数据库中的文件分配、磁盘空间使用和数据库增长。想一想在不久的将来，拥有 1000 个租户的高可用性/灾难恢复方案会是什么？1000 个镜像数据库，1000 个日志传送会话？想想如果 6 个月后你的开发团队来找你说“我知道如何为我们的产品提供这个很棒的功能，我们将使用事务复制！”，你会说什么？“当然，让我建立 500 个出版商，“！不是不可能的可管理数百个DB的，但如果你打算，你最好擦亮你的PowerShell使用的用户界面管理工具，技能和停止现在。

此外，您需要考虑多个（数百个）数据库对性能和成本的影响可衡量：

• 物理磁盘空间的使用效率较低（每个数据库都必须有一些空闲空间，您将拥有该空闲空间乘以 DB 数量）
• 您无法为写入密集型任务创建专用日志磁盘，您必须将所有这些 LDF 移动到一个（或多个）SSD 存储上
• 日志写入在频繁提交时效率较低，因为它们分布在许多单独的日志块记录中而不是聚合成一个（您将得到未充分利用的日志块）。请参阅什么是 LSN：日志序列号以了解我在说什么。

尽管由于隔离，分离的数据库具有一些优势，主要优势是独立的备份/恢复。

像您这样的场景是SQL Azure 数据库的完美候选者。无需管理磁盘空间，无需提供 HA/DR，可增长到数百/数千 DB 等。