高流量的有效数据库结构

Question

我们正在考虑重组我们的数据库。我们目前列出的每艘船在几个月内约有60,000艘船跟踪观看，每艘船的综合浏览量都会更新。当前的数据库就像;

BoatID Year Month Views 
1554  2013 2  124 
1554  2013 3  1542 

愿我们每天存储在这种结构的信息（见下文）将在拥有对数据库的任何应变？（在一年内，我们将有一个最低60000×365 = 21360000行）

BoatID Date   Views 
1554  01/02/2013 20 
1554  02/02/2013 142 

关于我们的网站 - 我们获得约600万〜700万的页面浏览量一个月。我们有一个运行sql2008的专用数据库服务器 - 四核2.2 x 2，24gb ram。

Answer 1

您现有结构的问题在于您仅限于提供每艘船的视图的高级概览。您只能根据月份/年份显示观看次数。如果您想深入了解数据以查看哪些日子有更多的观点或活动，那么您不能。

第二个结构为您提供了更大的灵活性，当谈到报告，日期比较等

至于您的查询的性能，你需要使用的执行计划和查询优化，以确定查询将如何执行。

Answer 2

新设计看起来不错。

如果我的计算正确，那么您平均每秒获得的请求数少于1个。即使我们加倍（有些人晚上睡觉），这是每秒2个请求。

我有一种强烈的感觉，你提到的数据库服务器将能够处理它。

一些想法：

• ，请检查您的应用程序可以查看缓存命中和执行插入/是否更新每隔，说10次

• 确保您的索引表格正确，以尽量减少查询时间，它将花费很少的时间来更新一行

• 如果你在夜间流量低，你可以做一份工作，每天为每条船插入新条目;对于大量索引的表格插入可能非常昂贵;这是一个想法，我还没有测试过或使用它，曾经...