Apache IoTDBとは｜時系列DBを動かして100万行の書き込みと圧縮率を実測、AINodeの予測SQLも解説

Apache IoTDB は、センサーや設備から届く「時刻つきの値」を大量に書き込み、時間窓で集計するための時系列データベースだ。Apache ソフトウェア財団のプロジェクトで、2026-10-15 時点の GitHub Star は約6.4k、最新リリースは 2.0.11（2026-09 公開）。本記事では公式の配布物を Linux で起動し、100万行の書き込み時間、ディスク上の大きさ、集計クエリの応答を測った。あわせて、時系列の基盤モデルを SQL から呼ぶ AINode と、リポジトリが置いている AI エージェント向けの指示書も読んだ。

時系列の予測モデルも、言語モデルと同じく事前に学習した重みを推論に使う。言語モデルそのものの仕組みは LLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版 にまとめている。

Apache IoTDBとは：IoTの時系列データを溜めて集計するDB

README は IoTDB を「時系列データの収集・保存・分析のためのデータ管理システム」と説明し、特徴として高い圧縮率、高スループットの読み書き、時間方向の集計関数、Hadoop・Spark・Grafana との連携を挙げている。リポジトリの CLAUDE.md によると、構成は次の3種類のノードだ。

・ConfigNode：クラスタのメタデータと分割（リージョン）の管理
・DataNode：保存・検索・クライアント接続を受け持つ本体
・AINode：Python で書かれた、AI・機械学習の推論用ノード

1台で試すときは ConfigNode と DataNode を1つずつ起動する。2.0.11 からは、2つを1つの JVM にまとめてメモリを 512MB に抑える Edge 版の配布物（edge-bin）も加わった（リリースノートの記載。本記事では未検証）。

データの書き方は2通りある。2.x の CLI は何も指定しないとツリーモデルで、-sql_dialect table を付けると表モデルになる（start-cli.sh のヘルプで確認）。

両者のデータベースは別の名前空間になる。表モデルで作った factory は、ツリーモデルの SHOW DATABASES には出なかった。

リポジトリには AI エージェント向けの指示書がある

ルートに CLAUDE.md と AGENTS.md があり、2つは1バイトも違わない同じ内容（各15,868バイト）だった。書かれているのは、Maven でのビルドと結合テストの回し方、Apache ライセンスのヘッダーを必ず付けること、Java は Spotless で整形すること、AINode の Python は black と isort を通すこと。ログや例外のメッセージを英語の文字列で直書きせず、英語と中国語の両方の定数クラスに同じ名前で足すという国際化の規則には、名前の付け方（MD5 の先頭8桁を使う）まで書いてある。コミットに Co-Authored-By の行を付けないこと、脆弱性を探すエージェントは SECURITY.md と脅威モデルを先に読むことも指示している。

.claude/settings.json と .codex/hooks.json には同じフックがあり、エージェントが .java ファイルを書き換えるたびに mvn spotless:apply をそのファイルにかける。Claude Code と Codex の両方に、整形を人の注意に頼らず機械で通す設定だ。

Apache IoTDBを動かす：ダウンロードから起動確認まで

公式の配布物 apache-iotdb-2.0.11-all-bin.zip（113MB）を使った。2.0.11 から Java 17 以上が必要になっている（リリースノートの破壊的変更。検証は OpenJDK 21）。Docker イメージは、この環境で Docker デーモンが動いていなかったため試していない。

curl -O https://downloads.apache.org/iotdb/2.0.11/apache-iotdb-2.0.11-all-bin.zip
curl -O https://downloads.apache.org/iotdb/2.0.11/apache-iotdb-2.0.11-all-bin.zip.sha512
echo "$(cat apache-iotdb-2.0.11-all-bin.zip.sha512)  apache-iotdb-2.0.11-all-bin.zip" | sha512sum -c
unzip -q apache-iotdb-2.0.11-all-bin.zip && cd apache-iotdb-2.0.11-all-bin
bash sbin/start-standalone.sh
# 10秒ほど待ってから
./sbin/start-cli.sh -h 127.0.0.1 -p 6667 -u root -pw root -e "show cluster"

.sha512 にはハッシュ値しか入っていないので、ファイル名を足してから sha512sum -c に渡している。show cluster で ConfigNode と DataNode がどちらも Running になれば起動できている。新しい版が出ると 2.0.11 は downloads.apache.org から archive.apache.org/dist/iotdb/ に移る。

表モデルでは、CLI に入って次の SQL を実行した。CLI に標準入力から流したときは1行が1文として実行されたので、文の途中で改行しない。

-- ./sbin/start-cli.sh -u root -pw root -sql_dialect table で入る
CREATE DATABASE factory;
CREATE TABLE factory.sensor (device_id STRING TAG, temperature DOUBLE FIELD, humidity FLOAT FIELD);
INSERT INTO factory.sensor(time, device_id, temperature, humidity) VALUES (2026-10-15T09:00:00+09:00, 'dev00', 21.5, 48.0), (2026-10-15T09:30:00+09:00, 'dev00', 22.3, 47.5);
SELECT device_id, date_bin(1h, time) AS hour, avg(temperature) AS avg_t, max(temperature) AS max_t FROM factory.sensor GROUP BY device_id, date_bin(1h, time) ORDER BY device_id, hour;

ツリーモデルでは CREATE TIMESERIES root.plant.line1.temperature WITH DATATYPE=DOUBLE, ENCODING=GORILLA で系列を作り、GROUP BY ([2026-10-15T09:00:00+09:00, 2026-10-15T11:00:00+09:00), 1h) で1時間ごとの平均を取れた。圧縮方式は指定しなければ LZ4 だった（SHOW TIMESERIES の表示）。

100万行を書き込んで測った結果（2026-10-15実測）

Python クライアント（PyPI の apache-iotdb 2.0.11）から、表モデルのテーブルに10台×10万行（1秒間隔、温度と湿度の2列）を、1万行ずつの NumpyTablet で書き込んだ。同じ値を CSV にも書き出して大きさを比べた。

応答時間は CLI が表示する「It costs」の値で、各3回実行した。同じ CSV を gzip で固めると 4.4MB で、TsFile より小さい。TsFile は圧縮したまま時刻の範囲や集計で引ける点が gzip と違う。書き込み後の常駐メモリは ConfigNode が約368MiB、DataNode が約955MiB だった。

AINodeの予測SQL：FORECASTで時系列の基盤モデルを呼ぶ

AINode は DataNode とは別の Python プロセスで、ConfigNode に登録して使う（設定ファイル iotdb-ainode.properties の待ち受けは 10810番）。表モデルでは、テーブル関数 FORECAST に過去の値を渡すと予測を返す。2.0.11 のソースに組み込みで登録されているモデルは次のとおり。

ソースのコメントには、基盤モデルの重みは AINode に同梱しないとある。初回に Hugging Face から取得する作りだ。同じ系統の Google の TimesFM は TimesFMとは｜Google Researchの時系列基盤モデルを公式README・論文・ベンチマークで読み解く で扱った。言語モデルを手元で動かす道具が Ollama だとすれば（Ollamaとは？使い方・インストール・モデル選び・エラー対処まで｜ローカルLLM完全ガイド2026年版）、AINode は時系列の予測モデルをデータの置き場所のすぐ隣で動かす役になる。

SELECT * FROM FORECAST(TARGETS => (SELECT time, temperature FROM factory.sensor WHERE device_id = 'dev00' ORDER BY time DESC LIMIT 1440) ORDER BY time, MODEL_ID => 'sundial', OUTPUT_LENGTH => 60);

書き方は、リポジトリの結合テスト（AINodeSharedClusterIT）にある SQL の型に合わせた。AINode の無い構成で実行すると、構文は通ったうえで「1011: Failed to connect to AINode」で止まった。

公開前に確かめること：root / root と既定のポート

2.0.11 の配布物は、クライアント用の 6667番も内部通信の 10710〜10760番も 127.0.0.1 で待ち受けた（起動後に待ち受けアドレスを確認）。REST API（18080番）は enable_rest_service=false で起動しない。一方で初期ユーザーは root / root のままログインできる。別のホストから使うために dn_rpc_address を広げるなら、先にパスワードを変える。ALTER USER root SET PASSWORD '<新しいパスワード>' で変更でき、4文字未満は拒否された。

リポジトリの THREAT_MODEL.md（ASF のセキュリティチームが起草し、PMC のレビューを2回経た v0）は、次の点を利用者の責任としている。

・root / root を残したまま公開することは、サポートする運用ではない
・クライアント通信の TLS（enable_thrift_ssl）は既定で無効。ノード間と AINode の通信には今のところ暗号化が無い
・UDF・トリガー・パイプ・モデルの権限（USE_MODEL など）は、サーバー内でコードを動かす権限と同じ。権限管理は境界であってサンドボックスではない

脆弱性の報告先は [email protected] で、公開の Issue には書かないよう SECURITY.md が求めている。

Apache IoTDBとInfluxDB・TimescaleDBの違いと選び方

各製品の README（2026-10-15 時点）に書かれている範囲で並べた。性能は測っていないので比べない。

IoTDB が候補に入るのは、工場・設備のように装置の階層が深く、測定点が多い場面だ。DB の中で集計から予測までつなげたい場合も候補になる。すでに PostgreSQL で運用していて、その上に時系列を足したいなら TimescaleDB が近い。InfluxDB 1.x・2.x の書き込み API を使う既存の収集系があるなら InfluxDB 3 Core が移りやすい。

参照ソース

・apache/iotdb（公式リポジトリ） — README・CLAUDE.md・AGENTS.md・THREAT_MODEL.md・SECURITY.md（2026-10-15時点、master 8effe5d）
・Apache IoTDB 2.0.11 配布物 — all-bin・RELEASE_NOTES.md
・Apache IoTDB 過去の配布物 — AINode 配布物の版ごとの有無
・apache-iotdb（PyPI） — 書き込みに使った Python クライアント 2.0.11
・influxdata/influxdb ・ timescale/timescaledb — 比較表の記載（README・LICENSE）