将数据仓库拆分为多个数据库的主要原因是什么？

Question

我正在与一位同事合作，他建议将我们的 1 个实例数据库拆分为大约 7 个数据库（按数据域划分）用于开发和 7 个相同的数据库用于生产。我得到了测试生产二元性逻辑，但是在什么情况下或将我们的 1 个相对简单的数据库拆分为 7 个数据库有什么优势？我们的数据仓库仅由一个商业智能应用程序消耗/使用，期间。

我很关心这个方向，所以希望你能讨论提出这个拆分的一般原因，我可以给你一个数据库当前属性的概要。

1 个数据库数据仓库：总共 352 GB，203 个表，170 个视图

建议拆分：

A: 280 GB
B: 43 GB
C: 28 GB
D: 1 GB
E,F,G: < 1 GB combined

正如您所看到的，就提议的好处而言，这已经是一个令人头疼的问题，因为存储甚至不会远程平均分配，80% 还留在 1 个数据库上。显然，按架构对我们的数据库进行分区是不可能的（从硬件角度来看），因为我们没有企业级 SQL Server。

给出的拆分原因：

1. 当前的数据库优化不佳，文档很少，数据类型次优，索引次优。

我的菜鸟想法：这些问题不是和数据库拆分无关吗？它们只是需要以任何方式自行解决的问题。

2. 当前数据库中有 372 个对象，这使它变慢。

我的想法：在我看来，这似乎并不大。

3. 一个数据库比 7 个数据库更难记录和绘制模式图（我们将拥有跨越多个数据库的视图）。

我的想法： .... 这对我来说似乎完全荒谬，但也许我错了。我们已经按照 13 个“源系统”模式组织了我们的数据仓库。

4. 一个数据库会导致更多的数据库死锁。

-- 这个问题不是也和多数据库完全无关吗？我的理解是死锁发生在表级别（实际上通常甚至只是行级别，但是呃）。即便如此，我们所有的数据插入都发生在午夜，我们所有下游到 BI 的选择发生在凌晨 2 点。让两个进程更新同一个表与多个数据库无关，是不是（死锁会发生）？另外，我个人没有看到在正常操作期间发生表死锁的证据。

5. 数据库技术所有权/所有权。

只有我们两个人在数据库上工作。他有可能真的想隔离我们的“封地”。真的，这不是问题，但无论如何不能在架构级别确定用户权限吗？

将数据仓库拆分为多个数据库的正当理由是什么？

很想在这里进一步了解一般的数据库。是的，我碰巧在我的知识空白处做了很多工作，但这份工作就是它，我一直在努力。到目前为止，东西一直很好用（敲木头）。

Answer 1

你绝对是在正确的轨道上！320GB 对于数据库来说并不是很大，尤其是 DW。

1）当前的数据库优化不佳，文档很少，数据类型次优，索引次优。

我的菜鸟想法：这些问题不是和数据库拆分无关吗？它们只是需要以任何方式自行解决的问题。

这太划算了。将一个大型（ish）组织、优化和记录不完善的数据库拆分为 7 个组织不当、优化和记录不充分的数据库是浪费时间！你需要解决问题的根源！

2) 当前数据库中有 372 个对象，这使它变慢。

我的想法：在我看来，这似乎并不大。

再说一遍，你是对的！372 在对象数量方面确实很小 - 许多大型服务器有 10 千个。从这里

一个数据库中所有对象的总数不能超过 2,147,483,647。

你的 370 除以 ~ 2E9 ~= 1.7E-7 - 所以这个分数不用担心！:-)

3) 一个数据库比 7 个数据库更难记录和绘制模式图（我们将拥有跨越多个数据库的视图）。

我的想法： .... 这对我来说似乎完全荒谬，但也许我错了。我们已经按照 13 个“源系统”模式组织了我们的数据仓库。

再说一遍，你是对的。如果有 372 个实体之间存在相互关系，则您需要记录并绘制它们。它将具有固有的复杂程度。您可以做的是尝试将您的整个系统分成子系统并记录它们，然后尝试将它们融入更大的图景 - 来自小橡子的大橡树成长！

4）一个数据库会导致更多的数据库死锁。

-- 这个问题不是也和多数据库完全无关吗？我的理解是死锁发生在表级别（实际上通常甚至只是行级别，但是呃）。即便如此，我们所有的数据插入都发生在午夜，我们所有下游到 BI 的选择发生在凌晨 2 点。让两个进程更新同一个表与多个数据库无关，是不是（死锁会发生）？另外，我个人没有看到在正常操作期间发生表死锁的证据。

在多数据库场景中，您将失去的是同一架构内的 ACID 事务 - 好吧，您可以进行两阶段提交，但它不如同一架构内的事务（恕我直言）健壮。如果您的要求有必要，我不确定是否有正当理由将桌子分开。

你似乎在谈论写阻塞读？好吧，您似乎也有一个在午夜进行批处理，然后在 02:00 进行查询的过程？如果您可以将事务/表设为只读，这将减轻服务器引擎在处理数据时的一些负担。只有您可以判断这是否可以应用于您的场景！

5) 数据库技术所有权/所有权。

只有我们两个人在数据库上工作。他有可能真的想隔离我们的“封地”。真的，这不是问题，但无论如何不能在架构级别确定用户权限吗？

当然，所有权是在表级别，并且根据您的服务器/版本，可以在列和/或行级别授予访问权限 - 因此所有权业务完全是红鲱鱼！如果您是执行重组（而不是简单地安排备份和其他平凡任务）的服务器 DBA，那么您将需要“访问所有区域”！

您应该对系统中的每个表和字段进行评论 - 您可以将“所有权”（在组织中而不是数据库意义上的事物）放在那里 - 评论表和字段是记录系统的绝佳第一步 - 它成为自我记录！

将数据仓库拆分为多个数据库的正当理由是什么？

可能有很多原因 - 有些与多租户有关（在机器资源（CPU、RAM、HDD 和网络）和客户端机密性或要求方面。看看这里，还有谷歌“数据库多租户”或类似的.

每个人都这么说，但这是一场斗争——“文档很重要”！第一步，在评论中记录您的表格和字段。为您的所有子系统生成 ERD 图。如果没有实施这些步骤，不要让任何新东西进入系统。祝你在新角色中好运！