2026.08.01 データベース

InfluxDBとは？時系列DBの仕組み・InfluxDB 3の設計から採用判断まで実装者向けに解説

設備センサーの値を1秒おきに貯めはじめたら、数か月でテーブルが数十億行に膨らみ、直近1時間のグラフを描くだけでタイムアウトする。この行き詰まりの先で候補に挙がるのがInfluxDBです。ただ日本語の入門記事の多くは2.x世代のFlux前提で、いま入れる版とは中身が別物。本記事では2026年8月時点の一次情報で内部構造を分解し、採否の線引きまで整理しました。

まとめ：InfluxDBの仕組みと採用判断の結論

InfluxDBは、時刻の付いたデータを大量に書き込み、時間の範囲で走査する用途に向けて設計された時系列データベースです。IoTセンサー、サーバーのメトリクス、設備の稼働ログといった「後から訂正しない追記中心のデータ」を主な対象にしています。

2025年4月にGAとなったInfluxDB 3で中身は入れ替わりました。実装言語はRust、メモリ上の表現はApache Arrow、問い合わせはDataFusion、永続化はParquetをオブジェクトストレージへ置く構成。1.x・2.xのTSMエンジン時代に運用を苦しめたタグのカーディナリティ制約は、この載せ替えで解けています。

採否の軸は3つ。書き込みが追記中心か、問い合わせが時間範囲の走査中心か、無償のCore版が持つ「1クエリあたり約72時間」という制約を許容できるかです。長期の履歴を1本のクエリで横断したいなら、有償版かAWSのマネージド版を前提に見積もる。更新が頻発する業務データや数千行規模なら、PostgreSQLのままで足ります。

InfluxDBとは何か｜時系列データに寄せた設計と3系列の版の位置づけ

時系列データベースが汎用RDBと分かれる点｜追記中心の書き込みと走査

時系列データベースは、行に必ず時刻が付き、その順に積み上がるデータのために作られた製品群です。PostgreSQLやMySQLでも同じデータは持てる。分かれ目は量と読み方の偏りにあります。PostgreSQLを離れずに時系列へ寄せる道もあり、TimescaleDB（PostgreSQL拡張）の仕組みと採用可否が比較対象になります。

センサー100台が1秒おきに5項目を送ると、1日で4,320万行に達します。汎用RDBはこの規模の追記でB木索引の更新コストとページ分割が効いてきて書き込みが重くなる。しかも問い合わせは「直近24時間を1分単位で平均する」形にほぼ固定されます。

InfluxDBはこの偏りを前提に組まれています。時刻でデータを区切って束ね、その束ごと読み飛ばす。同じ系列の値は似た数値が並ぶため圧縮がよく効き、保持期間を過ぎたものは束の単位で捨てられる。読み方を絞るかわりに桁違いの量をさばく設計です。

measurement・tag・field・timestampというデータモデル

InfluxDBの1件のデータは4要素で構成されます。measurementはデータの種類を表す名前で、RDBのテーブル名に近い位置づけ。tagは文字列のラベルで、機器IDや設置場所が入ります。fieldは記録したい数値や文字列。timestampはナノ秒まで持てる時刻です。

tagとfieldの区別が設計上の要です。tagには索引が張られ、絞り込みやグループ化の条件に使われる。fieldには索引が張られず、集計の対象になります。条件に使う値はtagへ、測った値はfieldへ、という切り分けが基本です。

同じmeasurementかつ同じtagの組み合わせを1本の「シリーズ」と呼びます。tagの値の種類が増えるとシリーズ本数は掛け算で増える。ここが1.x・2.x世代でメモリを圧迫した原因です。

1.x・2.x・3系の3世代が並存する2026年8月時点の版の位置づけ

InfluxDBは世代ごとに設計が異なり、2026年8月時点で3系列が並行して保守されています。解説記事を読むときは、どの系列の話かを先に確かめてください。

系列 クエリ言語 2026年8月時点の版
1.x系 InfluxQL v1.12.4（2026年4月）
2.x系 Flux・InfluxQL v2.9.1（2026年5月）
3系 SQL・InfluxQL v3.10.0（2026年6月）

1.x系はdatabaseという単位とInfluxQLの初期世代。2.x系はorganizationとbucketを導入し、Fluxを主役に据えました。3系は2025年4月15日にCore・EnterpriseがGAとなった世代で、単位はdatabaseへ戻り、問い合わせはSQLが主役です。

新規に構築するなら3系が前提。ただし既存が2.x系でFluxのクエリを大量に抱えている場合、移行は書き換えを伴う作業になります。

InfluxDB 3の内部構造｜Rust・Arrow・Parquetへ載せ替えた設計

FDAPスタックとは何か｜Arrow・DataFusion・Parquetの役割分担

InfluxDB 3は、開発元が4年半をかけて土台から作り直したと説明する製品です。中核はFDAPと呼ばれる4部品の組み合わせで、担当が分かれています。

  • Apache Arrow：メモリ上でカラム単位にデータを並べる形式。処理系をまたいでコピーせず渡せる
  • Apache DataFusion：Rust製のクエリ実行エンジン。SQLの解析から実行計画の生成までを担う
  • Apache Parquet：オブジェクトストレージへ書き出す圧縮済みのファイル形式
  • Arrow Flight：Arrow形式のデータをネットワーク越しに転送するプロトコル

この構成が効くのは、集計クエリで読み込むデータ量が減るからです。Parquetはカラム単位でファイル内を区切り、統計情報を持ちます。「温度の平均」を求めるとき湿度や機器IDには触れず、条件に合わないブロックは統計情報を見た時点で読み飛ばせる。公式ドキュメントは直近値の問い合わせが10ミリ秒未満という水準を挙げています。

ディスクレス設計｜オブジェクトストレージへ計算と保存を切り離す

3系は永続化先としてAmazon S3・Google Cloud Storage・Azure Blob Storageを直接扱えます。開発元はこれを「ディスクレス」と表現。ローカルディスクだけでも動くため、試すときに外部依存は不要です。

利点は、複数のアベイラビリティゾーンにまたがる耐久性を作り込みなしに得られること、計算資源と保存容量を別々に増減できること、保存済みParquetを他のツールから直接読めることの3つ。一方でオブジェクトストレージへの往復はレイテンシが大きい。そこで直近データはメモリ上に厚くバッファとキャッシュを持ち、ホットな範囲はRAMだけで返す設計です。割り当てたメモリ量が直近クエリの応答時間を左右するため、サイジングは書き込みレートと直近何時間をメモリに載せるかから逆算します。

TSMエンジン時代のカーディナリティ制約が消えた理由と設計への影響

1.x・2.x世代のストレージエンジンはTSM（Time-Structured Merge Tree）と呼ばれ、シリーズごとの索引をメモリ上に保持する構造でした。tagの値の種類が増えるとシリーズ本数が掛け算で膨らみ、索引がメモリを食い潰して書き込みが止まる。ユーザーIDやリクエストIDをtagに入れた瞬間に破綻するため、「tagに何を入れないか」が設計の主題でした。

3系ではこの前提が変わりました。データはParquetのカラムとして保存され、シリーズ単位の巨大な索引をメモリへ常駐させる必要がありません。開発元は3系の性質を「カーディナリティの上限がない」と説明しています。

従来はtagに入れられず断念していた識別子を、そのままラベルとして持てる。ただしカラムの種類が増えればファイル数も増えます。壁が「メモリの限界」から「走査量の設計」へ移ったと捉えてください。

書き込みと問い合わせ｜line protocolとSQL・InfluxQLの使い分け

line protocolでの書き込みとv1・v2互換APIで既存資産を引き継ぐ

書き込みは line protocol というテキスト形式で行います。1行が1件で、measurement、tag、field、timestampをカンマと空白で区切る構造です。

home,room=Living temp=21.1,hum=35.9 1735689600000000000
home,room=Kitchen temp=20.4,hum=38.2 1735689600000000000
home,room=Living temp=21.4,hum=35.7 1735689660000000000

measurementが home、tagが room、fieldが temp と hum、末尾がナノ秒のタイムスタンプ。この形式は1.x系から一貫しており、既存スクリプトの出力をそのまま流し込めます。3系のHTTP APIはdatabaseを単位とし、トークンで認証。1.x系と2.x系の互換エンドポイントを備えるため、送信側を書き換えずに受け側だけ差し替える移行も可能です。

docker run -it -p 8181:8181 quay.io/influxdb/influxdb3-core:latest serve --node-id host01 --object-store file --data-dir ~/.influxdb3
influxdb3 write --database home --file sensors.lp
influxdb3 query --database home "SELECT room, avg(temp) FROM home GROUP BY room"

SQLとInfluxQLの二本立てとFluxが3系で外れたことの移行影響

3系がネイティブに解釈するのはSQLとInfluxQLの2つ。SQLは標準的な構文が通り、時間でのグループ化やウィンドウ関数も書けます。InfluxQLは1.x系から続く独自言語で、既存のダッシュボード定義を引き継ぐ用途に残されました。

移行の分かれ目になるのがFluxです。2.x系で主役だった関数型のパイプライン言語で、3系では対応から外れています。開発元はSQLへの需要を理由に、Fluxを保守モードへ移すと表明しました。1.x・2.x系では引き続き使えるものの、3系へ上げる計画にはFluxクエリの書き換えが必ず含まれます。

移行を見積もるときは、Fluxの資産を3つに分けて数えてください。単純な絞り込みと集計だけのものはSQLへ機械的に置き換えられる。join や pivot を含むものは構文の組み替えが要る。map や独自関数で手続き的に書かれたものは、作り直す判断になります。この3分類を先にやらないと、工数の見積もりが数倍ぶれます。

組み込みPythonの処理エンジン｜3種類のトリガーで前処理を回す

3系はPythonの実行環境をDB内部に持ちます。トリガーは書き込みがディスクへ吐き出される時のWAL Flush、指定間隔のSchedule、HTTPリクエストのRequestの3種類。「閾値を超えたら通知する」「1分値から1時間値を作る」処理のために、Kafkaやワーカーを別途立てずに済みます。ただしDBのプロセス内でユーザーコードが動く以上、重い処理は応答に跳ね返る。軽量な前処理と通知に絞ってください。

Core・Enterprise・Cloudの違い｜72時間クエリ制約と料金モデルの実態

Core版の72時間というクエリ範囲制約の正体と実務で当たる場面

無償のInfluxDB 3 Coreには、機能表から読み取りにくい制約があります。1本のクエリが対象にできる時間の幅が、おおむね72時間に制限される点です。

この数字の出どころは実装にあります。クエリの実行計画が扱えるParquetファイル数の上限が432に設定されており、10分単位のブロックで区切ると 432 × 10分 = 72時間になる。つまり「72時間より古いデータを保存できない」のではありません。書き込み側の期間制限はすでに解除済みで、何年前の時刻でも入れられます。制限されるのは1本のクエリがまたげる幅だけです。

実務で当たるのは、過去1年の月次推移や直近30日の傾向線、年間の稼働率レポートを1クエリで出したいとき。期間を分割して複数回問い合わせる手はありますが、ダッシュボードから直接叩く構成とは相性がよくない。長期の可視化が要件なら、Coreは検証用と割り切るのが安全です。

Enterpriseが足す履歴クエリと冗長構成・無償の家庭利用枠の条件

InfluxDB 3 EnterpriseはCoreの上に商用機能を重ねた版で、この制約を解きます。加わるのは長期の履歴クエリ、複数ノードによる高可用構成、リードレプリカ、行単位の削除、シリーズ単位の索引。費用はCPU構成に応じた個別見積もりで、公開定価はなく30日間の試用があります。

見落とされがちなのが無償枠です。開発元は個人・家庭での利用に限り、1ノード・2コアまでのEnterpriseを無償で提供しています。提案前の技術検証をCoreの72時間制約の中だけで行うと、本番で初めて詰まる事故につながります。

Cloud Serverlessの従量課金とAmazon Timestreamの選択肢

自前で運用しない道も2つ。開発元のマネージドサービスと、AWSのマネージド版です。

提供形態 クエリ範囲 費用の考え方
3 Core 1本あたり約72時間 無償（MIT・Apache 2.0）
3 Enterprise 長期履歴に対応 CPU構成に応じた個別見積
Enterprise 家庭利用 長期履歴に対応 1ノード2コアまで無償
Cloud Serverless 制約なし 書き込み・クエリ量の従量
Timestream for InfluxDB 制約なし AWSの利用量課金

Cloud Serverlessの公開単価は、書き込みが1MBあたり0.0025ドル、クエリが100実行あたり0.012ドル、ストレージが1GB時あたり0.002ドル、下り転送が1GBあたり0.09ドル。新規には250ドルのクレジットが付きます。金額は書き込みレートとダッシュボードの更新頻度で決まるため、試算では「1日あたりの書き込みMB数」と「1時間あたりのクエリ回数」を先に押さえてください。

AWS側の事情も効きます。Amazon Timestreamの独自エンジンLiveAnalyticsは2025年6月20日に新規顧客の受付を終了し保守運用へ移りました。AWSがすすめる移行先はTimestream for InfluxDBで、Core版とEnterprise版の2形態。AWS上に基盤を置く案件では事実上InfluxDBが第一候補です。エンジンごとの料金モデルと採否はAmazon Timestreamとは？仕組み・2つのエンジンと料金モデル・採用判断で扱っています。

時系列データ基盤の使い分け｜Prometheus・ClickHouseとの境界と構成

Prometheusとの違い｜プル型の監視基盤と汎用時系列ストアの役割

比較対象に必ず挙がるのがPrometheusです。両者は似た形のデータを持つが成り立ちが違う。Prometheusは監視の仕組みで、対象へ定期的に取りに行くプル型を基本とし、アラート評価までを含む一式として設計されました。InfluxDBは汎用の時系列ストアで、書き込みは送り側から押し込むプッシュ型。出自と標準化の経緯はPrometheusの誕生とCloud Native Computing Foundationとの関係で扱っています。

観点 Prometheus InfluxDB
収集方式 プル型が基本 プッシュ型が基本
主な用途 インフラ・アプリ監視 汎用の時系列蓄積
長期保存 外部ストレージ前提 本体で長期保持
問い合わせ PromQL SQL・InfluxQL

棲み分けの実務解はこうです。サーバー監視だけならPrometheusで完結する。センサーや業務データを年単位で貯めて後から分析するならInfluxDBを置く。両方あるなら、Prometheusを収集とアラート、InfluxDBを長期保存先として併置する形も取れます。

ClickHouseや列指向DWHで代替できる場面と、Telegrafを含む構成

Parquetを使う以上、InfluxDBの保存構造は汎用の分析DBに近づいています。ではClickHouseとは？列指向DBの仕組みとBigQueryとの使い分けで扱った製品で代替できるのか。代替が効くのは、書き込みが数分おきのバッチで、時系列以外の分析も同じ基盤で回したい場合。汎用の分析DBのほうがjoinや複雑な集計に強く、BIツールとの接続実績も多い。1基盤へ寄せられるなら運用の手数が減ります。

代替が効かないのは3つの場面。第1に、1秒未満の粒度で秒間数十万点を投げ込む高頻度の書き込み。第2に、保持期間の自動失効やダウンサンプリングを製品機能として持たせたい場合。第3に、収集エージェントのTelegrafやGrafanaの設定をそのまま使いたい場合。TelegrafはOSメトリクス・MQTT・Modbus・クラウドAPIにプラグインで対応し、設定ファイルだけで収集側を組めます。この周辺を自前で作り直す工数と比べてください。

逆に「自前で組むほどの規模ではない」なら、可視化込みのSaaSに寄せる道もあります。小規模なセンサー計測ならAmbient（アンビエント）とは？IoTセンサーデータを可視化するクラウドサービスで足りる場合が多い。基盤を持つ判断は、データ量と保持期間が固まってからでも遅くありません。

InfluxDBを採用してよい3条件と、見送るべき3つの場面の判断軸

採用してよい3条件｜書き込み特性・保持期間・問い合わせ範囲で見る

ここまでの内部構造を踏まえ、採否を条件付きで言い切ります。次の3つがすべて成り立つとき、InfluxDBは有力な候補です。

  1. 書き込みが追記中心で、過去の行を訂正する運用がほぼないこと
  2. データを月単位以上で保持し、期間を過ぎたら自動で捨てたいこと
  3. 問い合わせが「時間で範囲を切って集計する」形に収まること

加えて版の選択が要ります。長期の履歴を1本のクエリで横断する要件があるなら、無償のCore版は候補から外してください。Enterprise、Cloud Serverless、Amazon Timestream for InfluxDBのいずれかで見積もるのが出発点です。

見送るべき3場面｜更新頻発・少量データ・既存監視基盤で足りるとき

逆に、次の3場面では見送りをすすめます。

第1に、記録した値を後から訂正する業務。検査結果の再測定や伝票の修正のように値が変わるデータは向きません。行単位の削除はEnterpriseでようやく入る機能で、無理に載せると運用が破綻します。

第2に、データ量が小さい場合。数万行から数百万行で読み方も単純なら、PostgreSQLに時刻索引を張るだけで足ります。時系列DBを1つ増やすことは、監視対象・バックアップ手順・切り分け先が1つ増えることでもある。運用コストが先に効きます。

第3に、目的がサーバー監視だけの場合。PrometheusとGrafanaが動いているなら、InfluxDBを足す理由は薄い。長期保存が課題なら、Prometheus側の保持設定とリモートストレージの検討が先です。

時系列データ基盤の構築を外部へ委ねるとき見積書で確かめる5項目

外部へ設計・構築を依頼するとき、見積書の粒度が粗いと後から追加費用が出ます。次の5項目を確かめてください。

  1. 版と提供形態の明記。どの版を使い、ライセンス費用は誰が持つか
  2. クエリ範囲の要件。年次レポートの有無と、それをどの版で満たすか
  3. スキーマ設計の根拠。tagとfieldの振り分け方針とシリーズ本数の見積もり
  4. 保持期間と縮約の設計。生データを何日持ち、何分値へまとめて何年残すか
  5. 移行対象の内訳。既存が2.x系ならFluxクエリの本数と書き換えの分類

特に5番目は工数のぶれが大きい箇所。Fluxの資産を数えずに見積もった案件は、移行フェーズで必ず膨らみます。設計から運用まで相談するなら、データ分析基盤構築・MLOps構築支援で要件整理から対応しています。

よくある質問

InfluxDBは無料で使えますか？

InfluxDB 3 CoreはMIT・Apache 2.0のライセンスで公開され、商用利用を含めて無償で使えます。ただし1本のクエリが対象にできる幅がおおむね72時間に制限されるため、長期の履歴を横断する用途には不向き。個人・家庭での利用なら1ノード2コアまでのEnterpriseも無償です。

InfluxDB 2.xから3系へ移行するとき、何が問題になりますか？

最大の障壁はクエリ言語です。2.x系の主役だったFluxは3系で対応から外れており、SQLかInfluxQLへの書き換えが要る。書き込み側は互換APIがあるため、送信するアプリケーションやTelegrafの設定はほぼそのまま使えます。移行工数はFluxクエリの本数と複雑さでほぼ決まります。

InfluxDBとPrometheusはどちらを選ぶべきですか？

サーバーやコンテナの監視とアラートが目的ならPrometheusで完結します。計測値を年単位で貯めて後から分析する要件があるならInfluxDB。両立させるなら、Prometheusを収集とアラート、InfluxDBを長期保存に割り当てる構成が取れます。

タグには何を入れてよいのですか？

絞り込みやグループ化の条件に使う文字列をtagへ、測った値をfieldへ置くのが基本です。1.x・2.x系ではtagの値の種類が増えるとメモリを圧迫したため、識別子をtagに入れることは避けられていました。3系ではこの制約が解けています。ただしカラム数の増加は走査量に響きます。

AWS上で使う場合、どの選択肢がありますか？

EC2などへ自前で構築するほか、マネージドのAmazon Timestream for InfluxDBが使えます。独自エンジンのTimestream for LiveAnalyticsは2025年6月20日に新規顧客の受付を終了しており、AWSが案内する移行先はこちら。Core版とEnterprise版の2形態から選べます。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る