作者 | Ryo Nakao ? ? ? ?
译者 | 王雪迎 ? ? 责编 | 张红月
出品 | CSDN（ID：CSDNnews）
本文翻译自 Ryo Nakao 的个人博客（https://corecursive.com/066-sqlite-with-richard-hipp/）主要告诉人人如何实现一个时间序列内容库引擎。它是作者的经验之谈，是我在从头起头编写一个轻量级时间序列内容库引擎中所学到的。
固然本引擎用 Go 语言编写，但文中所涉及的绝大部门数据与编程语言无关。
动机
我一直在研究一些处理海量时间序列内容的工具。此中之一名为 Ali（https://github.com/nakabonne/ali），是一个负载测试工具，能够在客户端及时绘制度量值。它哀求执行特定的查询，并将每个查询的效果，如耽误或任何其它度量，进行无休止地写入。换句话说，这有点像在一台主机上建立一个带有简洁查询功能的推送监督体系。
在以前的实现中，它只是将内容点追加到堆上的变长数组中。这种做法天然会导致一个问题，即跟着时间的推移，内存使用量将络续增加：
由 nakabonne/gosivy 测量的 Ali 堆使用量
为认识决这个问题，我尝试开发了一个存储引擎，能够被用作 Go 法式库。
时间序列内容的特性
我们首先要认识时间序列内容，以便理清必要解决的问题。
时间序列内容是具有时间戳的多个值的鸠合。它一般被用于察看随时间转变的内容。每个时间序列内容都被称为内容点，平日透露为一个带有时间戳和值的元组。时间序列内容具有以下特性：
1. 内容量伟大
由于时间序列内容的性质，单个内容点很少有意义，只有在网络了大量内容之后，它才会变得有效。在金融行业里，内容捕捉要求跨越 1000000/s 次的环境并不少见，因为内容平日是在短时间内写入的。
在 Ali 的用例中，用户指定的哀求速度与写性能需求直接相关（尽管文件描述符数量的上限根基上是瓶颈）。
为了处理海量内容，我们必要集中精神尽量优化内容写入过程，还必要尽可能削减磁盘空间的消耗。
2. 只追加
每个内容点都是不变的。并且，平日会对较老的内容执行批量删除操纵，而不指定特定内容点。
3. 按时间排序
由于内容按时间戳排序存储，因此能够将其视为已按时间索引。行使这一性质你能够在没有任何开销的环境下创建索引。
4. 批量访问
在读出内容时，主要是通过指定一个时间段来检索具有一连时间戳的多个内容点。你能够行使此特征来提拔内容读取时的局部性。
5. 近来优先
在许多用例中，我们倾向于读取和使用近来的内容点。这可能会影响缓存算法的选择。
6. 高基数
时间序列内容往往具有更高的基数。例如，在体系监控情况中尤其如此。云原生时代，我们获得了更多的机会来监控动态转变的主机和收集等情况。
从这个意义上说，险些没有完全雷同的度量尺度；为每个度量建立一个文件将导致各种问题，例如 inode 限定。
现有解决方案
总体来说，我们发现对时间序列内容的操纵是写密集型，而且很多环境下是在一个时间范围内顺序读 / 写内容。
Google 的 LevelDB 是一个众所周知的键 - 值存储引擎，并已发布了一些 Go 语言的实现。LevelDB 是基于 LSM 树实现的，它只对尾部进行顺序写入，适用于只追加的时间序列内容。按键排序也使它得当于基于时间戳的时间序列内容。事实上，早期的 Prometheus 和 InfluxDB 存储引擎也是基于 LevelDB 的。
本文地址：http://www.wbwb.net/bianchengyuyan/224244.html 转载请注明出处！