将16字节储存扩展到大规模——PromCon 2017会议介绍

2 年 ago
新, 韵
1 minute

虽然时间已经过去了一段时间，但今年8月，专注于Prometheus的会议PromCon 2017在慕尼黑举行，来自Z Lab的我和@tkusumi也参加了会议。

在这篇文章中，我想介绍一下我听到的关于最近发布的 Prometheus 2.0 中最重要的变化之一，即时间序列数据库（TSDB）的会议。

简介

演讲者：Fabian Reinartz (CoreOS)
视频链接：https://youtu.be/b_pEevMAC3I
幻灯片链接：https://www.slideshare.net/FabianReinartz/storing-16-bytes-at-scale-81282712

在Prometheus 2.0版本中，由TSDB实现者进行了关于详解和基准测试的会议。

请注意：本文中使用的所有图片都是经过演讲者同意后引用自上述幻灯片。

请用中文本地语言重新表达以下内容，只需提供一种选择：

– “The weather is nice today.”
– 今天的天气很好。

Prometheus 的 TSDB 数据结构

1.0.time_series.png

TSDB的数据结构可以模拟成上图所示。纵轴表示时间序列的列，每个一一对应于一个度量指标和其所附带的标签组合。例如，以下每个度量指标将与时间序列的每个对应。

requests_total{path="/status", method="GET", instance=”10.0.0.1:80”}
requests_total{path="/status", method="POST", instance=”10.0.0.3:80”}
requests_total{path="/", method="GET", instance=”10.0.0.2:80”}
...

随着时间的推移，时间轴代表时间。由于Prometheus进行刮取，数据样本将被添加到图表的右侧。图表中出现空缺的部分是考虑到刮取可能失败等因素。

1.1.time_series_query.png

在执行对TSDB的查询时，需要获取指定时间段内的指标，并且与多个指标名称和标签的组合相关联的时间序列。因此，需要获取的样本范围将扩展到由红色矩形围起来的多个范围。

请提供所需的磁盘空间估计。

1.2.estimation.png

由于 Prometheus 在时间戳和值之间需要每个8字节，如果直接存储到磁盘上，根据以下要求，所需的磁盘容量将约为7 TB。

項目値アクティブな time series 数500 万スクレイプ間隔30 秒に 1 回データ保持期間1 ヶ月

怎样进行压缩？

1.3.timestamp_compression.png

时间戳压缩是利用样本之间的时间戳差异小于时间戳本身的值来进行的。此外，通过取差异之间的差异可以得到更小的值。

1.4.value_compression.png

利用差分取样，可以将值的压缩变为较小的数值，这种情况常常出现。

1.5.revised_estimation.png

通过这种压缩，似乎可以将相同要求下的所需硬盘容量由7TB提升到0.8TB。

请注意，即使在v1阶段，通过添加启动选项也可以使用这种压缩方法。

指数的改善

1.6.chrun.png

当在Kubernetes中使用Prometheus时，如果由于滚动更新等原因导致Pod重新创建，那么如果Pod或容器的标识符等信息包含在度量指标的标签中，时间序列会在此处断裂，导致图中活跃时间序列的比例减小。

1.7.re-revised_estimation.png

因此，在这种环境下，总体时间序列的数量（包括非活跃时间序列）对查询性能产生影响，而不只是活跃时间序列的数量。

1.8.index.png

Prometheus v2 为了改进，在标签和时间序列（指标）之间引入了逆转索引。每个时间序列都有一个ID，并且该ID会在一个包含任意标签和值组合的时间序列列表（逆转索引）中使用。通过维护这个列表，在执行查询时只需搜索满足搜索条件的列表的交集，就可以找到目标的时间序列。

更改存储布局

1.14.chunks_v1.png

在Prometheus v1中，每个时间序列都需要准备一个文件进行管理。此外，写入文件是以称为“块”的单位进行的。

1.15.blocks_v2.png

在 Prometheus v2 中，通过被时间划分的块来管理所有的时间序列。

1.16.storage_layout.png

每个块都被分开管理在目录中，每个块都有索引和块准备好。新数据被写入预写日志 (WAL) ，一段时间后被写出为块。因此，设计使得不对块进行写入。

基准测试

以下是基准测试的环境。

項目値取得するサンプル数110,000 個毎秒ターゲット数850

下面是对Prometheus的设置进行比较的方式。

    • Prometheus v1.5.2 – クエリの負荷あり

 

    • Prometheus v1.5.2 – クエリの負荷なし

 

    • Prometheus v2 (どの時点のものか不明) – クエリの負荷あり

 

    Prometheus v2 (どの時点のものか不明) – クエリの負荷なし
1.9.benchmarks_memory.png

上面的图表显示了内存使用量（GB）的变化。不论是否有负载查询，与v1.5.2相比，v2的内存使用量约减少了三分之一至四分之一左右。在经过约六个小时后，v1.5.2的内存使用量出现了剧增，这是因为它已经达到了数据保留期的上限，并且在进行数据删除时也会有一定的负载压力。

1.10.benchmarks_cpu.png

下图展示了CPU使用率（每秒核心数）的变化。与内存使用率的趋势相似，但与v1.5.2相比，v2的使用率保持在3-10分之1的水平。

1.11.benchmarks_disk_writes.png

以上的图表显示了向磁盘写入的推移情况（MB/秒）。该指标改善得最为显著。

1.12.benchmarks_disk_size.png

以下图表展示了磁盘大小（GB）的变化。可以看出在v2版本中，相较于v1.5.2版本，磁盘大小被限制在五分之一以下。

1.13.benchmarks_query_latency.png

这个图表展示了查询延迟（秒，99百分位）的变化。

✖
广告
将在 10 秒后关闭
bannerAds