tsdb 时空时序数据库 中的 几个关键词
metric: metric 类似 关系型数据库 的一张 表名。
fields 就是 其中 的字段 类似于 column 字段。
tags ： 是 能作为查询tsdb 的字段。 设置成tags 的 是固定不变化的，维度查询的字段。至于 说 为什么tags 这样设定。 下边引出一个 时间线的概念。
tsdb 的中时间线的概念
从图中可以看出，tsdb 的 时间线 是由 mertic + tags 组合来确定来确定的。
mertic 这 从你写入数据 你会起一名称 ，这个是唯一的。
tags 是 查询维度字段， 像 ip ，ecs_id ,用户 id 等固定的字段的字段。 为什么选这些字段作为tags . tsdb 有时间线的概念，时间线在tsdb 中不能太多，因为在数据量很大的时候，数据量太大，时间线太多 ，tsdb会承载不住，查询也会报错。 即是 性能问题。
时间线= metric * tags *（每个tags 有多少的情况） 的笛卡尔积
这样会得到时间线的总和。
时间线的汇聚 ：
详情
tsdb 查询聚合逻辑 采坑
数据清洗出来的粒度是 1分钟的，想看一小时维度的数据，这就用到 tsdb 的降采样。
降采样 ：https://help.aliyun.com/document_detail/107573.html?spm=5176.11065259.1996646101.searchclickresult.41a93ca4ol6OLy#h2–downsample-5
sum 和 zimsum 的区别
这里指出的一个问题是， 聚合一小时 用 zimsum ，不要用 sum。sum 是线性插值，zimsum 是 给这时间线汇聚的时候 补0.
一般情况下，都是OK的。但是 在数据源扩容对的时候，数据源的数据来源改变了。 原先的时间线 会发生改变。所以，这种情况下，要用 zimsum 去计算。 不然会出现数据在同一时刻 不同时间范围去看 ，值不一样的情况。
TSDB 查询 计算数据 采坑总结
问题描述 ： 对一分钟数据 计算 当月的总流量（因为是 bps 美妙的速率，要乘以60转换 成流量） ，计算用户当月每小时 累计流量（小时粒度的 要 乘以 3600）。 发现 累计流量 最后一个点 比 总流量的数值 大。
问题分析：
对一分钟数据直接查询，然后 求和 算出 总流量。 查询累计流量的时候 是 先对 tx_bps 做 1小时 求平均 {"field":"tx_bps","aggregator":"none","downsample":"1m-avg"}
tsdb 查询 每小时 聚合逻辑 ，由于数据不是 连续的，累加求和 会导致 数据 会偏大 。
问题分析 ： 处理过的数据 因为 存在 不是没分钟都有数据，也就是 数据不是连续的，不是 每分钟一个点。 如果 用降采样 {“field”:“tx_bps”,“aggregator”:“none”,“downsample”:“1m-avg”}这样的查询 的出的值 乘以 3600 （也就是 tx_bps*60*60）会导致 偏大。 正确的处理是 先把一个小时的点{“field”:“tx_bps”,“aggregator”:“avg”,“downsample”:“1m-zimsum”}`
求 和 也就是 算出 每小时 有多少bps (思路累加) 。
(tx_bps+一小时累加) * 60
这样 算出的是 bps 总的速率， 然后 在乘以 60 算出每小时流量。
处理原理 仔细分析， 处理 是 一小时 先做 聚合 算出 一小时的点之和，然后 根据点数之和 乘以 60 就可以 得出 总的 这样计算 符合 逻辑。 认真分析。
TSDB 的具体原理和亮点
TSDB 架构图
计算引擎层，分布式SQL引擎，时空引擎以及面向IoT市场的边缘计算版本，极大的提高了TSDB的计算能力和场景。下图就是TSDB的主要架构图，接下来的篇章我会分时序引擎，计算引擎，SQL引擎，时空引擎，边缘计算这5大部分来详细的介绍我们的核心技术能力。
1. 复杂时间线索引、无限制时间线支持
2. 高效列式内存缓存、时间线内存分片
参考：
tsdb 时空时序数据库核心解析
tsdb 的特点
TSDB 提供时序数据的高效读写。对于百万数据点的读取，响应时间小于 5 秒，且最高可以支撑每秒千万数据点的写入。
支持通过 HTTP 协议 和 TSDB Java Client 两种方式进行数据写入。
TSDB 支持通过 HTTP 协议、TSDB Java Client 以及 TSDB 控制台三种方式进行数据的查询操作。也可以通过 TSDB 控制台的数据查询功能进行数据分组、降采样、空间聚合的可视化数据查询展现。