在启动项目时,我经常会想到几个不同的模式。经过粗略的猜测,我意识到有些人比其他人更不适合生长或存储空间。显然,列值的大小是主要的事情。但是表元数据、索引和行标题也起着一定的作用。
此外,RDBMS使用与对象或键值数据库完全不同的数据存储方法.
有哪些很好的资源可以用来计算数据库存储所需的成本(或空间)?
Note,我的问题与选择数据库无关,而是知道如何更有效地利用每个数据库的设计。像PostgreSQL、MySQL、CouchDB这样的数据库都有不同的目标用例和多种解决相同问题的方法。因此,了解每个解决方案的存储成本将有助于为模式选择最佳解决方案。
发布于 2012-03-03 22:50:33
RDBMS使用与对象或键值数据库完全不同的数据存储方法.
关系模型假设您不知道将来需要哪些数据,也不知道将来如何访问数据。在我的经验中,这已经证明是一个相当可靠的假设。
这就是SQL dbms允许您根据需要添加索引的原因之一,并允许您删除已经证明无用的索引。它将允许您添加已知的约束--有时需要添加更多表的约束--以及随着需求的变化而删除约束。它将允许您添加列,因为您发现更多的事情,将是好的了解。它将允许您用视图替换表,用表替换视图。一些dbms将允许您创建物化视图--它们对查询速度的影响可能是巨大的,它们对磁盘使用的影响是毁灭性的。
有用的数据库扩大了它们的范围。根据关系模型设计的SQL数据库可以相对容易地添加在初始设计过程中没有想到的特性,并且不会破坏系统的其他部分。所以他们经常被召唤去做他们最初设计师没有想到的事情。
所有这些事情
对磁盘使用情况的任何估计都是浪费时间。它们中的任何一个都可以极大地改变数据库所需的磁盘空间。
您可以相当准确地计算行和页所需的空间。(试试谷歌的"YourDBMSname行布局“和"YourDBMSname页面布局”。)但是,当您试图乘以所需的行数时,您必须估计行数。这让你处于史蒂夫·McConnell (Steve不确定锥)所称的“不确定锥”的高端。
如果您还没有在您自己的公司测量过多个项目中的磁盘使用情况,那么估计上面这些要点的影响只是猜测而已。
我为“财富”100强公司工作的上一家公司拥有一个运行数据库,自20世纪70年代以来就已投入生产。在过去的40年里,每天都有数以百计的应用程序用超过25种编程语言编写。(我认为它最初是建立在IBM的IMS上的;今天它运行在Oracle上。)
就在几年前,那里还没有人想到他们的数据库会被用来把工程图纸和材料清单翻译成中文,也可以用来制作从中国那里得到成品所需的海关文件。要实现这些新特性,就需要存储关于每个部件和每个设计文档的额外数据。在那个项目的早期,我们的估计是相当遥远的。那是圆锥体的大头。(我们估计了几种情况,但没有估计磁盘的使用情况。我们必须成功,所以不管我想出什么设计,都需要有人提供所需的磁盘空间。)但是当我们去现场的时候,我们知道每个评估的确切价值,因为我们已经完成了这项工作。(这是圆锥体的窄端。)
那么,如何在数据库设计和部署环境中减少猜测的风险呢?吸取1972年的教训。
构建了一个原型,并对其进行了测量.
化学工程师很久以前就知道,在实验室里工作的过程不能在工厂中一步一步地实施。一个名为“试点工厂”的中间步骤是必要的,以提供扩大数量和在非保护性环境中运行的经验。。。。 。。。一个接一个的项目设计了一组算法,然后投入到客户交付软件的建设中,这个计划要求交付所构建的第一件东西。。。。 因此,管理问题不在于是否建立一个试点系统并将其扔掉。你会这么做的。唯一的问题是,是提前计划建立一个丢弃,还是承诺将一次性交付给客户。
小佛瑞德布鲁克斯,在神话中的男人月,第116页。
发布于 2012-03-03 20:57:50
这里有一篇我觉得很有帮助的AskTom文章。不过,这是甲骨文特有的。
ID:266215435203
https://stackoverflow.com/questions/9422025
复制相似问题