从零写一个时间序列数据库

尽管基于块存储的方法非常棒，但为每个序列保存一个独立的文件会给 V2 存储带来麻烦，因为：

• 实际上，我们需要的文件比当前收集数据的时间序列数量要多得多。多出的部分在序列分流Series Churn上。有几百万个文件，迟早会使用光文件系统中的 inode。这种情况我们只能通过重新格式化来恢复磁盘，这种方式是最具有破坏性的。我们通常不想为了适应一个应用程序而格式化磁盘。
• 即使是分块写入，每秒也会产生数千块的数据块并且准备持久化。这依然需要每秒数千次的磁盘写入。尽管通过为每个序列打包好多个块来缓解，但这反过来还是增加了等待持久化数据的总内存占用。
• 要保持所有文件打开来进行读写是不可行的。特别是因为 99% 的数据在 24 小时之后不再会被查询到。如果查询它，我们就得打开数千个文件，找到并读取相关的数据点到内存中，然后再关掉。这样做就会引起很高的查询延迟，数据块缓存加剧会导致新的问题，这一点在“资源消耗”一节另作讲述。
• 最终，旧的数据需要被删除，并且数据需要从数百万文件的头部删除。这就意味着删除实际上是写密集型操作。此外，循环遍历数百万文件并且进行分析通常会导致这一过程花费数小时。当它完成时，可能又得重新来过。喔天，继续删除旧文件又会进一步导致 SSD 产生写入放大。
• 目前所积累的数据块仅维持在内存中。如果应用崩溃，数据就会丢失。为了避免这种情况，内存状态会定期的保存在磁盘上，这比我们能接受数据丢失窗口要长的多。恢复检查点也会花费数分钟，导致很长的重启周期。

我们能够从现有的设计中学到的关键部分是数据块的概念，我们当然希望保留这个概念。最新的数据块会保持在内存中一般也是好的主意。毕竟，最新的数据会大量的查询到。

一个时间序列对应一个文件，这个概念是我们想要替换掉的。

序列分流

（编辑：网站开发网_安阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!