最佳数据库丰满度?

时间:2011-01-25 22:07:47

标签: database-design relational-database

假设您有一个任意但有限容量的关系数据库,并且数据库保存了不断生成新事件的在线系统的历史事件信息。数据库应保存事件信息以用于报告目的,但应清除超过(N)天数的事件。鉴于您有足够的历史信息来推断事件发生率相对恒定且不随时间增加或减少,您是否会设计出最佳百分比(60%,70%,80%,......)丰满度对于这个数据库?如果是这样,那你为什么选择那个百分比?

2 个答案:

答案 0 :(得分:1)

取决于。

嗯,稍微有点帮助,你说事件发生的速度是“相对恒定的”。您需要足够的保证金来处理该比率的不一致,包括统计和紧急情况。您可以从历史中获得的统计数据,但紧急情况只能在猜测中发现。

实际使用的空间量取决于它的存储方式。在相关的说明中,如果超过一定程度的丰满度,许多文件系统会变得非常慢;您可能希望将此百分比作为总保证金的一部分。另外,请考虑事件清除的粒度:它经常发生的次数?

另外,请考虑容量耗尽的后果。你的系统会崩溃吗?无论如何,系统有多重要?你可以进行紧急清洗以增加空间吗?相对于中断的费用,额外容量有多贵?

答案 1 :(得分:0)

这不是一个数据库设计问题,而是一个操作问题。

你每晚的维护过程(或者你过期的数据老化)需要保持足够的可用空间来容纳任何合理的每日活动量。据推测,由于空间不足而导致的故障不是一种选择。但是你只知道每日音量是多少以及方差是多少,你才能知道多少空间。如果您的平均每日交易量为5,000,000个事件,且差异为+/- 4,000,000个事件,并且您的标准偏差为2,000,000,那么您需要保留比您获得相同的更多可用空间平均日交易量,但方差为+/- 500,000,标准差为50,000。直到你得到一些统计数据通知你,你只是在猜测。

在一个TB级硬盘售价不到200美元的世界里,担心空间不值得。

更重要的是,从操作角度来看,恕我直言,只是在数据和索引页面上维护多少可用空间,以便最大限度地减少插入和更新操作上的页面拆分以及从中获取的性能。而且,您需要了解有关实际数据的信息才能弄明白。