在过去的几年里，时间序列数据库已经从一个奇怪的东西（高度专业化地用于开放监控系统（并与特定解决方案相关）或大数据项目中）变成了“消费产品”。 在俄罗斯联邦境内，必须为此特别感谢 Yandex 和 ClickHouse。 到目前为止，如果您需要存储大量时间序列数据，您要么必须接受构建庞大的 Hadoop 堆栈并维护它的需求，要么与每个系统的单独协议进行通信。
2019年，一篇关于哪个TSDB值得用的文章似乎只有一句话：“就用ClickHouse吧”。 但是……存在细微差别。
事实上，ClickHouse 正在积极发展，用户群在增长，支持也非常积极，但是我们是否成为 ClickHouse 公众成功的人质，它已经掩盖了其他可能更有效/可靠的解决方案？
去年年初，我们开始改造自己的监控系统，期间就出现了选择一个合适的数据库来存储数据的问题。 我想在这里谈谈这个选择的历史。
制定问题
首先，必要的前言。 为什么我们需要自己的监控系统？它是如何设计的？
我们于 2008 年开始提供支持服务，到 2010 年，很明显，用当时存在的解决方案（我们正在谈论，上帝原谅我，Cacti，Zabbix）聚合有关客户端基础设施中发生的流程的数据变得很困难和新兴的石墨）。
我们的主要要求是：
- 在一个系统内支持（当时是数十个，将来是数百个）客户端，同时存在集中式警报管理系统；
- 管理警报系统的灵活性（值班人员之间的警报升级、调度、知识库）；
- 深入描述图表细节的能力（Zabbix当时以图片的形式渲染图表）；
- 长期存储大量数据（一年或更长时间）并能够快速检索。
在本文中，我们对最后一点感兴趣。
说到存储，要求如下：
- 系统必须快速运行；
- 系统最好有SQL接口；
- 系统必须稳定并且有活跃的用户基础和支持（曾经我们面临需要支持系统，例如不再开发的MemcacheDB，或MooseFS分布式存储，其错误跟踪器保留为中文：我们为我们的项目重复这个故事并不想要）；
- 遵守CAP定理：一致性（必需）——数据必须是最新的，我们不希望警报管理系统无法接收新数据并吐出所有项目数据未到达的警报； 分区容错性（必需）——我们不想得到裂脑系统； 可用性（并不重要，如果有活动副本）——我们可以在发生事故时使用代码自行切换到备份系统。
奇怪的是，当时 MySQL 竟然成为我们的理想解决方案。 我们的数据结构非常简单：服务器id、计数器id、时间戳和值； 大缓冲池保证热点数据的快速采样，SSD保证历史数据的采样。
因此，我们获得了两周的新鲜数据样本，详细信息可精确到数据完全渲染前的第二个 200 毫秒，并在该系统中存活了相当长的时间。
与此同时，时间流逝，数据量不断增长。 到 2016 年，数据量达到数十 TB，这对于租用 SSD 存储来说是一笔巨大的开支。
这个时候，列式数据库已经积极普及，我们开始积极思考：在列式数据库中，数据按照你可以理解的方式存储在列中，如果你看一下我们的数据，很容易看到一个很大的数据。如果您使用列式数据库，则可以使用压缩来压缩它的重复项数。
不过，公司的关键系统继续稳定运行，我不想尝试切换到其他系统。
2017 年，在圣何塞举行的 Percona Live 会议上，Clickhouse 开发者可能首次宣布了自己的身份。 乍一看，该系统已做好生产准备（嗯，Yandex.Metrica 是一个苛刻的生产系统），支持快速而简单，最重要的是，操作也很简单。 自2018年起，我们开始了转型过程。 但到那时，已经有很多“成熟”且经过时间考验的 TSDB 系统，我们决定投入大量时间来比较替代方案，以确保根据我们的要求，没有 Clickhouse 的替代解决方案。
除了已经指定的存储要求之外，还出现了新的要求：
- 新系统应该在相同数量的硬件上至少提供与MySQL相同的性能；
- 新系统的存储占用空间应显着减少；
- DBMS 仍然必须易于管理；
- 我想在更改 DBMS 时对应用程序进行最少的更改。
我们开始考虑哪些系统？
Apache Hive/Apache Impala
一个经过考验的旧 Hadoop 堆栈。 本质上，它是一个建立在 HDFS 上以本机格式存储数据之上的 SQL 接口。
优点。
- 运行稳定，数据扩容非常容易。
- 数据存储有列式解决方案（空间较小）。
- 当资源可用时，并行任务的执行速度非常快。
缺点。
- 它是 Hadoop，而且很难使用。 如果我们还没有准备好在云中采用现成的解决方案（而且我们在成本方面还没有准备好），那么整个堆栈将必须由管理员来组装和支持，我们真的不希望这。
- 数据已汇总 .
但是：
速度是通过扩展计算服务器的数量来实现的。 简单地说，如果我们是一家大公司，从事分析，并且尽快聚合信息对业务至关重要（即使是以使用大量计算资源为代价），这可能是我们的选择。 但我们还没有准备好增加硬件群来加速任务。
德鲁伊/皮诺
关于 TSDB 的具体内容还有很多，但同样是 Hadoop 堆栈。
有 .
简而言之：在以下情况下，Druid/Pinot 看起来比 Clickhouse 更好：
- 您具有异构的数据性质（在我们的例子中，我们只记录服务器指标的时间序列，事实上，这是一张表。但可能还有其他情况：设备时间序列、经济时间序列等 - 每个都有它自己的结构，需要聚合和处理）。
- 而且，这样的数据还有很多。
- 具有时间序列的表格和数据出现和消失（即，某些数据集到达、被分析和删除）。
- 没有明确的数据划分标准。
相反的情况下，ClickHouse 表现更好，这就是我们的情况。
点击之家
- 类似SQL
- 易于管理。
- 人们说它有效。
进入测试候选名单。
数据库
ClickHouse 的国外替代品。 缺点： 高可用性仅存在于商业版本中，但需要进行比较。
进入测试候选名单。
卡桑德拉
一方面，我们知道它用于存储监控系统的指标时间序列，例如： 或 OkMeter。 不过，也有具体情况。
Cassandra并不是传统意义上的列式数据库。 它看起来更像是行视图，但每行可以有不同数量的列，从而可以轻松组织柱状视图。 从这个意义上讲，很明显，在 2 亿列的限制下，可以在列中存储一些数据（以及相同的时间序列）。 例如，在 MySQL 中，列数限制为 4096，如果您尝试执行相同的操作，很容易发现代码 1117 的错误。
Cassandra引擎专注于在没有master的分布式系统中存储大量数据，而上述Cassandra CAP定理更多的是关于AP，即关于数据可用性和抗分区性。 因此，如果您只需要写入该数据库而很少从中读取数据，那么该工具可能会非常有用。 在这里，使用 Cassandra 作为“冷”存储是合乎逻辑的。 也就是说，作为一个长期、可靠的地方来存储大量很少需要但可以在必要时检索的历史数据。 尽管如此，为了完整起见，我们也会对其进行测试。 但是，正如我之前所说，我们不想主动重写所选数据库解决方案的代码，因此我们将对其进行有限的测试 - 不根据 Cassandra 的具体情况调整数据库结构。
普罗米修斯
出于好奇，我们决定测试 Prometheus 存储的性能 - 只是为了了解我们是否比当前解决方案快或慢以及慢了多少。
测试方法和结果
因此，我们在以下 5 种配置中测试了 6 个数据库：ClickHouse（1 个节点）、ClickHouse（3 个节点的分布式表）、InfluxDB、Mysql 8、Cassandra（3 个节点）和 Prometheus。 测试计划如下：
- 上传一周历史数据（每天840亿个值；208万个指标）；
- 我们生成一个记录负载（考虑了 6 种负载模式，见下文）；
- 在记录的同时，我们定期进行选择，模拟使用图表的用户的请求。 为了不让事情变得太复杂，我们选择了一周 10 个指标的数据（这正是 CPU 图表上的数量）。
我们通过模拟监控代理的行为来加载，该代理每 15 秒向每个指标发送一次值。 与此同时，我们对改变：
- 写入数据的指标总数；
- 向一个指标发送值的时间间隔；
- 批量大小。
关于批量大小。 由于不建议通过单个插入加载几乎所有实验数据库，因此我们需要一个中继来收集传入指标并将它们分组并将它们作为批量插入写入数据库。
此外，为了更好地理解如何解释接收到的数据，让我们想象一下，我们不仅发送一堆指标，而且将指标组织到服务器中 - 每个服务器 125 个指标。 这里服务器只是一个虚拟实体——只是为了理解，例如，10000 个指标对应大约 80 个服务器。
考虑到所有这些，这里是我们的 6 种数据库写入加载模式：
这里有两点。 首先，对于 Cassandra 来说，这些批量大小太大，因此我们使用了 50 或 100 的值。其次，由于 Prometheus 严格在拉模式下工作，即它本身会从指标源收集数据（甚至pushgateway，尽管有这个名字，并没有从根本上改变情况），相应的负载是使用静态配置的组合来实现的。
测试结果如下：
有什么值得注意的：来自 Prometheus 的样本速度极快，来自 Cassandra 的样本速度极慢，来自 InfluxDB 的样本速度慢得令人无法接受； 在录制速度方面，ClickHouse赢得了所有人，而Prometheus不参与竞争，因为它自己进行插入，我们不测量任何东西。
其结果是，：ClickHouse和InfluxDB证明了自己是最好的，但是Influx的集群只能建立在企业版的基础上，需要花钱，而ClickHouse不花钱，而且是俄罗斯制造的。 合乎逻辑的是，在美国，选择可能会支持 inInfluxDB，而在我们国家，选择可能会支持 ClickHouse。
来源： habr.com