自定义统计的最佳做法

Question

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

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

我之前制作了类似的系统，但从来没有任何必须存储大量信息的东西。

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

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

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

现在，我的问题是：

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

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

Answer 1

我相信你要遇到的一个问题是你想要两个交易和分析的世界。在小的情况下这是好的，但是当你开始扩展时，特别是进入500M +记录的领域。

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

对于跟踪事件，您可以将它们保存在事件发生的表中，或者在执行此跟踪的数据库之前具有某些功能，然后向数据库提供定期聚合。想想使用收集代理生成事件的监控系统的世界，这些事件会转到聚合层，聚合层然后将周期性度量快照写入分析区域（例如CollectD到StatsD / Graphite to Whisper）

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