0

我们正在考虑重组我们的数据库。我们目前列出了大约 60,000 艘船在几个月内跟踪每艘船的浏览量，这会在每个船的网页浏览量上更新。当前的数据库是这样的； 

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

我们希望每天以这种结构存储信息（见下文）这会对数据库造成压力吗？（一年内我们将至少有 60,000 x 365 = 21,360,000 行）

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

关于我们的网站 - 我们每月收到大约 6,000,000 到 7,000,000 次页面浏览量。我们有一个运行 sql2008 的专用数据库服务器 - 四核 2.2 x 2, 24gb ram。

4

2 回答 2

0

您现有结构的问题在于您仅限于为每艘船提供高级别的视图概览。您只能显示基于月/年的视图。如果您想深入研究数据以查看哪些日子有更多的浏览量或活动，那么您做不到。

第二种结构在报告、日期比较等方面为您提供了更大的灵活性。

至于查询的性能，您将需要使用执行计划和查询调优来确定查询的执行方式。

于 2013-04-17T10:41:58.000 回答
0

新设计看起来不错。

如果我计算正确，您（平均）每秒收到少于 1 个请求。即使我们加倍（有些人在晚上睡觉），也就是每秒 2 个请求。

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

一些想法：

  • 检查您的应用程序是否可以缓存视图命中并每次执行插入/更新，例如 10 个视图

  • 确保正确索引表以最小化查询时间，更新行将花费很少的时间

  • 如果您在夜间交通量低，您可以做一个每天为每艘船插入新条目的工作；对于索引严重的表，插入可能非常昂贵；这是一个想法，我没有测试或使用过它，曾经......

于 2013-04-17T10:42:30.913 回答