時系列データベース「TimescaleDB」って何なんだ？

こんにちは。サイオステクノロジー OSS サポート担当山本です。

今回のお題は「TimescaleDB」です。
まずはこれがどんなものなのか、という基本のところからお話ししてみようと思います。

1 ■TimescaleDB って何だ？
2 ■列指向データベース・時系列データベースって何だ？
3 ■で、結局 TimescaleDB ってどういうものなの？
4 ■最後に

■TimescaleDB って何だ？

TimescaleDB は、Tiger Data 社 (旧名：Timescale 社) によって開発された PostgreSQL の拡張機能です。
“時系列データベース” と呼ばれるカテゴリのデータベースであり、”列指向データベース” の技術を活用した強力な機能を提供してくれます。

■列指向データベース・時系列データベースって何だ？

列指向データベースと時系列データベースは、結論から言ってしまうと、いずれも大規模なデータの集計・分析に特化したデータベースです。

順を追って確認していきましょう。

■そもそもデータベースって何だっけ？

単に「データベース」と言う場合、長く広く利用されている関係性データベース管理システム (RDBMS / Relational DataBase Management System) を指すケースがほとんどでしょう。
まずはこちらをざっくり確認します。

RDBMS は、雑に言うと一定の構造にまとめたデータの集まりを保存し、読み出しや検索・集計、データの修正・削除などを行える、極めて汎用性の高いシステムです。

用途は多岐にわたりますが、例えばある商店が “顧客情報” “商品情報” “販売履歴” を管理したい…と考えた場合、例えばこんな感じで利用できます。
（正規化しろ、と怒られるかもしれませんが、ここではイメージ優先ということでご容赦を…！）

■列指向データベースって？

列指向データベースは、前述の RDBMS の後に生まれた概念です。

先ほどの RDBMS のイメージ例を見ていただくとわかるとおり、従来の RDBMS では1行で一つのデータのセットを表現しています。

内部的にも基本は行単位でデータを保存しているため、列方向での合計や平均値の計算といった集計処理は（その列の情報のみをピンポイントで抽出できないため）少し苦手としています。

大抵の場合は問題にならないのですが、超大規模なデータを使って集計・分析を行う場合……例えば監視系のシステムや、純粋に分析目的の超多量のデータを扱うシステムなどでは、規模次第ではこの性質がネックになります。

……それなら、内部的に（RDBMS で言うところの）列方向でデータがまとまるように保存すれば、集計処理に有利になるのでは？
という考え方を実装したのが、列指向データベースです。

このため、このカテゴリのデータベースは超大規模データの集計・分析向けとされるものが多く、この点において RDBMS より優位に立ちます。
また、集計処理向けのデータを列方向に見た場合、同じ形式で似たような値が連続するケースが少なくないため、様々なデータ圧縮技術を適用しやすいという副次効果もあります。

今回扱う TimescaleDB では、複数の圧縮技術を活用することで、通常の PostgreSQL としてデータを保持するよりもデータ容量を最大 95% ほど削減できるとされています。
参考：Time-Series Compression Algorithms, Explained – Tiger Data

ただし、列指向データベースは逆に行方向での処理、特に登録済みデータの個別編集などを極めて苦手としているため、万能な選択肢というわけではありません。
・データ規模が著しく大きく
・データの蓄積・集計処理を目的としていて
・登録したデータを個別に変更することが基本的にはない
といった条件を満たす、限られたケースでのみ輝くカテゴリと言えるでしょう。

■時系列データベースって？

時系列データベースもまた、RDBMS の後に生まれた概念です。

こちらは名前から推測できるとおり、保存するデータに含まれる “時間” の要素を軸にしてデータを整理しよう、という構想のデータベースです。
これもやはり、超大規模データへの対応を目的としています。

“時間” の要素がある大規模データの代表例として、監視システムについて考えてみましょう。

監視システムでは定期的にデータを収集してデータベースへ書き込んでいきますが、運用期間が長くなるほどデータは蓄積し、いずれ容量不足を引き起こします。
そのため、一定以上古くなったデータを削除することで容量問題を対策する、というのが定石です。

しかし、RDBMS は大規模なデータにおける選択的な削除 (DELETE 文) の処理があまり得意ではありません。
また、すでに大規模なデータが保存されている状態での継続的なデータの追加も、徐々にパフォーマンスが落ちる傾向があります。

このように、定期的な大規模データの書き込みと削除を繰り返すシステムを運用する場合、RDBMS がボトルネックになる可能性があります。

この大規模なデータの継続的な書き込みや、効率的なデータ削除に対応することを目指したのが、時系列データベースです。
目標や着眼点はある程度共通していますが、実際のアプローチ方法はソフトウェアごとにまちまちなようです。

■で、結局 TimescaleDB ってどういうものなの？

さて、それでは改めて TimescaleDB がどういうものなのかを見てみましょう。

まず、これは RDBMS である PostgreSQL の拡張機能です。

この拡張機能を有効にしたデータベース上で、table (※) の代わりとなる hypertable というものを作ることで、機能を利用できるようになります。
ユーザからは、この hypertable は普通の table とまったく同じように見えます。
※ table とは「どんな列を持つデータを保存するのか」を定義した入れ物のようなものです。
→ つまり、hypertable を作成する定義の部分を除けば、ほぼ通常の PostgreSQL の操作感で使うことができます。

一方で内部的には、hypertable は時間軸などを基準にして “chunk” と呼ばれる小さな table を継続的に自動作成し、それらを束ねて参照することで「一つの大きなテーブル」に見せかける……ということをしています。

chunk への書き込みは RDBMS である PostgreSQL の標準どおり「行単位」で実行されますが、
設定した規定の時間が過ぎた古い chunk は、列指向の考え方を基にデータの組み替え・圧縮が行われます。
→ これにより、集計処理に強くなり、データ容量も大幅に削減できます。