我应该使用 Infobright 数据库还是有更好的聚合解决方案？

Question

我们是一家 MySQL 前端商店，目前有一个系统以高度结构化的格式记录事件数据。想想 apache 流量日志。

我们需要能够通过 vi 临时查询聚合这些数据（立方体）的计数。我们目前正在将数据发送到 CouchDB。这是非常快的，一旦一个视图完全映射，但我们的数据库大小只有 31GB 并且 CouchDB 正在永远映射一个新视图（2+小时）。检索 JSON 格式的数据对我们来说效果很好。但是我们害怕创建新的视图文档。我认为所有 Map-Reduce 系统都可能有这个问题。

我们正在评估 Infobright，因为他们声称可以为即席查询提供卓越的聚合性能，并且是 MySQL 的分支。

我们已经评估了蒙德里安，但它对我们不起作用。

MySQL/InnoDB 太慢了。

到年底，我们将拥有大约 500GB 的日志数据。

Infobright 是正确的解决方案还是我们还应该评估其他东西？

Answer 1

几乎总是（根据我的经验），以下是针对大型、类日志、数据和半临时查询的性能解决方案。

数据特点及应用：

• 不断到达的数据
• 没有更新“旧”数据
• 可选地清除旧数据（如果是这样，请使用 PARTITION BY RANGE(TO_DAYS())）
• 查询往往在 WHERE 子句中有一个日期范围

解决方案：建立和维护“汇总表”。

• 选择一个时间范围（通常是天或小时）
• 午夜（或最晚）之后，将昨天的数据从原始（事实）表汇总到汇总表中。
• 汇总表的 PK 通常包括一些维度和四舍五入的日期/小时。
• 其余字段包括 COUNT()、SUM() 等聚合，但不包括 AVG()。
• AVG 计算为 SUM(sum_foo)/SUM(ct)
• “报告”命中汇总表，而不是事实表。
• 1-10 个汇总表通常足以满足给定的应用程序
• 查询汇总表通常可以使您的性能提高 10 倍；我在极少数情况下见过 1000 倍。

我说“半临时”是因为您会发现用户并没有真正查询所有内容。即使他们这样做，您也可以拥有至少有帮助的汇总表。

我提到了完全总结“昨天”的直接方式。还有许多其他口味。一种是“根据需要”，借助 INSERT ... ON DUPLICATE KEY UPDATE。