2026.08.23 データベース

時系列データベースとは？RDBとの違いと圧縮・保持設計から製品選定までを実装目線で解説

時系列データベース（TSDB）は、時刻の付いた測定値だけを相手にする専用のデータストアです。センサの計測値、サーバの監視メトリクス、課金の使用量ログのように、書き込みが追記へ偏り、読み出しが期間の範囲走査へ偏るワークロードで、汎用のリレーショナルデータベースとは別の格納方式を採ります。この記事では、データモデルの三要素、時間でチャンクを切る格納と圧縮の原理、保持ポリシーとダウンサンプリングの段の決め方、系列数が破綻する条件、そしてPostgreSQL拡張・専用エンジン・マネージドが入れ替わる選定の境界までを、設計判断の単位で組み立てます。

まとめ：時系列データベースを選ぶ三条件と、汎用DBのままで足りる境界

先に結論を置きます。時系列データベースを導入してよいのは、次の三条件がそろったときだけです。第一に、書き込みが追記中心で、過去行の更新がほとんど発生しないこと。第二に、読み出しが「この期間のこの系列を集約する」という範囲走査に寄っていること。第三に、生データを何日で捨てるかという保持期限を決められること。三つ目が決まらない案件は、製品を替えても容量とコストが伸び続けます。

逆に、行数が数千万件に届かない規模、金額の訂正が入る課金データ、既存の監視SaaSで運用が回っている状態のいずれかに当てはまるなら、専用エンジンは持ち込まないほうがよいでしょう。PostgreSQLのパーティションと索引で十分に捌けます。データベース全体の種類と選び方から確認したい場合は、RDBとNoSQLの構造と選定基準を整理した記事を先に読むと、この後の話が位置づけしやすくなります。

製品の比較は最後でかまいません。順序としては、系列数の見積もりと保持段階の設計が先に来ます。この二つが決まっていれば、候補は自然に二つか三つへ絞られます。

時系列データベースとは何か｜追記中心の書き込みと時刻キーのデータモデル

まずデータの形から押さえます。ここを曖昧にしたまま製品比較へ進むと、後からタグ設計のやり直しが発生します。

時系列データの三要素｜計測時刻・系列を識別するタグ・測定値の並び

時系列データは、計測時刻（timestamp）、系列を識別するラベルまたはタグ、そして測定値（field）の三つで成り立ちます。InfluxDBのline protocolでは measurement、tag、field、timestamp という四つの区画に分かれ、Prometheusではメトリクス名とラベルの組で系列が一意に決まります。ここでいう系列とは、たとえば「工場A・ライン3・温度センサ07の温度」という一本の線のことです。タグの組み合わせが一つ増えれば、系列も一本増えます。この一対一の関係が、後で述べるカーディナリティ設計の土台になります。

汎用RDBと分かれる四つの前提｜更新なし・範囲走査・期限削除の扱い

時系列データベースが汎用RDBと分かれるのは、四つの前提を置いているからです。一つ、書き込みは追記のみで、過去行のUPDATEを想定しない。二つ、読み出しは主キー1件の取得ではなく、期間を指定した範囲走査と集約になる。三つ、1行1点ではなく、同じ系列の連続した点をまとめて格納する。四つ、削除は行単位ではなく期間単位でまとめて行う。製品によっては点単位のDELETEを備えず、保持期間の設定による一括削除だけを提供します。RDBのB木索引は1点ごとの挿入で更新コストを払いますが、時系列エンジンは追記前提のため、そのコストを構造的に外しています。

メトリクスとイベントログの違い｜等間隔と不定期で変わる設計判断

同じ「時刻付きデータ」でも、15秒ごとに必ず1点が来るメトリクスと、いつ発生するか分からないイベントログでは設計が変わります。等間隔のメトリクスは後述の圧縮がよく効き、1日あたりの点数も台数から先に算出可能です。一方でイベントログは発生量が読めず、値が数値ではなく文字列や構造化された属性を含みます。監視メトリクスは時系列エンジンへ、イベントは列指向のOLAPエンジンかログ基盤へ、というのが実務上の分け方です。両方を1つのストアへ押し込むと、片方の要件が必ず犠牲になります。

時系列データベースの内部構造｜時間分割・圧縮率とダウンサンプリング

ここからは、なぜ専用エンジンが速いのかという中身に入ります。原理を知っておくと、見積もりの前提が正しいかどうか自分で判断できます。

時間でチャンクを切る格納方式｜インデックスが小さく保たれる理由

時系列エンジンは、データを時間の区間で切って別々の塊へ格納します。TimescaleDBはhypertableを一定期間ごとのchunkへ分け、InfluxDB 3が書き込みを落とす先は、Parquetファイルとしてのオブジェクトストレージです。この分割には二つの効き目があります。書き込みは常に最新の塊だけを触るため、索引の更新範囲がメモリに載る大きさに収まる。そして古いデータの破棄は、行を1件ずつ消すのではなく塊ごと落とす操作になり、削除にかかる時間が行数に比例しません。数億行のDELETE文が半日走り続ける、という事故が構造的に起きない設計です。

差分の差分とXOR圧縮｜Gorillaが1点1.37バイトまで縮めた原理

圧縮の原理は、2015年のVLDBで公開されたGorillaの論文が土台になっています。タイムスタンプは値そのものではなく、前の点との差分の、さらに差分（delta of delta）を書きます。15秒間隔で取得していれば差分の差分はゼロが続き、論文の報告ではタイムスタンプの約96%が1ビットでした。測定値は前の値とのXORを取り、値が近ければ符号部と指数部が一致して0が並ぶ性質を使います。値の約51%が1ビットになり、1点あたり16バイトが平均1.37バイト、およそ12分の1まで縮みました。裏を返せば、取得間隔が不定期で値がランダムに動くデータでは、この圧縮率は再現しません。InfluxDB 3のArrowとParquetを使った格納についてはInfluxDB 3の内部構造と採用判断を扱った記事で詳しく触れています。

保持ポリシーとダウンサンプリング｜生データを捨てる期限の決め方

保持ポリシーは、容量から逆算するものではありません。「どの粒度で、いつまで遡って問い合わせるか」から決めます。実務でよく採る形は三段です。生データは7日から30日、1分平均は13か月、1時間平均は5年。この段を先に決めておくと、集約結果を書き出す処理（TimescaleDBのcontinuous aggregate、InfluxDBの定期タスク）を最初から組み込めます。逆に、生データを溜めてから間引こうとすると、集約処理が本番の書き込みと競合し、ディスクも先に埋まります。「後で決める」が最も高くつく設計判断です。設備データを対象にこの段を決める場面については、デジタルツインの設計｜収集層・データモデル・同期頻度の決め方を実装目線で解説もあわせて参照してください。

カーディナリティ爆発という失敗｜タグ設計が性能を壊す条件と兆候

系列数は、タグ値の直積で増えます。デバイス1万台×センサ20種で20万系列。ここまでは多くのエンジンが捌けます。壊れるのは、タグにリクエストID、セッションID、ユーザーIDのような一意な値を入れたときです。1リクエストごとに新しい系列が生まれ、系列数が数百万から数千万へ跳ね上がり、索引がメモリを食い尽くします。兆候は分かりやすく、書き込み遅延が時間とともに悪化し、再起動後だけ速い状態に戻ります。対処は一つ、一意な識別子はタグではなくfield側へ置くか、そもそもログ基盤へ流すことです。InfluxDB 3のようにParquetへ載せ替えた世代では旧来の制約が緩みましたが、無制限になったわけではありません。

時系列データベースが効く三領域｜IoT計測・監視メトリクス・課金ログ

用途によって要件の重心が違います。同じ製品を選んでも、設計の力点は次のようにずれます。

IoTと設備計測での要件｜欠測・時刻ずれとエッジ側での間引き設計

製造設備やインフラ設備の計測では、通信断による欠測と、デバイス側の時刻ずれが常に付いて回ります。時刻はデバイスのRTCではなくNTP同期を前提にし、それでも残る数秒の揺れを見込んで集約の窓を決める設計です。1秒ごとに1点を1万台から受ければ毎秒1万点になり、そのまま送ると回線とストレージの両方を圧迫します。エッジ側で移動平均を取って5秒に1点へ落とす、変化がしきい値未満なら送らない（デッドバンド）といった間引きを、ゲートウェイ側の要件として先に決めておきます。欠測を0で埋めるか欠測のまま残すかは、後段の異常検知の精度に直結する分岐です。投入前の補間と再サンプリングの手順は、時系列データの前処理を工程順に整理した記事にまとめています。検知側でこの分岐をどう扱うかは、時系列データの異常検知における前処理としきい値の設計で整理しています。

監視メトリクスの構成｜Prometheus 3系のプル型と長期保存の分離

サーバやコンテナの監視では、Prometheusが対象からメトリクスを取りに行くプル型で収集し、ローカルのTSDBへ書きます。ただしPrometheus本体は長期保存を主目的にしていないため、数か月以上の履歴はremote write経由で外部の時系列ストアへ分離するのが定石です。Remote-Write 2.0の仕様はPrometheus 3.0（2024年11月14日公開）で導入され、メタデータやexemplarを運べるようになりました。2026年8月時点の最新はv3.13.0（2026年7月1日公開）で、長期運用向けにはLTSのv3.5系が置かれています。監視の入口をPrometheusに寄せ、保存側だけを別製品にする構成が、移行コストを最も小さくできます。

課金と使用量ログの扱い｜正確性を優先し時系列DBを選ばない判断

課金や使用量の記録は、時刻付きデータでありながら時系列データベースに向きません。理由は前提が崩れるからです。請求の訂正で過去のレコードを更新する、月次で厳密に突き合わせる、監査のために1件単位で削除も改変もできない形で残す。どれも追記中心・期限削除という設計と正面から衝突します。ここはRDBのトランザクションで持ち、集計だけを列指向のDWHへ流す構成にします。「時刻が付いているから時系列DB」という選び方は、この領域では避けてください。

製品選定の四つの軸｜PostgreSQL拡張・専用エンジン・マネージドの境界

候補は大きく四系統に分かれます。まず全体像を並べ、そのうえで各系統が入れ替わる条件を見ていきます。

系統	向く条件	運用の主体	注意点
PostgreSQL拡張	既存SQL資産とJOINを残す	自社またはクラウド提供	超大量書き込みは苦手
専用エンジン	書き込み量と圧縮率を優先	自社運用が前提	タグ設計の制約が強い
リアルタイムOLAP	多次元の任意軸で集計する	自社運用かマネージド	構成要素が多く重い
マネージド	運用当番を置けない	クラウド事業者	提供変更の影響を受ける

四系統のうち、迷ったときの初期値はPostgreSQL拡張です。既存の運用体制をほぼ変えずに時間分割と圧縮を得られるため、外れ値が小さくなります。

PostgreSQL拡張で寄せる条件｜TimescaleDBが向く既存資産の形

すでにPostgreSQLを運用していて、マスタテーブルとのJOINや外部キー制約を残したまま時系列を扱いたいなら、TimescaleDBが第一候補になります。通常のテーブルをhypertableへ変換すれば時間分割が入り、SQLもドライバもそのまま使えます。開発元のTimescaleは2025年6月17日にTiger Dataへ社名を変更しましたが、TimescaleDB拡張自体は現在もOSSです。判断の分かれ目は書き込み量で、毎秒数万点を超えて伸び続ける見込みがあるなら専用エンジンを検討します。詳しい仕組みと採用可否はPostgreSQL拡張としてのTimescaleDBを扱った記事にまとめています。

専用エンジンを選ぶ条件｜InfluxDBとDruidで分かれる問い合わせ

専用エンジンの中でも、問い合わせの形で選ぶ製品が変わります。InfluxDBが得意なのは、系列を指定して期間を切り、集約して返すという時系列らしい問い合わせです。対してApache Druidは、多数の次元を持つイベントを取り込み、任意の軸で絞り込んで集計するダッシュボード用途に寄っています。「センサ07の直近24時間の平均」ならInfluxDB、「地域別・機種別・時間帯別のクロス集計を秒で返す」ならDruid、という分け方が実装上の目安です。後者の設計はリアルタイムOLAPの取り込み設計を扱った記事で扱っています。

マネージドを選ぶ条件｜Timestreamの提供変更が示した入口の変化

運用当番を置けない体制なら、マネージドを選ぶ理由は十分にあります。ただし提供形態の変更は起こります。AWSはAmazon Timestream for LiveAnalyticsについて、2025年6月20日付で新規顧客の受付を終了しました。既存の稼働中ワークロードに影響はなく、既存の支払いアカウント配下ではアカウント追加も続けられますが、これから採用する側の入口はAmazon Timestream for InfluxDBへ寄せる案内になっています。マネージドを選ぶときは、移行手順とデータの取り出し方を契約前に確かめておくのが実務の作法です。二つのエンジンと料金モデルの違いはAmazon Timestreamの仕組みと採用判断を扱った記事で整理しています。

時系列DBを見送る三つの条件｜行数・保持期間・既存基盤で引く線

ここは言い切ります。次の三条件のいずれかに当たるなら、時系列データベースは導入しないでください。第一、総行数が数千万件に届かず、今後3年でも一桁増える見込みがない場合。PostgreSQLの宣言的パーティションとBRIN索引で足ります。第二、保持期限を決められず、生データを全期間残す要件がある場合。この要件では圧縮より安いオブジェクトストレージとParquetの組み合わせが勝ちます。第三、既存の監視SaaSやDWHで運用が成立している場合。新しいストアを1つ増やすと、監視・バックアップ・権限管理・バージョン更新という運用項目が丸ごと増えます。導入しない判断も、設計の成果物です。

時系列データ基盤の内製と外部委託｜見積書で確かめる五つの確認項目

製品が決まっても、運用まで含めた体制設計が残ります。ここを曖昧にした案件が、半年後に停止します。

内製で回る条件と破綻する条件｜運用当番と保持設計を維持する負荷

内製で回るのは、系列数とデータ量の増加を継続して見られる担当が置けるときです。時系列基盤の運用は、監視ダッシュボードを作って終わりにはなりません。タグが増えて系列数が跳ねていないか、保持ポリシーの段が実際の問い合わせ範囲と合っているか、メジャーバージョンの更新でクエリ言語や互換APIが変わっていないか。この点検が四半期ごとに発生します。担当が1人しかいない、あるいは他業務と兼務で工数が確保できない体制では、更新が止まって数年前の版で塩漬けになります。

外部委託で確かめる五項目｜取り込み量・保持段階・移行手順の明示

外部へ委ねるときは、見積書と提案書で次の五項目が明示されているかを確かめます。ひとつ、ピーク時の取り込み点数（毎秒何点か）。ふたつ、想定する系列数の上限と、超えたときの挙動。みっつ、保持段階ごとの粒度と保持期間。よっつ、既存データの移行手順と、失敗したときの再取り込み方法。いつつ、運用引き継ぎの範囲（監視・バックアップ・版更新のどこまでを誰が持つか）。この五つが数値で書かれていない提案は、稼働後に追加費用が発生します。IoT計測や監視データを含む基盤の設計・構築から運用引き継ぎまでを外部に委ねる場合は、データ分析基盤構築の相談窓口で要件の整理段階から相談できます。

よくある質問

時系列データベースの導入検討で実際に多い質問を、判断に使える形で答えます。

時系列データベースはRDBと何が違うのですか？

データの前提が違います。RDBは任意の行を更新・削除し、複数テーブルを結合して1件を正確に取り出す用途に向いた構造です。時系列データベースは、過去行を更新しない追記中心の書き込みと、期間を指定した範囲走査・集約に特化しています。そのため時間で区間を切って格納し、連続する点をまとめて圧縮し、古い区間を塊ごと破棄します。同じ量のデータでも、書き込み速度とディスク使用量で差が出るのはこの構造差によるものです。

時系列データベースは無料で使えますか？

主要な製品はOSS版を持っています。TimescaleDBはPostgreSQL拡張としてOSSで提供され、InfluxDBやApache Druidにも無償で使える版があります。ただし版によって機能制限が付く点には注意してください。たとえばInfluxDB 3のCore版には問い合わせ範囲の制約があり、長期の履歴を遡る用途では上位版かマネージドが必要になります。無料で始められるかどうかより、保持期間と問い合わせ範囲の要件を先に決めるほうが、後の選び直しを防げます。

PostgreSQLだけで時系列データを扱えますか？

扱えます。総行数が数千万件程度までなら、時刻列で宣言的パーティションを切り、BRIN索引を張る構成で実用的な性能です。むしろこの規模で専用エンジンを増やすと、運用対象が1つ増える分だけ損をします。分岐点は書き込み量と保持設計です。毎秒数万点の取り込みが続く、あるいは段階的なダウンサンプリングを自動で回したいという要件が出てきた時点で、TimescaleDB拡張か専用エンジンを検討してください。

Prometheusと時系列データベースはどう使い分けますか？

Prometheusは収集と警報の仕組みを含んだ監視システムで、内部に時系列ストアを持っています。役割としては入口側です。長期保存には向かないため、数か月を超える履歴が必要ならremote write経由で外部の時系列ストアへ書き出し、保存と長期の問い合わせをそちらに任せます。2026年8月時点の最新はv3.13.0で、長期運用向けはLTSのv3.5系です。監視の入口をPrometheusに保ったまま保存側だけを差し替えられる構成が、後の移行を軽くします。

データ保持期間はどのくらいに設定すればよいですか？

容量から決めず、問い合わせの粒度と遡る範囲から決めてください。実務では、生データを7日から30日、1分平均を13か月、1時間平均を5年という三段が使いやすい形です。1分平均を13か月にするのは、前年同月と比較する運用が多いためです。段を決めたら、各段への集約を定期処理として最初から組み込みます。運用開始後に段を増やすと、既存データの再集約が必要になり、本番の書き込みと競合します。