文档章节

浅谈时序数据库TDengine

乒乓狂魔
 乒乓狂魔
发布于 2019/07/26 08:23
字数 1667
阅读 2.4W
收藏 2

「深度学习福利」大神带你进阶工程师,立即查看>>>

浅谈时序数据库TDengine

最近TDengine很火,本人也一直很早就有关注,其官方给出的测试性能结果很喜人,所以一开源,本人就进行了相关调研,最终发现还是存在着一定的问题,期待后续的完善吧

写入问题

必须为每个Tag组合起一个表名

付出的代价:

  • 用户必须要保证每个Tag组合起的表名唯一,并且一旦Tag组合数过多用户很难记住每个Tag组合对应的表名,在查询时基本都是靠超级表STable来查询。所以对用户来说这个表名几乎没用到却让用户来花代价来起名

这样设计的最终目的是为了将相同Tag组合的数据放到一起,但是系统设计时完全可以自己内部针对这个Tag组合记录一个唯一id或者唯一字符串来作为内部隐藏的表名,来替换让用户自己起表名的操作,对用户只需要呈现一个超级表STable即可,减轻用户负担。

其实可以看到上述其实是将系统内部判断唯一的负担转交给用户,麻烦了用户。假如系统内部自动判断Tag组合是否唯一,则在数据写入过程中一直需要判断当前Tag组合是否存在以及查找对应的底层唯一id或者唯一字符串,而让用户起表名则省去了上述代价,因为用户起的表名就是一个唯一的字符串,所以写入性能自然好一些

Tag支撑与管理

  • 最多支持6个Tag,如果想要支持更多就要重新源码编译
  • 超级表STable对Tag组合的索引是全内存的,终将会遇到瓶颈的,InfluxDB已经走过这条路了,从之前的全内存到后面的tsi
  • 超级表STable对Tag组合的索引仅仅是对第一个Tag作为key来构建一个skiplist,也就是说当你的查询用到第一个tag时可以利用下上述索引,当你的查询没用到第一个tag时,那就是暴力全扫,所以这种在Tag组合数过多的时候过滤查询能力还是很有限的。而像其他时序数据库InfluxDB、Druid都在写入过程中针对Tag组合构建了倒排索引来应对任意维度的过滤,写入性能比TDengine自然就会差一些
  • 对于不再使用的Tag组合的过期目前也是个麻烦的事情

不支持乱序写入

  • 每张表会记录该表目前写入的最大时间,一旦后续的写入时间小于该时间则不允许写入。假如你不小心向某张表写入2021-07-24 00:00:00时间的数据,那么该时间之前的数据都无法写入了

这样做带来的好处,简化了写入过程,写入过程永远是append操作。举个简单例子,比如用数组来存放内存数据,数组中的数据是按时间排序的,如果后来的数据的时间不是递增,那么就需要将数据插入到数组中间的某个位置,并且需要将该位置之后的数据全部后移。假如后来的数据的时间都是递增的,那么直接往数组的最后面放即可,所以不支持乱序写入即以牺牲用户使用为代价来简化写入过程提高写入性能

不支持乱序写入还省去的一个麻烦就是:LSM中常见的compact。如果允许乱序写入,那么就会存在2个文件中时间范围是有重叠的,那么就需要像RocksDB那样来进行compact来消灭重叠,进而减少查询时要查询的文件个数,所以你就会发现HBase、RocksDB、InfluxDB等等辛辛苦苦设计的compact在TDengine中基本不存在

总结一下就是:不支持乱序写入是以牺牲用户的使用为代价来提高写入性能以及简化设计

查询问题

求topN的group

  • order by只能对时间、以及tag进行排序。top或者bottom只能对某个field求topN

时序领域非常常见的topN的group,比如求CPU利用率最大的3台机器,目前也无法满足

downsampling和aggregation

  • downsampling:将同一根时间线上1s粒度的数据聚合成10s粒度的数据
  • aggregation:将同一时刻多根时间线聚合成1根时间线

比如每个appId有多台机器,每台机器每秒都会记录该机器的连接数,目前想画出每个appId的总连接数的曲线

假如使用标准SQL则可能表示如下:

select sum(avg_host_conn),appid,new_time from (
		select avg(connection) as avg_host_conn,
				appid,host,time/10 as new_time 
		from t1 group by appid,host,time/10
) as t2 group by appid, new_time

内部的子查询会先将每个appid的host 10s内的connection求平均值,即downsampling,外部的查询将每个appid下的host的上述平均值求和,即aggregation

由于这类需求在时序查询中太常见了,使用上述SQL书写非常麻烦,有些系统就通过函数嵌套的方式来简化这类查询的书写

目前TDengine的聚合函数要么只能是downsampling要么只能是aggregation,也不支持子查询,那么是无法满足上述需求的

查询聚合架构

查询分2阶段:第一阶段请求管理节点,获取符合tag过滤的所有表的meta信息(包含每个表在哪个数据节点上),假如满足条件的表有上百万个,这这个阶段的查询基本也吃不消,第二阶段向数据节点查询聚合每个表的数据,返回给客户端,客户端再做最终的聚合。

这种查询方案终究还是会面临客户端聚合瓶颈的,还是要上多机协调的分布式查询方案比如类似Presto、Impala等等

乒乓狂魔

乒乓狂魔

粉丝 1073
博文 111
码字总数 289957
作品 0
长宁
程序员
私信 提问
加载中
此博客有 1 条评论,请先登录后再查看。
数据库代码辅助工具--MaoCaiJun.Database

MaoCaiJun.DataBase 是一个用于 Microsoft Visual Studio 的数据库代码生成组件。它是基于 xml 文件的代码创建工具,支持sql2000,sql2005,sql2008,access, SQLite MaoCaiJun.Database 数据库...

mccj
2013/02/06
2.5K
1
数据库表单生成器--SQLScreens

SQLScreens 是一个使用 Tcl/TK 编写的简单关系型数据库表单生成工具。可让你快速创建查询界面,并指定相应的表和字段。支持多种数据库,包括:MySQL, SQLite, and INFORMIX, and ODBC for o...

匿名
2013/02/17
939
0
统一数据库访问接口--edbc

edbc 是 Emacs-Lisp Database Connectivity 的缩 写 ,是从 Emacs-CGI 项目中独立出来的一个子项目,为 Emacs Lisp 访问数据库提供简洁、统一的接口! 在其他语言(比如Java)中访问数据库,...

redraiment
2012/12/26
1.6K
0
高性能NoSQL数据库--SSDB

SSDB 是一个 C/C++ 语言开发的高性能 NoSQL 数据库, 支持 zset(sorted set), map(hash), kv, list 等数据结构, 用来替代或者与 Redis 配合存储十亿级别列表的数据. SSDB 在 QIHU 360 被大量使...

ideawu
2013/01/08
2.6W
4
移动数据库--NyaruDB

NyaruDB 是 Objective-C 撰写的移动数据库。NyaruDB 属于 key 对 document 的 NoSQL 数据库,可以使用某个栏位搜寻或排序数据。 效能上 NyaruDB 比 sqlite 快非常多,而且不需要将对象转成 ...

kelp
2013/05/08
871
0

没有更多内容

加载失败,请刷新页面

加载更多

Hacker News 简讯 2020-08-15

最后更新时间: 2020-08-15 06:01 Welders set off Beirut blast while securing explosives - (maritime-executive.com) 焊工在固定炸药的同时引爆了贝鲁特爆炸 得分:347 | 评论:302 Factor......

FalconChen
今天
24
0
OSChina 周六乱弹 —— 老椅小猫秋乡梦 梦里石台堆小鱼

Osc乱弹歌单(2020)请戳(这里) 【今日歌曲】 @小小编辑 :《MOM》- 蜡笔小心 《MOM》- 蜡笔小心 手机党少年们想听歌,请使劲儿戳(这里) @狄工 :腾讯又在裁员了,35岁以上清退,抖音看到...

小小编辑
今天
89
1
构建高性能队列,你不得不知道的底层知识!

前言 本文收录于专辑:http://dwz.win/HjK,点击解锁更多数据结构与算法的知识。 你好,我是彤哥。 上一节,我们一起学习了如何将递归改写为非递归,其中,用到的数据结构主要是栈。 栈和队列...

彤哥读源码
今天
17
0
Anaconda下安装keras和tensorflow

Anaconda下安装keras和tensorflow 一、下载并安装Anaconda: Anaconda下载 安装步骤: 如果是多用户操作系统选择All Users,单用户选择Just Me 选择合适的安装路径 然后勾选这个,自动配置环境...

Atlantis-Brook
今天
15
0
滴滴ElasticSearch千万级TPS写入性能翻倍技术剖析

桔妹导读:滴滴ElasticSearch平台承接了公司内部所有使用ElasticSearch的业务,包括核心搜索、RDS从库、日志检索、安全数据分析、指标数据分析等等。平台规模达到了3000+节点,5PB 的数据存储...

滴滴技术
今天
13
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部