在 MariaDB / MySQL 中存储实时时间序列的最佳解决方案是什么？

Question

用例：测量创建给定数量的图像。对于每张图像，我们需要存储一小组质量指标（浮点数、双精度数）以及图像整数 [1 ...N]、时间戳和一个或两个外键值。然后应该在 Web 应用程序 (PHP) 中“实时”绘制它以供用户评估。

每个 Web 客户端每 5 秒轮询一次数据库。理想情况下，每组质量指标的存储 + 检索应该花费 < 2 秒（大约）。在最坏的情况下，可能有大约 30 个同时进行的 Web 客户端轮询，并且可能同时写入大约 10 个测量值，从而导致大约 30 次的写入突发。每秒1000组质量指标。

在编程语言中，这类数据可能会存储在数组或列表中。由于我不知道在 MariaDB / MySQL 世界中有任何类似的东西，我只是使用一个常规的 InnoDB 表，上面提到的每个值都有一列。这已经有 90 多万行，预计在未来几个月会增长得更快。

InnoDB 总体上是最好的存储引擎，还是我应该考虑其他？最好的做法是在一段时间后存档数据，也许是在处理完所有测量图像后？它会帮助启用压缩，还是会对性能产生非常负面的影响？

Answer 1

只使用 MySQL/MariaDB，我会使用：

高速摄取：http : //mysql.rjweb.org/doc.php/staging_table
汇总表（使获取数据更快）：http : //mysql.rjweb.org/doc.php/summarytables
我什至会考虑不存储原始数据；而是汇总数据，然后将其扔掉。如果这是可行的，它可以避免您提出的大多数问题。
（如果数据需要清除）：快速删除旧数据：http : //mysql.rjweb.org/doc.php/partitionmaint
我会避免FOREIGN KEYS因为额外的开销。（相反，我会调试 SQL。）
我不会使用 UUID 键；性能在巨大的表中严重退化。( http://mysql.rjweb.org/doc.php/uuid )
我会避免额外的索引——AUTO_INCREMENT如果其他列是唯一的，请不要使用。
你提到空间——请详细说明。2D 查找很棘手；SPATIAL是一种方法；这是另一个：http : //mysql.rjweb.org/doc.php/latlng

你的最后一段抛出了问题的厨房水槽（Toku、MyRocks、存档、压缩、历史表）。我很惊讶这个帖子并没有因为“太宽泛”而被删除。请详细说明您的数据和查询是什么样的；否则，我们所能做的就是扔一个装满解决方案的厨房水槽。

你说“实时”，但你需要“数千/秒”。你能允许实时延迟 1 分钟吗？1秒？你不能得到 1ms；1s 很难实现。一次爆发能持续多久？什么是每分钟爆发？1K/秒可能会溢出到接下来的几秒钟。6K/分钟也不是很麻烦。

有多少客户端存储数据？一些解决方案适用于单个客户端；多个客户需要不同的解决方案。

请记住，基准测试是为了炫耀一件事，很少与现实生活相匹配。

Answer 2

那里有一些大问题，可能需要比这里更仔细的检查，因为有太多的依赖关系（意识到你知道这一点！）。Percona Live 和 Percona Live Europe 页面上的演示文稿中有许多关于时间序列的幻灯片，可以帮助您进一步了解这一点。例如，关于使用 Yandex 的 ClickHouse

您可能还会发现一些博客文章很有趣。本文着眼于 TokuDB 与 InnoDB 的时间序列基准测试。

希望这些有帮助。