InfluxDB记录丢失的真相竟然是

标题党一回😄

过程现象

折腾了近一周InfluxDB,从MySql导数据2亿多条， 期间为了导库效率，又折腾了一个多线程分段导库

就在一切就绪，正式从监控服转发实时数据 写到InfluxDB后

准备写个Rest接口 供前端查询终端曲线

突然发现 InfluxDB里面少记录

之前导大量数据测试时候也发现select count(*) Mysql和InfluxDB不一致问题，

当时以为InfluxDB 的Series概念导致的，给忽略了....

经过一顿断点调试，开启InfluxDB log level all

生成的BatchPoints没有问题 log中的batchPoints也没有问题

去翻官方的issue, 翻文档

翻stackoverflow 突然醒悟了

Finally, a point is the field set in the same series with the same timestamp

docs.influxdata.com/influxdb/v1… A point is uniquely identified by the measurement name, tag set, and timestamp

docs.influxdata.com/influxdb/v1…

原本设计的point结构是这样的

time	tag:terminalNo	field:sensorNo
2019-07-11 08:08:48.099	LZSGAJ0066	E11
2019-07-11 08:08:48.099	LZSGAJ0066	E12
2019-07-11 08:08:48.099	LZSGAJ0066	E13

然后开心的向InfluxDB写入：

private BatchPoints createBatchPoints(String dbName, String measurement, List<SensorBean> sensors) {
		BatchPoints batchPoints = BatchPoints.database(dbName).retentionPolicy(RP_NAME).build();
		for (int i = 0; i < sensors.size(); i++) {
			SensorBean sensor = sensors.get(i);
			Point point = Point.measurement(measurement)
					.time(System.currentTimeMillis(), TimeUnit.MILLISECONDS)
					.tag("terminalNo", sensor.getTerminalNo())
					.addField("sensorNo", sensor.getSensorNo())
					.addField("dataValue", sensor.getDataValue())
					.addField("alarmLevel", sensor.getAlarmLevel())
					.build();
			batchPoints.point(point);
		}
		return batchPoints;
	}

看似毫无问题啊

结果 一个batch 8个point，结果只写入了最后一条，前7个都会被覆盖，why?

这里就需要了解 InfluxDB的重要概念：Series

docs.influxdata.com/influxdb/v1…

a series is the collection of data that share a retention policy, measurement, and tag set

retention policy, measurement, and tag set三者组合在一起构成一个唯一的series

原因

回过来看咱们自己写入库的结构

tag set 是 time 和 terminalNo

但是一个batch 写入的8个point 具有一样的time 和terminalNo 所以 InfluxDB认为他们是同一条记录，或者说认定是同一个point，所以会覆盖!!!!

Finally, a point is the field set in the same series with the same timestamp

解决方法

schema修改，把sensorNo加入tag

time	tag:terminalNo	tag:sensorNo	dataValue
2019-07-11 08:08:48.099	LZSGAJ0066	E11	12
2019-07-11 08:08:48.099	LZSGAJ0066	E12	31
2019-07-11 08:08:48.099	LZSGAJ0066	E13	34

同时 写入库时 time 毫秒递进

教训

对于新技术过于兴奋 忽视了对整个流程的验证

导了几亿数据，忘了验证字段完整