5

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

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

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

  • 从具有特定个人资料的用户那里获取事件数量（例如，来自俄罗斯莫斯科的 18-25 岁的男性）
  • 从具有特定配置文件的用户那里获取事件值的总和（也可能是平均值） -

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

访问模式：数据将主要由收集器进程写入，但在查询时（不经常通过 web ui），它必须快速响应。

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

我正在考虑每天将事件分组在不同的表中（即“events_20111011”）。此外，我想在表名前加上客户 ID 和源 ID，以便数据被隔离并且可以很容易地丢弃（清除旧数据）并且相对容易移动（将负载分配到其他机器）。这样，每个这样的表都会有有限的行数，比如 10M 的顶部。

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

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

  • (pro) 不重复数据。
  • (con) 连接，这很昂贵（或者我听说过）。
  • (con) 这要求用户表和事件表在同一台服务器上

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

  • （亲）更容易的负载平衡（自包含的表可以移动）
  • （专业版）更简单（更快？）的查询
  • (con) 大量磁盘空间和内存用于重复用户属性和相应的索引
4

3 回答 3

8

你的设计应该被规范化，你的物理模式可能会因为性能原因而被非规范化。

有可能两者都做吗？SQL Server 附带分析服务器是有原因的。即使您不在 Microsoft 领域，通常的设计也是有一个用于数据输入和日常处理的事务系统，而一个报告系统可用于可能导致事务系统负载过重的各种查询。

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

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

于 2011-10-11T00:57:40.937 回答
3

使用 OLAP/数据仓库方法。也就是说，以标准规范化方式存储您的数据，但还将经常查询的数据的聚合版本存储在单独的事实表中。用户查询不会基于实时数据，但为了性能折衷通常是值得的。

此外，如果您使用的是 SQL Server 企业版，我不会推出您自己的水平分区方案（将数据分解为数天）。SQL Server 中内置了一些工具，可以自动为您执行此操作。

于 2011-10-11T00:55:48.953 回答
1

请规范化

使用分区和索引来平衡负载

于 2011-10-11T00:56:57.330 回答