SQL:连接与非规范化(大量数据)

Question

我知道，之前已经问过这个问题的变体。但我的情况可能有点不同:-)

所以，我正在建立一个跟踪事件的网站。每个事件都有 id 和 value。它也由用户执行，用户具有 id、年龄、性别、城市、国家和等级。 (这些属性都是整数，如果重要的话)

我需要能够快速获得两个查询的答案:

从具有特定个人资料的用户(例如，来自俄罗斯莫斯科的 18-25 岁男性)获取事件数量

从具有特定配置文件的用户那里获取事件值的总和(也可能是平均值) -

此外，数据是由多个客户生成的，而这些客户又可以有多个 source_id。

访问模式:数据主要由收集器进程写入，但在查询时(很少，通过 web ui)它必须快速响应。

我希望有大量数据，当然不止一个表或单个服务器可以处理。

我正在考虑每天在单独的表中对事件进行分组(即“events_20111011”)。此外，我想用客户 ID 和源 ID 作为表名的前缀，以便数据被隔离并且可以被简单地丢弃(清除旧数据)并且相对容易地移动(将负载分配到其他机器)。
这样，每个这样的表的行数都是有限的，比方说，10M 顶。

所以，问题是:如何处理用户的属性？

选项 1，规范化:将它们存储在单独的表中并从事件表中引用。

(pro) 不重复数据。

(con) 连接，这是昂贵的(左右)
我听说)。

(con) 这需要打开用户表和事件表
同一台服务器

选项 2，冗余:将用户属性存储在事件表中并对其进行索引。

(pro) 更容易的负载平衡(独立的表可以四处移动)

(专业版)更简单(更快？)查询

(con) 大量磁盘空间和内存用于重复用户属性和相应的索引

Answer 1

您的设计应该规范化，您的物理架构可能会因性能原因而非规范化。

两者都可以吗？ SQL Server 附带 Analysis Server 是有原因的。即使您不在 Microsoft 领域，也有一个常见的设计是使用事务系统进行数据输入和日常处理，而报告系统可用于对事务系统造成沉重负载的各种查询。

这样做意味着您可以两全其美:日常操作的规范化系统和汇总查询的非规范化系统。

在大多数情况下，每晚更新对于报告系统来说都很好，但这取决于您的工作时间和其他最有效的因素。我发现大多数 8-5 家企业在晚上有足够的时间来更新报告系统。