为什么ListenBrainz从InfluxDB迁移到TimscaleDB

ListenBrainz团队一直在努力将我们的主要监听存储从InfluxDB迁移到TimscaleDB，今天UTC 16：00我们将进行转换。

我们在推特上被问到为什么要进行转换--为了给出一个真实的转换用例，我写了这篇文章。原因是多方面的：

开放性：随着时间的推移，InfluxDB似乎走上了一条会降低其开放性的道路。TimscaleDB及其对Postgres的依赖让我们在这方面感到安全得多。

现有用途：我们已经使用Postgres大约18年了，它一直是我们可靠的主力。我们的团队从Postgres和InfluxDB的角度考虑，对我们来说总是感觉像是方孔中的圆钉。

数据结构：InfluxDB显然是用来存储服务器事件信息的。我们存储的是LISTEN信息，它的使用模式略有不同，但这种细微的差异足以让我们碰壁，因为我们数据库中的用户比我们预期的要少得多。InfluxDB根本不够灵活，不能满足我们的需求。

查询语法和度量名称：查询InfluxDB的语法既奇怪又混乱。我们犯了一个错误，试图向用户提供测量地图，但是正确地转义测量名称几乎把我们的一名团队成员逼到了疯人院。

现有数据：如果您曾经将错误数据写入InfluxDB中的度量，则无法更改它。我意识到这是一种常见的大数据使用模式，但对我们来说，要为用户提供简单的功能是巨大的挑战和严重的限制。使用TimscaleDB，我们可以非常偶尔地进行更新或删除，然后继续前进。

可伸缩性：即使为了设计一个可伸缩的模式，我们尝试了尽可能多的读取，但我们仍然失败了，并且弄错了。(当我们第一次开始使用InfluxDB时，我甚至认为用于计算可伸缩性的文档根本不存在。)。除非您以完全正确的方式使用InfluxDB，否则您也有可能遇到这个问题。对我们来说，有一天插入速度降到了离谱的每秒数，备份了我们的系统。深入研究这个问题，我们意识到我们的模式设计有一个致命的缺陷，为了修复它，我们必须彻底地将模式更改为更不直观的东西。这是一件让人筋疲力尽的事情，我开始寻找替代方案。

在迁移到TimscaleDB的过程中，我们删除了大量复杂的代码，并接受了我们熟悉和喜爱的数据库。我们知道Postgres的规模，我们知道如何将其投入生产，我们知道它的警告。TimscaleDB允许我们灵活地处理数据，并且可以对数据执行令人惊叹的查询，这纯粹是Postgres的爱好。TimscaleDB在使用Postgres时仍然需要仔细考虑，远低于使用InfluxDB时的要求。TimscaleDB还为我们提供了一条清晰的扩展路径，即使TimscaleDB仍在制定自己的扩展路线图。如果TimscaleDB像Postgres一样进化，我迫不及待地想看到这种进化。