每天感悟 偶然听到一个刺耳的论断，大多数的动物，雌性都具备保护自己幼崽的能力，智力越低下，越不求回报，在自然界哺乳动物的爱远不及一些冷血动物。
对于时序数据SQL的加入会让很多处理，变得异常的复杂，当然这不是说SQL语言本身的问题，而是SQL语言加入导入的关系型数据处理的思维方式让事情变得困难，主要的原因还是SQL得思维方式并不是为处理时序数据而设计的，用SQL来分析时序数据会让着一些变得糟糕。
从传统的思维模式来看，SQL的产生是起源于传统的RDBMS数据库，并且他继承了传统关系型数据库的思维模式，结构化的概念，更新记录，定义结构，所以在很长的一段时间里，SQL是数据分析人员，DBA ，等习惯处理数据的语言，这让他们感到亲切和舒服。
不过，时间序列data给关系数据库带来了新的挑战和处理的一些问题。应用程序、传感器和一系列设备会产生源源不断的时间序列数据streaming，这些数据不像关系数据那样完全符合固定模式。这种不间断的数据流创建了巨大的数据集，导致分析工作负载需要独特类型的数据库。正是在这些情况下，开发人员倾向于转向 NoSQL 和时间序列数据库来处理边缘设备生成的大量半结构化或非结构化数据。
虽然传统数据库本身对于时序数据来说是一种病态的设计，但在时序数据中使用SQL来处理数据是一些传统的数据分析人员最后的救命稻草。
SQL 用户现在可以利用这种熟悉的语言来开发实时应用程序，并有效地收集、存储、管理和分析不断增长的时间序列数据量。虽然目前这样处理时序数据的方法还是有效的，但是我们需要知道一些其他的事情来应对为了的挑战。这里总结了4点
1 时序数据本身之间是没有关系的，在处理这些数据的方式上我们需要转变思路，例如单个点的数据本身是没有意义的，并且这些数据的背景信息是重要的，在数据一段时间内的变化，或者这些数据与定义的背景之间产生了一些意义，用户需要考虑时间并确定查询时间窗口来寻找数据存在的意义，同时时序数据中最大的意义是通过一段时间的数据点的变化，产生不同的指导，并且这些指导有些事需要快速进行处理并给后续的判断产生快速的决策依据，这对于传统数据库来说提出了挑战，从多个表来写入数据或查询相关数据，需要更多的时间和资源。
2 扩展性变得更加重要
针对互联网或工业互联网中的设备并非为我们传统意义的设备，这些设备可能是电子眼，或者触感器，这些设备产生数据的能力远超你的想象，而这些设备的生产商并未达成一致的数据产生的格式，这样的情况下，传统数据库有结构的二维表格将是针对这样的数据的一个障碍。数据写入经常需要调整表结构，数据无法任意扩展，或者数据量太大导致传统数据库中认为的事务太大，等等这些问题，同时这些设备强大的摄取数据的能力，让数据库很肯能在每秒就接受更多的我们传统无意义不能理解的数据量，并且没有任何上限，随着数据不断的增加，对于开源人员和数据库本身的处理速度来说，这都是挑战，是否有能力来进行数据的压缩降低成本，也是一个时序数据本身应该提供的功能。
3 专门优化查询的系统
在查询大量数据的情况下，是否有更适合的查询系统，比如事务分布式SQL的查询引擎，查询引擎本身是否既可以支持行，也能支持列的数据处理，对于时序数据列式存储是必不可少的一种数据处理方式和存储方式，同时是否能利用现代CPU中SIMD 指令让扫描的速度更快，并进行数据额排序处理 根据数据的排序方式，用户可能只需要查看数据的第一列即可找到特定字段的最大值。与此相比，面向行的存储需要用户查看每个字段、标签集和时间戳以找到最大字段值。换句话说，用户必须读取第一行，将记录解析为列，在结果中包含字段值，然后重复。
4 数据的处理本身是否与数据更加的接近，而不是与语言的架构更加的贴近，比如这类数据处理程序的是否可以嫁接更多的语言，如C、C 、C#、Go、Java、JavaScript、Julia、MATLAB、Python、R、Ruby等这些数据。这意味着，在这样类型的框架中，工作中所有的系统都使用同样的内存格式，交互时没有额外的开销，并数据交互都是标准的。
时间序列数据包括从事件、点击和传感器数据到日志、指标和跟踪的所有内容。从这些数据中提取的见解的数量和多样性十分的丰富。时间序列数据让你对随时间变化的事情有细致入微的了解，并为实时分析、预测分析、物联网监控、应用程序监控和 DevOps 监控开辟新途径，使时间序列成为数据驱动决策不可或缺的工具。能够使用 SQL 查询数据，为具有 RDBMS 经验的开发人员消除了进入和采用的重大障碍。支持 SQL 的时间序列数据库通过提供熟悉的工具来充分利用时间序列数据，有助于缩小事务和分析工作负载之间的差距。
