SQL Server 体系结构指南

Question

我们正在根据新架构设计现有产品的新版本。 它是一个内部 Web 应用程序，可能有 100 个并发用户（最大）这将在 SQL Server 2008 数据库上运行。

最近的讨论项目之一是我们是否应该有一个单一的数据库，出于性能原因将数据库拆分为 2 个独立的数据库。

数据库可以在 5 年内增长到 50-100GB。

我们是开发人员而不是 DBA，因此很高兴获得一些一般性指导。

[我知道答案并不简单，因为它取决于架构、归档策略、数据量等。]

选项 1 单一主数据库 [这是我的首选]。

计划是将所有表放在一个数据库中，如果需要跨多个磁盘，可能会使用文件组和分区来分隔数据。 [如果合适，使用模式]。这应该处理性能问题 其中一个问题是单个服务器实例仍将处理此数据，因此仍存在处理瓶颈。

对于报告，我们可以有一个单独的报告数据库，但这仍在讨论中。

选项 2 将数据库拆分为 2 个单独的数据库

DB1 - 客户、帐户、客户资源等

DB2 - 这将包含大量数据 [即车辆跟踪数据、金融交易表等]。

这些表通常包含大量数据。 [如果需要，它可以驻留在单独的服务器上]

该计划包括将主要数据保存在较小的数据库 [DB1] 中，并将 [主要] 只读事务类型数据保存在单独的数据库 [DB2] 中。 UI 将主要从 DB1 读取，因此响应速度更快。 [我知道此选项使执行参照完整性变得更加困难。]

考虑的要点 由于我们正处于设计阶段，我们至少可以正确使用索引来处理性能问题，这就是为什么选项 1 对我来说很有吸引力并且它更像是一种标准方法。 对于这两个选项，我们正在考虑实施一个归档数据库。

为这个冗长的问题道歉。总而言之，问题是 1 DB 还是 2？

提前致谢，

利亚姆

Answer 1

我同意其他 cmets 的说法，即如今 50 到 100GB 之间的空间很小。我也同意你不应该过度设计。

但是，如果您存储的实体之间存在明显（或不那么明显）的逻辑分离（就像您说的那样，一个是读写的，而其他部分主要是只读的），我仍然会将其拆分为不同的数据库。至少我会以一种我可以很容易地分解出一个部分的方式来设计它。安全性是一个原因，管理/备份/恢复是另一个原因，更易于维护（因为从本质上来说，设计会更好地考虑因素并且部件之间会更好地隔离），并且在 SQL Server 中，具有横向扩展能力（或者如果它缺乏横向扩展能力）是一个单一的数据库）。例如，分离登录和内容数据库对于更大的 Web 应用程序通常是有意义的。

而且，如果你真的想要一个合理的设计，将你的实体分离在一个数据库中，使用不同的模式，对对象设置适当的权限，在我看来你最终会付出几乎相同的努力。

SharePoint、TFS 和 BizTalk 等 Microsoft 产品都使用几种不同的数据库（尽管我不假装知道原因/可能只是他们组织团队方式的结果）。

特别是关于你不能在 SQL Server 上扩展单个数据库实例（集群需要多个实例），我很想拆分它。

@John：我从不使用 RAID5。除了损害性能之外，没有其他目的。我同意 RAID10 方法。

Answer 2

我认为选项 1 是可行的方法。

CPU 不太可能成为 100 个并发用户提供工作负载的瓶颈。您可以通过热插拔技术购买具有额外 CPU 容量的单个多插槽服务器，以便在您愿意时提供增长空间。根据您的可用性要求，您还可以考虑使用集群解决方案，以便通过强制故障转移到另一个节点来交换更多处理 CPU 资源。

磁盘子系统的性能将是您最关心的问题。您的设计决策将受到您使用的存储解决方案的影响，我认为这将是 SAN 技术。

您至少需要将 LOG（RAID 1）和 DATA 文件（RAID 10 或 5，取决于工作负载）放在单独的 LUN 上。

根据您的表访问权限，您可能希望考虑将不同的文件组放在不同的 LUN 上。对表数据进行分区可能对您有利，但仅适用于大型表。

Answer 3

将数据放入另一个数据库不会对性能产生丝毫影响。性能完全是其他因素的一个因素。

创建新数据库的原因是出于维护和管理的原因。例如，如果一组数据需要不同的备份和恢复策略或具有更高的可用性要求。

Answer 4

按照当今的大多数标准，50 到 100GB 和 100 个用户是一个非常小的数据库。不要通过尝试解决您甚至还没有看到的问题来过度设计您的解决方案。将其拆分为两个数据库，尤其是在两个不同的服务器上会产生一大堆令人头疼的问题，如果没有的话你会更好。而是将精力集中在创造有用的产品上。