InfluxDB 的UTC时间问题与简单的持续查询语句

时间:2023-03-08 20:59:18

原文:https://blog.****.net/Vblegend_2013/article/details/80904275

最近项目中使用了时序数据库InfluxDB 各方性能也是蛮强大的。但是唯一不足的地方时间格式,默认是使用的UTC时间也是固定的不能修改的,研究了下找到解决方案。

        public static void Write()
{
String[] Tags = new string[] { "Element_1", "Element_2", "Element_3", "Element_4", "Element_5" };
List<Point> Points = new List<Point>();
foreach (var item in Tags)
{
Point point = CreatePoint(item);
Points.Add(point);
}
var r = InfluxDB.WriteAsync(DBName, Points.ToArray()).Result; }
public static Random r = new Random(); public static Point CreatePoint(String name)
{
Dictionary<string, object> fields = new Dictionary<string, object>();
Dictionary<string, object> tags = new Dictionary<string, object>(); tags.Add("Name", name);
fields.Add("Value", r.Next(, ));
Point point = new Point()
{
Fields = fields,
Measurement = "base",
Tags = tags,
Timestamp = DateTime.UtcNow.AddHours(),
};
return point;
}

很简单 写入数据时 UTC时间加上8小时就OK

看下 持续查询代码

按小时查询

CREATE CONTINUOUS QUERY Group_Hour_Query ON TestDB RESAMPLE EVERY 1h FOR 1h BEGIN SELECT mean(Value) AS Avg, max(Value) AS Max, min(Value) AS Min, spread(Value) AS Spread, sum(Value) AS Sum, count(Value) AS Count, difference(max(Value)) AS Difference, stddev(Value) AS Stddev INTO TestDB.autogen.Group_Hour FROM TestDB.autogen.base GROUP BY "Name", time(1h) fill() END

按天查询

CREATE CONTINUOUS QUERY Group_Day_Query ON TestDB RESAMPLE EVERY 1d FOR 1d BEGIN SELECT mean(Value) AS Avg, max(Value) AS Max, min(Value) AS Min, spread(Value) AS Spread, sum(Value) AS Sum, count(Value) AS Count, difference(max(Value)) AS Difference, stddev(Value) AS Stddev INTO TestDB.autogen.Group_Day FROM TestDB.autogen.base GROUP BY "Name", time(1d) fill() END

以上两个持续查询脚本会将base表中数据按每小时、每天 以Name聚合 写入到新的表中去

每天聚合的表  我们看下 2018-07-01 00:00:00 这一天的 Element_1 的数据

每小时聚合的表  我们看下 2018-07-01 13:00:00 这一小时的 Element_1 的数据

然后我们自己写查询语句 查询这一小时的平均值 跟持续查询的结果是相同的

然后我们写查询07-01一天的平均值 跟持续查询的结果也是相同的

因为之前写入时我们是UTC+8小时的 ,最后我们确认下 数据库中的数据是否是最新的。

查询下最后一条语句,  因为是每隔10分钟写入一次。。 所以貌似没毛病。

经过我的简单测试 数据库在写入2000W条数据后并没有明显的降速(写入),且查询速度依然很理想化。