公式ウェブサイトのユーザーマニュアルのシステムツール欄に同期ツールがあります。多くの人がこのツールの使用方法と遅延について質問します。本日は、このツールの使用シナリオ、基本原則、テストについて紹介します。スキル。
本文は2439語で、予想読書時間は7分です。
使用するシーン
会社には複数の発電所があり、IoTDBが各発電所に展開され、発電所内の複数のデバイスの動作状態を監視します。発電所間のデータ交換はありません。現時点では、会社は分析のためにすべての発電所のデータを集約するクラウドプラットフォームを構築したいと考えています（ここに前提があり、クラウドプラットフォームのデータ分析は主に長期的な履歴データのためであり、データのリアルタイム要件は高くありません）。現時点では、このファイル同期ツールを使用できます。
ファイル同期ツールの配置：あるIoTDBのスキーマとデータファイル（TsFile）を別のIoTDBに同期するには、負荷と構成に応じて、同期プロセスに一定の遅延が発生します。
基本的
このツールの同期の細分性はすべてのデータポイントではなくデータファイルであることは、名前から明らかです。これにより、データファイルの生成（ファイルの作成からシーリングまで）にかかる時間が最長の同期遅延につながります。送信者は、ファイルが同期される前にファイルが生成されるのを待つ必要があるため、そうでない場合、ファイルの半分は解析されません。ファイルの転送はscpに似ており、各データを同期することの利点は、データの分析と再インポートを回避できることです。
ファイルの同期に関連する2つのIoTDBを送信者と受信者と呼びます。
書き込みプロセス
時間のかかるデータファイルの生成をよりよく理解するには、書き込みプロセスを簡単に紹介する必要があります。
IoTDBはLSM構造を使用します。データは、最初にメモリバッファーメモリに書き込まれます。メモリが特定のサイズに達すると、ディスクに配置され、複数のメモリがデータファイルに対応します。
たとえば、ストレージグループには1つの時系列があり、書き込み頻度は1秒で、各データポイントは16バイトです。memtableのサイズは160バイトで、TsFileファイルのサイズは200バイトです。ストレージグループには、最初は書き込み可能な空のTsFileがあります。
（1）memtableが初めて10データポイントでいっぱいになったとき、非同期フラッシュディスクタスクを送信し（現在書き込み中のTsFileに追加）、TsFileのサイズを確認します。現時点では、サイズはまだ0バイトなので、ファイルはそのままにしておきます。
（2）非同期フラッシュディスクタスクが実行され、フラッシュ後、TsFileは200バイトになります。
（3）memtableが2回目に10データポイントでいっぱいになったときに、非同期フラッシュディスクタスクを送信し、同時にTsFileサイズを確認して、200バイトを見つけるので、オフファイルをマークします。
（4）非同期点滅タスクの実行を開始し、点滅後、現在のTsFileを閉じます。
この例では、2つのメモリテーブル（20データ）が入力され、ファイルが1回閉じられます。書き込み頻度は1秒で、ファイルの生成には約20秒かかります。
同期プロセス
送信者は、新しく作成されたスキーマと新しく生成された完全なデータファイルがローカルに存在するかどうかを定期的にチェックし、存在する場合は受信者に送信されます。同期遅延は基本的に最大です（同期チェック間隔、時間のかかるファイル生成）。
iotdb-sync-client.properties構成ファイルには、送信者がチェックする頻度を制御するパラメーターsync_period_in_secondがあります。60秒が構成されている場合、最長の同期遅延は60秒です。10秒が構成されている場合、遅延は20秒です（ファイルの生成には時間がかかります）。同期遅延は構成に関連しており、書き込み頻度にも関連していることがわかります。
構成ファイルのsync_period_in_secondは比較的小さく構成でき、大きな問題はありません。主な問題は、memtable_size_thresholdとtsfile_size_thresholdによって制御されるTsFileの生成間隔です。これらの2つのパラメーター、特にmemtableが大きいほど、履歴データのクエリが高速になります。したがって、同期が達成できる最小のレイテンシとクエリのパフォーマンスのバランスをとる必要があります。
自分のシステムでのファイル生成率の比較的単純なチェックである、データディレクトリdata / data / storage group {/ partition}に移動して、.resourceファイルの最終変更時間間隔を確認できます。
同期のテスト
マシンで同期をテストします。サンプルスクリプトはLinux環境、バージョン0.10.1です。まず、バイナリパッケージをダウンロードし、解凍して、1つの送信者と1つの受信者の名前を2回変更します。
受け取り開始
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
総括する
ファイルの同期は、リアルタイムのパフォーマンスをそれほど必要としないデータの収集とバックアップに適しています。2番目または1分の同期で計画を変更する必要があります。実験では、データが同期されていない場合、同期タイミングのチェック間隔が長すぎるか、ファイルが閉じられていません。ファイルを定期的に閉じるメカニズムがありません。フラッシュを手動で呼び出す必要があります。ちなみに、start-cli.shスクリプトは、-h -p -u -pwパラメーターを使用してリモートiotdbに接続することもできます。