通用数据库
事务 MVCC ACID
Facebook 的 Gorilla  甚至提出不需要保证 Duration

乱序数据

写入延迟 吞吐量 查询性能 实时性  集群方案的运维成本

时序数据量大 价值偏低 压缩
列存   根据不同的类型使用高效的压缩算法
写入性能与压缩比 

设备 传感器  采样 
数据分区分片  实时构建索引

存储引擎 B-Tree  LSM-Tree

LSM Tree 上 建 B-Tree Index 
HBase 在 region 上 有 B-Tree Index
B-Tree  先写 WAL 和 内存 Cache 

InfluxDB  各种存储引擎尝试 LevelDB RocksDB BoltDB 等 
BoltDB 中 mmap+BTree 模型中随机 IO 导致的吞吐量低
RocksDB 纯 LSM Tree 存储引擎无法 优雅快速地按时间分区删除
多个 LevelDB + 划分时间分区的方法又会产生大量句柄

InfluxDB  自研存储引擎 TSM

TDengine  存储引擎
LSM Tree   WAL  内存skip list 等
去掉 LSM Tree 的层级结构 
按时间段分区、按表分块的 log 块


按表分块的设计和 OpenTSDB 的行聚合有些相似
OpenTSDB 行聚合把相同 tag 以一小时为时间范围，将这些数据都放到一行中存储，减少了聚合查询要扫描的数据量

TDengine 多列模型，而 OpenTSDB 单列模型
单列模型下是多行的聚合，多列模型下聚合会自然形成数据块

BRIN 索引  Block Range Index
块的起止时间 
.head 文件就是 key，而 .data 和 .last 文件就是 value
时序场景下，有了 BRIN 索引，可以不需要 bloom filter

tag数据 和 时序数据 分离
减少 tag数据 空间占用
TDengine 中表的数目和设备数目相同，上亿设备就是上亿张表
大量的元数据  元数据 分片存储

数据与元数据进行分片、多副本操作时，涉及一致性与可用性的问题
时序数据 通常采用最终一致  
最终一致算法 延迟低 吞吐量高 可用性比强一致算法好

InfluxDB 集群版 采用 Dynamo 这种无主风格的数据同步

元数据需要强一致，通常用 Raft Paxos 这类算法