转载

Facebook 刚刚开源了高性能、内存型的时序数据库存储引擎：Beringei

运行大规模的全球分布式服务需要对我们系统的运行状况和性能进行精确监控，以便在第一时间识别和诊断出现的问题。Facebook使用时间序列数据库（TSDB）来跟踪和存储系统度量指标，比如说产品的统计信息（比如每分钟发送多少消息）、服务的统计信息（比如命中缓存层与MySQL层的查询速率），以及系统的统计信息（比如CPU、内存和网络的使用情况），那样我们就能看到基础设施上的实时负载，并就如何分配资源做出决策。

Facebook的每个系统和服务向我们的存储引擎写入数百个至数千个计数器，查看仪表板、执行即席性能分析的工程师可以实时查询这些数据。

2013年初，我们的监控团队意识到，我们的系统和公司发展后， HBase支持的现有TSDB无法灵活扩展，无法处理未来的读取负载。如果是分析少量数据，我们的平均读取延迟还可以接受，但是试图通过交互式仪表板显示更多的数据导致了糟糕的体验。第90个百分位查询时间增加到了数秒，这对于可能需要发出数百个或数千个查询来执行分析的自动化工具来说是不可接受的。几千个时间序列的中等大小的查询要花几十秒的时间来执行，针对稀疏数据集执行的更庞大的查询会超时，因为HBase数据存储已经过调整，优先处理写入操作。

一般来说，大规模监控系统无法实时处理大规模分析，因为查询性能太差劲了。在评估和否决了几款基于磁盘的解决方案和现有的内存缓存解决方案后，我们将注意力转移到自行编写内存TSDB上，以支持Facebook的运行状况和性能监控系统。我们在VLDB 2015大会上发表了《Gorilla：一种快速、可扩展的内存时间序列数据库》，最近开源了Beringei，这种高性能时间序列存储引擎基于这项工作的成果。

Beringei不同于其他的内存系统，比如memcache，原因在于它经过了优化，可以存储专门用于运行状况和性能监控的时间序列数据。我们设计Beringei的初衷是获得很高的写入速率和很低的读取延迟，同时尽可能高效地使用内存来存储时间序列数据。最后，我们创建了一种系统，可以存储最近24小时内在Facebook生成的所有性能和监控数据，以便我们在生产环境中遇到问题后，可以极快地探究并调试系统和服务。

数据压缩对于帮助降低存储开销必不可少。我们考虑了几种现有的压缩方案，否决了仅适应于整数数据的方法、使用近似技术的方法，或者需要对整个数据集进行操作的方法。

Beringei使用一种无损耗数据流压缩算法来压缩时间序列里面的数据点，不进行跨时间序列的额外压缩。每个数据点是一对64位值，表示当时计数器的时间戳和值。时间戳和值使用关于先前值的信息单独压缩。时间戳压缩使用delta-of-delta编码，所以规则的时间序列占用很少的内存来存储时间戳。

我们在分析了存储在我们的性能监控系统中的数据后发现，大多数时间序列中的值与相邻数据点相比并没有显著的变化。此外，许多数据源只存储整数（尽管系统支持浮点值）。

我们知道这一点后，就能够调整以前的学术工作，以便计算起来更容易，只要使用XOR将当前值与先前值进行比较，然后存储发生变化的比特。最终，该算法将整个数据集至少压缩了90%。

我们预计Beringei主要有两种使用场合。首先，我们创建了一个简单的分片服务和参考客户端实现，后者可以存储和处理时间序列查询请求。第二，Beringei可以用作一个嵌入库，处理高效存储时间序列数据的低层细节。以这种方式使用Beringei类似RocksDB――Beringei有望成为支持其他性能监控解决方案的高性能存储系统。

Beringei作为库来使用具有下列特点：

支持速度非常快的磁盘支持的内存存储，获得数据持久性。进入到存储引擎的查询总是在内存中来处理，因而提供了极高的查询性能，但是倒回到磁盘，所以可以在停机时间极短、数据没有丢失的情况下重启或迁移进程。
极其高效的数据流压缩算法。我们的数据流压缩算法能够将实际的时间序列数据压缩90%以上。Beringei使用的delta of delta压缩算法也很高效――单个机器每秒就能够压缩150多万个数据点。

虽然将Beringei直接嵌入到另一个TSDB是它的一种用法，但是我们添加了一种参考服务实现。这种一体化实现让用户得以构建可横向扩展的分片服务。

参考分片服务实现。Beringei项目同时包括时间序列存储数据库和相关的客户端实现。
可视化集成。我们提供一种HTTP服务实现，能够直接与Grafana集成起来，并且易于横向扩展。

Beringei在Facebook的应用

Beringei是我们Facebook的监控基础设施的一部分。拥有一个快速、可扩展的存储层对于支持我们的工程师期望监控系统提供的实时响应机制而言很重要。在成功的put请求后，数据立马可以用来查询；内容写到Beringei与可供使用之间的延迟大约是300微秒，我们的p95服务器响应读取请求的时间大约是65微秒。相比我们原来基于磁盘的旧系统，Beringei的内存系统在读取性能方面和写入性能方面都高出几个数量级。此外，Beringei可与我们的自动检测系统配合使用，该系统观察数百万个时间系列，以便检测异常、发出警报。

Beringei目前存储多达100亿个独特的时间序列，每分钟可处理1800万次查询，为Facebook的大部分性能和运行状况监控任务提供支持，同时让我们的工程师和分析员能够借助准确的实时数据，快速做出决策。

我们希望，通过更广泛地共享这项技术，能与业界和学术界更紧密地合作，并且将新的解决方案集成到我们的监控系统中。

Github： https://github.com/facebookincubator/beringei

云头条编译｜未经授权谢绝转载