在官网用户手册的系统工具(System Tools)一栏,有一个同步工具(Sync Tool),有很多人问这个东西怎么用,延迟是多少,今天就介绍一下这个工具的使用场景、基本原理和测试技巧。
正文 2439 字,预计阅读时间 7 分钟。
使用场景
某公司有多个电厂,每个电厂内部署了一个 IoTDB,负责监控电厂内多个设备的运行状态。各个电厂间数据不互通。这个时候公司想建一个云平台,汇总所有电厂的数据进行分析(这里有一个前提,云平台的数据分析主要针对长期历史数据,对数据的实时性要求不高)。这时候就可以用这个文件同步工具了。
文件同步工具的定位:将一个 IoTDB 的 Schema 和数据文件(TsFile)同步至另一个 IoTDB 中,同步过程会有一定延迟,具体延迟取决于负载和配置。
基本原理
通过名字应该能看出来,这个工具的同步粒度是数据文件,而不是每一个数据点。这也就导致同步的最长延迟是一个数据文件的生成耗时(从创建文件到封口)。因为发送端必须等一个文件生成好才会同步,否则传过去半个文件也没法解析。传文件类似 scp,相对同步每条数据的好处就是避免了数据的解析和重新导入。
我们把文件同步涉及到的两个 IoTDB 称为发送端、接收端。
写入流程
为了更好的理解数据文件的生成耗时,需要简单介绍一下写入流程。
IoTDB 采用了 LSM 结构,数据先写到内存缓冲区 memtable 中,memtable 达到一定大小会落盘,多个 memtable 会对应一个数据文件。
举个例子,某个存储组有 1 个时间序列,写入频率为 1 秒,每个数据点是 16 字节。一个 memtable 大小为 160 字节,TsFile 文件大小为 200 字节。存储组刚开始有一个空的 TsFile 可供写入。
(1)memtable 第一次存满 10 个数据点时,提交一个异步刷盘任务(追加到当前正在写入的 TsFile 中),同时检查 TsFile 大小,这个时候还是 0 字节,先不关文件。
(2)异步的刷盘任务开始执行,刷完之后 TsFile 变成了 200 字节。
(3)memtable 第二次存满 10 个数据点时,提交一个异步刷盘任务,同时检查 TsFile 大小,发现到了 200 字节,于是就标记关文件。
(4)异步刷盘任务开始执行,刷完之后把当前 TsFile 关掉。
在这个例子里,写满 2 个 memtable (20条数据) 关闭一次文件,写入频率为 1 秒,文件的生成耗时是 20 秒左右。
同步流程
发送端定时检查本地有没有新创建的 Schema 和新生成的完整的数据文件,如果存在,就发给接收端。同步的延迟基本就是 max(同步检查间隔,文件生成耗时)。
在 iotdb-sync-client.properties 配置文件中,有一个参数sync_period_in_second,这个控制发送端检查的频率。假如配置 60 秒,那同步的最长延迟就是 60秒,如果配置 10秒,那延迟就是 20秒(一个文件的生成耗时)。可以看到,同步延迟跟配置有关系,跟写入频率也有关系。
配置文件里的 sync_period_in_second 可以配的比较小,没啥大问题。主要问题是 TsFile 的生成间隔,这个由 memtable_size_threshold 和 tsfile_size_threshold 控制,这两个参数,尤其是 memtable 越大,历史数据查询越快。因此,同步能达到的最低延迟和查询性能之间需要平衡。
一个比较简单的查看自己系统里文件的生成速率,可以到数据目录 data/data/存储组{/分区} 看 .resource 文件的最后修改时间间隔。
测试同步
在一个机器测试同步,示例脚本为 linux 环境,版本 0.10.1。先下载二进制包,解压缩两遍重命名,一个 sender,一个 receiver。
启动接收端
cd receiver
## 配置
conf/iotdb-engine.properties 中的 is_sync_enable=true
## 启动接收端 IoTDB
nohup ./sbin/start-server.sh >/dev/null 2>&1 &
## 启动接收端 CLI,默认用 root 用户连本地 6667 端口
./sbin/start-cli.sh
启动发送端,准备数据
cd sender
## 配置
conf/iotdb-engine.properties 中的 rpc_port=6668
conf/iotdb-sync-client.properties 中的 sync_period_in_second=10
## 启动 iotdb
nohup ./sbin/start-server.sh >/dev/null 2>&1 &
## 启动发送进程
nohup ./tools/start-sync-client.sh >/dev/null 2>&1 &
## 启动发送端 CLI,注意,改到 6668 端口了
./sbin/start-cli.sh -h 127.0.0.1 -p 6668 -u root -pw root
## 输入
insert into root.turbine1.d1(timestamp,s1,s3) values(2,1,3);
flush (这个是精髓,强制把 memtable 刷盘,文件封口)
接收端验证数据
## 在接收端 CLI 中输入
select * from root
如果想自己配置,需要先把 enable_parameter_adapter 置为 false,不然系统会自动调 memtable 和 tsfile 大小。
具体可参考用户手册,也可点阅读原文跳过去。
http://iotdb.apache.org/zh/UserGuide/V0.10.x/System%20Tools/Sync%20Tool.html
总结
文件同步适合对实时性要求没那么高的数据汇总,备份。秒级或分钟级的同步就需要换方案了。在实验中遇到数据没同步过去的,要么是同步的定时检查间隔设置的过长了,要么是文件没关闭,现在还没有定时关文件的机制,需要手动调用 flush。对了,提示一个东西,start-cli.sh 脚本也可以连远端的 iotdb,加上 -h -p -u -pw 参数就行了。
本文分享自 Apache IoTDB 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!