如何计算数据库设计存储成本？答案

【问题标题】：How can I calculate database design storage costs?如何计算数据库设计存储成本？
【发布时间】：2012-02-23 21:57:32
【问题描述】：

在开始项目时，我经常会想到几个不同的架构。经过粗略的猜测后，我意识到有些对于增长或存储空间的优化不如其他优化。显然，列值的大小是主要的。但是表元数据、索引和行标题也都在起作用。

此外，RDBMS 使用与对象或键值数据库完全不同的数据存储方法。

有哪些好的资源可以用来计算数据库存储的成本（或所需空间）？

注意，我的问题与选择数据库无关，而是知道如何正确利用每个数据库的设计以实现最有效。 PostgreSQL、MySQL、CouchDB 等数据库都有不同的目标用例和解决同一问题的多种方法。因此，了解每个解决方案的存储成本将有助于为架构选择最佳解决方案。

【问题讨论】：

为什么在设计模式时要计算它……这听起来像是不合理的尝试，因为仅模式根本无法确定数据库大小。还考虑到存储空间成本将是总成本的最不重要因素，例如选择您需要的数据库。
@ManfredMoser，数据库模式是应用程序数据设计的核心。它的构建方式显示了您对数据存储的计划。
是的.. 但是许多其他因素会显着影响存储，因此仅从模式进行任何评估而无需进一步的要求，例如性能（缓存、索引..）或查询（数据仓库之上的OLTP）变得完全没有意义......恕我直言，你在浪费时间。
@ManfredMoser，是的，我不怀疑缓存是必要的。但是，让我们一次只关注一件事。首先，我们需要知道从哪里可以获取信息来衡量我们的选项，然后我们可以制定设计计划，最后我们可以将 CDN 和缓存添加到我们的设计文档中以确保一切正常。
很公平.. 就这样。我认为在您似乎参与的项目的早期阶段考虑存储成本是一种浪费（对不起，我错过了聊天......）

标签： database-design nosql rdbms capacity-planning

【解决方案1】：

RDBMS 使用与对象或键值数据库完全不同的数据存储方法。

关系模型假设您不知道将来需要哪些数据，或者将来如何访问数据。根据我的经验，这已被证明是一个非常可靠的假设。

这就是 SQL dbms 允许您根据需要添加索引并删除已证明无用的索引的原因之一。它将允许您在已知约束时添加约束（有时需要添加更多表的约束）并在需求变化时删除约束。当您发现更多值得了解的事情时，它可以让您添加列。它将允许您用视图替换表并用表替换视图。一些 dbms 可以让您创建物化视图 - 它们对查询速度的影响可能是巨大的，而它们对磁盘使用的影响则是毁灭性的。

有用的数据库扩大了他们的范围。根据关系模型设计的 SQL 数据库可以相对容易地添加在初始设计时没有想到的功能，并且不会破坏系统的其他部分。所以他们经常被要求做他们最初的设计师没有想到的事情。

所有这些

随着时间的推移添加和删除索引，
随着时间的推移添加和删除约束，
随着时间的推移添加和删除列，
随着时间的推移添加和删除表，

对磁盘使用情况的任何估计都像是在浪费时间。其中任何一个都可以极大地改变数据库所需的磁盘空间。

您可以相当准确地计算出一行和一页所需的空间。（尝试使用 Google 搜索“YourDBMSname 行布局”和“YourDBMSname 页面布局”。）但是当您尝试乘以所需的行数时，您必须估计行数。这使您处于史蒂夫·麦康奈尔（Steve McConnell）所说的“cone of uncertainty”的尽头。

如果您没有在自己公司的多个项目中随时间推移测量磁盘使用情况，那么估计上述要点的影响只是猜测。

我工作的最后一家财富 100 强公司拥有一个自 1970 年代以来一直在生产的运营数据库。在 40 年的时间里，用超过 25 种编程语言编写的数百个应用程序每天都会遇到这种情况。（我认为它最初是在 IBM 的 IMS 上构建的；现在它在 Oracle 上运行。）

即使在几年前，也没有人想到他们的数据库会被用于将工程图纸和材料清单翻译成中文，以及制作他们将成品运出中国所需的海关文件。实施这些新功能需要在实时库存中存储有关每个零件和每个设计文档的附加数据。在那个项目的早期，我们的估计相差甚远。那是圆锥体的大端。（我们估计了几件事，但没有估计磁盘使用量。我们需要成功，所以无论我想出什么设计，都需要有人提供所需的磁盘空间。）但是当我们上线时，我们知道每个人的确切价值估计，因为我们已经完成了这项工作。（那是锥形的窄端。）

那么，您如何降低数据库设计和部署环境中的猜测风险？吸取 1972 年的教训。

构建原型并进行测量。

化学工程师很久以前就了解到，在实验室不可能一步到位地在工厂中实施。一个称为试验工厂的中间步骤是必要的在扩大数量和非保护性操作方面的经验环境。 . . .

。 . .一个接一个的项目设计了一套算法，然后按照要求交付第一件东西的时间表投入到客户可交付软件的构建中。 . . .

因此，管理问题不是是否建立一个试点系统并将其丢弃。你会这样做。唯一的问题是是提前计划构建一次性产品，还是承诺将一次性产品交付给客户。

Fred Brooks, Jr.，The Mythical Man-Month，第 116 页。

【讨论】：

我完全同意存储成本仅次于灵活性和功率的观点。但是，我的问题不在于选择一个数据库而不是另一个，甚至不是仅仅基于节省空间来做出选择。我根据需求选择数据库。我的问题是关于在数据库中选择一条路线而不是另一条路线时的存储成本。例如，计算一种方法的成本，或另一种替代方法（同样有效）的成本，其中空间也可能是影响最终判断的决定因素。
@Xeoncross：我认为你误读了我的回答。关于选择 dbms 或技术，我没有说任何。我说，本质上，您不能使用比猜测更准确的方法来表达 SQL dbms 的磁盘空间“要求”。（如果您使用敏捷方法，则尤其如此。）因此，您无法使用比猜测更准确的方法来表示 SQL dbms 的磁盘空间成本。（除非 Java 程序员设计数据库，在这种情况下，所有的约束、一半的索引和一半的数据都可能最终出现在应用程序代码中。）

【解决方案2】：

这是我发现有帮助的 AskTom 文章。但它是特定于 Oracle 的。

http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:266215435203

【讨论】：