数据库设计 – 如何计算数据库设计存储成本?
启动项目时,我经常会有几个不同的模式.在做出粗略的猜测后,我意识到有些对于增长或存储空间比其他人更少.显然,列值的大小是主要的.但是表元数据,索引和行标题也起到了一定的作用. 此外,与对象或键值数据库相比,RDBMS使用完全不同的数据存储方法. 为了找出数据库存储的成本(或需要的空间),有什么好的资源? 注意,我的问题与选择数据库无关,而是知道如何最有效地使用每个数据库的设计.像PostgreSQL,MySQL,CouchDB这样的数据库都有不同的目标用例和多种方式来解决同样的问题.因此,了解每个解决方案的存储成本将有助于为模式选择最佳解决方案. 解决方法
关系模型假设您不知道将来需要什么数据,或者将来如何访问数据.这在我的经验中被证明是一个非常可靠的假设. 这就是SQL dbms将允许您根据需要添加索引的原因之一,并让您放弃已证明无用的索引.它将允许您添加约束,因为它们变得已知 – 有时需要添加更多表的约束 – 随需求变化而丢弃约束.当您发现更多有助于了解的内容时,它会让您添加列.它将允许您用视图替换表,并用表替换视图.一些dbms将允许您创建物化视图 – 它们对查询速度的影响可能会非常显着,并且会对磁盘使用造成影响,具有破坏性. 有用的数据库扩展了其覆盖根据关系模型设计的SQL数据库使初始设计中没有人想到的功能相对容易,并且不会破坏系统的其他部分.所以他们经常被要求做最初设计师没想到的事情. 所有这些事情 >随着时间的推移添加和删除索引, 对磁盘使用的估计看起来像是浪费时间.任何一个人都可以大幅度地更改数据库所需的磁盘空间. 您可以相当准确地计算行和页面所需的空间. (尝试Google“YourDBMSname行布局”和“YourDBMSname页面布局”.)但是,当您尝试乘以所需的行数时,您必须估计行数.这让你处于史蒂夫·麦康奈(Steve McConnell)所说的“cone of uncertainty”的大端. 如果您自己的公司在多个项目中没有测量多个项目的磁盘使用情况,估计以上这些项目点的影响只是猜测. 自从上世纪70年代以来,我所工作的财富100强公司拥有一个运行数据库. 40多年来,数以百计的应用程序以超过25种编程语言编写,每天都会播放这些东西. (我认为它最初建立在IBM的IMS上;今天它运行在Oracle上.) 即使在几年前,没有人会想到他们的数据库将用于将工程图纸和物料清单翻译成中文,并且还要生产他们需要将成品从中国出来的海关文件.实施这些新功能需要存储有关每个部分的附加数据以及其实际库存中的每个设计文档.在这个项目的初期,我们的估计是相当遥远的.这是圆锥的大端. (我们估计有几件事情,而不是磁盘使用,我们被要求成功,所以无论我想到什么设计,都有人需要提供所需的磁盘空间).但是当我们上线的时候,我们知道每个估计,因为我们已经完成了这项工作. (那是圆锥的窄端) 那么,如何减轻数据库设计和部署环境中的猜测风险?从1972年开始吸取教训. 建立一个原型,并测量它.
弗雷德布鲁克斯小姐,在神话人月,第116页. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |