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 主要有两种使用场合：
- 创建一个简单的共享服务和客户端，后者可以存储和处理时间序列查询请求。
- Beringei 可以用作一个嵌入库，处理高效存储时间序列数据的底层细节。以这种方式使用 Beringei 类似 RocksDB ，Beringei 有望成为支持其他性能监控解决方案的高性能存储系统。
Beringei 作为库的使用具有下列特点：
- 支持速度非常快的内存存储，并由硬盘保证数据持久性。存储引擎的查询总是在内存张处理，提供了极高的查询性能，除非需要到磁盘查询，否则一般不进行磁盘操作，所以可以在停机时间极短、数据没有丢失的情况下重启或迁移进程。
- 极其高效的数据流压缩算法。采用的数据流压缩算法能够将实际的时间序列数据压缩 90% 以上。Beringei 使用的 delta of delta 压缩算法也很高效，单个机器每秒就能够压缩 150 多万个数据点。
虽然将 Beringei 直接嵌入到另一个 TSDB 里面也是一种方案，但是 Facebook 更加推荐采用一体化实现方案，这种一体化实现让用户可以扩建可扩展的分片服务。
- 参考分片服务实现。Beringei 项目同时包括时间序列存储数据库和相关的客户端实现。
- 可视化集成。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 的原型系统。作为监控系统，它重点赶住数据集合分析，并且认为对于发现、诊断正在发生的问题时，最近的数据点的价值要大于旧的数据点，传统的 ACID 不是核心内容。Gorilla 主要针对高可用的读写做了优化，故障发生时，允许丢失少量写数据。Gorilla 将数据保存至多个数据中心，但不保证数据一致性。
为了改善效率，时间戳压缩算法使用了 delta-of-delta 编码算法，数据值采用 XOR 进行压缩，存储容量压缩了近 10 倍。Gorilla 将数据放置于内存中，与基于 HBase 的传统数据库存储时间序列数据方式相比，查询延时缩短了 73 倍，吞吐量提高了 14 倍。
2015 年数据，Gorilla 支持 80 台集群规模，提供了富客户端解决方案，需要客户端配合完成机房容灾、异常恢复。
Gorilla 实际上是一套混合存储解决方案：
- In-Memory 解决快速写入，提供近期快速读取
- In-SSD 提供星期级别的监控数据读取
- In-SATA 提供历史数据永久归档
另外，阿里云数据库高级专家叶翔借着源代码和论文，对Beringei 原理进行了解读，同时也介绍了它在Facebook 的应用情况，读者可以参考了解。
感谢郭蕾对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。
