Xeo*_*oss 16 rdbms database-design capacity-planning nosql
在启动项目时,我经常会想到几个不同的模式.经过粗略的猜测后,我意识到有些人对增长或存储空间的优化程度低于其他人.显然,列值的大小是主要的.但表元数据,索引和行标题也都起作用.
此外,RDBMS使用与对象或键值数据库完全不同的数据存储方法.
试图找出数据库存储的成本(或需要的空间)有哪些好的资源？
请注意,我的问题与选择数据库没什么关系,而是知道如何最有效地正确使用每个数据库的设计.PostgreSQL,MySQL,CouchDB等数据库都有不同的目标用例和多种方法来解决同样的问题.因此,了解每个解决方案的存储成本将有助于为架构选择最佳解决方案.
与对象或键值数据库相比,RDBMS使用完全不同的数据存储方法.
关系模型假设您不知道将来需要哪些数据,或者将来如何访问数据.根据我的经验,这被证明是一个非常可靠的假设.
这就是SQL dbms允许您在需要时添加索引的一个原因,并让您删除已被证明无用的索引.它将允许您在已知约束时添加约束 - 有时需要添加更多表的约束 - 并在需求更改时删除约束.当您发现更多可以了解的内容时,它会让您添加列.它将允许您用视图替换表并用表替换视图.一些dbms将允许您创建物化视图 - 它们对查询速度的影响可能是巨大的,它们对磁盘使用的影响是毁灭性的.
有用的数据库可扩展其范围 根据关系模型设计的SQL数据库使得在初始设计期间添加没有人梦寐以求的功能变得相对容易,并且不会破坏系统的其他部分.所以他们被称为经常被要求做他们最初的设计师没想到的事情.
所有这些事情
估计磁盘使用情况看起来像是浪费时间.只有它们中的任何一个都可以彻底改变数据库所需的磁盘空间.
您可以非常准确地计算行和页面所需的空间.(尝试使用Google获取"YourDBMSname行布局"和"YourDBMSname页面布局".)但是当您尝试乘以所需的行数时,您必须估计行数.这让你成为Steve McConnell所说的" 不确定性的锥体 "的大结局.
如果您没有在自己的公司测量多个项目中的磁盘使用情况,那么估计上述那些要点的影响只是猜测.
我工作的最后一家财富100强企业拥有一个自20世纪70年代以来一直投入生产的运营数据库.数百个应用程序,在40年的时间里用超过25种编程语言编写,每天都会发生这种情况.(我认为它最初是基于IBM的IMS构建的;今天它运行在Oracle上.)
就在几年前,没有人想到他们的数据库会被用来将工程图纸和物料清单翻译成中文,还可以生成他们需要从中国获得成品所需的海关文件.实现这些新功能需要在其实时库存中存储关于每个部件和每个设计文档的附加数据.在该项目的早期,我们的估计相当遥远.那是锥形的大头.(我们估计了几件事,但没有磁盘使用.我们被要求成功,所以无论我想出什么设计,都需要有人提供所需的磁盘空间.)但是当我们上线时,我们知道每个人的确切价值估计,因为我们已经完成了工作.(那是锥形的窄端.)
那么,如何降低数据库设计和部署环境中猜测的风险呢？从1972年开始吸取教训.
构建原型并进行测量.
化学工程师很久以前就了解到,在实验室中工作的过程不能仅在一个工厂中实施.需要一个称为试验工厂的中间步骤,以提供扩大数量和在非保护环境中运行的经验....
...项目之后的项目设计了一套算法,然后按照要求交付第一件事物的时间表投入到客户可交付软件的构建中....
因此,管理问题不在于是否建立一个试点系统并将其扔掉.你会那样做的.唯一的问题是,是否提前计划建造一次性计划,或承诺向客户提供一次性计划.
小弗雷德布鲁克斯,在神话人月,第116页.
这是我发现有用的AskTom文章.它虽然是Oracle特有的.
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:266215435203