数据仓库：一个数据库还是多个？答案

【问题标题】：Data Warehouse: One Database or many?数据仓库：一个数据库还是多个？
【发布时间】：2011-02-23 07:57:09
【问题描述】：

在我的新公司，他们将与数据仓库相关的所有数据（包括导入、暂存、审计、维度和事实表）保存在同一个物理数据库中。

我已经从事数据库开发多年了，这种功能和形式的整合似乎与我所知道的一切背道而驰。

这似乎使安全、备份/恢复和性能管理问题更加手动密集。

这是行业内的事情吗？这样做或不这样做有充分的理由吗？

平台是 Netezza。大小以 TB 为单位，数亿行。

我希望从这个问题的答案中获得对这条道路的正确或错误的深刻理解。根据您的经验，如果这是一条会给我们带来麻烦的道路，我应该重点讨论哪些问题。如果没什么大不了的，那我也想知道。

【问题讨论】：

了解平台会有所帮助。一些数据库具有实例范围的设置，可能会影响决策。
@Stephanie：平台是 Netezza。
重要的是要注意这是一个非常特定于 netezza 的问题。当这个问题需要解释细节时，插话的“数据仓库”专家可能会泛泛而谈。

标签： data-warehouse netezza database-design

【解决方案1】：

一般来说，我建议使用单独的数据库。这是我在生产中经常看到的配置，它确实很有意义，因为 - 正如你所提到的 - 两个数据库具有根本不同的目的/使用模式等。

【讨论】：

感谢贾斯汀，您的快速反馈。我正在寻找具体而具体的论据，我可以用来评估这一走向物理整合的举措。如果这两种方式都没有强有力的理由，那么我不值得战斗。然而，似乎有或应该有许多性能、可维护性和安全性原因来保持我们的数据按使用、功能和安全性进行分区。

【解决方案2】：

编辑

如果您使用的是一台物理服务器，则该服务器上的实例越少，管理就越简单，流程就越高效。

如果您将两个实例放在同一个物理服务器上，您会得到：

否定：

要使用一半的内存
数据库进程计数的两倍

正面：

您可以在不影响 DW 的情况下关闭整个暂存数据库

那么对您来说，中断窗口或 CPU 和内存哪个更宝贵？

在同一台物理服务器上，多个实例使性能管理问题更加手动解决。如果您查看其中一个实例的运行状况，它可能看起来不错，但用户报告性能不佳，因此您必须查看下一个实例以查看问题是否来自那里......等等每个实例.

多个实例的安全性也更难。充其量它就像单个实例一样难，但它从未如此简单。您将有两个管理员帐户（SYS 或其他）、重复进程帐户等。

告诉我们您为什么认为拥有多个实例会更好。

原帖

我们能说清楚条款吗？当您说“在同一个数据库中”时，您的意思是说同一个实例或同一个物理服务器。如果您确实将暂存区移至新实例，它会驻留在相同的物理硬件上吗？

我认为人们对实例有点过于执着了。如果您要将两个实例放在同一个硬件上，那么您只会将所有实例的数量翻倍，而优势很小。所有服务器进程将运行两次...所有内存池将减半。

所以假设您确实是指两个单独的物理盒子......

假设您购买了 2 个 12 路盒子（只是说）。当您在一天内完成 db server 的登台工作时，这 12 个 CPU 正在浪费。当您的用户收拾行李回家时，您的产品 DW CPU 正在浪费。 CPU 周期是易腐烂的，你无法取回它们。但是，如果您有一个 24 路盒子...那么暂存数据库可以在晚上使用 20 个 CPU 来进行一些出色的并行执行来构建汇总表，并且您的用户将在白天拥有双倍的进程容量。

假设您指的是相同的硬件。

“它似乎使安全、备份/恢复和性能管理问题更加手动密集。”

保证性能问题更难解决共享相同硬件的更多实例。保证。

安全

您在实例级别采取什么安全措施？

备份

您在实例级别备份什么 DW？您不是在备份表空间，而是在备份整个实例？似乎该模式在一定大小时会失败。

平台：NETEZZA

具体不熟悉该工具。因此，如果它是单个盒子上的单个实例，那么划分似乎比物理上更合乎逻辑，因此它们存在的原因是管理，而不是性能。您不会通过添加数据库来增加 CPU 或内存，对吗？因此，它似乎没有任何性能优势。每个数据库可能正在添加单独的进程（性能影响），或者它可能完全像 Oracle 中的模式。如果每个数据库都由新进程管理，那么它们之间的数据将意味着 IPC。

也许添加 Netezza 标记会获得一些吸引力。

【讨论】：

很好的答案，斯蒂芬妮。我会更新我的问题以解决您的问题。
Stephanie，Netezza 是一个单实例设备。所有数据库都驻留在单个实例中。我说的是把我们的暂存表和审计表与生产数据放在同一个数据库中。

【解决方案3】：

我们为每个细分市场（INVENTORY、CRM、BILLING...）使用数据库。没有性能上的缺点，维护和概述要好得多。

【讨论】：

【解决方案4】：

迟到总比没有好，但对于 Netezza：

查询跨数据库时不会影响性能。 Netezza 只允许SELECT 跨数据库操作，不允许INSERT、UPDATE 或DELETEstatements。

这意味着你不能这样做：

THISDB(ADMIN)=>INSERT INTO OTHERDB..TBL SELECT * FROM THISDBTABLE;

但是你可以\c OTHERDB然后

OTHERDB(ADMIN)=>INSERT INTO TBL SELECT * FROM THISDB..THISDBTABLE;

您也无法在跨数据库对象上创建物化视图，例如： OTHERDB(ADMIN)=>CREATE MATERIALIZED VIEW BLAH AS SELECT * FROM THISDB..THISDBTABLE;

管理可能是您决定（尽管您可能很久以前就已经这样做了）您将创建什么样的数据库的地方。根据您的基础架构，您可能在同一个盒子上或在不同的盒子上拥有一个 TEST/QA 系统和一个 PROD 系统。

【讨论】：

【解决方案5】：

如果表位于同一架构（数据库）中，您将加快加载和输出速度。很明显……但是，嘿，我说过了。

将更多的表放入一个模式中，开销就越大。备份时间、备份大小、易用性。

在我所在的位置，我们在一个数据仓库中拥有许多多个 TB 数据库。我们的经验法则是单个加载过程或单个报告查询不应该跨越数据库。这将“喜欢”的表放在一起，但为我们的备份和应急流程留出了一些余地。它还使“查找”数据变得更加容易。

对于那些需要打破这一规则的进程，我们要么将数据从一个数据库移动到另一个数据库，要么允许进程跨模式加入。

我对 Netezza 不太熟悉，所以我不能 100% 确定您的选择是什么。

【讨论】：

我发现这个答案没有帮助。首先，它仅对您的平台（和体验）是“显而易见的”。您所做的每条评论都特定于您的数据库平台。您没有规定您对“数据仓库”的定义是什么（多模式或数据库或多合一？）。然后你总结说你不熟悉netezza（有问题的平台）。似乎您可能对您的（神秘）数据库给出了合理的建议。

【解决方案6】：

您需要考虑的几点 a) 如果一个或多个 staging、审计、维度和事实表中的数据必须连接，最好将它们保存在一个数据库中

b) 通常，您会将维度表和事实表保留在同一个数据库中，并分布在最常连接的列上，以利用 Netezza 的“同位连接”功能

c) 您应该能够使用 SQL 授予权限来管理对所有对象（数据库、表、视图等）的访问

【讨论】：