在什么时候每个客户端只能使用一个数据库？

31

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

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

有什么想法吗？

database-design sql-server-2012

— NibblyPig
source

我不知道每个服务器具有多个数据库的利弊（我从来没有任何问题），但是在同一数据库中的许多架构概念technet.microsoft.com/en-us/library/dd207005.aspx都提供了这两种方法隔离和安全。因此，您也可以尝试这种架构。

— Alexandros

2

@Alexandros模式分离提供了一些好处，但是它不允许您使用单独的恢复模型，按不同的时间表进行备份，将一个客户端还原到特定的时间点，轻松地删除一个客户端，轻松地移动一个客户端等等

— 亚伦·伯特兰（Aaron Bertrand）

4

我已经看到在单个服务器上具有3,000多个数据库（每个客户端1个）的系统。我不会太担心-只要确保您仔细计划资源并在客户端数量增加时监视使用情况即可。

— Max Vernon

你可能会读这一点，特别注意日期和OPS评论：stackoverflow.com/questions/5596755/...

— NotMe

48

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

在我之前的工作中，我们使用了这种体系结构，即使有一些挑战可能是“艰巨的”，我也从未想过将两个客户端合并到一个数据库中。

最大的好处是独立的恢复模型（a可以是简单的，b可以是完整的等），可以在不中断其他客户端的情况下恢复到某个时间点（或完全删除）的功能，可以无缝移动大量资源的客户端的功能迁移到自己的存储或完全不同的服务器，而透明性很少（您可以更新配置文件或表来告知应用程序在哪里找到该客户端）。

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

综上所述，我认为我们谁也无法告诉您管理对您不切实际的一点-只要知道您遇到的任何具体挑战，就可以单独询问这些问题。

— 亚伦·伯特兰
source

6

您还将需要一个良好的命名约定，并保持一致。

— Greenstone Walker

谢谢那些是很棒的链接。（目前）这实际上不是管理问题，我只是担心事情可能会停顿下来。但是似乎我不必为此担心，只需确保我可以管理所有内容即可。那谢谢啦！

— NibblyPig 2014年

@Aaron我在OMS中也有类似的情况，在那里我有多个处理订单的车间，它们是独立的。根据订单（客户）地址选择车间。因此，客户可以在多个工作区中获得订单。因此，当需要在每个数据库服务器上加载客户订单历史记录时，这很困难。

— Navrattan Yadav

15

我建议您阅读Multi-Tenant Data Architecture，该白皮书讨论了您的选择以及优缺点。总而言之，它提供了三个选项：

单独的数据库
单独的模式
共享架构

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

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

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

尽管由于隔离，分离的DB也具有一些优势，主要优势是独立的备份/还原。

像您这样的方案是SQL Azure数据库的理想选择。无需管理磁盘空间，无需提供HA / DR，可扩展到成百上千的DB等。

— 雷木斯·鲁萨努（Remus Rusanu）
source

谢谢，这是一些很好的建议，尤其是可能切换到云模型。我将不得不认真考虑如何处理备份内容。

— NibblyPig 2014年

并且一旦您的自动化开发得足够好，可以为每个客户端支持单独的数据库，那么为每个客户端提供单独的VM并不是一个巨大的飞跃。毕竟，这就是“云”托管公司的工作。同意这对于SQL Azure可能是一个很好的用例

— Gavin Campbell

2

在我之前的工作中，我们不仅为每个客户端托管一个数据库，而且在大多数情况下，托管的数据库还不止于此！在我离开时，在一个MariaDB集群中运行着4,500多个数据库，在另一个（具有讽刺意味的是，较小的）集群中运行着近7,000个数据库，以及4个“分片”（完全独立的独立Web和数据库服务器，甚至在一个完全独立的数据中心中），每个主机单个MySQL服务器中包含200-500个数据库。该公司仍在快速发展。

总而言之，就是该公司的成功证明了这种架构确实可行。（注意：与通过使用单独的数据库单独获得明显的收益相反，所有数据都是通过三个紧密耦合的应用程序访问的，这些应用程序都使用相同的数据库用户/密码！我怀疑如果每个客户端的性能可能会受到轻微影响有一个单独的用户/密码-但只有一点点。）

根据与系统管理员紧密合作的经验（从技术上讲，我是公司的程序员，但实际上，我是他们拥有的最好的DBA，也是唯一的他们知道如何设置防火墙的人！），与性能相关这些问题归结为并发访问，查询复杂性/时间，索引性能等。换句话说，所有常见的可疑对象以及服务器上的数据库数量都没有明显的作用，这一结论得到了高薪专家的肯定。我们定期咨询的顾问。

最重要的是，您应该将关注点集中在应用程序，基础结构上，而不是您碰巧拥有的数据库数量上。所有其他因素将足以让您忙于解决性能问题和瓶颈。

— 克罗米
source