自定义统计的最佳实践

Question

我正处于一种情况，我必须构建一个可以存储用户相关统计信息的统计模块。

基本上，所有存储的都是事件标识符、日期时间对象和触发此事件的次数以及正在与之交互的对象的 ID。

我以前做过类似的系统，但从来没有像这个系统那样需要存储大量信息。

我的建议是在数据库中创建一个简单的表格。 等“统计”包含以下行

• id（主要，自动递增）
• 金额（整数）
• 事件（枚举-（列表、点击、查看、联系人）
• 日期时间（日期时间）
• object_id（整数）

通常，此方法工作正常，使我能够在给定时间范围内存储有关对象的统计信息（每隔一小时或 15 分钟插入一个新的日期时间，因此统计信息将每 15 分钟更新一次）

现在，我的问题是：

• 是否有更好的方法或更优化的方法来实现 并构建自定义统计模块。
• 由于这个新站点将获得大量流量，我该如何解决对象 id 上的索引会导致更新响应时间变慢的悖论
• 您如何实现实时统计数据等分析？这仅与服务器大小和处理能力有关吗？或者是否有最佳做法。

我希望我的问题是可以理解的，我期待在这个话题上变得更明智。 最好的祝福。 乔纳斯

Answer 1

我相信您将遇到的问题之一是您想要交易和分析两个世界。在小型情况下这很好，但是当您开始扩展时，尤其是扩展到 500M+ 记录的领域。

我建议将两者分开，您生成事件并仅跟踪事件本身。然后，您将运行分析查询以获取诸如每个对象交互的事件计数之类的信息。您可以定期将这些计数或其他指标计算汇总到报告表中。

至于跟踪事件，您可以将它们保存在事件发生的表中，或者在执行此跟踪的数据库之前有一些东西，然后它会向数据库提供定期聚合。想想监控系统的世界，它使用收集代理生成事件，这些事件进入聚合层，然后将定期指标快照写入分析区域（例如，收集 D 到 StatsD / Graphite 到 Whisper）

免责声明，我是 InfiniDB 的架构师 不确定您使用的是哪种数据源，但随着您的成长和确定历史数量等......您可能会面临大多数人在收集事件数据或监控数据时通常会遇到的大小问题。如果您在 MySQL / MariaDB / PostegreSQL 中，我建议您查看 InfiniDB（用于分析的开源柱状 MPP 数据库）；它是完全开源的 (GPLv2)，将为您提供对数十亿和 TB 数据进行查询以回答这些分析问题所需的性能。