出于性能原因，什么时候应该将数据库拆分为2-3个数据库？

Question

我不是数据库性能方面的专家。一位同事建议将BI数据仓库数据库拆分为几个基于功能业务单元的数据库--我相信仍然存在于一台机器上，尽管我不确定--出于性能原因--有许多过程、过程、日志记录和监视正在发生。这与安全性或权限无关--事实上，这些可能会变得更加复杂。

再说一遍，我不能说我是专家，但出于某种原因，这在我看来是不合逻辑的。DB的总容量约为500 GB，我们有大约200个表。当然，由于性能原因，我粗略研究得出的大多数解决方案似乎都建议提高磁盘驱动器的速度(如SSD)或RAM (目前为4GB)。或者可能保留一个逻辑数据库，但将模式分解为2-3台不同的机器。

但我不知道。是否有重要的用例或性能原因将一个数据库拆分为两个逻辑数据库--除了用户权限/安全性之外，这不是这里的一个因素。在这些3-4个数据库中将有许多视图。

这里有读取操作、规范化、调优选项或数据库/表锁吗？我的直觉告诉我不是--这些都是完全不同的问题，但我肯定是错的。我只是担心，如果不是零的话，我们将进行最低限度的性能改进，以获得大量额外的复杂性和维护。

很明显，我到这里来的时候已经在一边倾斜/有偏见了，但我很想知道你的想法。

Answer 1

大小并不是进行数据库拆分的真正原因。如果查询性能较慢或其他类似的因素，则可能。但是请记住，使用相同的硬件和存储来分割数据库只会带来很少的好处。也有可能对数据进行分区，这将完成类似的任务。

问题是，这是作为一种可能不适合的解决办法而设计的。我有多兆字节的数据库，响应速度超过100 GB数据库，因为它在生命周期的一英寸范围内被调优和索引。更换硬件往往会掩盖糟糕的数据库和查询设计。一个直接的解决办法是增加更多的RAM。8GB将是我希望在SQL服务器中看到的最小值，但考虑到数据库的大小，我建议至少为128 GB。

最终，我们需要更多关于您正在经历的性能问题的信息，以便指导您找到更完整的解决方案。

Answer 2

回应塔拉的评论，我会澄清你想要解决的问题。如果存在性能问题，我想不出为什么如果数据库被拆分并且仍然存在于同一台服务器上，您将获得更高的性能。

而不是一个30磅左右的重量，你是建议携带大约3，10磅的重量。还是一样重。

Answer 3

由于性能原因，您应该拆分数据库，一旦有证据表明这是您拥有的性能瓶颈(或为了进一步扩展)

在没有性能问题的情况下，无论是负载测试还是负载测试，您都将修复一些可能是瓶颈的东西，也可能不是瓶颈。即使您的瓶颈是拆分数据库的需要，业务单元也可能不是正确的拆分方式(例如，如果50%的查询针对的是最后2天的数据，那么过去2周的查询率是40%，而旧的数据是10%，那么所有业务单元都是这样吗？)

虽然拆分并不是不可能的，但您应该首先探索各种途径(为了简单起见)，特别是：

• 调优指标
• 对数据库进行分区(仍然是同一个数据库，但分布在不同的文件上，最好是磁盘卷)