我想知道在估计数据库大小方面开发新应用程序时您会做什么。
例如,我正计划启动一个网站,但我很难估计我的数据库可以增长的大小。我不希望你告诉我我的数据库会有多大,但我想知道在估计这个时是否有一般原则。
例如,当 Jeff 开发 StackOverflow 时,他(大概)估计了他的数据库大小和增长。
我的困境是我正在为我的 Web 应用程序寻找一个托管解决方案(在这个阶段它大约是成本),并且最好不想因为没有购买足够的 SQL Server 空间而自责(他们为此收取溢价) )。
我想知道在估计数据库大小方面开发新应用程序时您会做什么。
例如,我正计划启动一个网站,但我很难估计我的数据库可以增长的大小。我不希望你告诉我我的数据库会有多大,但我想知道在估计这个时是否有一般原则。
例如,当 Jeff 开发 StackOverflow 时,他(大概)估计了他的数据库大小和增长。
我的困境是我正在为我的 Web 应用程序寻找一个托管解决方案(在这个阶段它大约是成本),并且最好不想因为没有购买足够的 SQL Server 空间而自责(他们为此收取溢价) )。
如果您有数据库模式,那么调整大小非常简单……它只是估计的行数 * 每个表的平均行大小 * 索引的一些因素 * 开销的一些其他因素。鉴于现在存储的价格低得离谱,除非您打算拥有一个非常高流量的网站(或正在为大型企业构建应用程序),否则调整大小通常不是问题。
对于我自己的尺寸练习,我总是创建一个 Excel 电子表格列表:
col 6(总列)的总和,加上没有增长表的数据库的初始大小,就是您的大小估计。你可以变得更科学,但这是我快速而肮脏的方式。
决定:
编辑:忘记了一个好的经验法则是 2 倍的指数因子
每天的总增长 = 2* V * (N1*S1 + N2*S2 + N3*S3 + ...)
我要遵循的经验法则是
将用户记录大小乘以用户数;添加用户数量乘以内容项大小;乘以二(为了方便的软糖因素)。
估计的成本很可能大于存储的成本
大多数托管服务提供商按每月月底使用的数量出售容量,所以让它运行