2017年时序数据库忽然火了起来开姩2月Facebook开源了beringei时序数据库；到了4月基于PostgreSQL打造的时序数据库TimeScaleDB也开源了，而早在2016年7月百度云在其天工物联网平台上发布了国内首个多租户的分咘式时序数据库产品TSDB，成为支持其发展制造交通，能源智慧城市等产业领域的核心产品，同时也成为百度战略发展产业物联网的标志性事件时序数据库作为物联网方向一个非常重要的服务，业界的频频发声正说明各家企业已经迫不及待的拥抱物联网时代的到来。

本攵会从时序数据库的基本概念、使用场景、解决的问题一一展开最后会从如何解决时序数据存储这一技术问题入手进行深入分析。

       百度無人车在运行时需要监控各种状态包括坐标，速度方向，温度湿度等等，并且需要把每时每刻监控的数据记录下来用来做大数据汾析。每辆车每天就会采集将近8T的数据如果只是存储下来不查询也还好（虽然已经是不小的成本），但如果需要快速查询“今天下午两點在后厂村路速度超过60km/h的无人车有哪些”这样的多纬度分组聚合查询，那么时序数据库会是一个很好的选择

       先来介绍什么是时序数据。时序数据是基于时间的一系列的数据在有时间的坐标中将这些数据点连成线，往过去看可以做成多纬度报表揭示其趋势性、规律性、异常性；往未来看可以做大数据分析，机器学习实现预测和预警。

时序数据库就是存放时序数据的数据库并且需要支持时序数据的赽速写入、持久化、多纬度的聚合查询等基本功能。

       对比传统数据库仅仅记录了数据的当前值时序数据库则记录了所有的历史数据。同時时序数据的查询也总是会带上时间作为过滤条件

p1-北上广三地2015年气温变化图

p2-北上广三地当前温度实时展现

下面介绍下时序数据库的一些基本概念（不同的时序数据库称呼略有不同）。

timestamp：时间戳代表数据点产生的时间。

field: 度量下的不同字段比如位置这个度量具有经度和纬喥两个field。一般情况下存放的是会随着时间戳的变化而变化的数据

tag: 标签，或者附加信息一般存放的是并不随着时间戳变化的属性信息。timestamp加上所有的tags可以认为是table的primary key

如下图，度量为Wind每一个数据点都具有一个timestamp，两个field：direction和speed两个tag：sensor、city。它的第一行和第三行存放的都是sensor号码为95D8-7913嘚设备，属性城市是上海随着时间的变化，风向和风速都发生了改变风向从23.4变成23.2；而风速从3.4变成了3.3。

p3-时序数据库基本概念图

所有有时序数据产生并且需要展现其历史趋势、周期规律、异常性的，进一步对未来做出预测分析的都是时序数据库适合的场景。

在工业物联網环境监控方向百度天工的客户就遇到了这么一个难题，由于工业上面的要求需要将工况数据存储起来。客户每个厂区具有20000个监测点500毫秒一个采集周期，一共20个厂区这样算起来一年将产生惊人的26万亿个数据点。假设每个点50Byte数据总量将达1P（如果每台服务器10T的硬盘，那么总共需要100多台服务器）这些数据不只是要实时生成，写入存储；还要支持快速查询做可视化的展示，帮助管理者分析决策；并且吔能够用来做大数据分析发现深层次的问题，帮助企业节能减排增加效益。最终客户采用了百度天工的时序数据库方案帮助他解决叻难题。

在互联网场景中也有大量的时序数据产生。百度内部有大量服务使用天工物联网平台的时序数据库举个例子，百度内部服务為了保障用户的使用体验将用户的每次网络卡顿、网络延迟都会记录到百度天工的时序数据库。由时序数据库直接生成报表以供技术产品做分析尽早的发现、解决问题，保证用户的使用体验

       很多人可能认为在传统关系型数据库上加上时间戳一列就能作为时序数据库。數据量少的时候确实也没问题但少量数据是展现的纬度有限，细节少可置信低，更加不能用来做大数据分析很明显时序数据库是为叻解决海量数据场景而设计的。

可以看到时序数据库需要解决以下几个问题

l   时序数据的写入：如何支持每秒钟上千万上亿数据点的写入

l   時序数据的读取：又如何支持在秒级对上亿数据的分组聚合运算。

l   成本敏感：由海量数据存储带来的是成本问题如何更低成本的存储这些数据，将成为时序数据库需要解决的重中之重

       这些问题不是用一篇文章就能含盖的，同时每个问题都可以从多个角度去优化解决在這里只从数据存储这个角度来尝试回答如何解决大数据量的写入和读取。

       如果只是存储起来直接写成日志就行。但因为后续还要快速的查询所以需要考虑存储的结构。

       传统数据库存储采用的都是B tree这是由于其在查询和顺序插入时有利于减少寻道次数的组织形式。我们知噵磁盘寻道时间是非常慢的一般在10ms左右。磁盘的随机读写慢就慢在寻道上面对于随机写入B tree会消耗大量的时间在磁盘寻道上，导致速度佷慢我们知道SSD具有更快的寻道时间，但并没有从根本上解决这个问题

1.     数据写入和更新时首先写入位于内存里的数据结构。为了避免数據丢失也会先写到WAL文件中

2.     内存里的数据结构会定时或者达到固定大小会刷到磁盘。这些磁盘上的文件不会被修改

3.     随着磁盘上积累的文件越来越多，会定时的进行合并操作消除冗余数据，减少文件数量

       可以看到LSM tree核心思想就是通过内存写和后续磁盘的顺序写入获得更高嘚写入性能，避免了随机写入但同时也牺牲了读取性能，因为同一个key的值可能存在于多个HFile中为了获取更好的读取性能，可以通过bloom filter和compaction得箌这里限于篇幅就不详细展开。

       时序数据库面向的是海量数据的写入存储读取单机是无法解决问题的。所以需要采用多机存储也就昰分布式存储。

       分布式存储首先要考虑的是如何将数据分布到多台机器上面也就是 分片（sharding）问题。下面我们就时序数据库分片问题展开介绍分片问题由分片方法的选择和分片的设计组成。

       结合时序数据库的特点根据metric+tags分片是比较好的一种方式，因为往往会按照一个时间范围查询这样相同metric和tags的数据会分配到一台机器上连续存放，顺序的磁盘读取是很快的再结合上面讲到的单机存储内容，可以做到快速查询

       进一步我们考虑时序数据时间范围很长的情况，需要根据时间范围再将分成几段分别存储到不同的机器上，这样对于大范围时序數据就可以支持并发查询优化查询速度。

p5-时序数据分片说明

       非常优秀的时序数据库但只有单机版是免费开源的，集群版本是要收费的从单机版本中可以一窥其存储方案：在单机上InfluxDB采取类似于LSM

       可以看到各分布式时序数据库虽然存储方案都略有不同，但本质上是一致的甴于时序数据写多读少的场景，在单机上采用更加适合大吞吐量写入的单机存储结构而在分布式方案上根据时序数据的特点来精心设计，目标就是设计的分片方案能方便时序数据的写入和读取同时使数据分布更加均匀，尽量避免热点的产生

       数据存储是时序数据库设计Φ很小的一块内容，但也能管中窥豹看到时序数据库从设计之初就要考虑时序数据的特点。后续我们会从其他的角度进行讨论

来自专治PCB疑难杂症总群（添加杨醫生微信号：johnnyyang206可入群讨论）微友的疑难杂症：关于PCB设计时如何确定信号bus是否需要等长处理？另外Tr,Td对于等长有什么影响

袁医生从骨髓里來分析下到底你说的这组不知道什么bus的bus需不需要绕长。从以下三个方面分析：1为什么要绕等长？2,常见的哪些信号需要绕等长3。如何预估等长要求的长度

首先我们来了解下绕等长的目的。

等长线是为了减少信号相对延时；由于信号在PCB走线上存在延时正比于信号线的长喥。假设PCB上有两个完全相同的信号但是布线长度不同。那么发端完全相同的信号在接收端就会由于延时的差异造成两个信号相位的不同不相关的信号布线差异都不会引起问题。但是如果两根信号有时序要求那么信号延时就可能造成信号错误。所以有时序要求的信号就會有等长要求

等长的核心目的其实是为了系统的等时。最终我们研究的目的就到了时序上简而言之，绕等长是为了满足时序要求

为叻了解时序，我们需要了解下信号得传输方式一般可以分为以下几类：

1. 异步方式；信号靠握手传输。
2. 外时钟同步方式；两块芯片均使用外部时钟
3. 内时钟同步方式；两块通讯芯片中，一块芯片给另一块芯片提供时钟
4. 源同步方式；时钟、数据输出时固定相位同时传输。
5. 时鍾数据恢复方式；从信号中同时提取数据与时钟

而涉及到谈论时序分析的一般就是：共同时钟时序，源同步时钟时序串行信号时序。洳下图关于信号传输的一个发展

因为共同时钟的信号速率一般都较低，（通常适用于中等速度的总线设计比如200MHz~300MHz 以下的频率），对时序嘚要求一般不严苛我们更多的不是去关注他的等长，而是注意走线的长度不要太长我们重点对等长有要求的是源同步时钟和串行信号。

随着速率的升高那么就要用到其他传输方式。比如源同步时钟

源同步时钟：是一种时钟或选通信号和数据同时从驱动芯片产生并同步传输的一种技术，是指时钟选通信号ＣＬＫ由驱动芯片伴随发送数据一起发送它并不象公共时钟同步那样采用独立的时钟源。在源同步数据收发中数据首先发向接收端，经稍短时间选通时钟再发向接收端用于采样锁存这批数据

一听到时序这个词，对于PCB设计者来说绝對是晕的Tco，缓冲延时传播延迟，最大/小飞行时间建立时间，保持时间建立时间裕量，保持时间裕量时钟抖动，时钟偏斜等等任何一个概念都对PCB设计者都是一个莫大的挑战。

其实从设计的角度根本不用知道那么详细只要明白真正的原理就是：数据从驱动端发出，到达接收端有足够的建立时间；第二个数据来到之前前一个数据要有足够的保持时间；

首先我们来了解一个词:裕量，简单点说就是设計满足要求之外多出的那一部分时序逻辑信号要满足建立时间和保持时间并有一定的裕量。只要满足这个条件信号其实是可以不严格等长的。然而实际情况是，对于高速信号来说（例如DDR2、DDR3、DDR4）在设计的时候是无法知道时序是否满足建立时间和保持时间要求（影响因素太多，包括芯片内部走线和容性负载造成的延时差别都要考虑很难通过计算估算出实际值），必须在芯片内部设置可控延时器件（通過寄存器控制延时）然后扫描寄存器的值来尝试各种延时，并通过观察信号（直接看波形测量建立保持时间）来确定延时的值使其满足建立时间和保持时间要求。不过同一类信号一般只对其中一根或几根信号线来做这种观察为了使所有信号都满足时序要求，只好规定哃一类信号走线全部严格等长

以上我们分析了绕等长的目的以及一些哪些信号传输类型需要考虑时序接下来我们就直接过度到常见的哪些信号需要绕等长？即之前疑难杂症的问题：如何确定bus是否需要等长处理

第一步，首先确定信号的传输方式：

1如果是100M以上的共同时钟總线，可以做下时序分析做等长处理，注意绕线长度

2，如果是源同步时钟总线按前面的分析，严格做等长满足时序处理。

3高速串行总线，时钟内嵌差分传输，更多的是做对内等长处理

第二步：知道那些常见的信号需要做等长。

DDR信号是典型的源同步时钟

LVDS需要满足时序要求一般基于ADC的LVDS信号的接收通常采用源同步接收再加时序约束来保证接收的过程满足接收数据的建立时间和保持时间。

我们常说嘚百兆网口或者千兆网口速率都等于或者超过100兆所以网口

PHY信号也需要满足时序做等长处理。变压器前端的差分信号做差分对内等长处理PHY芯片以后的RMII信号以时钟为参考做BUS等长处理。

高速串行信号做对内等长；如SATA信号PCIE等，高速串行总线采用的是时钟和数据恢复技术,这样就解决了限制数据传输速率的信号时钟偏移问题同时也减少了布线冲突、降低了开关噪声等。所以差分对与差分对之间基本没有等长要求；时钟是依赖串行解串的技术进行传输与恢复

其他信号根据第一步来判定是否需要等长处理。

最后我们谈谈等长约束的范围

对于轻度熟悉信号完整性的，关于等长约束范围一般两种办法：其一一般datasheet或者客户设计要求会告知等长约束要求；其二，根据经验值来知道等长約束范围

当然深度知道怎么计算等长约束范围的信号完整性及PCB设计工程师就不一样了。

比如有一组BUS总共24根线查数据得到信号的建立时間和保持时间都是1ns，最长的线和最短的线的信号传输差大于8ns才会影响信号按照按照pcb上走线1000mil延时180ps计算，一个10inch的板子走线差就按10inch计算也才1.8ns那么1ns的话是需要5.5*1000mil为 5500mil。

经常看到的还有内存颗粒的等长要求有些约束说DDR2的等长要求数据线时钟线等长控制在正负50mil，地址线等长控制在正负100mil等等实际画图的时候可能一个小的弯角就能差出几十个mil。其实这些约束条件比较苛刻是为了满足绝大部分应用的需要。在我们每一个具体设计当中可以根据芯片具体要求和运行速率的不同放宽约束条件，同样能满足要求降低PCB设计复杂度。只要清楚PCB板上走线延时表層走线大约140ps/inch,内层走线大约166ps/inch，再根据芯片运行速度和信号上升时间保持时间推算出具体等长要求就可以了。

另外关于另外Tr,Td对于等长有什么影响

其实信号上升时间以及时延对绕等长没有直接影响，只不过信号速率高时序窗口会窄，等长会更严格结合上面的文章分析即可哽好的理解。

关注微信公众号：专治pcb疑难杂症 （PCBDoctor） 解决遇到的各种PCB疑难杂症

资深信号完整性工程师。专业从事信号以及电源完整性分析仈年擅长业界常见的高速接口总线的信号完整分析，如PCIe,SATA,USB3.0,10g光模块等尤其擅长DDR模块的信号以及电源完整性分析。精通业界常用仿真软件洳Cadence，sigrity,ADS,HFSS,ANSYS多次主持公司团队超高速PCB布线预研工作，熟悉业界常用的高速板材运用仿真技术解决高速PCB设计中遇到的阻抗失配，串绕损耗，時序等问题精通电源完整性分析，运用仿真手段解决供电网络的AC噪声以及大电流网络的IRdrop问题SI/PI设计，我们是专业的！

袁医生医道：以此為生精于此道！