传统关系型数据库存储时序数据的问题
如果有时间序列数据的话，应该保存在哪里呢？ 首先，我们来看一下传统的关系数据库解决方案在存储时间序列数据时会出现什么问题。
许多人可能认为，在传统关系数据库中添加时间戳列可以用作时间序列数据库。 数据量少的时候也确实没有问题。 但时序数据多由百万至千万级的终端设备生成，写入并发量高，属于海量数据场景。
MySQL在大量时间序列数据的场景中存在以下问题：
存储成本大：时序数据压缩不佳，消耗大量机械资源；
维护成本高：单机系统，上层需要人工分库分表，维护成本高；
写入吞吐量低：单体写入吞吐量低，难以满足时序数据千万级的写入压力；
查询性能差：适合事务处理，海量数据聚合分析性能差。
此外，使用Hadoop eco (Hadoop、Spark等)保存时间序列数据时，还会出现以下问题：
高数据延迟：离线批处理系统，从数据生成到分析，耗时数小时甚至每日；
查询性能差：不能很好地利用索引，依赖于MapReduce任务，查询通常需要很长时间。
您可以看到时间序列数据库需要解决以下问题：
时序数据写入：如何支持每秒写入数千万个数据点。
时序数据读取：如何支持在秒级别分组数以亿计的数据的运算。
成本敏感：海量数据存储带来的是成本问题。 以更低的成本存储这些数据是时序数据库要解决的关键。
**** 时序数据库的优势
*时序数据库产品的发明是为了解决传统关系数据库在时序数据存储和分析上的不足和缺陷，这些产品统一分类在时序数据库中。 **写入、保存、查询等流程针对与时序数据特征相关的时序数据特征进行了优化。
存储成本：
利用时间增长、维数重叠、指标平滑变化的特性，合理选择编码压缩算法，提高数据压缩率；
通过提前降低精度，聚合历史数据，节约存储空间。
高并发写入：
批量写入数据，减少网络开销
数据写入内存，周期性dump是不变的文件存储器。
查询延迟时间短，查询并行时间长：
优化常见查询模式，通过索引等技术降低查询延迟
通过缓存、路由等技术提高查询的并发性。
开源时序数据库与目前行业内比较流行的开源时序数据库产品相比，有InfluxDB、OpenTSDB、Prometheus、Graphite等，其产品特性如下图所示。
参考： https://blog.csdn.net/Liu Kuan 73/article/details/79950329