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%。
使用场景及特点
创建一个简单的共享服务和客户端，后者可以存储和处理时间序列查询请求。
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的应用情况，读者可以参考了解。
本文转自d1net（转载）
