...

InfluxDB是当前世界排名第一的时序数据库，具有繁荣的生态系统，目前很多用户使用它来作为自己的第一选择。但是，实际上线后，会有高可用，高扩展的需求。如果换成别的数据库，会有比较高的迁移成本。

2.目标

开发一套Java版本的适配器可以使IoTDB兼容InfluxDB协议，完善IoTDB的功能。

1. IoTDB-InfluxDB：支持InfluxDB写入；支持InfluxDB部分查询；支持完整的InfluxDB查询。
2. 对正确性和性能的测试，不仅要适配InfluxDB，也要知道在繁重的负载下是否可以很好的工作，例如：以非常高的频率生成数据
1. 正确性测试：通过适配器以influxdb的协议插入数据，然后查询IoTDB数据库，将我们认为发送的内容与我们希望存储的内容进行比较。进行正确性测试
2. 性能测试：以多线程的方式或者以Fiber多协程方式并发写入和读取，进行性能测试，类似的 demo：https://github.com/Tencent/TencentKona-8/tree/KonaFiber/demo/fiber/iotdb-sync-stress-demo

...

1. 为了存储的方便，第二种情况的存储，没有把tag的value存入路径中，即直接把tag的key存入路径中。其表现为

前面累积的path都是相同的，这样最后会导致的结果是：会加快根据path过滤的查找，如：

```sql
select * from root.teststress.test2.*.*.*.*.SL.*.*.*.*.*
```

这时只有一条路径，所有速度会变快，即第二种查找的时间会比实际的快一些

5.4测试结果

第二种查找的时间平均可以达到1000多ms，第二种查找的时间在300ms附近第一种查找的时间平均可以达到1000多ms，第二种查找的时间在300ms附近

同时如果第二种查找的时候，在较靠前的路径使用*，(select * from root.teststress.test2.* where A=1 and B=1 )会导致需要查找的path过多，报错信息如下

​```log
Too many paths in one query! Currently allowed max deduplicated path number is 715, this query contains 1000 deduplicated path. Please use slimit to choose what you real want or adjust max_deduplicated_path_num in iotdb-engine.properties.
​```

综上所述，建议采取**第一种**方案（把tag放在path中存储）(同时需要解决上述提到的问题:Too many paths in one query)。

...