【问题标题】:How many is too many databases on SQL Server?SQL Server 上有多少数据库?
【发布时间】:2011-03-17 22:59:36
【问题描述】:

我正在使用一个应用程序,我们将客户数据存储在每个客户的单独 SQL 数据库中。到目前为止效果很好,甚至出现了一些错误代码从数据库中选择了错误的客户 ID 的情况,并且由于数据库中的唯一数据属于该客户,因此损坏并没有想象中那么严重。我担心的是您在 SQL Server 上实际拥有的数据库数量。

您创建的每个新数据库是否有任何额外开销?我们最终碰壁了,我们在一台服务器上只有多个数据库? SQL Server 规范说您可以拥有 32000 个数据库,但有可能吗,有人在一台服务器上拥有大量数据库吗?您遇到了什么问题。

谢谢,

弗兰克

【问题讨论】:

  • 我正在考虑为我们目前正在开发的托管应用程序设置类似的设置,因此欢迎任何真实世界的战争故事 :)
  • 到目前为止,这个想法运行良好,但需要大量工具代码来支持。例如,我们有一个用于创建新站点的管理应用程序和一个用于将客户端从一台服务器移动到另一台服务器的导入/导出工具。迁移主要是为了调试,但未来我们计划有两台生产服务器来平衡负载。
  • 为每个客户端单独数据库的另一个重要副作用是它迫使您设计一个可重置的环境,您可以在其中快速创建应用程序的新实例并针对其运行单元/手动测试它。
  • 可能许多工具停止了高效工作(包括 SSMS)。 SQL Server 是否随数据库数量线性或二次扩展也不清楚。有过这样的错误。可能服务器启动延迟很大。

标签: asp.net sql-server database


【解决方案1】:

我知道这是一个旧线程,但它与我们在过去 2 年中使用的结构相同,目前在 3 台服务器上运行 1768 个数据库。

我们有以下设置(不包括镜像等):

  • 2 个网络场服务器和 4 个内容服务器
  • SQL 实例仅用于客户的主数据库,当他们通过 ID 访问其网页时查询该数据库以获取其数据所在的服务器/实例和数据库名称。然后将其存储在身份验证票证中。
  • 3 个 SQL 服务器,用于托管客户数据库,并根据每个服务器上所有数据库中存在的当前学习者总数(通过主数据库中的许可证号字段快速计算)在创建时分散负载。
  • 在每个 SQL Server 上都有一个较小的主数据库设置,其中包含所有客户端使用的共享静态数据,因此允许更小的客户端数据库和更快的内容更新。

上面提到的最重要的事情是保持数据库结构同步!为此,我最终编写了一个小型 .NET Windows 窗体,该窗体在主数据库中查找所有客户,然后将代码粘贴到执行中,它将循环获取数据库位置并执行您过去的 SQL。

创建新客户也给我们带来了一些问题,所以我最终为我们的销售人员编写了一个管理系统,它基于非活动“空白”数据库的备份创建了一个新数据库,因此我们拥有最新的数据库,没有需要重新编写整个数据库创建脚本。然后,它将客户详细信息插入主数据库,其中包含创建数据库的位置,并从我们软件的旧版本迁移任何旧数据。所有这些都是在移动之前在单独的实例上完成的,因此减少了任何 SQL 锁。

我们现在正在为我们的下一个版本的软件迁移到单个数据库,因为数据库冗余几乎是不可能的,因为有这么多数据库!这是一件需要考虑的大事,因为 SQL 创建了几个等待任务来镜像每个数据库的数据,一旦你开始增加数据库,它就会失控,系统几乎只负责同步,并且可能由于剪切而锁定线程数。请参阅下面的 Microsoft 文档第 30 页:

SQLCAT's Guide to High Availability Disaster Recovery.pdf

但是,由于上述一些问题,我确实对迁移到单个数据库存有疑虑,例如不断检查当前客户只能访问其数据的每个过程以及类似一点点的事情问题现在将影响每个数据库,例如表索引等。同样在我们的客户间隔超过 3 台服务器的那一刻,但单个数据库意味着是的,我们有冗余,但如果错误出现在数据库内而不是服务器停机,那么这是每个客户停机,而不仅仅是 1 个客户数据库。

总而言之,这取决于您在做什么以及您是否想要冗余;对我来说,冗余现在是关键,完美世界中的其他一切都不应该发生(例如导致每个人的数据库中出现错误的错误)。我们刚开始时只期望有 100 人左右从旧的自托管软件迁移到系统,很快就变成了 200,500,1000,1500……我们现在每年有超过 750,000 名用户使用我们的系统,在 8 月/9 月,我们在线并发用户超过 15,000 人(预计今年将达到 20,000 人)。

希望这对沿线的人有所帮助:-)

问候

利亚姆

【讨论】:

  • 哇,有很多数据库!我最终也在我正在从事的项目中实施了这种结构,并遇到了同样的陷阱。这种类型的设置需要更多的架构和自定义工具,而不是单个数据库系统,因此任何考虑的人都需要注意,这不适合胆小的人。
  • 完全同意“不适合胆小的人”这一点,因为我们必须定制很多东西才能让生活更轻松。我自定义了备份例程来备份每个备份并将其上传到 Amazon S3 存储。就像我说的那样,我现在的主要突破点是,如果没有大量的手动输入来在数据库中移动人员,我们就无法提供这种模型的冗余。
【解决方案2】:

上限是

  • 磁盘空间
  • 内存
  • 维护

例子:

  • 为 32k 数据库重建索引?什么时候?
  • 如果 10% 的 32k 数据库中的每个数据库同时在内存中都有一组 100MB 的活动数据,那么您的目标服务器内存已经达到 320GB
  • 了解您连接的数据库
  • ...

有效限制取决于负载、使用情况、数据库大小等。

编辑:Wyatt Barnett 提到的带宽......我忘了网络,每个人都忘记的瓶颈......

【讨论】:

  • 我确信数据库的数量存在实际限制,但正如您所说,您会很快达到实际资源限制。
  • 那么对于内存来说,拥有一个拥有 500 兆数据的数据库与拥有 5 个数据库每一个拥有 100 兆数据的数据库有什么不同吗?数据库结构需要的内存量很大吗?
  • @Frank:如果全部同时使用,不会。占用空间的是数据库中的数据,而不是结构
【解决方案3】:

从架构上来说,这通常是正确的调用。您已经看到了第一个巨大的优势——通常,损害可能仅限于单个客户,并且您的客户进入另一个客户的数据的风​​险几乎为零。但是您错过了另一大优势——您不必将所有客户端都保留在同一个数据库服务器上。当您的服务器变得足够大时,您可以毫不费力地将客户端完全卸载到另一个机器上。

我还敢打赌,在您的服务器无法处理更多数据库之前,您将耗尽带宽来管理数据库。 . .

【讨论】:

    【解决方案4】:

    所有多个数据库的最大问题是在您进行架构更改时使它们保持同步。就实际数量的数据库而言,您可以拥有并使系统正常工作,这取决于往常。这取决于服务器有多强大以及数据库有多大。您可能希望在某个时候拥有多台服务器,这不仅是因为它对您的客户来说会更快,而且因为如果服务器发生问题,它会一次性让更少的客户面临风险。在什么时候,只有您的公司可以决定。当然,如果您开始出现大量超时,则可能会指示另一台服务器(或者修复您的不良查询也可能会这样做)。大客户通常会为使用单独的服务器支付额外费用,因此请在定价时考虑这一点。我们有一个客户对他们的数据如此偏执,我们不得不有一个单独的服务器,甚至不与其他服务器位于同一位置。他们为此付出了高昂的代价,因为我们不得不租用额外的空间。

    【讨论】:

      【解决方案5】:

      您真正要问的是可扩展性;虽然,理想情况下在一台服务器上设置 32,000 个数据库可能并不有利,但这是可能的(但不推荐)。

      阅读 - http://www.sql-server-performance.com/articles/clustering/massive_scalability_p1.aspx

      【讨论】:

      • 我将链接放在底部作为参考,但它没有保存。对于造成的混乱,我深表歉意。
      【解决方案6】:

      ISP 通常拥有一台由数百或数千个数据库共享的数据库服务器。

      【讨论】:

        猜你喜欢
        • 2012-05-05
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-01-13
        • 1970-01-01
        • 2018-01-20
        • 2012-08-31
        相关资源
        最近更新 更多