Facebook开源时间序列内存数据库Beringei，追求极致压缩率——若是是int根据大多数时间序列中的值与相邻数据点相比并无显著的变化，只要使用XOR将当前值与先前值进行比较，而后存储发生变化

转自：http://www.infoq.com/cn/news/2017/02/Facebook-Beringei

2017年2月3日，Facebook宣布将开源他们的高性能时序数据存储引擎Beringer。Beringei是用来解决其内部监控数据存储和查询需求的数据库，其特色是读写速度快，属于内存数据库的一种。本文将会详细介绍Beringei的前因后果以及它的设计思路、应用场景和特色。

Beringei的诞生背景

运维大规模的分布式服务，一般须要对内部系统的运行情况和性能指标进行实时并精确的监控，以便在第一时间发现、诊断、处理出现的问题。

Facebook使用时间序列数据库（TSDB）跟踪和存储系统度量指标，好比说产品的统计信息（每分钟发送多少消息）、服务的统计信息（命中缓存层与MySQL层的查询速率），以及系统的统计信息（CPU、内存和网络的使用状况）等等，基于这些数据运维人员就能够看到基础设施上的实时负载状况，并指定策略决定如何分配资源。

Facebook的每一个系统、服务每秒须要向存储引擎写入成百上千个数据指标，而负责进行数据分析的工程师能够实时查询这些数据。

2013年初，随着公司和系统的不断发展，Facebook的存储引擎监控团队发现HBase使用的TSDB没法灵活扩展，致使将来可能没法处理高并发的读取负载。若是是分析少许数据，平均读取延迟能够接受，可是试图实时处理大量数据的需求没法知足，用户体验不好。大批量数据查询时间可能须要数秒钟，这对于可能须要发出数百个或数千个查询来执行分析的自动化工具来讲是不可接受的。几千个时间序列的查询请求要花几十秒的时间来执行，针对稀疏数据集执行的查询可能会超时，这是由于HBase数据存储通过调整后，策略改成优先处理写入操做。

因为查询性能太差，监控系统没法实时处理大规模分析。Facebook团队在评估和否决了几款基于磁盘的解决方案和现有的内存缓存解决方案后，存储引擎开发团队将注意力转移到自行编写内存TSDB方案，以支持Facebook的运行情况和性能监控系统。团队在VLDB2015大会上发表了一篇名为《Gorilla：一种快速、可扩展的内存时间序列数据库》的文章，Beringei正是基于这项工做成果的进一步发展。

Beringei的设计思路

Beringei基于BSD协议，它不一样于其余的内存系统（好比Memcached），Beringei经过优化，支持存储专门用于运行情况和性能监控的时间序列数据。设计Beringei的初衷是为了更高的写入速率和更低的读取延迟，同时尽量高效地使用内存来存储时间序列数据。Facebook团队建立了一种系统，该系统能够存储最近24小时内在Facebook生成的全部性能和监控数据，以便Facebook在生产环境中遇到问题后，能够极快地探究并调试系统和服务。

数据压缩对于帮助下降存储开销必不可少。Facebook考虑了现有的压缩方案，仅适用于整数数据的方法、使用近似技术的方法，以及须要对整个数据集进行操做的方法都被Facebook否决了。

Beringei使用一种无损耗数据流压缩算法，压缩时间序列里面的数据点，不进行跨时间序列的额外压缩。每一个数据点是一对64位值，表示当时计数器的时间戳和值。时间戳和值使用前一个值的信息单独压缩。时间戳压缩使用delta-of-dalta编码方式，经过采用规则的时间序列在较少的内存内存储时间戳。

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

知道这一点后，只要使用XOR将当前值与先前值进行比较，而后存储发生变化的比特。最终，该算法将整个数据集至少压缩了90%。

使用场景及特色

Facebook团队预计Beringei主要有两种使用场合：

1. 建立一个简单的共享服务和客户端，后者能够存储和处理时间序列查询请求。

2. Beringei能够用做一个嵌入库，处理高效存储时间序列数据的底层细节。以这种方式使用Beringei相似RocksDB，Beringei有望成为支持其余性能监控解决方案的高性能存储系统。

Beringei做为库的使用具备下列特色：

1. 支持速度很是快的内存存储，并由硬盘保证数据持久性。存储引擎的查询老是在内存张处理，提供了极高的查询性能，除非须要到磁盘查询，不然通常不进行磁盘操做，因此能够在停机时间极短、数据没有丢失的状况下重启或迁移进程。

2. 极其高效的数据流压缩算法。采用的数据流压缩算法可以将实际的时间序列数据压缩90%以上。Beringei使用的delta of delta压缩算法也很高效，单个机器每秒就可以压缩150多万个数据点。

虽然将Beringei直接嵌入到另外一个TSDB里面也是一种方案，可是Facebook更加推荐采用一体化实现方案，这种一体化实现让用户能够扩建可扩展的分片服务。

1. 参考分片服务实现。Beringei项目同时包括时间序列存储数据库和相关的客户端实现。

2. 可视化集成。Beringei提供一种HTTP服务实现，可以直接与Grafana集成起来，而且易于横向扩展。

Beringei须要部署在Ubuntu 16.10（其他系统未作测试），较为严重的问题是外部代码依赖较多，致使部署环境不太容易，须要依赖fbthrift、folly、wangle、proxygen、gtest、gflags。

Beringei在Facebook的应用

Beringei目前是Facebook的监控基础设施的一部分，它能够支持针对监控系统提供的实时响应机制。Beringei收到请求后，当即能够提供查询服务，数据写入Beringei与可供使用之间的延迟大约是300微秒，Facebook的p95服务器响应读取请求的时间大约是65微秒。相比Facebook本来基于磁盘的旧引擎设计方案，Beringei的内存系统在读取性能方面和写入性能方面都高出几个数量级。此外，Beringei支持与Facebook的自动检测系统配合使用，该系统观察数百万个时间序列，以便检测异常、发出警报。

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

Gorilla：Beringei的原型系统

Gorilla是一种快速、可扩展的内存时间序列数据库，是开源的Beringei的原型系统。

另外，阿里云数据库高级专家叶翔借着源代码和论文，对Beringei原理进行了解读，同时也介绍了它在Facebook的应用状况，读者能够参考了解。