分布式时序数据库-不破不立

题外话：时间过了这么久（最近确实有点忙），才开始说时序数据库背景、需求及现状。其实主要想说明一个问题：为什么需要做一个分布式时序数据库？DBEngine 数据库关注度趋势有趣地是，这些细分领域中，数据就像时间流水线一样，源源不断。

而基于时间戳地时序分析、时序预测、时序存储才是时序数据库要解决的问题。

那么为什么我们不用Hadoop、不用RDBMS？无人驾驶领域存储：每辆车每天产生8TB+ 的数据存储分析：多种维度组合聚合、统计、关联和机器学习读写：各种状态监控数据，包括温度、湿度、方向、坐标、速度、告警、运行数据的高并发写入和查询。计算：时序范围的窗口计算，要求近实时返回结果。也许数据依然是那些类型，结构化、半结构化、非结构化。

但是IOE领域，对于时序数据存储和计算的要求更高了。

数据分析的维度更加复杂数据计算的效率要求更高数据存储的成本要求更低数据读写的能力要求更强在这里，我不得不吐槽一下围绕着Hadoop做的时序数据库，真的太重了，那么多组件要维护，好复杂。可能，有同学会基于Hadoop来做时序数据的存储和分析。OK，我告诉你，没有问题。

但是，我想要时序数据在边缘设备进行部署，这个Hadoop是不是太重了呢？我还想要做海量数据多维分析计算，你能忍受Hadoop的计算延迟吗？可能，有同学会基于RDBMS来作为时序数据，OK，我告诉你，也没有问题。但是，你可以忍受海量时序数据巨大的数据冗余和高昂的存储成本吗？我还想要基于时间和计数器的窗口计算，这个怎么搞？抽象一下，其实落脚到时序数据库具体设计目标上，其实我们要解决的问题域应该以下一些，是不是？高效地时序数据压缩，降低存储成本，为用户省钱啊。

支持时间范围，维度组合、指标组合的数据检索，比如数亿时序点的秒级响应支持时间范围，维度组合、指标组合的数据计算，支持海量数据高并发的持续写入，比如每秒写个上千万的时序点支持基于计数和时间的窗口计算当然，你还要足够轻量级。

我既可以放在边缘侧做边缘侧的数据存储和计算；也可以放在大数据中心，海量数据的存储。还有很多....这里主要先明确一下问题域，大概知道我们要做的时序数据库的设计目标。才能将目标拆分，是吧。

具体看看一下篇吧。里面会涉及到时序数据库功能架构，然后会分别介绍一下每个模块的功能和一些设计思路。 当然，技术架构要放到后面一篇，是不是？好了！ 时序数据库开胃菜 --不破不立。 做事情，一定要说服自己为什么？今天，心情色。