网站收录查询爱站,大连市建设工程集团有限公司,建网站费用记技术服务费,青岛网站运营本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
本作品 (李兆龙 博文, 由 李兆龙 创作)#xff0c;由 李兆龙 确认#xff0c;转载请注明版权。 文章目录 引言问题定义新技术数据模型schemalessTsfile设计双MemTable高级可扩展查询其他 IotD…本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
本作品 (李兆龙 博文, 由 李兆龙 创作)由 李兆龙 确认转载请注明版权。 文章目录 引言问题定义新技术数据模型schemalessTsfile设计双MemTable高级可扩展查询其他 IotDB劣势influxDB 1.x 劣势结束语 引言
在时序数据库这样一个小众的圈子里面每年有意思的东西并不多每一篇顶会paper都值得细细品读。其次靠自己想很多问题很难解决还是需要向业界优秀的团队虚心学习才能清除和增加自己产品的核心竞争力。
问题定义
如下图是《Apache IoTDB: A Time Series Database for IoT Applications》中提出的一个典型场景
边缘设备时序数据的产生点边缘服务器中需要一个用于写入存储和查询的数据库云端的计算集群用于OLAP分析
文章开篇指出了IotDB聚焦的问题即
不断变化的模式即对于SchemaLess的支持传感器经常被替换移除新增周期性的数据采集强相关的series利用23可以增加压缩的可能性多样化延迟数据的写入高并发的数据写入
其次在优雅的解决这些问题能保证查询上做到
一天之内10万数据点的selection在100ms三年之内1000万数据点的aggregation在100ms
新技术
数据模型
InfluxDB中measurementtagsfields的数据模型基本已经成为现实标准但是IotDB认为这样的模型对于设备和传感器进行管理难以优化物理存储遂使用树形管理所有的时间序列。 iotDB使用SensorDevice管理所有的时间序列
物理模式如下
Time Series每一条根节点到叶子结点是一个时间序列Series Family一个设备的时间序列存储在一个tsfile中一个tsfile中可以存储多个设备的时间序列每一个 Series Family有一个独立的存储引擎所有的tsfile存储在一个目录中
这样的优势我理解是可以控制哪些设备处于一个Series Family中进而利用周期性和强相关的数据执行更有效的数据压缩。
schemaless
[12]中描述了iotdb的方案后续有时间看下influxdb的方案就很简单不知道有什么区别。
Tsfile设计 page基本存储单位一个page属于一个时间序列其中存储两列即时间和filedchunk由metadata多个page组成所有page都属于一个时间序列chunk group由metadata多个chunk组成所有的chunk属于一个或多个时间序列。多个chunk放在一起的原因文章中提到是一个设备所属的多个传感器一般被同时访问index很巧妙的组织形式可以很快的索引某个时间序列的所有chunk信息并且携带时间序列的统计信息比如countbeginend等用于查询优化
本质上和TSM存储格式差不多但是因为TSM是KV模型依赖于TSI获取完整的seriesID在这之中还需要在series file中获取时机的serieskey这就很慢了。这也是现代时序数据库均使用Parquettsfile这样存储模型的原因不仅导入导出方便摆脱了倒排索引的依赖。
双MemTable
本质要解决的问题就是乱序数据会使得tsfile的时间区间存在重复但是这只适用于乱序数据较少的情况此时会有益于查询和写放大否则会退化为普通版本还增加了维护的开销。在iotdb遇到的场景下长延时只有0.0375%但是在我们当前的场景中乱序数据是常态其次influxdb内数据的写入其实是在TSM每个memtable中包含的是kv数据就算乱序到达也只不过是查询时需要在level0中的多扫几个块罢了 [10]中提到了可以通过数据的到达情况自动判断是否分裂这对于iodDB来说确实是一种很好的思路。
高级可扩展查询
这几乎是领域龙头做的最好的一个方向了因为这里非常偏学术无论是DolphinDB还是IotDB对于各类特殊场景的算子支持都强于公有云厂商。
模式匹配算子PATTERN[2]异常检测函数[3]数据估算函数用于填补空缺值[4][5]用户自定义函数UDF用于特定领域个性化计算的需求在查询引擎中算子的处理都是迭代器化的这个其实我们也可以加但是现阶段来看需求并不强烈没必要透漏给用户这个接口。
其他
高效的数据传输可以在边缘设备边缘服务器和云端之间导入不需要昂贵的ETL。这其实不是IotDB独有的优势本质上只要存储层是独立可解释的文件就有这个优势单很可惜inlfuxDB1.x不是这也是InfluxData推动InfluxDBiox的关键动机之一。高效的压缩能力这其实是核心要解决的问题中周期性以及强相关数据的具体优化方式在[6]中阐述了各种数据类型压缩的方式iotdb也研究出了一些巧妙的压缩方式[7][8][9]也证明了一般时序数据库中默认比如influxdb的Timestamp: Delta → Scaling → (RLE/Simple8b); FloatXORIntegerZigZag → (Simple8b/RLE/Uncompress);BooleanBit-packing并不是最优的解决方案。但是这并不是IotDB独有的方案理论上只需要一个实习生任意一个系统都可以具备这样的优势。其次存储目前从经验来看并不是运营中最大的问题工程不是学术在压缩率已经达到要求的情况下没有必要过度优化。
IotDB劣势
分布式系统设计历史气息浓厚这带来的直接差异我能想到的有元数据管理节点存在单点集群规模TB级别不适用于公有云只适合于私有云这也导致了价钱不会太便宜聚焦于Iot场景可以说把无损压缩做到了极致但是现在SSD并不贵以我们的运营经验来看存储不是瓶颈。优势带来的劣势时时间线较多的场景无法处理因为tsfile中的树形索引基本失效每一个series都是一个根节点。java编写我猜测和influxdb1.x一样存在full gc的问题基本无法解决TSQL能力弱于influxql和SQL
influxDB 1.x 劣势
不支持SQL基数无法无限扩展国内目前TDengine以外其他大厂的时序数据库仔细看都存在时间线限制存算不分离开源没有集群版导致隔离很难做[13]基本上是无解的也有办法不过实施比较复杂所以只能在运营角度规避这个问题go实现且实现的不严谨导致内存问题很严重显然Rust/cpp才是最好的引擎语言应该允许在没有本地存储的情况下运行但是内部实现大量使用mmap建议大家都看看[14]索引数据分离导致导入导出极为困难Highly indexed导致写操作较为繁琐且昂贵可能需要更新两个索引和一个数据查询多时间线时极为昂贵tsi中需要消耗大量的时间因为需要对所有的查询条件的结果集做并集并在seriesfile中查询series key[15]也提到拆分索引是没有用的查询的时间线客观存在拆分索引还会造成内存问题因为维护索引信息也需要不少内存时间线较多时索引信息大于数据但是时序的场景导致很多索引自始至终是无法被使用的
结束语
跟着老大InfluxDB IOX走基本上没有错其他的路都是徒劳。
参考
Announcing InfluxDB IOx - The Future Core of InfluxDB Built with Rust and ArrowKv-match: A subsequence matching approach supporting normalization and time warping icde2019Time series data cleaning: From anomaly detection to anomaly repairing vldb2017Sequential data cleaning: A statistical approach sigmod2016SCREEN: stream data cleaning under speed constraints sigmod2015Time series data encoding for efficient storage: A comparative analysis in apache iotdb vldb2022On aligning tuples for regression KDD22Grouping time series for efficient columnar storage sigmod2023Frequency domain data encoding in apache iotdb vldb2022Separation or not: On handing out-of-order time-series data in leveled lsm-tree icde2022Non-blocking raft for high throughput iot data icde2023Swapping repair for misplaced attribute values icde2020从一到无穷大 #7 Database-as-a-Service租户隔离挑战与解决措施Are You Sure You Want to Use MMAP in Your Database Management System?The Design of InfluxDB IOx: In-Memory Columnar Database Written in Rust with Apache Arrow (Paul Dix)