🚀 功能请求
此功能请求旨在支持一个原生的时间序列数据库，它支持相同的丰富查询界面，但以一种高效的方式持久化数据，这种方式也可以进行汇总，并在将来可选地卸载/归档。
动机
当前将指标写入rocks db,这使得扩展到数千或数百万个不同的实验变得具有挑战性。它也不太可能支持多租户环境，该环境可能有数千或数百万个不同的实验。
提议
探索已证明能够捕获和报告大规模指标的开源时间序列选项，例如：
- Grafana Loki,它支持metric queries和LogQL日志查询语言
- M3分布式TSBD是chronosphere的存储层，并支持PromQL查询语言
- Redis TimeSeries是一个更低级解决方案，它提供了快速的内存过滤时间序列，包括对降采样和聚合的支持
替代方案
或者，您可以探索使用SaaS解决方案，如Influxdb或aiven。在另一端，您可以在类似于Apache Bookkeeper的基础上构建自己的自定义分布式TSDB,它提供了高效的预写日志和对云对象存储的本地卸载。
其他上下文
此功能将使解决方案能够扩展到数千或数百万个不同的实验，这将使其与mlflow区别开来。
4条答案
按热度按时间pobjuy321#
另一个选择可能是使用ClickHouse,因为它是一个开源的快速OLAP存储。它还支持多种不同的日志引擎，这可能非常适合指标。它还支持嵌入式RocksDB。
查看此线程以了解更多关于引擎类型的信息：
$1. ClickHouse支持多种日志引擎，包括：$
$JSONEachRow
$Log
$TsvEachRow
$TSVEachRow
$TinyLog
$TinyLogWithTime
$LZ4
$LZ4HC
$SnappyStreamingCompression
$ZSTD
suzh9iv82#
感谢brightsparc的评论。目前我们专注于集中式跟踪服务器的实现，这将使我们在服务器端有更多的灵活设置。
Clickhouse对于大量数据的处理是一个很好的选择，它具有强大的数据聚合和采样功能。从某种意义上说，删除数据是有点问题的，但这些问题是可以解决的。考虑到Aim对数据库的需求，值得考虑使用时间序列数据库。一旦我们开始着手这个工作，我们会确保以一种不会破坏SDK和其他用户界面的方式重新设计Aim,从而改变存储后端。
apeeds0o3#
是否有关于这个目标的更新？
如果有一个存储后端的实现，那么人们就可以开始使用不同的时间序列数据库和它们的性能来贡献了，这将会非常有用。
hfwmuf9z4#
感谢你的评论。目前我们专注于集中式跟踪服务器的实现，这将使我们在服务器端有更灵活的设置。
Clickhouse对于大量数据来说是一个很好的选择，它具有强大的数据聚合和采样功能。从删除数据的Angular 来看，它有一些问题，但这些问题是可以解决的。考虑到Aim对数据库的需求，值得考虑时间序列数据库。一旦我们开始着手这个项目，我们会确保以一种不会破坏SDK和其他UI的方式重新设计Aim,以便可以更改存储后端。我认为，为Aim添加对多个后端的支持将极大地帮助其采用。我刚刚在几天前了解到这个项目，并对其UI印象深刻，但如果没有这种互操作性，将其集成到现有成熟项目的基础设施中似乎需要付出太多的努力。