TimescaleDB は、時系列データベースの機能を PostgreSQL に追加する拡張モジュールで、自動的にデータを時間単位で分割された小さなテーブルに格納できます。Zabbix のデータベースに TimescaleDB を使用することで、性能向上、ディスク使用量の削減などの効果が期待できます。

本記事では、 Zabbix で TimescaleDB を利用するメリット、セットアップ方法、利用上の注意点について紹介します。

TimescaleDB のサポート

TimescaleDB は Zabbix 4.4 から正式にサポートされるようになりました。

TimescaleDB では、時系列データベースの機能を適用した親テーブルをハイパーテーブルと呼び、データは内部的にチャンクと呼ばれる小さなテーブルに分割されます。

具体的には以下のヒストリ・トレンドデータを格納するテーブルをハイパーテーブルに変換し、日付ごとにチャンクが自動的に作成されます。

• history
• history_uint
• history_log
• history_text
• history_str
• trends
• trends_uint

また、Zabbix 5.0 以降では、古くなったチャンクを圧縮し、ファイルサイズを縮小することも可能です。

Zabbix で TimescaleDB を利用するメリット

Zabbix で TimescaleDB を利用することで、次のようなメリットが得られます。

Housekeeper による削除処理の負荷軽減

Housekeeper とは、保存期間を超えたヒストリ・トレンドやイベント、アラートなどのデータを定期的に削除する機能です。

Housekeeper の削除処理は時間範囲で絞り込んで、1行ずつ DELETE するので、削除するレコード数が多くなればなるほど時間がかかり、データベースへの負荷が高まります。データベースの負荷上昇によって、データの読み取り/書き込みが遅くなり、監視の遅延や誤検知など監視全体に影響を与える可能性があります。

一方、Zabbix で TimescaleDB を利用すると、1行ずつ削除する DELETE に対して、TimescaleDB はチャンク単位でデータを削除するため、非常に高速です。これまでの Housekeeper の削除処理による高負荷問題を解決できます。

NVPS が 300 程度、同様な監視設定の Zabbix サーバで、素の PostgreSQL と TimescaleDB を利用した場合の Housekeeper の負荷を検証してみました。Zabbix サーバとデータベースは同一サーバ上で動作し、環境情報は以下の通りです。

• OS: RHEL 8.5 (VirtualBox 上の VM)
• CPU: 2vCPUs
• メモリ: 4GB

PostgreSQL の場合は、Housekeeper プロセスのビジー率が 100% まで上がる場合がありました。PostgreSQL と比べて、TimescaleDB の場合は最大でも 20% 以下で大幅に軽減されていることがわかります。
※今回の検証で以下の結果を得ましたが、削除するイベントやアラートなどの量によって Housekeeper プロセスのビジー率が変動します。

不要領域発生の抑止

PostgreSQL は追記型アーキテクチャを採用しているため、DELETE を実行しても PostgreSQL が使用するディスク領域サイズは減りません。DELETE はデータを削減することはできますが、不要領域が発生します。不要領域を回収して再利用可能な状態にするには VACUUM が必要になります。

Zabbix で TimescaleDB を利用すると、チャンクごと削除するため、DELETE による不要領域の発生を抑止でき、不要領域を回収するための VACUUM 処理によるオーバーヘッドも削減できます。

圧縮によるディスク領域の節約

Zabbix で長期運用すると、収集した監視データによって DB のサイズが肥大化していきます。TimescaleDB の圧縮機能を利用し、一定期間経過したヒストリ・トレンドデータを自動的に圧縮できます。

10GB の history テーブルと history_uint テーブルにおいて、7日を超過したデータを圧縮すると、圧縮前に比べて、ディスク領域はそれぞれ 89% と 95% 削減できました。history_log、history_text、history_str テーブルのレコードは可変長レコードであり、レコードのサイズによって圧縮率が変動します。

書き込み性能の向上

TimescaleDB では、チャンクごとにインデックスを構築するため、インデックスのサイズが小さくなります。また、TimescaleDB は最新のチャンクのデータとインデックスをメモリに保存するため、データ挿入時のインデックスの更新が高速になり、書き込み性能が向上します。

TimescaleDB のインストール・設定

この節では、Zabbix のデータベースとして TimescaleDB を利用するためのインストール・設定手順を説明します。

検証環境

今回は以下の構成でインストールを行います。各ソフトウェアは 2022 年 5 月時点での最新バージョンを利用しています。

• OS: RHEL 8.5
• Zabbix 6.0.3
• PostgreSQL 14.2
• TimescaleDB 2.6.1

TimescaleDB は 2022 年 5 月時点で以下のバージョンがメンテナンスされており、それぞれ対応する PostgreSQL のバージョンは以下の通りです。

前提条件

TimescaleDB をインストールする前に、Zabbix サーバと PostgreSQL がすでにインストールされており、データベースの初期設定、データベーススキーマと初期データの投入が完了していることが前提となります。

まだ完了していない場合は、こちらのインストール手順を参照してください。

TimescaleDB のインストール

本記事では、RHEL 8 上で構築した PostgreSQL サーバに TimescaleDB をインストールします。他のプラットフォーム向けのインストール方法については TimescaleDB のドキュメントを参照してください。

TimescaleDB の Yum リポジトリを登録します。

$ sudo tee /etc/yum.repos.d/timescale_timescaledb.repo <<EOL
[timescale_timescaledb]
name=timescale_timescaledb
baseurl=https://packagecloud.io/timescale/timescaledb/el/$(rpm -E %{rhel})/\$basearch
repo_gpgcheck=1
gpgcheck=0
enabled=1
gpgkey=https://packagecloud.io/timescale/timescaledb/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300
EOL

TimescaleDB の RPM パッケージをインストールします。
※ PostgreSQL xx がインストールされている場合は timescaledb-2-postgresql-xx を指定します。

$ sudo dnf install timescaledb-2-postgresql-14

TimescaleDB の設定

PostgreSQL で TimescaleDB を利用するための設定を行います。

PostgreSQL の設定ファイル postgresql.conf を直接編集しても良いですが、ここでは、環境のスペックに応じて対話的に PostgreSQL パラメータのチューニングを行う timescaledb-tune コマンドを使います。

--pg-config オプションには pg_config コマンドのパスを指定します。その他のオプションについては timescaledb-tune --help で確認できます。
以下のコマンドを実行すると、次々と質問されますが、基本的には y を入力していけば良いです。最後に設定が postgresql.conf に書き込まれます。環境によって、Zabbix で使用するには max_connections の推奨値が小さすぎる可能性があるので、ここでは明示的に max_connections の値を設定します。

$ sudo timescaledb-tune --pg-config=/usr/pgsql-14/bin/pg_config --max-conns=100

上記コマンドによって、TimescaleDB が shared_preload_libraries にロードされ、PostgreSQL のパラメータが環境に応じた適切な値に設定されます。

設定変更を反映するため、PostgreSQL のサービスを再起動します。

$ sudo systemctl restart postgresql-14

TimesaceleDB 拡張の作成

Zabbix サーバが利用する zabbix データベースに TimesaceleDB 拡張をインストールします。

$ echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

/usr/share/doc/zabbix-sql-scripts/postgresql/ にある TimescaleDB のスキーマ作成スクリプト timescaledb.sql を実行します。

$ cat /usr/share/doc/zabbix-sql-scripts/postgresql/timescaledb.sql | sudo -u zabbix psql zabbix

上記コマンドに指定した timescaledb.sql スクリプトの中身を確認してみましょう。

(以下、実行不要)
$ cat /usr/share/doc/zabbix-sql-scripts/postgresql/timescaledb.sql
(省略)
# ヒストリ・トレンドテーブルを1日ごとにチャンクを作成するハイパーテーブルに変換。
# ヒストリ・トレンドテーブルに既存のデータがある場合には、既存のデータの移行が行われる。
PERFORM create_hypertable('history', 'clock', chunk_time_interval => 86400, migrate_data => true);
PERFORM create_hypertable('history_uint', 'clock', chunk_time_interval => 86400, migrate_data => true);
PERFORM create_hypertable('history_log', 'clock', chunk_time_interval => 86400, migrate_data => true);
PERFORM create_hypertable('history_text', 'clock', chunk_time_interval => 86400, migrate_data => true);
PERFORM create_hypertable('history_str', 'clock', chunk_time_interval => 86400, migrate_data => true);
PERFORM create_hypertable('trends', 'clock', chunk_time_interval => 2592000, migrate_data => true);
PERFORM create_hypertable('trends_uint', 'clock', chunk_time_interval => 2592000, migrate_data => true);

# [管理] -> [一般設定] -> [データの保存期間]ページで「アイテムのヒストリ/トレンドの保存期間設定を上書き」オプションを有効にする。
UPDATE config SET db_extension='timescaledb',hk_history_global=1,hk_trends_global=1;

# 圧縮機能を有効にする。デフォルトでは7日間を超えたデータは自動的に圧縮される。
UPDATE config SET compression_status=1,compress_older='7d';

Zabbix サーバのデータベースにアクセスし、history テーブルを確認してみます。

$ psql -U zabbix
Password for user zabbix: 
psql (14.2)
Type "help" for help.

zabbix=> \d+ history
                                                    Table "public.history"
 Column |       Type       | Collation | Nullable |        Default        | Storage | Compression | Stats target | Description 
--------+------------------+-----------+----------+-----------------------+---------+-------------+--------------+-------------
 itemid | bigint           |           | not null |                       | plain   |             |              | 
 clock  | integer          |           | not null | 0                     | plain   |             |              | 
 value  | double precision |           | not null | '0'::double precision | plain   |             |              | 
 ns     | integer          |           | not null | 0                     | plain   |             |              | 
Indexes:
    "history_pkey" PRIMARY KEY, btree (itemid, clock, ns)
    "history_clock_idx" btree (clock DESC)
Triggers:
    ts_insert_blocker BEFORE INSERT ON history FOR EACH ROW EXECUTE FUNCTION _timescaledb_internal.insert_blocker()
Child tables: _timescaledb_internal._hyper_1_1_chunk
Access method: heap

history テーブルがハイパーテーブルに変換されており、チャンク (Child tables) が1つ存在することがわかります。

ヒストリ・トレンドテーブルデータの保存期間や圧縮に関する詳細設定は Web インターフェースの [管理] -> [一般設定] -> [データの保存期間] ページにて設定できます。

timescaledb.sql スクリプトを実行すると、以下のような設定となります。

「アイテムのヒストリの保存期間設定を上書き」と「アイテムのトレンドの保存期間設定を上書き」にチェックが付いている状態になります。この設定により、ヒストリ・トレンドテーブルにて Housekeeper によるチャンクごとの削除処理が有効になります。また、これらにチェックが入っていると、各アイテムで設定したヒストリとトレンドの保存期間を上書きし、すべてのアイテムで共通のヒストリとトレンドの保存期間を設定できます。

ヒストリとトレンドが圧縮されるまでの期間は「次よりも古いものはレコードを圧縮」にて設定できます。7日以上の値を設定する必要があります。

TimescaleDB 利用上の注意点

本節では、Zabbix で TimescaleDB を利用する際の注意点を記載します。

• TimescaleDB は Zabbix プロキシではサポートされていません。
• パーティション化された Housekeeper 処理を利用する場合は、Zabbix サーバで共通のヒストリ・トレンドの保存期間を使用することになるので、アイテム別にヒストリ・トレンドの保存期間を設定できません。
• TimescaleDB の圧縮を利用するには、以下の条件が前提となります。
  • Zabbix 5.0 以降
  • PostgreSQL 10.2 以降
  • TimescaleDB 1.5 以降
• 圧縮したヒストリ・トレンドテーブルのデータは参照処理 (SELECT) はできますが、更新処理 (INSERT、UPDATE、DELETE) はできません。また、圧縮した ヒストリ・トレンドテーブルのスキーマ変更はできません。
• PostgreSQL から TimescaleDB に移行する場合、既存のヒストリ・トレンドテーブルのデータ量が多ければ多いほど、移行に時間がかかります。データの移行を行う前に、サーバに十分な空き領域があることを確認してください。少なくともヒストリ・トレンドテーブルとインデックスの合計サイズの 1.5 倍の空き領域が必要です。また、移行期間中に、Zabbix サーバと Zabbix フロントエンドを停止する必要があります。

おわりに

今回は、Zabbix サーバのバックエンドデータベースとして時系列データベース TimescaleDB を利用する際のメリットや注意点、インストール手順について紹介しました。

TimescaleDB を導入することによって、Housekeeper による負荷の軽減や書き込み性能の向上、ディスク使用量の削減などのメリットを得られます。

既存の PostgreSQL から容易に移行でき、これまで PostgreSQL で利用していたバックアップ、リストアなどの運用方式は TimescaleDB でも利用できるので、PostgreSQL を利用していて性能やディスク使用量を改善したい場合は、TimescaleDB を使うことを検討してみてはいかがでしょうか。

この記事では、TimescaleDB の備える時系列データ向けの分析機能について紹介します。TimescaleDB の概要やインストール、基本的な使い方については前回の TimescaleDB の紹介 を参照してください。

時系列データの分析関数

TimescaleDB には時系列データの分析に便利な関数がいくつかあります。ここでは、前回生成したデータを使って各関数の概要と使い方について紹介していきます。それには、まず、test データベースに接続しておきます。

$ psql test
psql (13.2)
"help"でヘルプを表示します。

=#

time_bucket 関数

time_bucket 関数は時間を任意の間隔で丸める関数です。同じような関数は PostgreSQL にもあって date_trunc 関数と言います。

date_trunc 関数を使うと、例えば、1 分間隔で収集した温度のデータに対し、1 時間ごとの平均を求められます。

=# SELECT date_trunc('hour', time) AS time_1h,
     location,
     avg(temperature)
   FROM conditions
   GROUP BY time_1h, location
   ORDER BY time_1h, location;
       time_1h       | location |        avg
---------------------+----------+--------------------
 2020-01-30 00:00:00 | nagoya   | 19.883333333333333
 2020-01-30 00:00:00 | osaka    |  20.68333333333333
 2020-01-30 00:00:00 | tokyo    |              20.73
 2020-01-30 01:00:00 | nagoya   |  19.65666666666666
 2020-01-30 01:00:00 | osaka    |              20.82
 2020-01-30 01:00:00 | tokyo    |  20.04000000000001
 2020-01-30 02:00:00 | nagoya   | 18.854999999999993
 2020-01-30 02:00:00 | osaka    |  19.89833333333333
 2020-01-30 02:00:00 | tokyo    | 20.345000000000006
 2020-01-30 03:00:00 | nagoya   | 20.338333333333335
 2020-01-30 03:00:00 | osaka    |             20.395
 2020-01-30 03:00:00 | tokyo    | 20.781666666666673
(省略)

同じことは time_bucket 関数でもできます。

=# SELECT time_bucket('1 hour', time) AS time_1h,
     location,
     avg(temperature)
   FROM conditions
   GROUP BY time_1h, location
   ORDER BY time_1h, location;
       time_1h       | location |        avg
---------------------+----------+--------------------
 2020-01-30 00:00:00 | nagoya   | 19.883333333333333
 2020-01-30 00:00:00 | osaka    |  20.68333333333333
 2020-01-30 00:00:00 | tokyo    |              20.73
 2020-01-30 01:00:00 | nagoya   |  19.65666666666666
 2020-01-30 01:00:00 | osaka    |              20.82
 2020-01-30 01:00:00 | tokyo    |  20.04000000000001
 2020-01-30 02:00:00 | nagoya   | 18.854999999999993
 2020-01-30 02:00:00 | osaka    |  19.89833333333333
 2020-01-30 02:00:00 | tokyo    | 20.345000000000006
 2020-01-30 03:00:00 | nagoya   | 20.338333333333335
 2020-01-30 03:00:00 | osaka    |             20.395
 2020-01-30 03:00:00 | tokyo    | 20.781666666666673
(省略)

date_trunc 関数と time_bucket 関数の違いは、date_trunc 関数が 1 時間や 1 日など、固定の時間でしか丸められないのに対し、time_bucket 関数は 3 時間や 5 日など、任意の時間で丸められることです。time_bucket 関数を使うと、例えば、3 時間ごとの平均を求められます。

=# SELECT time_bucket('3 hours', time) AS time_3h,
     location,
     avg(temperature)
   FROM conditions
   GROUP BY time_3h, location
   ORDER BY time_3h, location;
       time_3h       | location |        avg
---------------------+----------+--------------------
 2020-01-30 00:00:00 | nagoya   |             19.465
 2020-01-30 00:00:00 | osaka    |  20.46722222222223
 2020-01-30 00:00:00 | tokyo    | 20.371666666666673
 2020-01-30 03:00:00 | nagoya   | 20.202777777777776
 2020-01-30 03:00:00 | osaka    |  19.89277777777778
 2020-01-30 03:00:00 | tokyo    | 21.122222222222224
 2020-01-30 06:00:00 | nagoya   |  19.99055555555557
 2020-01-30 06:00:00 | osaka    | 19.288333333333338
 2020-01-30 06:00:00 | tokyo    | 19.353333333333335
 2020-01-30 09:00:00 | nagoya   | 20.950000000000003
 2020-01-30 09:00:00 | osaka    | 20.285000000000007
 2020-01-30 09:00:00 | tokyo    | 20.203333333333326
(省略)

time_bucket_gapfill 関数

time_bucket_gapfill 関数は time_bucket 関数と同じく時間を任意の間隔で丸める関数ですが、欠落したデータを補ってくれることが異なります。

例えば、2020 年 2 月 1 日、東京のデータを削除し、人為的にデータを欠落させ、time_bucket 関数を使って 3 時間ごとの平均を求めると、6 時、9 時のデータが欠落しているのが分かります。

=# DELETE FROM conditions
   WHERE time >= '2020-02-01 06:00:00'
     AND time < '2020-02-01 12:00:00' AND location = 'tokyo';
DELETE 360
=# SELECT time_bucket('3 hours', time) AS time_3h, location, avg(temperature) FROM conditions WHERE time >= '2020-02-01'
     AND time < '2020-02-02'
   GROUP BY time_3h, location
   ORDER BY time_3h, location;
       time_3h       | location |        avg
---------------------+----------+--------------------
 2020-02-01 00:00:00 | nagoya   |  19.75833333333333
 2020-02-01 00:00:00 | osaka    |  20.46555555555556
 2020-02-01 00:00:00 | tokyo    | 19.315555555555555
 2020-02-01 03:00:00 | nagoya   | 19.328888888888887
 2020-02-01 03:00:00 | osaka    | 20.167777777777783
 2020-02-01 03:00:00 | tokyo    | 19.592777777777773
 2020-02-01 06:00:00 | nagoya   |  19.87055555555555
 2020-02-01 06:00:00 | osaka    |  20.07277777777777
 2020-02-01 09:00:00 | nagoya   | 19.240555555555563
 2020-02-01 09:00:00 | osaka    |             19.915
 2020-02-01 12:00:00 | nagoya   | 20.018888888888895
 2020-02-01 12:00:00 | osaka    |  19.66388888888888
 2020-02-01 12:00:00 | tokyo    | 19.437777777777782
 2020-02-01 15:00:00 | nagoya   | 19.904444444444444
 2020-02-01 15:00:00 | osaka    |  20.11388888888888
 2020-02-01 15:00:00 | tokyo    | 19.707222222222217
 2020-02-01 18:00:00 | nagoya   | 20.251111111111115
 2020-02-01 18:00:00 | osaka    | 20.023888888888884
 2020-02-01 18:00:00 | tokyo    | 20.571666666666676
 2020-02-01 21:00:00 | nagoya   |  19.91722222222222
 2020-02-01 21:00:00 | osaka    | 20.952777777777772
 2020-02-01 21:00:00 | tokyo    | 19.904444444444447
(22 行)

それに対し、time_bucket_gapfill 関数を使うと、欠落したデータに NULL が補われるようになります。

=# SELECT time_bucket_gapfill('3 hours', time) AS time_3h,
     location,
     avg(temperature)
   FROM conditions
   WHERE time >= '2020-02-01'
     AND time < '2020-02-02'
   GROUP BY time_3h, location
   ORDER BY time_3h, location;
       time_3h       | location |        avg
---------------------+----------+--------------------
 2020-02-01 00:00:00 | nagoya   |  19.75833333333333
 2020-02-01 00:00:00 | osaka    |  20.46555555555556
 2020-02-01 00:00:00 | tokyo    | 19.315555555555555
 2020-02-01 03:00:00 | nagoya   | 19.328888888888887
 2020-02-01 03:00:00 | osaka    | 20.167777777777783
 2020-02-01 03:00:00 | tokyo    | 19.592777777777773
 2020-02-01 06:00:00 | nagoya   |  19.87055555555555
 2020-02-01 06:00:00 | osaka    |  20.07277777777777
 2020-02-01 06:00:00 | tokyo    |
 2020-02-01 09:00:00 | nagoya   | 19.240555555555563
 2020-02-01 09:00:00 | osaka    |             19.915
 2020-02-01 09:00:00 | tokyo    |
 2020-02-01 12:00:00 | nagoya   | 20.018888888888895
 2020-02-01 12:00:00 | osaka    |  19.66388888888888
 2020-02-01 12:00:00 | tokyo    | 19.437777777777782
 2020-02-01 15:00:00 | nagoya   | 19.904444444444444
 2020-02-01 15:00:00 | osaka    |  20.11388888888888
 2020-02-01 15:00:00 | tokyo    | 19.707222222222217
 2020-02-01 18:00:00 | nagoya   | 20.251111111111115
 2020-02-01 18:00:00 | osaka    | 20.023888888888884
 2020-02-01 18:00:00 | tokyo    | 20.571666666666676
 2020-02-01 21:00:00 | nagoya   |  19.91722222222222
 2020-02-01 21:00:00 | osaka    | 20.952777777777772
 2020-02-01 21:00:00 | tokyo    | 19.904444444444447
(24 行)

time_bucket_gapfill 関数を使う場合には、どこからどこまでデータを補うかを指定するため、時間の範囲を WHERE 句か start、finish 引数で指定する必要があります。指定しないとエラーになります。

(以下、例示のため、実行不要)
=# SELECT time_bucket_gapfill('3 hours', time) AS time_3h,
     location,
     avg(temperature)
   FROM conditions
   GROUP BY time_3h, location
   ORDER BY time_3h, location;
ERROR:  missing time_bucket_gapfill argument: could not infer start from WHERE clause
HINT:  Specify start and finish as arguments or in the WHERE clause.

NULL の代わりに値を補うこともできます。それには、locf または interpolate 関数を使います。

locf (last observation carried forward; 最後に観測された値を繰り越す) 関数を使うと、直前の値がそのまま補われます。ここでは、6 時、9 時には直前の 3 時と同じ 19.592度 (以下、小数点第 4 位以下切り捨て) が補われます。

=# SELECT time_bucket_gapfill('3 hours', time) AS time_3h,
     location,
     locf(avg(temperature))
   FROM conditions
   WHERE time >= '2020-02-01'
     AND time < '2020-02-02'
   GROUP BY time_3h, location
   ORDER BY time_3h, location;
       time_3h       | location |        locf
---------------------+----------+--------------------
 2020-02-01 00:00:00 | nagoya   |  19.75833333333333
 2020-02-01 00:00:00 | osaka    |  20.46555555555556
 2020-02-01 00:00:00 | tokyo    | 19.315555555555555
 2020-02-01 03:00:00 | nagoya   | 19.328888888888887
 2020-02-01 03:00:00 | osaka    | 20.167777777777783
 2020-02-01 03:00:00 | tokyo    | 19.592777777777773
 2020-02-01 06:00:00 | nagoya   |  19.87055555555555
 2020-02-01 06:00:00 | osaka    |  20.07277777777777
 2020-02-01 06:00:00 | tokyo    | 19.592777777777773
 2020-02-01 09:00:00 | nagoya   | 19.240555555555563
 2020-02-01 09:00:00 | osaka    |             19.915
 2020-02-01 09:00:00 | tokyo    | 19.592777777777773
 2020-02-01 12:00:00 | nagoya   | 20.018888888888895
 2020-02-01 12:00:00 | osaka    |  19.66388888888888
 2020-02-01 12:00:00 | tokyo    | 19.437777777777782
 2020-02-01 15:00:00 | nagoya   | 19.904444444444444
 2020-02-01 15:00:00 | osaka    |  20.11388888888888
 2020-02-01 15:00:00 | tokyo    | 19.707222222222217
 2020-02-01 18:00:00 | nagoya   | 20.251111111111115
 2020-02-01 18:00:00 | osaka    | 20.023888888888884
 2020-02-01 18:00:00 | tokyo    | 20.571666666666676
 2020-02-01 21:00:00 | nagoya   |  19.91722222222222
 2020-02-01 21:00:00 | osaka    | 20.952777777777772
 2020-02-01 21:00:00 | tokyo    | 19.904444444444447
(24 行)

interpolate 関数を使うと、直前と直後の値をもとに線形補間によって値が補われます。ここでは、直前の 3 時は 19.592 度、直後の 12 時は19.437 度で、6 時は線形補間によって19.592 + (19.437 – 19.592) / 3 = 19.541 度、9 時も同じように 19.592 + (19.437 – 19.592) × 2 / 3 = 19.489 度が補われます。

=# SELECT time_bucket_gapfill('3 hours', time) AS time_3h,
     location,
     interpolate(avg(temperature))
   FROM conditions
   WHERE time >= '2020-02-01'
     AND time < '2020-02-02'
   GROUP BY time_3h, location
   ORDER BY time_3h, location;
       time_3h       | location |    interpolate
---------------------+----------+--------------------
 2020-02-01 00:00:00 | nagoya   |  19.75833333333333
 2020-02-01 00:00:00 | osaka    |  20.46555555555556
 2020-02-01 00:00:00 | tokyo    | 19.315555555555555
 2020-02-01 03:00:00 | nagoya   | 19.328888888888887
 2020-02-01 03:00:00 | osaka    | 20.167777777777783
 2020-02-01 03:00:00 | tokyo    | 19.592777777777773
 2020-02-01 06:00:00 | nagoya   |  19.87055555555555
 2020-02-01 06:00:00 | osaka    |  20.07277777777777
 2020-02-01 06:00:00 | tokyo    |  19.54111111111111
 2020-02-01 09:00:00 | nagoya   | 19.240555555555563
 2020-02-01 09:00:00 | osaka    |             19.915
 2020-02-01 09:00:00 | tokyo    | 19.489444444444445
 2020-02-01 12:00:00 | nagoya   | 20.018888888888895
 2020-02-01 12:00:00 | osaka    |  19.66388888888888
 2020-02-01 12:00:00 | tokyo    | 19.437777777777782
 2020-02-01 15:00:00 | nagoya   | 19.904444444444444
 2020-02-01 15:00:00 | osaka    |  20.11388888888888
 2020-02-01 15:00:00 | tokyo    | 19.707222222222217
 2020-02-01 18:00:00 | nagoya   | 20.251111111111115
 2020-02-01 18:00:00 | osaka    | 20.023888888888884
 2020-02-01 18:00:00 | tokyo    | 20.571666666666676
 2020-02-01 21:00:00 | nagoya   |  19.91722222222222
 2020-02-01 21:00:00 | osaka    | 20.952777777777772
 2020-02-01 21:00:00 | tokyo    | 19.904444444444447
(24 行)

first、last 関数

first、last 関数は別の列をキーに並び替え、最初、最後の値を取得する集約関数です。時間ごとに平均などでなく、素の値を抜き出すのに使います。並び替えにインデックスは使えないので、実行に時間がかかる場合があります。

例えば、2020 年 3 月 1 日、東京の温度のデータを 3 時間ごとに最初の値を取得してみます。

=# SELECT time_bucket('3 hours', time) AS time_3h,
     first(temperature, time)
   FROM conditions
   WHERE time >= '2020-03-01'
     AND time < '2020-03-02'
     AND location = 'tokyo'
   GROUP BY time_3h
   ORDER BY time_3h;
       time_3h       | first
---------------------+-------
 2020-03-01 00:00:00 |  24.4
 2020-03-01 03:00:00 |  18.9
 2020-03-01 06:00:00 |  25.1
 2020-03-01 09:00:00 |  22.8
 2020-03-01 12:00:00 |  25.8
 2020-03-01 15:00:00 |  23.1
 2020-03-01 18:00:00 |  11.6
 2020-03-01 21:00:00 |  21.3
(8 行)

histogram 関数

histogram 関数はヒストグラムを取得する集約関数です。データの度数分布を確認するのに使います。

例えば、2020 年 3 月 1 日、東京の温度のデータを 3 時間ごとに 12.5 度から 27.5 度まで 2.5 度刻みで 6 つに区切ったヒストグラムを取得してみます。

=# SELECT time_bucket('3 hours', time) AS time_3h,
     histogram(temperature, 12.5, 27.5, 5)
   FROM conditions
   WHERE time >= '2020-03-01'
     AND time < '2020-03-02'
     AND location = 'tokyo'
   GROUP BY time_3h
   ORDER BY time_3h;
       time_3h       |         histogram
---------------------+---------------------------
 2020-03-01 00:00:00 | {23,16,19,21,29,19,27,26}
 2020-03-01 03:00:00 | {21,17,21,25,25,21,29,21}
 2020-03-01 06:00:00 | {20,29,14,25,22,24,27,19}
 2020-03-01 09:00:00 | {17,24,19,27,18,28,28,19}
 2020-03-01 12:00:00 | {20,17,25,22,31,22,21,22}
 2020-03-01 15:00:00 | {28,23,17,29,25,18,18,22}
 2020-03-01 18:00:00 | {23,14,27,18,30,22,25,21}
 2020-03-01 21:00:00 | {20,20,20,32,19,27,25,17}
(8 行)

ヒストグラムは波カッコ {} で囲まれ、カンマ , で区切られた配列として出力されます。配列の各要素が区間内の度数を表します。ここでは、最初の要素が 12.5 度未満、次が 12.5 度以上、15 度未満、その次が 15 度以上、17.5 度未満と続いていき、最後が 27.5 超過のデータの度数になります。

approximate_row_count 関数

approximate_row_count 関数は統計情報を使ってテーブルのおおよその行数を取得する関数です。結果が正確でない代わりに、count 関数に比べて高速に動作します。

\timing コマンドで実行時間を比べると、approximate_row_count 関数が高速なのが分かります。

=# \timing
タイミングは on です。
=# SELECT count(*) FROM conditions;
  count
---------
 1455480
(1 行)

時間: 246.751 ミリ秒
=# SELECT approximate_row_count('conditions');
 approximate_row_count
-----------------------
               1455840
(1 行)

時間: 4.144 ミリ秒

おわりに

今回は、TimescaleDB の分析関数として、時間を任意の間隔で丸める time_bucket 関数や、別の列をキーに並び替え、最初、最後の値を取得する first、last 関数を取り上げ、関数の概要や使い方について紹介しました。関数については TimescaleDB Documentation の API Reference もあわせて参照してください。

次回は、時系列データの自動集計や削除、圧縮の機能について紹介する予定です。

この記事では、TimescaleDB の概要とインストール、基本的な使い方について紹介します。

TimescaleDB とは

TimescaleDB は米国 Timescale 社 が開発する時系列データベースで、ソースコードは GitHub リポジトリ で公開されています。ライセンスは一部が Timescale ライセンス (TSL) で、それ以外は Apache ライセンス 2.0 です。TSL 部分は簡単に言えばそれ自体をサービスとして提供しない限り自由に使えます。ライセンスについて正確には自分で確認してください。

TimescaleDB は PostgreSQL の拡張モジュールとして実装されていて、リレーショナルデータベースと NoSQL の特長をあわせもちます。

• 使いやすさ – SQL に完全対応をしていて、PostgreSQL 用のアプリケーションもそのまま接続でき、時系列データ向けの分析や管理機能も備えています。
• スケーラビリティの高さ – データは適切なサイズに分割して格納され、データ量が増えても安定して高速に書き込みでき、並列処理にも対応しています。
• 信頼性の高さ – 長い歴史をもつ PostgreSQL 上で動作し、レプリケーションやバックアップなど、PostgreSQL の機能はもちろん、PostgreSQL 用のツールも使えます。

TimescaleDB では、データは内部的に時間と空間で分割されたチャンクと呼ばれるテーブルに格納され、ハイパーテーブルを介して透過的にアクセスされます。空間は時間以外にチャンクを分割する条件です。分割方式として 継承によるパーティショニング を採用していて、複数の条件で分割しても階層が多段にならない実装になっています。

TimescaleDB のインストール

TimescaleDB は各プラットフォーム向けのバイナリに加え、Docker イメージや AMI、マネージドサービス Timescale Cloud も提供されています。すべてのインストール方法については TimescaleDB Documentation の Installation を参照してください。

TimescaleDB は 2021 年 6 月時点で以下のバージョンがメンテナンスされていて、それぞれ対応する PostgreSQL のバージョンが異なります。

ここでは、CentOS 8 上の PostgreSQL 13 に Yum を使って TimescaleDB をインストールしていきます。

1. TimescaleDB の Yum リポジトリを登録します。

   $ sudo tee /etc/yum.repos.d/timescale_timescaledb.repo <<EOF
   [timescale_timescaledb]
   name=timescale_timescaledb
   baseurl=https://packagecloud.io/timescale/timescaledb/el/\$releasever/\$basearch
   repo_gpgcheck=1
   gpgcheck=0
   enabled=1
   gpgkey=https://packagecloud.io/timescale/timescaledb/gpgkey
   sslverify=1
   sslcacert=/etc/pki/tls/certs/ca-bundle.crt
   metadata_expire=300
   EOF
   

2. TimescaleDB の RPM パッケージをインストールします。

   $ sudo yum -y install timescaledb-2-postgresql-13
   (省略)
   Installed:
     timescaledb-2-postgresql-13.x86_64 0:2.2.0-0.el8
   
   Dependency Installed:
     timescaledb-2-loader-postgresql-13.x86_64 0:2.2.0-0.el8
     timescaledb-tools.x86_64 0:0.11.0-0.el8
   
   Complete!
   

3. TimescaleDB 向けに PostgreSQL の設定を行います。設定ファイル postgresql.conf を直接編集してもよいですが、ここでは、メモリ量や CPU 数をもとに対話的に設定を行う timescaledb-tune コマンドを使います。

   $ sudo timescaledb-tune --pg-config=/usr/pgsql-13/bin/pg_config
   Using postgresql.conf at this path:
   /var/lib/pgsql/13/data/postgresql.conf
   
   Is this correct? [(y)es/(n)o]: y
   Writing backup to:
   /tmp/timescaledb_tune.backup202105010056
   
   shared_preload_libraries needs to be updated
   Current:
   #shared_preload_libraries = ''
   Recommended:
   shared_preload_libraries = 'timescaledb'
   Is this okay? [(y)es/(n)o]: y
   success: shared_preload_libraries will be updated
   
   Tune memory/parallelism/WAL and other settings? [(y)es/(n)o]: y
   Recommendations based on 465.21 MB of available memory and 1 CPUs for PostgreSQL 13
   
   Memory settings recommendations
   Current:
   shared_buffers = 128MB
   #effective_cache_size = 4GB
   #maintenance_work_mem = 64MB
   #work_mem = 4MB
   Recommended:
   shared_buffers = 119094kB
   effective_cache_size = 357282kB
   maintenance_work_mem = 59547kB
   work_mem = 2977kB
   Is this okay? [(y)es/(s)kip/(q)uit]: y
   success: memory settings will be updated
   
   WAL settings recommendations
   Current:
   #wal_buffers = -1
   min_wal_size = 80MB
   Recommended:
   wal_buffers = 3572kB
   min_wal_size = 512MB
   Is this okay? [(y)es/(s)kip/(q)uit]: y
   success: WAL settings will be updated
   
   Miscellaneous settings recommendations
   Current:
   #default_statistics_target = 100
   #random_page_cost = 4.0
   #checkpoint_completion_target = 0.5
   max_connections = 100
   #max_locks_per_transaction = 64
   #autovacuum_max_workers = 3
   #autovacuum_naptime = 1min
   #effective_io_concurrency = 1
   Recommended:
   default_statistics_target = 500
   random_page_cost = 1.1
   checkpoint_completion_target = 0.9
   max_connections = 20
   max_locks_per_transaction = 64
   autovacuum_max_workers = 10
   autovacuum_naptime = 10
   effective_io_concurrency = 200
   Is this okay? [(y)es/(s)kip/(q)uit]: y
   success: miscellaneous settings will be updated
   Saving changes to: /var/lib/pgsql/13/data/postgresql.conf
   

   --pg-config オプションには pg_config コマンドのパスを指定します。そのほかのオプションは --help オプションで確認できます。実行を開始すると、次々に聞かれる質問に答えていきます。基本的には y を入力していけばよいです。最後に設定がファイルに書き込まれます。

4. 設定を反映するため、PostgreSQL のサービスを再起動します。

   $ sudo systemctl restart postgresql-13
   

5. TimescaleDB の拡張モジュールをデータベースにインストールします。ここでは、PostgreSQL のスーパーユーザ postgres に切り替わり、テスト用に test データベースを作成し、そこにインストールします。

   $ sudo su - postgres
   $ createdb test
   $ psql -c "CREATE EXTENSION timescaledb" test
   WARNING:
   WELCOME TO
    _____ _                               _     ____________
   |_   _(_)                             | |    |  _  \ ___ \
     | |  _ _ __ ___   ___  ___  ___ __ _| | ___| | | | |_/ /
     | | | |  _ ` _ \ / _ \/ __|/ __/ _` | |/ _ \ | | | ___ \
     | | | | | | | | |  __/\__ \ (_| (_| | |  __/ |/ /| |_/ /
     |_| |_|_| |_| |_|\___||___/\___\__,_|_|\___|___/ \____/
                  Running version 2.2.0
   For more information on TimescaleDB, please visit the following links:
   
    1. Getting started: https://docs.timescale.com/getting-started
    2. API reference documentation: https://docs.timescale.com/api
    3. How TimescaleDB is designed: https://docs.timescale.com/introduction/architecture
   
   Note: TimescaleDB collects anonymous reports to better understand and assist our users.
   For more information and how to disable, please see our docs https://docs.timescaledb.com/using-timescaledb/telemetry.
   
   CREATE EXTENSION
   

TimescaleDB の基本的な使い方

ここからは、test データベースに接続し、TimescaleDB の基本的な使い方を確認していきます。

$ psql test
psql (13.2)
"help"でヘルプを表示します。

=#

ハイパーテーブルの作成

ハイパーテーブルを作成するには通常のテーブルを作成し、create_hypertable 関数を実行します。ここでは、時間と場所ごとに温度と湿度を格納する conditions テーブルを作成し、ハイパーテーブルに変換します。

=# CREATE TABLE conditions (
     time timestamp NOT NULL,
     location text NOT NULL,
     temperature double precision,
     humidity double precision
   );
CREATE TABLE
=# SELECT create_hypertable('conditions', 'time');
    create_hypertable
-------------------------
 (1,public,conditions,t)
(1 行)

create_hypertable 関数の引数にはハイパーテーブルに変換するテーブル名、分割の条件にする時間の列名を指定します。戻り値はそれぞれハイパーテーブルの ID、スキーマ名、テーブル名、実際に作成されたかが返されます。

チャンクはデフォルトで 7 日ごとに分割されます。時間列のデータ型はタイムスタンプや日付以外に整数にも対応しています。整数の場合には値が表す時間の大きさが分からないため、チャンクを分割する間隔を chunk_time_interval 引数で指定する必要があります。例えば、時間列が秒を表し、7 日ごとに分割する場合には、7 日 × 24 時間 × 60 分 × 60 秒 = 604,800 を指定します。

(以下、例示のため、実行不要)
=# SELECT create_hypertable('conditions', 'time');
ERROR:  integer dimensions require an explicit interval
=# SELECT create_hypertable('conditions', 'time', chunk_time_interval := 604800);
    create_hypertable
-------------------------
 (1,public,conditions,t)
(1 行)

変換元のテーブルは空でないとエラーになります。migrate_data 引数に true を指定すれば、データを移行することもできます。データ量が多いと時間がかかり、外部キー制約があるとデッドロックが発生する可能性があります。通常はハイパーテーブルの作成後にデータを投入したほうがよいでしょう。

(以下、例示のため、実行不要)
=# SELECT create_hypertable('conditions', 'time');
ERROR:  table "conditions" is not empty
HINT:  You can migrate data by specifying 'migrate_data => true' when calling this function.
=# SELECT create_hypertable('conditions', 'time', migrate_data := true);
NOTICE:  migrating data to chunks
DETAIL:  Migration might take a while depending on the amount of data.
    create_hypertable
-------------------------
 (1,public,conditions,t)
(1 行)

create_hypertable 関数について詳しくは TimescaleDB Documentation の API Reference を参照してください。

時系列データの操作

時系列データの操作はハイパーテーブルを介して通常のデータと同じようにできます。ここでは、まず、データの挿入、検索、更新、削除をしてみます。

=# INSERT INTO conditions
     VALUES ('2021-05-01 09:00:00', 'tokyo', 19.4, 62.0);
INSERT 0 1
=# SELECT * FROM conditions;
        time         | location | temperature | humidity
---------------------+----------+-------------+----------
 2021-05-01 09:00:00 | tokyo    |        19.4 |       62
(1 行)

=# UPDATE conditions
   SET temperature = temperature + 0.1
   WHERE time = '2021-05-01 09:00:00'
     AND location = 'tokyo';
UPDATE 1
=# DELETE FROM conditions
   WHERE time = '2021-05-01 09:00:00'
     AND location = 'tokyo';
DELETE 1

次に、あとで分析に使うデータを生成します。データは 2020 年 1 月 1 日から 1 分間隔で 1 年間、場所は東京、名古屋、大阪の 3 か所、温度は 10 〜 30 度、湿度は 60 〜 90% の範囲でランダムです。これで 55 個のチャンクからなる 1,581,120 行、135MB のデータになります。データの投入後は ANALYZE コマンドで統計情報を更新しておきましょう。

=# INSERT INTO conditions
   SELECT time,
     location,
     round(10 + random()::numeric * (30 - 10), 1) AS temperature,
     round(60 + random()::numeric * (90 - 60), 0) AS humidity
   FROM generate_series('2020-01-01 00:00:00'::timestamp, '2020-12-31 23:59:00', '1 minute') AS time,
     unnest(ARRAY['tokyo', 'nagoya', 'osaka']) AS location;
INSERT 0 1581120
=# ANALYZE;
ANALYZE

チャンクの削除

データの削除は DELETE コマンドでもできますが、それだと不要領域が発生し、回収して再利用可能にするにはバキュームが必要です。それに対して、チャンクごと削除すれば、不要領域が発生せずに済みます。

チャンクを削除するには drop_chunks関数を実行します。ここでは、2021 年 2 月 1 より前のチャンクを削除します。

=# SELECT drop_chunks('conditions', '2020-02-01 00:00:00'::timestamp);
              drop_chunks
----------------------------------------
 _timescaledb_internal._hyper_1_2_chunk
 _timescaledb_internal._hyper_1_3_chunk
 _timescaledb_internal._hyper_1_4_chunk
 _timescaledb_internal._hyper_1_5_chunk
 _timescaledb_internal._hyper_1_6_chunk
(5 行)

drop_chunks 関数の引数にはハイパーテーブルの名前、いつより前のデータしか含まないチャンクを削除するかのタイムスタンプを指定します。戻り値は削除されたチャンクの名前が返されます。

いつより前を削除するかはタイムスタンプや日付、整数以外に間隔にも対応しています。間隔の場合には現在を基準にその間隔より前が削除されます。例えば、現在が 2021 年 5 月 1 日で、間隔が 15 か月の場合には、2020 年 2 月 1 日より前のチャンクが削除されます。

(以下、例示のため、実行不要)
=# SELECT drop_chunks('conditions', '15 months'::interval);
              drop_chunks
----------------------------------------
 _timescaledb_internal._hyper_1_2_chunk
 _timescaledb_internal._hyper_1_3_chunk
 _timescaledb_internal._hyper_1_4_chunk
 _timescaledb_internal._hyper_1_5_chunk
 _timescaledb_internal._hyper_1_6_chunk
(5 行)

drop_chunks 関数について詳しくは TimescaleDB Documentation の API Reference を参照してください。

おわりに

今回は、リレーショナルデータベースと NoSQL の特長をあわせもった時系列データベース TimescaleDB の概要、CentOS 8 上の PostgreSQL 13 への Yum を使ったインストール、ハイパーテーブルの作成や時系列データの操作など、基本的な使い方について紹介しました。

次回は、TimescaleDB の備える時系列データ向けの分析機能について紹介します。