皆さん、幸せな週末を！最近のプロジェクトの着陸に伴い、0.10.0がリリースされ、一連のチュートリアルを書く準備が整いました。今日の最初のチュートリアルでは、IoTDBのデータモデルとモデリング方法を紹介します。
テキストは2855語で、推定読書時間は8分です。
時系列データとは何ですか？
モノのインターネットは1999年に誕生しました。そのコンセプトとテクノロジーの絶え間ない革新の下で、ユビキタスデバイスと設備はネットワークを通じてますます接続され、ライブデータをクラウドに継続的に送信しています。
全国の気象観測所を例にとると、全国に約6万の気象観測所があり、各気象観測所には70の気象物理量が収集されています。都市の地下鉄の各列車には、3,200のインジケーターが測定され、都市内の列車の数は300に達します。サーバーの運用とメンテナンスの監視では、サーバーはIOPS、CPU、ネットワークなどの10以上のインジケーターを同時に監視する必要があります。これらの例は、機器とメトリックの2つの概念を示しています。いわゆるメトリック（作業条件、測定ポイントとも呼ばれます）は、CPU使用率、温度、湿度など、ユーザーが気にするターゲットの特定の条件を反映できるデータ項目を指します。機器とは、サーバー、プロセス、列車、気象観測所など、一連のメトリックを持つエンティティを指します。デバイスのメトリックは、時系列データの一意の識別を形成します。
時間の経過とともに、この時系列データは一連の（タイムスタンプ、値）バイナリデータポイントを生成し、時系列データセットを形成します。したがって、時系列を、時系列識別子（機器とメトリック）、一連のタイムスタンプ、およびデータ値のペアで構成される無限のセットとして定義します。時系列データベースは、このような時系列の数百万または数千万を管理します。
IoTDBデータモデルと手動作成方法
IoTDBのメタデータ管理は、ディレクトリツリーの構造を採用し、異なるレベルを分離します。ルートノードはデフォルトでルートであり、さらに3つの主要な概念があります。ストレージグループ、機器、測定ポイント。
ストレージグループを手動で作成します。
set storage group to root.FU01
時系列を手動で作成します。
create timeseries root.FU01.deviceType1.AZQ01.Temperature with datatype=FLOAT, encoding=GORILLA, compression=SNAPPY
デバイスを作成する必要はありません。時系列を作成する場合、デフォルトでは最後から2番目のレイヤーがデバイスとして使用されます。上記の時系列を例にとると、デバイスIDはroot.FU01.deviceType1.AZQ01に設定されます。順不同のデータ生成を回避するために、デバイスの1つのタイムスタンプで複数の測定点の値を同時に書き込むことをお勧めします。
十分な時系列を作成すると、メタデータは次のツリーのようになります。
現在6つのデータ型をサポート
BOOLEAN、INT32、INT64、FLOAT、DOUBLE、TEXT
4つの主なエンコード方法があります
TS_2DIFF （时间列的默认编码方式）：适用 INT32、INT64
RLE：适用 INT32、INT64、FLOAT、DOUBLE（对于 FLOAT 和 DOUBLE 是有损压缩，默认保留2位小数，可在配置文件中修改 float_precision）
GORILLA：适用 FLOAT、DOUBLE
PLAIN：全搭
圧縮方法：
UNCOMPRESSED、SNAPPY（默认）
推奨されるモデリング方法
ストレージグループ：10〜50のストレージグループが推奨されます。各ストレージグループは独立したストレージエンジンです。ストレージグループを追加すると、書き込みの並列処理を向上させることができます。
設備：100,000未満を推奨
シーケンスの総数：1000万未満を推奨
通常の負荷でのこのモデリング方法は問題ありません。システムの負荷が高すぎるというメッセージが表示された場合は、enable_parameter_adapterをfalseに設定できます。メモリの急増を防ぐために、パラメータを手動で構成する必要があります。簡単なルールは次のとおりです：
memtable_size_threshold = tsfile_size_threshold
= IoTDBが割り当てたメモリ/ 2 /ストレージグループの数/ 4（順不同データあり）
= IoTDBが割り当てたメモリ/ 2 /ストレージグループ数/ 2（順不同データなし）
IoTDBはメモリを割り当て、conf / iotdb-env.shにMAX_HEAP_SIZEを設定します。
構成ファイルはconf / iotdb-engine.propertiesにあります。
この調整で推奨される負荷はほとんど問題ありません。負荷がどれほど高くても、お問い合わせください。この手動調整パラメータはバージョン0.11で削除され、生産性が向上します。
障害があるかどうかを判断する1つの方法：各デバイスの書き込みタイムスタンプがインクリメントされている限り、障害データはありません。そうでない場合、障害データが生成される可能性があります。
例：デバイスroot.turbine.d1には3つの測定ポイントs1、s2、s3があります。
# 无乱序数据
insert into root.turbine.d1(timestamp,s1,s2,s3) values(1,1,2,3);
insert into root.turbine.d1(timestamp,s1,s2,s3) values(2,1,2,3);
# 时间戳先写 2，再写 1，可能有乱序数据
insert into root.turbine.d1(timestamp,s1,s2,s3) values(2,1,2,3);
insert into root.turbine.d1(timestamp,s1,s2,s3) values(1,1,2,3);
# 时间戳先写 1，再写 1，虽然是不同测点，但还属于一个设备，可能有乱序数据
insert into root.turbine.d1(timestamp,s1,s2) values(1,1,2);
insert into root.turbine.d1(timestamp,s3) values(1,3);
メタデータスキーマを自動的に作成する
メタデータを手動で作成する方法に加えて、メタデータの自動作成もサポートしています。メタデータの自動作成は、データの書き込みプロセス中に実行されます。主にシーケンスの総数が事前にわからず、メッセージキューがリアルタイムで消費されるシナリオの場合、コードはすべてのデータに対してシーケンスを作成する必要はありません。
時系列にデータを書き込むときは、まずそのストレージグループが存在するかどうかを確認し、存在しない場合は自動的に作成されます。ルートを0番目のレベルとして定義します。ストレージグループは、デフォルトで最初のレベル（ルートの下のレベル）に設定されます。デフォルトで作成されたdefault_storage_group_levelは、構成ファイルで変更できます。
自動的に作成されたデータ型は、書き込まれた値の型から自動的に推測されます。受信データが文字列形式の場合、つまり、JDBCのinsertステートメント、またはセッション内の文字列の値の型を持つinsertRecord（s）インターフェースによって書き込まれる場合、値の形式に従って判断されます。主に4つの形式があります。文字列、およびデフォルトのタイプ：
不带 . 的整数：如 123 => FLOAT
带 . 的浮点数：如 12.34 => FLOAT
布尔型：true，false => BOOLEAN
其他类型：abc，124sa => TEXT
最初の3つの形式のデフォルトの文字列タイプは、構成ファイルで構成できます（バージョン0.10.0、現在のマスターブランチ、boolean_string_infer_typeパラメーターの近く）
簡単な裁判
ダウンロードして試してみてください：http://iotdb.apache.org/Download/
スクリプトはデフォルトでフォアグラウンドになり、バックグラウンドで手動で開始する必要があります。
nohup ./sbin/start-server.sh >/dev/null 2>&1 &
次に、Cliコマンドラインを開始できます。
./sbin/start-client.sh -h 127.0.0.1 -p 6667 -u root -pw root
or
./sbin/start-client.sh （默认用root连接本机）
バージョン0.10.0では、start-cli.shに名前が変更されます。
総括する
今日は、主にIoTDBのデータモデル、クイックスタート、推奨されるモデリング方法、手動によるチューニングのヒント、メタデータの動的作成に関する知識を紹介します。次のセクションでは、IoTDBの基本的なSQLクエリ機能を紹介します。