開催概要

プログラム

Pgpool-IIの歩みと進化 ー 基本機能から最新ユースケースまで

Pgpool-IIはオンプレ用途に限らず、クラウド上での運用やマネージドサービスと組み合わせることで、多様なユースケースで活用できます。それらの代表的なケースと導入メリットを解説します。

また近年は、遠隔地での性能改善など、従来構成では顕在化しにくかった新たな要望も増えています。こうしたユーザニーズに対し、Pgpool-IIがどのように機能強化や改善の取り組みを進めているのか、今後の方向性についてもご紹介します。

講師：株式会社SRA OSS 彭 博（Pgpool-II開発者／コミュニティリーダー）

Pgpool-II 4.7 新機能解説

2025年12月にリリースされたPgpool-II 4.7では、性能向上や構成の柔軟性を高めるための改善が複数盛り込まれています。本セッションでは、4.7の主要な追加・改善点を整理しながら解説します。

講師：株式会社SRA OSS 越野 太基（Pgpool-II開発者）

PostgreSQLを運用中、またはPostgreSQLの情報を収集中の方がお近くにいらっしゃいましたら、ぜひお声がけいただき、皆さまにご参加いただけますと幸いです。よろしくお願いいたします。

pg_store_plans は PostgreSQL の実行計画を取得するためのオープンソースソフトウェアで、PostgreSQL の拡張機能として実装されています。
開発元はNTT OSSセンターのDBチームで、pg_hint_plan、pg_bulkload、pg_rman、pg_statsinfo などの著名なソフトウェアを開発しています。

公式サイトはこちらで、ドキュメントは英語版のみ存在します。

pg_store_plans の機能

pg_store_plans は一言で言うと pg_stat_statements と一緒に使用して pg_stat_statements で取得できる情報に実行計画の情報を付加するものです。
pg_store_plans では、実行計画(プラン)は plan 列でわかりますがSQL文本体の情報は無いため、SQL文の情報は pg_store_plans の queryid 列を使って pg_stat_statements の query 列を参照する必要がありますので、本記事では pg_store_plans とあわせて pg_stat_statements も一緒にインストールして検証します。

pg_store_plansビュー

下記に pg_store_plansビューの列を示します。
pg_stat_statements と異なる pg_stat_plans ビュー独自の列は、planid(プランのハッシュコード)、plan(プランそのもの)、first_call(最も過去に呼ばれた時刻)、last_call(最も最近呼ばれた時刻)の4列のみで、その他の列は pg_stat_statements とほぼ同一の名称ですが実際に取得できる情報は、pg_store_plans では該当のプラン(実行計画)が使用された時、pg_stat_statements では該当のクエリが使用された時と違いがあり、後の実行例で違いを説明します。

pg_store_plansビュー定義

pg_store_plans_infoビュー

pg_store_plans モジュール自体の統計は追跡され、pg_store_plans_info というビューを通して利用することができます。 このビューは、1行のみが含まれます。

pg_store_plans_infoビュー定義

主なpg_store_plans関数

pg_store_plans_reset() returns void

pg_store_plans_resetは、pg_store_plansによってこれまでに収集された全ての統計情報を破棄します。デフォルトでは、スーパーユーザのみがこの関数を実行できます。

pg_store_plans サポート対象バージョン

pg_store_plans のバージョン体系は、 PostgreSQL 9.4 から PostgreSQL 11 までの複数のメジャーバージョンをサポート対象とする pg_store_plans 1.3.1 と、メジャーバージョンで導入された新機能に対応するため、単独の独立した PostgreSQL をサポートする pg_store_plans 1.4 以降とに分かれています。一旦リリースされた後はバグ修正のみが実施される PostgreSQL と同様のリリースモデルを採用しています。
pg_store_plans のバージョンとサポート対象の PostgreSQL のバージョンの対応は以下の通りです。

pg_store_plans インストール方法(rpmパッケージ)

pg_store_plans のインストール方法は、大きく分けてソースコードからのインストールと、pg_store_plansのサイトに掲載されている rpm からのインストールがあります。
今回は rpm からのインストールをご紹介します。
下記のインストールの実行例では Rocky Linux release 8.9, PostgreSQL 15.5, pg_store_plans 1.7, pg_stats_statements 1.10 を使用して説明します。
Rocky Linux から直接インターネット接続が可能な環境を使用しています。
PostgreSQL 公式 Yum リポジトリから PostgreSQL 15.5 は contrib も含めて既にインストールとDB初期化が済んでいるものとします。

pg_store_plans のインストール

PostgreSQL 15用の pg_store_plans はこちらからダウンロード可能で、pg_store_plans15-1.7-1.el8.x86_64.rpm
をローカルディスクにダウンロードした後、dnf localinstall で rpm ファイルをインストールします。

# wget https://github.com/ossc-db/pg_store_plans/releases/download/1.7/pg_store_plans15-1.7-1.el8.x86_64.rpm
:(略)
2023-12-25 15:19:00 (70.7 MB/s) - `pg_store_plans15-1.7-1.el8.x86_64.rpm' へ保存完了 [41492/41492]
# dnf localinstall pg_store_plans15-1.7-1.el8.x86_64.rpm
メタデータの期限切れの最終確認: 0:04:20 時間前の 2023年12月25日 15時15分07秒 に実施しました。
依存関係が解決しました。
=========================================================================================================================================
 パッケージ                           アーキテクチャー           バージョン                       リポジトリー                     サイズ
=========================================================================================================================================
インストール:
 pg_store_plans15                     x86_64                     1.7-1.el8                        @commandline                      41 k

トランザクションの概要
=========================================================================================================================================
インストール  1 パッケージ

合計サイズ: 41 k
インストール後のサイズ: 104 k
これでよろしいですか? [y/N]: y
パッケージのダウンロード:
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
トランザクションを実行中
  準備             :                                                                                                                 1/1
  インストール中   : pg_store_plans15-1.7-1.el8.x86_64                                                                               1/1
  scriptletの実行中: pg_store_plans15-1.7-1.el8.x86_64                                                                               1/1
  検証             : pg_store_plans15-1.7-1.el8.x86_64                                                                               1/1

インストール済み:
  pg_store_plans15-1.7-1.el8.x86_64

完了しました!
#

これで pg_store_plans がインストールできました。

postgresql.conf の shared_preload_libraries に pg_store_plans と pg_stat_statements を追加して PostgreSQL を再起動、有効になっていることを確認

shared_preload_libraries に共有ライブラリの pg_store_plans と pg_stat_statements を設定して PostgreSQL を再起動し、pg_store_plans と pg_stat_statements が有効になっていることを確認します。

$ cd $PGDATA
$ vi postgresql.conf
shared_preload_libraries = 'pg_store_plans, pg_stat_statements'
# systemctl restart postgresql-15
$ psql
psql (15.5)
"help"でヘルプを表示します。

postgres=# show shared_preload_libraries;
     shared_preload_libraries
-----------------------------------
 pg_store_plans, pg_stat_statements
(1 行)

CREATE EXTENSION を実行して拡張に登録

検証に使う db1 データベースを作成後 psql で接続して、CREATE EXTENSION を実行します。拡張が登録されていることを確認します。

$ createdb db1
$ psql db1
psql (15.5)
"help"でヘルプを表示します。

db1=# \dx
                    インストール済みの拡張一覧
  名前   | バージョン |  スキーマ  |             説明
---------+------------+------------+------------------------------
 plpgsql | 1.0        | pg_catalog | PL/pgSQL procedural language
(1 行)

db1=# CREATE EXTENSION pg_store_plans;
CREATE EXTENSION
db1=# CREATE EXTENSION pg_stat_statements;
db1=# \dx
                                              インストール済みの拡張一覧
        名前        | バージョン |  スキーマ  |                                  説明
--------------------+------------+------------+------------------------------------------------------------------------
 pg_stat_statements | 1.10       | public     | track planning and execution statistics of all SQL statements executed
 pg_store_plans     | 1.7        | public     | track plan statistics of all SQL statements executed
 plpgsql            | 1.0        | pg_catalog | PL/pgSQL procedural language
(3 行)

db1=# 

これで pg_store_plans と pg_stat_statements のインストールは完了しました。

pg_store_plans と pg_stat_statements で取得可能な情報

pgbench でDB初期化後、60秒間実行した後で、pg_store_plans と pg_stat_statements からのクエリと実行計画に関する情報を全実行時間の降順で並べて検索した例を以下に示します。
全実行時間(total_exec_time)を呼び出し回数(calls)で割れば1実行当たりの実行時間の平均が算出可能です。
このプランを使用した最初の実行時刻(first_call)と直近の実行時刻(last_call)でどの時間帯にどの実行計画が使われていたのかが判別できるので、この情報を定期的に保存しておけば自動ANALYZEにより途中で実行計画が変化してしまった場合に、通常時と悪化時の実行計画の両方が分かると思います。

db1=# \x
拡張表示は on です。
db1=# SELECT ps.query, ps.calls, ps.total_plan_time, ps.total_exec_time, pp.first_call, pp.last_call, pp.plan FROM pg_store_plans pp, pg_stat_statements ps WHERE pp.queryid = ps.queryid ORDER BY ps.total_exec_time DESC;
-[ RECORD 1 ]---+------------------------------------------------------------------------------------------------------------------------
query           | UPDATE pgbench_accounts SET abalance = abalance + $1 WHERE aid = $2
calls           | 26618
total_plan_time | 0
total_exec_time | 1740.1858220000065
first_call      | 2024-01-11 14:29:53.134722+09
last_call       | 2024-01-11 14:30:53.116803+09
planid          | 2057223742
plan            | Update on pgbench_accounts  (cost=0.29..8.31 rows=0 width=0)
                |   ->  Index Scan using pgbench_accounts_pkey on pgbench_accounts  (cost=0.29..8.31 rows=1 width=10)
                |         Index Cond: (aid = 75060)
-[ RECORD 2 ]---+------------------------------------------------------------------------------------------------------------------------
query           | UPDATE pgbench_tellers SET tbalance = tbalance + $1 WHERE tid = $2
calls           | 26618
total_plan_time | 0
total_exec_time | 335.3067220000009
first_call      | 2024-01-11 14:29:53.135509+09
last_call       | 2024-01-11 14:30:53.116962+09
planid          | 3391261630
plan            | Update on pgbench_tellers  (cost=0.00..1.13 rows=0 width=0)
                |   ->  Seq Scan on pgbench_tellers  (cost=0.00..1.13 rows=1 width=10)
                |         Filter: (tid = 2)
-[ RECORD 3 ]---+------------------------------------------------------------------------------------------------------------------------
query           | UPDATE pgbench_branches SET bbalance = bbalance + $1 WHERE bid = $2
calls           | 26618
total_plan_time | 0
total_exec_time | 299.5543750000008
first_call      | 2024-01-11 14:29:53.138592+09
last_call       | 2024-01-11 14:30:53.117044+09
planid          | 1429560889
plan            | Update on pgbench_branches  (cost=0.00..1.01 rows=0 width=0)
                |   ->  Seq Scan on pgbench_branches  (cost=0.00..1.01 rows=1 width=10)
                |         Filter: (bid = 1)

同一のクエリで実行計画が変化した時の実行例

同一のクエリで、複数の実行計画が使用された場合に pg_store_plans で取得できる情報と、pg_stat_statementsで取得できる情報の違いについて説明します。

10000件のtable1テーブルでインデックスが無い状態での検索とtable1_i1_idx インデックスを付加した状態での検索を実施してみます。
テーブルを作成してデータを挿入した段階で、pg_store_plans_reset() 関数とpg_stat_statements_reset() 関数で pg_store_plans と pg_stat_statements の統計情報をリセットしています。

db1=# CREATE TABLE table1 (i1 integer, t1 text);
CREATE TABLE
db1=# INSERT INTO table1 SELECT i, LEFT(MD5(i::text), 8) FROM generate_series(1,10000) as i;
INSERT 0 10000
db1=# SELECT pg_store_plans_reset();
 pg_store_plans_reset
----------------------

(1 行)

db1=# SELECT pg_stat_statements_reset();
 pg_stat_statements_reset
--------------------------

(1 行)

db1=# SELECT * FROM pg_store_plans_info;
 dealloc |          stats_reset
---------+-------------------------------
       0 | 2024-01-14 17:58:06.074107+09
(1 行)

db1=# SELECT * FROM pg_stat_statements_info;
 dealloc |         stats_reset
---------+------------------------------
       0 | 2024-01-14 17:58:10.57708+09
(1 行)

まず、インデックスが無い状態で検索しますので、Seq Scanの検索になります。その後、インデックスを付加した状態で検索しますので、Index Scanの検索になります。

db1=# SELECT * FROM table1 WHERE i1 = 1;
 i1 |    t1
----+----------
  1 | c4ca4238
(1 行)

db1=# CREATE INDEX table1_i1_idx ON table1 (i1);
CREATE INDEX
db1=# SELECT * FROM table1 WHERE i1 = 1;
 i1 |    t1
----+----------
  1 | c4ca4238
(1 行)

行数が多いので見やすくするために拡張表示をonにして、該当の検索のみを抽出します。また、pg_store_plans の列には先頭に p_ 、pg_stat_statements の列には先頭に s_ を付けて区別しやすくします。

db1=# \x
拡張表示は on です。
db1=# SELECT ps.query as s_query, pp.calls as p_calls, pp.total_time as p_total_time, ps.calls as s_calls, ps.total_plan_time s_total_plan_time, ps.total_exec_time as s_total_exec_time, pp.first_call as p_first_call, pp.last_call as p_last_call, pp.planid as p_planid, pp.plan as p_plan FROM pg_store_plans pp, pg_stat_statements ps WHERE pp.queryid = ps.queryid AND query LIKE 'SELECT * FROM table1%' ORDER BY ps.total_exec_time DESC;
-[ RECORD 1 ]-----+----------------------------------------------------------------------------
s_query           | SELECT * FROM table1 WHERE i1 = $1
p_calls           | 1
p_total_time      | 0.06921400000000001
s_calls           | 2
s_total_plan_time | 0
s_total_exec_time | 0.602927
p_first_call      | 2024-01-14 17:59:18.511485+09
p_last_call       | 2024-01-14 17:59:18.511485+09
p_planid          | 1345757884
p_plan            | Index Scan using table1_i1_idx on table1  (cost=0.29..8.30 rows=1 width=13)+
                  |   Index Cond: (i1 = 1)
-[ RECORD 2 ]-----+----------------------------------------------------------------------------
s_query           | SELECT * FROM table1 WHERE i1 = $1
p_calls           | 1
p_total_time      | 0.533713
s_calls           | 2
s_total_plan_time | 0
s_total_exec_time | 0.602927
p_first_call      | 2024-01-14 17:59:03.762229+09
p_last_call       | 2024-01-14 17:59:03.762229+09
p_planid          | 828508567
p_plan            | Seq Scan on table1  (cost=0.00..180.00 rows=1 width=13)                    +
                  |   Filter: (i1 = 1)

db1=#

pg_store_plans での calls(p_calls) と total_time(p_total_time )は該当の実行計画 (planid, plan) が使われた回数(1回ずつ)とその実行時間、pg_stat_statmentsでの calls(s_calls) と total_exec_time(s_total_exec_time )は(実行計画に関係無く)該当のクエリのすべての実行回数とすべての実行時間になるので、同じ calls でも取得される情報が異なることが分かります。
また、first_call と last_call を見比べると、Seq Scan は 17:59:03、Index Scan は 17:59:18 になっていますので、Seq Scan の後に Index Scan が実行されたことが分かります。この first_call と last_call で該当の実行計画がいつ実行されたのかが分かります。

まとめ

pg_store_plans を pg_stat_statements と一緒に使った時に取得できる情報について説明しました。pg_stat_statements 単独だとクエリの実行回数と実行時間は取得できますが、pg_store_plans を一緒に使うことで、クエリの実行計画とその実行計画で実行された実行時間も分かりますので、遅延が発生した時の実行計画を調査するために有用な機能だと思います。

pgvectorのインストールとセットアップ

PostgreSQLにpgvectorをインストールします。OSはRocky Linux release 9.6、PostgreSQLは公式リポジトリからインストールしたバージョン16.1を使います。PostgreSQLを動作させるPATH等の環境変数は設定済みで、すでにPostgreSQLインスタンスは起動済みとします。

pgvectorはPostgreSQLの公式リポジトリ経由でPostgreSQL 16用のpgvector_16をパッケージからインストールします。

# dnf install pgvector_16

続けて、testデータベースにpgvectorを登録します。

$ psql -U postgres -d test
psql (16.1)
Type "help" for help.

test=# CREATE EXTENSION vector;
CREATE EXTENSION
test=# \dx
                             List of installed extensions
  Name   | Version |   Schema   |                     Description
---------+---------+------------+------------------------------------------------------
 plpgsql | 1.0     | pg_catalog | PL/pgSQL procedural language
 vector  | 0.5.1   | public     | vector data type and ivfflat and hnsw access methods

ベクトル列の作成とベクトルデータの挿入

ベクトルデータを格納する列を作成します。pgvectorを登録すると、vector型が使えます。

test=# CREATE TABLE items (id bigserial PRIMARY KEY, embedding vector(3));

vector(3)は3次元のベクトル、つまり、ベクトル空間を形成する基底ベクトルの個数が3つであることを意味します。ここでは3次元に指定していますが、最大で16000次元まで指定できます。
異なる次元のベクトルを同じ列に保存したい場合は（vector(3)ではなく）vectorを使用できます。ただしその場合、式に対するインデックスや部分インデックスを使って同じ次元数の行にしかインデックスを作成できません。

また、vector型の各要素はPostgreSQLのreal型と同様の単精度浮動小数点数で格納されます。より高精度のベクトルデータ格納したい場合は、vector型ではなく、double precision[]やnumeric[]型が使えます。ただし、高精度の値を格納はできますが、pgvectorが提供する機能を使う場合はvector型にキャストする必要があり、格納したデータの検索時に精度値が喪失します。

test=# CREATE TABLE items2 (id bigserial PRIMARY KEY, embedding double precision[]);

データがvector型に変換可能であり、かつ、想定の次元数であることを保証するためにチェック制約を追加してもよいでしょう。

test=# ALTER TABLE items2 ADD CHECK (vector_dims(embedding::vector) = 3);

次に、作成した列にベクトルデータを挿入します。vector型は以下のようにARRAYキーワードを使った配列や、[要素1,要素2,…]といった典型的な配列を表す文字列定数を解釈できます。
なお、vector型ではなく、double precision[]やnumeric[]型を定義した場合は、ベクトルデータをPostgreSQLの配列リテラル定数で格納できます。

test=# INSERT INTO items (embedding)
SELECT
  ARRAY[
  random() * 1000, -- 最初の次元のランダム値
  random() * 1000, -- 二番目の次元のランダム値
  random() * 1000  -- 三番目の次元のランダム値
]
FROM
  generate_series(1 , 10000);

itemsテーブルに、乱数を使った3次元のベクトルデータを10000行挿入しました。

test=# SELECT * FROM items LIMIT 5;
 id |            embedding
----+---------------------------------
  1 | [747.1946,30.812382,226.11743]
  2 | [389.10852,188.70128,151.08716]
  3 | [176.6698,954.8121,233.49654]
  4 | [295.3235,539.09283,721.9699]
  5 | [786.6494,895.81323,160.88304]
(5 rows)

最近傍検索の実行

最近傍検索を実行して、特定のベクトルに最も近いデータのトップ3を検索します。

test=# SELECT * FROM items ORDER BY embedding <#> '[10.0, 2, 0.3]' LIMIT 3;
  id  |            embedding
------+---------------------------------
 7945 | [998.16565,992.58215,926.16675]
 4633 | [996.8208,985.77405,989.8139]
 3345 | [997.30383,966.3805,949.19257]
(3 rows)

<#>演算子はベクトル間の負の内積を表す演算子です。似ているベクトルデータほど小さい数値となります。これは<#>演算子が昇順のインデックススキャンのみに対応しているためです。昇順ソートで最近似のベクトルデータをインデックスを効かせて取り出せます。

提供される演算子と関数

pgvectorは2つのベクトルの乗算、減算、乗算、ユークリッド距離、内積、コサイン距離等の演算子が用意されています。

同様の機能を持った関数もあります。

また、avg(vector) および sum(vector) でベクトルデータの平均と合計を算出する集約関数もあります。

ベクトルデータのインデックス

デフォルトのpgvectorは最近傍検索を行うので、リコール率（近傍アイテムを取りこぼさない確率）は100%ですが、線形探索のために速度が問題になる場合があります。
そのため、pgvectorには近似最近傍検索を用いた、IVFFlatとHNSWの2種類のインデックスが追加できます。ただし、正確な最近傍検索でないので高速にデータを取得できますが、実行時間・メモリ・精度のトレードオフが発生します。

IVFFlatはHNSWよりもインデックス構築時間は短く、メモリ使用量は少ないですが、ベクトルデータがある程度テーブルに格納されていないとインデックスが構築できません。また、速度とリコールのトレードオフが大きく、速度を重視するとリコールが下がりやすくなり、データの取りこぼしが発生しやすくなります。
一方、HNSWはIVFFlatよりもインデックス構築時間は長く、メモリ使用量は多くなりますが、テーブルにトレーニングデータを格納しておく必要はありません。また、速度とリコールのトレードオフが少なく、速度を重視してもリコール率の低下が見られず、両者のバランスが取れています。

また、2000次元以上のベクトルをインデックス化することはpgvector 0.5.1時点ではできません。ベクトルデータを次元削減して対応する必要があります。

ここではHNSWインデックスを構築します。

HNSWインデックス

インデックスの構築はCREATE INDEX文で行います。
利用できる演算子クラスは以下です。

演算子クラス説明vector_cosine_opsコサイン距離vector_ip_ops内積vector_l2_opsユークリッド距離

たとえば、以下でitemsテーブルのembedding列にコサイン距離に基づくHNSWインデックスを構築します。

test=# CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops);

HNSWインデックのスオプション

CREATE INDEX文にWITH句を加えてHNSWインデクスのインデックスパラメータを指定できます。

パラメータ説明m層ごとの最大接続数（デフォルトは16）ef_constructionグラフ構築用の動的候補リストのサイズ（デフォルトは64）

test=# CREATE INDEX ON items USING hnsw (embedding vector_l2_ops) WITH (m = 16, ef_construction = 64);

m、ef_constructionの値が高いほど、インデックスの構築時間、挿入速度を犠牲にしてリコールが向上します。また、ef_constructionはm*2未満だとエラーとなります。

HNSWインデックのクエリオプション

SET文で検索用の動的候補リストのサイズを指定します。デフォルトは40です。

SET hnsw.ef_search = 100;

高い値はリコールを向上させますが、速度を犠牲にします。

トランザクション内でSET LOCALを使用して、単一のクエリに設定します。

test=# BEGIN;
test=# SET LOCAL hnsw.ef_search = 100;
test=# SELECT ...
test=# COMMIT;

HNSWインデックのス作成進行状況

PostgreSQL 12以上であればインデックス作成の進行状況を、たとえば以下のSQL文で、インデックスを作成中のバックエンド毎に確認できます。

test=# SELECT phase, round(100.0 * blocks_done / nullif(blocks_total, 0), 1) AS "%" FROM pg_stat_progress_create_index;

HNSWインデックスの場合、pg_stat_progress_create_indexのphase列はinitializing（初期化中）またはloading tuples（タプルの読み込み中）が表示されます。

終わりに

pgvectorは、PostgreSQLの拡張機能としてベクトルデータの効率的な管理と類似性検索を可能にします。この記事では、pgvectorのインストールから設定、ベクトルデータの操作方法、最近傍検索の実行、さらにはインデックスの構築と最適化について解説しました。
pgvectorは近年目覚ましい技術発展を遂げている、大規模言語モデルによる文書生成にも利用可能です。大量のテキストデータに含まれるパターンや構造をベクトルデータとして抽出し、それを効率的に検索・分析することで文書の自動生成において重要な役割を果たします。
データベース技術やAI分野に関心がある方は、ぜひpgvectorを使ってみてください

はじめに

PostgreSQLは広く使用されているオープンソース・ソフトウェアのRDBMSです。SRA OSS LLC ではPostgreSQLに関するサポートやコンサルティングのサービスを提供する一方、技術開発室という部署ではPostgreSQL開発コミュニティへの貢献やPostgreSQLに関する研究開発といった活動を行っています。本稿ではその中から「増分ビューメンテナンス（Incremental View Maintenance, IVM）」と呼ばれる機能の実装について紹介します。これは一言で言うならば、マテリアライズド・ビューの最新化を高速に行う技術です。

マテリアライズド・ビュー

マテリアライズド・ビューとは、そのビューを定義するSQLクエリ（SELECT 文）の実行結果をデータベース内に保存しているようなビューです。PostgreSQL では例えば以下のようなコマンドでマテリアライズド・ビューを作成することができます。

CREATE MATERIALIZED VIEW myview AS
 SELECT * FROM weather JOIN cities ON city = name;

通常のビューはアクセスされる度に定義クエリの実行を行いますが、マテリアライズド・ビューへのアクセスは保存されている実行結果をクライアントに返すだけなので高速な応答が可能です。その一方で、ビュー定義に使われているテーブルが更新された場合にはマテリアライズド・ビューの内容は古くなり、実際にビュー定義クエリを実行した結果と一致しなくなってしまいます。そのため、テーブルが更新された後にはマテリアライズド・ビューの内容を最新の状態に更新する必要が出てきます。この操作はビューのメンテナンスと呼ばれています。

増分ビューメンテナンスとは

ビューをメンテナンスする最も単純な方法は、マテリアライズド・ビューの内容を「再計算」することです。例えば、PostgreSQLでは以下のコマンドを実行するとビュー定義クエリを再実行し、その結果でマテリアライズド・ビューの古い内容を置き換えることができます。

REFRESH MATERIALIZED VIEW myview;

しかし、この方法ではマテリアライズド・ビューの全てのデータを再生成することになるため、あまり効率的とは言えません。テーブルの更新がごく一部の場合には、マテリアライズド・ビューの全体ではなく一部分を更新するだけで最新の状態を実現した方が効率がよいはずです。このようなビューのメンテンスの方法は、「増分ビューメンテナンス（Incremental View Maintenance, IVM）」と呼ばれています。

PostgreSQLにおける増分ビューメンテンス機能の実装

増分ビューメンテナンス機能は強力な機能ですが、現在のPostgreSQLには実装されていません。そこで、著者らはPostgreSQLにこの機能を実装して開発コミュニティに提案しているところです。

この提案中の機能を使うと、増分メンテナンス可能なマテリアライズド・ビュー（Incrementally Maintainable Materialized View, IMMVと呼んでいます）を作成することができます。このように作られたマテリアライズド・ビューの内容は、テーブルが更新される度に自動的に増分メンテナンスされるため、常に最新のテーブルの内容を反映した状態になっています。実際のビューのメンテナンスにかかる時間はビュー定義やテーブル更新の内容にもよりますが、例えば REFRESH MATERIALIZED VIEW コマンドの実行に20秒程要したビューが、増分メンテナンスを使った場合にはテーブルの更新時間込みで15ミリ秒程度で最新化できます。

PostgreSQLへの増分ビューメンテナンス機能の提案はpgsql-hackers[1]というメーリングリストで議論中です。ここで行われる設計や実装の議論やバグの報告などを通してコードの修正や改善を進めています。現在提案中の機能では、結合と一部の組み込み集約関数（count, sum, avg, min, max）を含むSELECT文がビュー定義の中で使用可能です。コードの修正量が大きくなりすぎないよう現在の提案には含めてはいませんが、外部結合やサブクエリへの対応についても実装済です。また、これらの成果はPostgreSQLコミュニティの海外カンファレンス[2][3][4][5][6]および国内の学会発表[7][8]でも報告しています。

pg_ivm: PostgreSQLに増分ビューメンテナンス機能を提供する拡張モジュール

前節ではPostgreSQL本体の新機能として増分ビューメンテナンス機能を提案していることを紹介しましたが、提案の過程で「増分ビューメンテナンス機能を既存のPostgreSQLでも使用したい」という要望を受けることがありました。そこで、この機能をリリース済のPostgreSQLでも使用できるように拡張モジュールとして開発したのがpg_ivm[9]です。現状では、PostgreSQL 13, 14, そして最新の 15 に対応しています。

pg_ivmはさらに、PostgreSQLにおける増分ビューメンテナンス機能に対するフィードバックや認知を得る機会の向上、および、PostgreSQL本体への提案には含まれていない追加的な機能の提供も目的としています。実際に、最新のpg_ivm 1.3では本体に提案している機能では対応していないサブクエリに部分的に対応しています。

pg_ivmの使用例

pg_ivmはGitHubレポジトリ[9]からソースコードを入手してインストールすることもできますし、PostgreSQLコミュニティで提供されているレポジトリ[10]で提供されているrpmファイルを利用してyumやdnfコマンドでインストールすることもできます。

PostgreSQLでpg_ivmを有効にするにはまず CREATE EXTENSION コマンドを実行します。

CREATE EXTENSION pg_ivm;

pg_ivmで増分メンテナンス可能なマテリアライズド・ビューを作成するには、create_immvという関数を実行します。これは CREATE MATERIALIZED VIEW コマンドに相当する関数で、第1引数にビューの名前と列のリスト、第2引数にビューの定義を指定します。実行結果として生成されたビューの行数（以下の例では10,000,000行）が返されます。

test=# SELECT create_immv('mv(aid, bid, abalance, bbalance)',
                          'SELECT a.aid, b.bid, a.abalance, b.bbalance
                           FROM pgbench_accounts a JOIN pgbench_branches b USING(bid)');
NOTICE: created index "mv_index" on immv "mv"
 create_mv
-------------
   10000000
(1 row)

このビューの定義で使われているテーブルの1行を更新してみます。著者の環境では、その所要時間は 15.448 ミリ秒でした。その後にビューの内容を確認してみると、更新されたテーブルの内容が反映されていることがわかります。これと同じ定義の通常のマテリアライズド・ビューを作成して REFRESH MATERIALIZED VIEW コマンドを実行した場合には20秒以上かかりました。これと比較すると、今回の例では増分メンテナンスが効果的に働いていることがわかると思います。

test=# UPDATE pgbench_accounts SET abalance = 1234 WHERE aid = 1;
UPDATE 1
Time: 15.448 mstoeic "ubuntu" ip windows
test=# SELECT * FROM mv WHERE aid = 1;
 aid | bid | abalance | bbalance
-----+-----+----------+----------
   1 |    1 |    1234 |        0
(1 row)

pg_ivm の性能

増分メンテナンスの性能を示す別の例として、業界標準のベンチマークである TPC-H のクエリを用いた性能評価を紹介します。TPC-H のクエリの１つ Q01 は１つの巨大なテーブルに対する集約です。

select
    l_returnflag,
    l_linestatus,
    sum(l_quantity) as sum_qty,
    sum(l_extendedprice) as sum_base_price,
    sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
    sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as
    sum_charge,
    avg(l_quantity) as avg_qty,
    avg(l_extendedprice) as avg_price,
    avg(l_discount) as avg_disc,
    count(*) as count_order
from
    lineitem
where
    l_shipdate <= date '1998-12-01' - interval '78' day
group by
    l_returnflag,
    l_linestatus;

このクエリで定義される通常のマテリアライズド・ビューを REFRESH MATERIALIZED VIEW コマンドで最新化した場合、筆者の環境では10秒以上かかりました。なお、TPC-Hのスケールファクタ は 1（lineitem テーブルの行数は600万行程度）を使用しました。一方、pg_ivmを使って増分メンテナンス可能なマテリアライズドビューを作って、lineitem テーブルを１行更新した場合の所要時間は20ミリ秒程度でした。

別のクエリ Q09 は6つのテーブルを結合して集約したクエリです。

select
    nation,
    o_year,
    sum(amount) as sum_profit
from
    (
    select
        n_name as nation,
        extract(year from o_orderdate) as o_year,
        l_extendedprice * (1 - l_discount) - ps_supplycost * l_quantity as amount
    from
        part, supplier, lineitem, partsupp, orders, nation
    where
        s_suppkey = l_suppkey
        and ps_suppkey = l_suppkey
        and ps_partkey = l_partkey
        and p_partkey = l_partkey
        and o_orderkey = l_orderkey
        and s_nationkey = n_nationkey
        and p_name like ''%sandy%''
    ) as profit
group by
    nation,
    o_year;

このクエリの場合、通常のマテリアライズド・ビューの REFRESH MATERIALIZED VIEW コマンド実行は3秒程度かかりましたが、pg_ivmを使用した場合の lineitem テーブルの１行更新の所要時間は45ミリ秒程度でした。

以上のように、増分メンテナンスに要する時間はビュー定義など状況によって異なりますが、増分メンテナンスが REFRESH MATERIALIZED VIEW によるクエリの再実行より効果的であることがわかります。

一方で、現在の機能ではテーブルの更新の度にビューのメンテナンスが発生するため、テーブル更新の性能にはオーバヘッドがあります。実際に上の例では、増分ビューメンテナンス機能を使用しない場合は lineitem の１行更新は10ミリ秒ほどで完了していますが、増分ビューメンテナンスを行う場合にはQ01の場合で20ミリ秒、Q09の場合で45ミリ秒とかかっています。その他にも、データ不整合の発生を防止するため、複数トランザクションが同時にビューをメンテナンスしようとする場合には排他処理を行うなど、同時実行性能にも影響があります。これらの性質から、PostgreSQLに現在提案中の増分ビューメンテナンス機能、および pg_ivmは「テーブル更新頻度は低いが、更新があった際にはすぐに最新のクエリ結果が欲しい」という状況に有用なものと言えます。

pg_ivmについては先月開催された PostgreSQL Conference Japan 2022 でも紹介しました[11]。講演資料も公開されていますのでぜひ参照してください。

今後の予定

PostgreSQL本体への増分ビューメンテナンス実装は開発コミュニティに提案中の機能です。PostgreSQLへの機能追加はコミュニティでの議論を経てコンセンサスを得る必要があるため時間がかかるのですが、これからも引き続き本体への採用を目指して議論と改善を重ねていきます。

pg_ivmはこれまでに何回かのリリースで、ビュー定義として対応できるクエリの種類の拡充やバグ修正を行ってきました。今後も引き続きEXISTSサブクエリ、CTE（WITH句）、外部結合といったクエリに対応していくと共に、バグ修正などの改善を続けていきます。また、さらに進んだ機能も追加していきたいと考えており、その中の１つが「遅延メンテナンス」です。現在の提供しているのはビューのメンテナンスをテーブルの更新と同時に行う「即時メンテナンス」のみであるため、テーブルの更新性能への影響が目立ちます。これに対して遅延メンテナンスはテーブル更新とは別のタイミング（コマンドの実行や、バックグラウンドによる定期処理など）で増分ビューメンテナンスを行う方法で、テーブル更新性能への影響を抑えられることが期待されます。その他にも性能全般の改善やパーティション・テーブルなどの特殊なテーブルへの対応なども考えています。

おわりに

本稿ではPostgreSQLにおける増分ビューメンテナンス機能の提案と、拡張モジュールpg_ivmについて紹介しました。pg_ivmはGitHubレポジトリ[9]、PostgreSQL Yum レポジトリ[10]から入手可能な他、最近販売開始されましたPowerGres Plus V13[12]に同梱されています。Linux版の提供はもちろん、Windows版にも Windows で使用可能なビルド済バイナリが含まれています。評価版もありますので、是非試してみてください。

また、本プロジェクトはオープンソースプロジェクトです。開発コミュニティでの議論はもちろん、GitHub への Issue, Pull Request の投稿なども大歓迎ですので、何かしらのフィードバックを寄せて頂けましたら幸いです。

参考文献・リンク等

[1] pgsql-hackers: https://www.postgresql.org/list/pgsql-hackers/

[2] Yugo Nagata, “Toward Implementing Incremental View Maintenance on PostgreSQL”, PGCon 2019.

[3] Yugo Nagata, “Toward Implementing Incremental View Maintenance on PostgreSQL”, PGConf.Asia 2019.

[4] Yugo Nagata, Takuma Hoshiai, “The Way for Updating Materialized Views Rapidly”, PGCon 2020.

[5] Yugo Nagata, “The Way for Updating Materialized Views Rapidly”, PostgresConf.CN & PGConf.Asia 2020.

[6] Yugo Nagata, “Updating Materialized Views Automatically and Incrementally”, PGConf.Online 2021/PGConf.Russia 2021.

[7] 長田悠吾, 星合拓馬, 石井達夫, 増永良文, “タプル重複のもとで外部結合および準結合を含むビューの増分メンテナンスとそのPostgreSQL への実装,” 第 12 回データ工学と情報マネジメントに関するフォーラム (DEIM Forum), 2020.

[8] 長田悠吾, 星合拓馬, 石井達夫, 三島健, 増永良文, “PostgreSQL におけるビューの増分メンテナンス機能の実装とその評価,” 第 13 回データ工学と情報マネジメントに関するフォーラム (DEIM Forum), 2021.

[9] pg_ivm: https://github.com/sraoss/pg_ivm

[10] PostgreSQL Yum Repository: https://yum.postgresql.org/

[11] 長田悠吾, “pg_ivm: マテリアライズドビューを高速に更新するための PostgreSQL 拡張モジュール”, PostgreSQL Conference Japan 2022. (https://www.postgresql.jp/jpug-pgcon2022#A3)

[12] PowerGres Plus V13: https://powergres.sraoss.co.jp/product/plusv13/

pgAudit Log to File とは

pgAudit Log to File とは PostgreSQL で監査ログを取得して PostgreSQL ログファイルに書き出す pgAudit のアドオンで、監査ログ専用ファイルを PostgreSQL ログファイルとは別の独立したファイルに分離して書き出してくれるソフトウェアです。

公式サイトはこちらです。分かりやすいドキュメント(README.md)とともに公開されています。

pgAudit のブログ記事はこちらになります。

pgAudit Log to File サポート対象バージョン

pgAudit Log to File がサポートする PostgreSQL / pgAudit のバージョンは特にドキュメントに記載はありませんので、使用する時点の最新バージョンを使用すればよいと思います。

現時点(2022年11月2日)の GitHub での最新バージョンは v1.5.8 で、GitHubのリリースページからダウンロード可能です。
また、PostgreSQL 公式リポジトリでは pgAudit Log to File が pgauditlogtofile_<PostgreSQLメジャーバージョン> というファイル名で rpm ファイルが配布されており、PostgreSQL 10,11,12,13,14,15 用バージョンが v1.5.6 となっています。

pgAudit Log to File インストール方法(rpmパッケージ)

pgAudit Log to File のインストール方法は、大きく分けてソースコードからのインストールと、PostgreSQL公式リポジトリの rpm からのインストールがあります。
今回は rpm からのインストールをご紹介します。
下記のインストールの実行例では Rocky Linux release 8.6, PostgreSQL 14.5, pgAudit v1.6.2, pgAudit Log to File v1.5.6 を使用して説明します。
Rocky Linux から直接インターネット接続が可能な環境を使用しています。

Rocky Linux に PostgreSQL 公式 Yum リポジトリを設定し、PostgreSQL 14をインストール

Rocky Linux から PostgreSQL 公式 Yum リポジトリのパッケージを dnf でインストール可能とするために repo ファイルを導入します。
PostgreSQL ダウンロードページの Packages and Installers で Linux と Red Hat/Rocky/CentOS を選択するとこのページが表示されます。PostgreSQL Yum Repository で使用する PostgreSQL バージョン(14)と OS のバージョン(Red Hat Enterprise, Rocky, or Oracle version 8)と CPU アーキテクチャ(x86_64)を選択すれば、repo ファイルを導入して PostgreSQL サーバを導入後有効にして起動するコマンドが表示されます。
表示されたコマンドを参考にして、まず repo ファイルを導入します。

# dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm
：
依存関係が解決しました。
================================================================================
パッケージ Arch バージョン リポジトリー サイズ
================================================================================
インストール:
pgdg-redhat-repo noarch 42.0-28 @commandline 13 k

トランザクションの概要
================================================================================
インストール 1 パッケージ

合計サイズ: 13 k
インストール後のサイズ: 14 k
パッケージのダウンロード:
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
トランザクションを実行中
準備 : 1/1
インストール中 : pgdg-redhat-repo-42.0-28.noarch 1/1
検証 : pgdg-redhat-repo-42.0-28.noarch 1/1

インストール済み:
pgdg-redhat-repo-42.0-28.noarch

完了しました!
#

次に、PostgreSQL公式サイトの PostgreSQL が導入できるように OS 組み込みの PostgreSQL を無効にします。これを実行しないと PostgreSQL 公式サイトの PostgreSQL が見つからないと言われてしまいます。

# dnf install -y postgresql14-server
すべての検出結果は引数のモジュラーフィルタリングに一致しません (filter out): postgresql14-server
エラー: 一致するものが見つかりません: postgresql14-server
#
# dnf -qy module disable postgresql
# dnf install -y postgresql14-server
依存関係が解決しました。
================================================================================
パッケージ Arch バージョン Repo サイズ
================================================================================
インストール:
postgresql14-server x86_64 14.5-1PGDG.rhel8 pgdg14 5.7 M
依存関係のインストール:
postgresql14 x86_64 14.5-1PGDG.rhel8 pgdg14 1.5 M
postgresql14-libs x86_64 14.5-1PGDG.rhel8 pgdg14 278 k

トランザクションの概要
================================================================================
インストール 3 パッケージ

ダウンロードサイズの合計: 7.5 M
インストール後のサイズ: 31 M
パッケージのダウンロード:
(1/3): postgresql14-libs-14.5-1PGDG.rhel8.x86_6 113 kB/s | 278 kB 00:02
(2/3): postgresql14-14.5-1PGDG.rhel8.x86_64.rpm 307 kB/s | 1.5 MB 00:05
(3/3): postgresql14-server-14.5-1PGDG.rhel8.x86 196 kB/s | 5.7 MB 00:29
--------------------------------------------------------------------------------
合計 258 kB/s | 7.5 MB 00:29
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
トランザクションを実行中
準備 : 1/1
インストール中 : postgresql14-libs-14.5-1PGDG.rhel8.x86_64 1/3
scriptletの実行中: postgresql14-libs-14.5-1PGDG.rhel8.x86_64 1/3
インストール中 : postgresql14-14.5-1PGDG.rhel8.x86_64 2/3
scriptletの実行中: postgresql14-14.5-1PGDG.rhel8.x86_64 2/3
scriptletの実行中: postgresql14-server-14.5-1PGDG.rhel8.x86_64 3/3
インストール中 : postgresql14-server-14.5-1PGDG.rhel8.x86_64 3/3
scriptletの実行中: postgresql14-server-14.5-1PGDG.rhel8.x86_64 3/3
検証 : postgresql14-14.5-1PGDG.rhel8.x86_64 1/3
検証 : postgresql14-libs-14.5-1PGDG.rhel8.x86_64 2/3
検証 : postgresql14-server-14.5-1PGDG.rhel8.x86_64 3/3

インストール済み:
postgresql14-14.5-1PGDG.rhel8.x86_64
postgresql14-libs-14.5-1PGDG.rhel8.x86_64
postgresql14-server-14.5-1PGDG.rhel8.x86_64

完了しました!
# dnf install -y postgresql14-contrib
依存関係が解決しました。
================================================================================
パッケージ Arch バージョン Repo サイズ
================================================================================
インストール:
postgresql14-contrib x86_64 14.5-1PGDG.rhel8 pgdg14 726 k

トランザクションの概要
================================================================================
インストール 1 パッケージ

ダウンロードサイズの合計: 726 k
インストール後のサイズ: 2.5 M
パッケージのダウンロード:
postgresql14-contrib-14.5-1PGDG.rhel8.x86_64.rp 203 kB/s | 726 kB 00:03
--------------------------------------------------------------------------------
合計 203 kB/s | 726 kB 00:03
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
トランザクションを実行中
準備 : 1/1
インストール中 : postgresql14-contrib-14.5-1PGDG.rhel8.x86_64 1/1
scriptletの実行中: postgresql14-contrib-14.5-1PGDG.rhel8.x86_64 1/1
検証 : postgresql14-contrib-14.5-1PGDG.rhel8.x86_64 1/1

インストール済み:
postgresql14-contrib-14.5-1PGDG.rhel8.x86_64

完了しました!
#

これで PostgreSQL 公式サイトの rpm から PostgreSQL 14.5 が導入出来ました。DBの初期化も実施しておきましょう。

# export PGSETUP_INITDB_OPTIONS="--encoding=UTF-8 --no-locale"
# /usr/pgsql-14/bin/postgresql-14-setup initdb
Initializing database ... OK

# systemctl enable postgresql-14
Created symlink /etc/systemd/system/multi-user.target.wants/postgresql-14.service → /usr/lib/systemd/system/postgresql-14.service.
# systemctl start postgresql-14
# systemctl status postgresql-14
● postgresql-14.service - PostgreSQL 14 database server
Loaded: loaded (/usr/lib/systemd/system/postgresql-14.service; enabled; vend>
Active: active (running) since Wed 2022-11-02 05:19:19 JST; 4s ago
Docs: https://www.postgresql.org/docs/14/static/
Process: 8619 ExecStartPre=/usr/pgsql-14/bin/postgresql-14-check-db-dir ${PGD>
Main PID: 8624 (postmaster)
Tasks: 8 (limit: 4783)
Memory: 19.9M
CGroup: /system.slice/postgresql-14.service
tq8624 /usr/pgsql-14/bin/postmaster -D /var/lib/pgsql/14/data/
tq8626 postgres: logger
tq8628 postgres: checkpointer
tq8629 postgres: background writer
tq8630 postgres: walwriter
tq8631 postgres: autovacuum launcher
tq8632 postgres: stats collector
mq8633 postgres: logical replication launcher

11月 02 05:19:19 rockey86 systemd[1]: Starting PostgreSQL 14 database server...
11月 02 05:19:19 rockey86 postmaster[8624]: 2022-11-02 05:19:19.463 JST [8624] >
11月 02 05:19:19 rockey86 postmaster[8624]: 2022-11-02 05:19:19.463 JST [8624] >
11月 02 05:19:19 rockey86 systemd[1]: Started PostgreSQL 14 database server.
#
# su - postgres
$ psql
psql (14.5)
"help"でヘルプを表示します。

postgres=#

無事 PostgreSQL 14 が起動しました。

pgaudit と pgauditlogtofile のインストール

PostgreSQL 公式リポジトリに含まれる pgaudit と pgauditlogtofile の rpm パッケージ名を調べてみます。PostgreSQL 14 用の pgaudit のパッケージは pgaudit16_14、pgauditlogtofile のパッケージは pgauditlogtofile_14 もしくは pgauditlogtofile_14-llvmjit (JITコンパイル対応)となっています。

# dnf list | grep pgaudit
pgaudit16_14.x86_64 1.6.2-1.rhel8 @pgdg14
pgauditlogtofile_14.x86_64 1.5.6-1.rhel8 @pgdg14
pgaudit12_10.x86_64 1.2.4-1.rhel8 pgdg10
pgaudit13_11.x86_64 1.3.4-1.rhel8 pgdg11
pgaudit14_12.x86_64 1.4.3-1.rhel8 pgdg12
pgaudit15_13.x86_64 1.5.2-1.rhel8 pgdg13
pgaudit17_15.x86_64 1.7.0-1.rhel8 pgdg15
pgaudit_analyze.x86_64 1.0.7-1.rhel8 pgdg-common
pgaudit_analyze.noarch 1.0.8-1.rhel8 pgdg-common
pgauditlogtofile-10.x86_64 1.0-1.rhel8 pgdg10
pgauditlogtofile-11.x86_64 1.0-1.rhel8 pgdg11
pgauditlogtofile-12.x86_64 1.0-1.rhel8 pgdg12
pgauditlogtofile-13.x86_64 1.0-1.rhel8 pgdg13
pgauditlogtofile_10.x86_64 1.5.6-1.rhel8 pgdg10
pgauditlogtofile_11.x86_64 1.5.6-1.rhel8 pgdg11
pgauditlogtofile_11-llvmjit.x86_64 1.5.6-1.rhel8 pgdg11
pgauditlogtofile_12.x86_64 1.5.6-1.rhel8 pgdg12
pgauditlogtofile_12-llvmjit.x86_64 1.5.6-1.rhel8 pgdg12
pgauditlogtofile_13.x86_64 1.5.6-1.rhel8 pgdg13
pgauditlogtofile_13-llvmjit.x86_64 1.5.6-1.rhel8 pgdg13
pgauditlogtofile_14-llvmjit.x86_64 1.5.6-1.rhel8 pgdg14
pgauditlogtofile_15.x86_64 1.5.6-2.rhel8 pgdg15
pgauditlogtofile_15-llvmjit.x86_64 1.5.6-2.rhel8 pgdg15
#

今回は pgaudit と pgauditlogtofile のパッケージを導入します。

# dnf install -y pgaudit16_14 pgauditlogtofile_14
依存関係が解決しました。
================================================================================
パッケージ Arch バージョン リポジトリー サイズ
================================================================================
インストール:
pgaudit16_14 x86_64 1.6.2-1.rhel8 pgdg14 56 k
pgauditlogtofile_14 x86_64 1.5.6-1.rhel8 pgdg14 18 k

トランザクションの概要
================================================================================
インストール 2 パッケージ

ダウンロードサイズの合計: 74 k
インストール後のサイズ: 124 k
パッケージのダウンロード:
(1/2): pgauditlogtofile_14-1.5.6-1.rhel8.x86_64 13 kB/s | 18 kB 00:01
(2/2): pgaudit16_14-1.6.2-1.rhel8.x86_64.rpm 37 kB/s | 56 kB 00:01
--------------------------------------------------------------------------------
合計 49 kB/s | 74 kB 00:01
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
トランザクションを実行中
準備 : 1/1
インストール中 : pgaudit16_14-1.6.2-1.rhel8.x86_64 1/2
インストール中 : pgauditlogtofile_14-1.5.6-1.rhel8.x86_64 2/2
scriptletの実行中: pgauditlogtofile_14-1.5.6-1.rhel8.x86_64 2/2
検証 : pgaudit16_14-1.6.2-1.rhel8.x86_64 1/2
検証 : pgauditlogtofile_14-1.5.6-1.rhel8.x86_64 2/2

インストール済み:
pgaudit16_14-1.6.2-1.rhel8.x86_64 pgauditlogtofile_14-1.5.6-1.rhel8.x86_64

完了しました!
#

これで pgaudit と pgauditlogtofile がインストールされました。

postgresql.conf の shared_preload_libraries の設定と有効化確認

shared_preload_libraries に共有ライブラリの pgaudit,pgauditlogtofile を設定して PostgreSQL を再起動し、新規に db1 データベースを作成後、pgaudit が有効になっていることを確認します。

$ cd $PGDATA
$ pwd
/var/lib/pgsql/14/data
$ vi postgresql.conf
shared_preload_libraries = 'pgaudit, pgauditlogtofile'
# systemctl restart postgresql-14.service
$ createdb db1
$ psql db1
psql (14.5)
"help"でヘルプを表示します。

db1=# show shared_preload_libraries;
shared_preload_libraries
---------------------------
pgaudit, pgauditlogtofile
(1 行)

CREATE EXTENSION を実行してエクステンションに登録

使用したいデータベースに psql で接続して、pgaudit と pgauditlogtofile で CREATE EXTENSION を実行します。エクステンションが登録されていることを確認します。

db1=# CREATE EXTENSION pgaudit;
CREATE EXTENSION
db1=# CREATE EXTENSION pgauditlogtofile;
CREATE EXTENSION
db1=# \dx
インストール済みの拡張一覧
名前 | バージョン | スキーマ | 説明

------------------+------------+------------+------------------------------------------------------------
pgaudit | 1.6.2 | public | provides auditing functionality
pgauditlogtofile | 1.5 | public | pgAudit addon to redirect audit log to an independent file
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 行)

db1=#

これで pgAudit と pgAudit Log to File のインストールは完了しました。

セッション監査ロギングを有効にして分離した監査ログファイルを確認

監査ログをセッション単位で取得するセッション監査ロギングを試して監査ログファイルが分離されることを確認します。postgresql.conf ファイルに pgaudit.log = ‘ALL’ を追加し、PostgreSQL に設定を読み込ませます。

$ cd $PGDATA
$ vi postgresql.conf
pgaudit.log = 'ALL'
# systemctl reload postgresql-14.service
$ cd $PGDATA/log
$ ls
postgresql-Wed.log
$ tail -3 postgresql-Wed.log
2022-11-02 05:30:01.537 JST [9842] LOG: database system is ready to accept connections
2022-11-02 05:37:08.831 JST [9842] LOG: received SIGHUP, reloading configuration files
2022-11-02 05:37:08.831 JST [9842] LOG: parameter "pgaudit.log" changed to "ALL"

table1 を作成してSELECT 文を実行したところ、無事 PostgreSQL ログとは別に新規に作成された監査ログファイル(audit-YYYYMMDD_0000.log)に記録されました。

$ psql db1
db1=# CREATE TABLE table1 (i1 integer, t1 text);
CREATE TABLE
db1=# INSERT INTO table1 VALUES (1, 'aaa'),(2, 'bbb');
INSERT 0 2
db1=# SELECT * FROM table1;
i1 | t1
----+-----
1 | aaa
2 | bbb
(2 行)
db1=# \q
$ cd $PGDATA/log
$ ls -tl
合計 8
-rw-------. 1 postgres postgres 651 11月 2 05:39 audit-20221102_0000.log
-rw-------. 1 postgres postgres 1972 11月 2 05:37 postgresql-Wed.log
$ cat audit-20221102_0000.log
2022-11-02 05:39:32.716 JST,postgres,db1,10095,[local],636183eb.276f,1,CREATE TABLE,2022-11-02 05:39:07 JST,3/24,737,00000,SESSION,1,1,DDL,CREATE TABLE,TABLE,public.table1,"CREATE TABLE table1 (i1 integer, t1 text);",<not logged>,,,,,,,,,psql
2022-11-02 05:39:43.309 JST,postgres,db1,10095,[local],636183eb.276f,2,INSERT,2022-11-02 05:39:07 JST,3/25,0,00000,SESSION,2,1,WRITE,INSERT,,,"INSERT INTO table1 VALUES (1, 'aaa'),(2, 'bbb');",<not logged>,,,,,,,,,psql
2022-11-02 05:39:49.228 JST,postgres,db1,10095,[local],636183eb.276f,3,SELECT,2022-11-02 05:39:07 JST,3/26,0,00000,SESSION,3,1,READ,SELECT,,,SELECT * FROM table1;,<not logged>,,,,,,,,,psql
$

pgaudit.log_connections, pgaudit.log_disconnections について

postgresql.conf ファイルで log_connections = on と log_disconnections = on を設定した上で pg_audit.log_connections = on と pg_audit.log_disconnections = on と設定して PostgreSQL に設定を再読み込みさせると、監査ログファイルにログイン情報とログアウト情報が記録されます。

$ cd $PGDATA
$ vi postgresql.conf
log_connections = on
log_disconnections = on
pg_audit.log_connections = on
pg_audit.log_disconnections = on
# systemctl reload postgresql-14.service
$ cd $PGDATA/log
$ tail -3 postgresql-Wed.log
2022-11-02 06:12:30.368 JST [9842] LOG: received SIGHUP, reloading configuration files
2022-11-02 06:12:30.368 JST [9842] LOG: parameter "log_connections" changed to "on"
2022-11-02 06:12:30.368 JST [9842] LOG: parameter "log_disconnections" changed to "on"
2022-11-02 06:12:30.368 JST [9842] LOG: parameter "pg_audit.log_connections" changed to "on"
2022-11-02 06:12:30.368 JST [9842] LOG: parameter "pg_audit.log_disconnections" changed to "on"

現在のバージョンでは、ログインが成功すると、監査ログファイルにのみ情報が記録されますが、ログインが失敗した場合は、ログインに失敗したこと自体は監査ログに記録されずに PostgreSQL ログのみに記録される点には注意が必要です。

[ログイン/ログアウト成功時]
$ psql db1
db1=# \q
$ tail -f audit-20221102_0000.log
2022-11-02 06:13:15.781 JST,,,11664,[local],63618beb.2d90,1,,2022-11-02 06:13:15 JST,,0,00000,connection received: host=[local],,,,,,,,,
2022-11-02 06:13:15.782 JST,postgres,db1,11664,[local],63618beb.2d90,2,authentication,2022-11-02 06:13:15 JST,3/140,0,00000,connection authenticated: identity="postgres" method=peer (/var/lib/pgsql/14/data/pg_hba.conf:85),,,,,,,,,
2022-11-02 06:13:15.782 JST,postgres,db1,11664,[local],63618beb.2d90,3,authentication,2022-11-02 06:13:15 JST,3/140,0,00000,connection authorized: user=postgres database=db1 application_name=psql,,,,,,,,,
2022-11-02 06:13:22.678 JST,postgres,db1,11664,[local],63618beb.2d90,4,idle,2022-11-02 06:13:15 JST,,0,00000,disconnection: session time: 0:00:06.896 user=postgres database=db1 host=[local],,,,,,,,,psql
[ログイン失敗時]
$ psql db1 -U nouser
psql: エラー: ソケット"/var/run/postgresql/.s.PGSQL.5432"上でのサーバーへの接続に失敗しました: FATAL: Peer authentication failed for user "nouser"
$ tail -f audit-20221102_0000.log
2022-11-02 06:14:29.051 JST,,,11676,[local],63618c35.2d9c,1,,2022-11-02 06:14:29 JST,,0,00000,connection received: host=[local],,,,,,,,,
2022-11-02 06:14:29.052 JST,nouser,db1,11676,[local],63618c35.2d9c,2,authentication,2022-11-02 06:14:29 JST,3/145,0,00000,connection authenticated: identity="postgres" method=peer (/var/lib/pgsql/14/data/pg_hba.conf:85),,,,,,,,,
$ tail -f postgresql-Wed.log
2022-11-02 06:14:29.052 JST [11676] LOG: provided user name (nouser) and authenticated user name (postgres) do not match
2022-11-02 06:14:29.052 JST [11676] FATAL: Peer authentication failed for user "nouser"
2022-11-02 06:14:29.052 JST [11676] DETAIL: Connection matched pg_hba.conf line 85: "local all all peer"
$

終わりに

pgAudit 単体では監査の記録が PostgreSQL ログと混在していましたが、pgAudit Log To File を追加で導入することで、監査の記録を PostgreSQL ログとは別の独立した監査ログファイルに記録することが出来るため、PostgreSQL ログに混在した監査ログの分離が不要となり PostgreSQL ログの扱いがこれまでと同様に出来るため非常に便利です。
pgAudit を新規に導入する際は pgAudit Log to File もセットで導入、pgAudit が既に導入されている環境には pgAudit Log to File を追加で導入することをお勧めします。

この記事では、redis_fdw の概要、インストール、基本的な使い方、テーブルオプションについて説明します。なお、Redis 自体の説明については Redis の紹介 をお読みください。

redis_fdw とは

redis_fdw の名前につく fdw は外部データラッパ (Foreign Data Wrapper) を表し、PostgreSQL から Oracle や CSV ファイルなど、PostgreSQL 外のデータに外部テーブルとしてアクセスする機能です。redis_fdw はこの機能を使って Redis 上のデータにアクセスします。

redis_fdw は、もともと PostgreSQL 開発者の一人 Dave Page 氏が実験的に開発し、その後、Andrew Dunstan 氏が開発を引き継ぎ、本番利用向けに改修しました。

ソースコードは GitHub リポジトリ上で公開され、PostgreSQL ライセンスに従って配布されています。PostgreSQL の対応バージョンは 9.1 以降で、2022 年 8 月時点で最新の PostgreSQL 14 にも対応しています。

なお、PGDG リポジトリ^[1] で同じ名前のパッケージが配布されていますが、ここで取り上げる redis_fdw とは異なるもので、便宜上、リポジトリ名をとって rw_redis_fdw と呼びます。

rw_redis_fdw も Redis 用外部データラッパで、名前につく rw は読み書き (Read-Write) を表し、以前は書き込みに対応していなかった redis_fdw に対して名づけられたものと考えられますが、現在は redis_fdw も書き込みに対応しています。

rw_redis_fdw は redis_fdw に比べて機能は多いですが、ここでは、より広く使われている redis_fdw を取り上げます。

redis_fdw のインストール

redis_fdw をインストールします。

ここでは、Rocky Linux 8 上に PostgreSQL、Redis をセットアップした上、redis_fdw をソースコードからビルドし、インストールします。

1. PGDG リポジトリをインストールします。

   $ sudo dnf -qy install https://download.postgresql.org/pub/repos/yum/reporpms/EL-$(rpm -E %rhel-%_arch)/pgdg-redhat-repo-latest.noarch.rpm
   
   Installed:
     pgdg-redhat-repo-42.0-24.noarch
   
   

   PostgreSQL は PGDG リポジトリからインストールします。

   これ以降、dnf コマンドの実行時に署名つきパッケージの検証に必要な PGP キーの取り込みを表すメッセージが出力される場合があります。

2. PostgreSQL モジュールを無効にします。

   $ sudo dnf -qy module disable postgresql
   

   OS 標準のリポジトリからも PostgreSQL をインストールできますが、バージョンが古いので、PGDG リポジトリのほうを使うように、PostgreSQL モジュールを無効にしています。

3. PostgreSQL をインストールします。

   $ sudo dnf -qy install postgresql14-server
   
   Installed:
     lz4-1.8.3-3.el8_4.x86_64
     postgresql14-14.4-1PGDG.rhel8.x86_64
     postgresql14-libs-14.4-1PGDG.rhel8.x86_64
     postgresql14-server-14.4-1PGDG.rhel8.x86_64
   
   

   ここでは、PostgreSQL 14 をインストールしています。

   パッケージ名 postgresql14-server をはじめ、これ以降、コマンドラインに含まれる 14 は PostgreSQL のバージョンを表します。お使いになるバージョンに合わせ、適宜、読み替えてください。

4. データベースクラスタを作成します。

   $ PGSETUP_INITDB_OPTIONS="-E UTF8 --no-locale" sudo -E /usr/pgsql-14/bin/postgresql-14-setup initdb
   Initializing database ... OK
   
   

   データベースクラスタはデータベースを格納する領域です。作成には通常 initdb コマンドを使いますが、ここでは、パッケージに付属のスクリプトを使います。

   環境変数 PGSETUP_INITDB_OPTIONS には initdb コマンドに渡すオプションを指定します。ここでは、デフォルトのエンコーディングを UTF8、ロケールをなしに指定しています。

5. PostgreSQL のサービスを起動します。

   $ sudo systemctl start postgresql-14
   

6. Redis をインストールします。

   $ sudo dnf -qy install redis
   
   Installed:
     redis-5.0.3-5.module+el8.5.0+657+2674830e.x86_64
   
   

7. Redis のサービスを起動します。

   $ sudo systemctl start redis
   

8. EPEL リポジトリ^[2] をインストールします。

   $ sudo dnf -qy install epel-release
   
   Installed:
     epel-release-8-13.el8.noarch
   
   

   redis_fdw の動作に必要な Redis 用 C 言語ライブラリ Hiredis は EPEL リポジトリからインストールします。

9. redis_fdw のビルドに必要なパッケージをインストールします。

   $ sudo dnf -qy install make redhat-rpm-config postgresql14-devel hiredis-devel
   
   Upgraded:
     libgcc-8.5.0-10.1.el8_6.x86_64          libgomp-8.5.0-10.1.el8_6.x86_64
     libstdc++-8.5.0-10.1.el8_6.x86_64
   Installed:
     annobin-10.29-3.el8.x86_64
     binutils-2.30-113.el8.x86_64
     clang-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64
     clang-devel-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64
     clang-libs-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64
     clang-resource-filesystem-13.0.1-2.module+el8.6.0+987+d36ea6a1.x86_64
     clang-tools-extra-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64
     cmake-filesystem-3.20.2-4.el8.x86_64
     compiler-rt-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64
     cpp-8.5.0-10.1.el8_6.x86_64
     dwz-0.12-10.el8.x86_64
     efi-srpm-macros-3-3.el8.noarch
     emacs-filesystem-1:26.1-7.el8.noarch
     gcc-8.5.0-10.1.el8_6.x86_64
     gcc-c++-8.5.0-10.1.el8_6.x86_64
     ghc-srpm-macros-1.4.2-7.el8.noarch
     glibc-devel-2.28-189.5.el8_6.x86_64
     glibc-headers-2.28-189.5.el8_6.x86_64
     go-srpm-macros-2-17.el8.noarch
     hiredis-0.13.3-13.el8.x86_64
     hiredis-devel-0.13.3-13.el8.x86_64
     isl-0.16.1-6.el8.x86_64
     kernel-headers-4.18.0-372.13.1.el8_6.x86_64
     libicu-devel-60.3-2.el8_1.x86_64
     libmpc-1.1.0-9.1.el8.x86_64
     libomp-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64
     libomp-devel-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64
     libstdc++-devel-8.5.0-10.1.el8_6.x86_64
     libxcrypt-devel-4.1.1-6.el8.x86_64
     llvm-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64
     llvm-devel-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64
     llvm-libs-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64
     llvm-static-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64
     llvm-test-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64
     make-1:4.2.1-11.el8.x86_64
     ocaml-srpm-macros-5-4.el8.noarch
     openblas-srpm-macros-2-2.el8.noarch
     perl-srpm-macros-1-25.el8.noarch
     postgresql14-devel-14.4-1PGDG.rhel8.x86_64
     python-rpm-macros-3-41.el8.noarch
     python-srpm-macros-3-41.el8.noarch
     python3-rpm-macros-3-41.el8.noarch
     qt5-srpm-macros-5.15.2-1.el8.0.1.noarch
     redhat-rpm-config-129-1.el8.noarch
     rust-srpm-macros-5-2.el8.noarch
     unzip-6.0-46.el8.x86_64
     zip-3.0-23.el8.x86_64
   
   

10. redis_fdw のソースコードをダウンロードします。

    $ curl -LOs https://github.com/pg-redis-fdw/redis_fdw/archive/refs/heads/REL_14_STABLE.tar.gz
    

    redis_fdw のソースコードは PostgreSQL のバージョンごとにブランチが分かれていて、ダウンロード時はブランチ名を指定する必要があります。ここでは、PostgreSQL 14 に対応したブランチ REL_14_STABLE を指定しています。

11. redis_fdw のソースコードを展開します。

    $ tar -xzf REL_14_STABLE.tar.gz
    

12. redis_fdw をビルドします。

    $ make -C redis_fdw-REL_14_STABLE USE_PGXS=1 PG_CONFIG=/usr/pgsql-14/bin/pg_config
    make: ディレクトリ '/home/vagrant/redis_fdw-REL_14_STABLE'　に入ります
    gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC -I. -I./ -I/usr/pgsql-14/include/server -I/usr/pgsql-14/include/internal  -D_GNU_SOURCE -I/usr/include/libxml2  -I/usr/include  -c -o redis_fdw.o redis_fdw.c
    gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC -shared -o redis_fdw.so redis_fdw.o -L/usr/pgsql-14/lib  -Wl,--as-needed -L/usr/lib64  -L/usr/lib64 -Wl,--as-needed -Wl,-rpath,'/usr/pgsql-14/lib',--enable-new-dtags  -lhiredis
    /usr/bin/clang -Wno-ignored-attributes -fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro -O2  -I. -I./ -I/usr/pgsql-14/include/server -I/usr/pgsql-14/include/internal  -D_GNU_SOURCE -I/usr/include/libxml2  -I/usr/include -flto=thin -emit-llvm -c -o redis_fdw.bc redis_fdw.c
    make: ディレクトリ '/home/vagrant/redis_fdw-REL_14_STABLE' から出ます
    

    引数の変数 USE_PGXS には PostgreSQL 用拡張モジュールの構築基盤 PGXS を使うことを表す 1、PG_CONFIG には pg_config コマンドのパスを指定します。

13. redis_fdw をインストールします。

    $ sudo make -C redis_fdw-REL_14_STABLE install USE_PGXS=1 PG_CONFIG=/usr/pgsql-14/bin/pg_config
    make: ディレクトリ '/home/vagrant/redis_fdw-REL_14_STABLE'　に入ります
    /usr/bin/mkdir -p '/usr/pgsql-14/lib'
    /usr/bin/mkdir -p '/usr/pgsql-14/share/extension'
    /usr/bin/mkdir -p '/usr/pgsql-14/share/extension'
    /usr/bin/install -c -m 755  redis_fdw.so '/usr/pgsql-14/lib/redis_fdw.so'
    /usr/bin/install -c -m 644 .//redis_fdw.control '/usr/pgsql-14/share/extension/'
    /usr/bin/install -c -m 644 .//redis_fdw--1.0.sql  '/usr/pgsql-14/share/extension/'
    /usr/bin/mkdir -p '/usr/pgsql-14/lib/bitcode/redis_fdw'
    /usr/bin/mkdir -p '/usr/pgsql-14/lib/bitcode'/redis_fdw/
    /usr/bin/install -c -m 644 redis_fdw.bc '/usr/pgsql-14/lib/bitcode'/redis_fdw/./
    cd '/usr/pgsql-14/lib/bitcode' && /usr/bin/llvm-lto -thinlto -thinlto-action=thinlink -o redis_fdw.index.bc redis_fdw/redis_fdw.bc
    make: ディレクトリ '/home/vagrant/redis_fdw-REL_14_STABLE' から出ます
    

    ソースコードと、それを展開したディレクトリはインストール後、削除しても構いません。

redis_fdw の基本的な使い方

redis_fdw を使って PostgreSQL から Redis 上のデータを操作してみます。

1. PostgreSQL のスーパーユーザに切り替わります。

   $ sudo su - postgres
   

2. データベースを作成します。

   $ createdb redis_db
   

   ここでは、redis_db という名前のデータベースを作成しています。

3. データベースに接続します。

   $ psql redis_db
   psql (14.4)
   "help"でヘルプを表示します。
   
   =# 
   

   ここでは、作成した redis_db データベースに接続しています。終了するには \q または Ctrl + D を入力します。

4. データベースに redis_fdw をインストールします。

   =# CREATE EXTENSION redis_fdw;
   CREATE EXTENSION
   

   redis_fdw はプログラムとしてはインストール済みですが、実際に使うにはデータベースごとにインストールする必要があります。

   ここでは、接続中の redis_db データベースにインストールしています。

5. 外部サーバを作成します。

   =# CREATE SERVER redis_server
        FOREIGN DATA WRAPPER redis_fdw
        OPTIONS (address '127.0.0.1', port '6379');
   CREATE SERVER
   

   外部サーバとは、外部データラッパを使って外部データにアクセスするのに必要な接続情報を定義したオブジェクトです。作成時には、外部サーバ名、外部データラッパ名、オプションを指定します。

   redis_fdw では、以下のオプションが指定できます。

   オプション	デフォルト値	説明
   address	127.0.0.1	Redis サーバの IP アドレスまたはホスト名
   port	6379	Redis サーバのポート番号

   ここでは、redis_server という名前で redis_fdw の外部サーバを作成しています。オプションは例示のため、指定していますが、デフォルトでよければ、指定する必要はありません。

6. 外部サーバのユーザマッピングを作成します。

   =# CREATE USER MAPPING FOR PUBLIC
        SERVER redis_server
        OPTIONS (password 'secret');
   CREATE USER MAPPING
   

   外部サーバのユーザマッピングとは、外部サーバとユーザの対応づけを定義したオブジェクトです。作成時には、ユーザ名、外部サーバ名、オプションを指定します。

   redis_fdw では、以下のオプションが指定できます。

   オプション	デフォルト値	説明
   password	(なし)	Redis サーバ接続時の認証に使うパスワード

   ここでは、すべてのユーザを表す PUBLIC と外部サーバ redis_server を対応づけるユーザマッピングを作成しています。password オプションはパスワードが未設定であれば、指定する必要はありません。

7. 外部テーブルを作成します。

   =# CREATE FOREIGN TABLE string_table (key text, val text)
        SERVER redis_server
        OPTIONS (database '0');
   CREATE FOREIGN TABLE
   

   外部テーブルとは、外部データラッパを使って外部データにテーブルとしてアクセスできるように定義した特別なテーブルです。作成時には、テーブル定義、外部サーバ名、オプションを指定します。

   redis_fdw では、以下のオプションが指定できます。

   オプション	デフォルト値	説明
   database	0	Redis のデータベース番号。0 からデフォルトでは 15 まで指定可能
   tabletype	(なし)	Redis のデータ型。list、hash、set、zset が指定可能。未指定は string
   tablekeyprefix	(なし)	指定した接頭辞をもつキーに対象データを絞り込む
   tablekeyset	(なし)	指定したキーをもつ集合に含まれるキーに対象データを絞り込む
   singleton_key	(なし)	指定したキーの単一データを展開して対象データにする

   tabletype オプションを指定しないと、文字列を表す string 型になりますが、値として string は指定できません。teblekeyprefix、tablekeyset、singleton_key はいずれも対象データを指定するオプションで、1 つのみ指定でき、指定しないと、すべてのデータが対象になります。詳しくは redis_fdw のテーブルオプション で説明します。

   

   ここでは、tabletype オプションは指定せず、テーブル定義は text 型の key と val 列を定義しています。Redis のキーと string 型の値は PostgreSQL ではそれぞれ text 型に対応します。列名は任意です。database オプションはデフォルトでよければ、指定する必要はありません。

8. 外部テーブルのデータを操作します。データの操作を受けて Redis サーバがどう動作するかを確認するため、Redis サーバで実行されたコマンドを出力するようにしておきます。終了するには Ctrl + C を入力します。

   $ redis-cli monitor
   OK
   

   PostgreSQL 側でデータを 3 件登録します。

   =# INSERT INTO string_table
        VALUES ('key1', 'val1'), ('key2', 'val2'), ('key3', 'val3');
   INSERT 0 3
   

   Redis 側で実行されたコマンドが出力されます。

   1658092725.885750 [0 127.0.0.1:46042] "AUTH" "secret"
   1658092725.886005 [0 127.0.0.1:46042] "SELECT" "0"
   1658092725.886333 [0 127.0.0.1:46042] "EXISTS" "key1"
   1658092725.886766 [0 127.0.0.1:46042] "SET" "key1" "val1"
   1658092725.887016 [0 127.0.0.1:46042] "EXISTS" "key2"
   1658092725.887387 [0 127.0.0.1:46042] "SET" "key2" "val2"
   1658092725.887620 [0 127.0.0.1:46042] "EXISTS" "key3"
   1658092725.887764 [0 127.0.0.1:46042] "SET" "key3" "val3"
   

   PostgreSQL 側でデータを 1 件更新します。

   =# UPDATE string_table SET val = 'val4' WHERE key = 'key1';
   UPDATE 1
   

   Redis 側で実行されたコマンドが出力されます。

   1658092937.940434 [0 127.0.0.1:46044] "AUTH" "secret"
   1658092937.940542 [0 127.0.0.1:46044] "SELECT" "0"
   1658092937.940660 [0 127.0.0.1:46044] "DBSIZE"
   1658092937.941136 [0 127.0.0.1:46046] "AUTH" "secret"
   1658092937.941352 [0 127.0.0.1:46046] "SELECT" "0"
   1658092937.941445 [0 127.0.0.1:46046] "EXISTS" "key1"
   1658092937.941835 [0 127.0.0.1:46048] "AUTH" "secret"
   1658092937.941976 [0 127.0.0.1:46048] "SELECT" "0"
   1658092937.942118 [0 127.0.0.1:46046] "GET" "key1"
   1658092937.942385 [0 127.0.0.1:46048] "SET" "key1" "val4"
   

   PostgreSQL 側でデータを 1 件削除します。

   =# DELETE FROM string_table WHERE key = 'key2';
   DELETE 1
   

   Redis 側で実行されたコマンドが出力されます。

   1658092947.811658 [0 127.0.0.1:46050] "AUTH" "secret"
   1658092947.811792 [0 127.0.0.1:46050] "SELECT" "0"
   1658092947.811875 [0 127.0.0.1:46050] "DBSIZE"
   1658092947.812375 [0 127.0.0.1:46052] "AUTH" "secret"
   1658092947.812605 [0 127.0.0.1:46052] "SELECT" "0"
   1658092947.812729 [0 127.0.0.1:46052] "EXISTS" "key2"
   1658092947.813055 [0 127.0.0.1:46054] "AUTH" "secret"
   1658092947.813197 [0 127.0.0.1:46054] "SELECT" "0"
   1658092947.813342 [0 127.0.0.1:46052] "GET" "key2"
   1658092947.813438 [0 127.0.0.1:46054] "DEL" "key2"
   

   PostgreSQL 側でデータを 1 件取得します。

   =# SELECT val FROM string_table WHERE key = 'key3';
    val
   ------
    val3
   (1 行)
   
   

   Redis 側で実行されたコマンドが出力されます。

   1658092954.987736 [0 127.0.0.1:46056] "AUTH" "secret"
   1658092954.987827 [0 127.0.0.1:46056] "SELECT" "0"
   1658092954.987876 [0 127.0.0.1:46056] "DBSIZE"
   1658092954.988113 [0 127.0.0.1:46058] "AUTH" "secret"
   1658092954.988283 [0 127.0.0.1:46058] "SELECT" "0"
   1658092954.988375 [0 127.0.0.1:46058] "EXISTS" "key3"
   1658092954.988482 [0 127.0.0.1:46058] "GET" "key3"
   

redis_fdw のテーブルオプション

redis_fdw を使って外部テーブルの定義時に指定できるオプションについて説明します。

tabletype オプション

tabletype は Redis のデータ型を指定するオプションです。オプションに指定できるデータ型について説明します。

list 型

list は登録順に並べた文字列の集合を表すデータ型で、PostgreSQL では値を並べた text 型の配列に対応します。

=# CREATE FOREIGN TABLE list_table (key text, val text[])
     SERVER redis_server
     OPTIONS (database '1', tabletype 'list');
CREATE FOREIGN TABLE
=# INSERT INTO list_table
     VALUES ('key1', '{val1,val2,val3,val1}');
INSERT 0 1
=# SELECT * FROM list_table WHERE key = 'key1';
 key  |          val
------+-----------------------
 key1 | {val1,val2,val3,val1}
(1 行)

=# SELECT key, unnest(val) FROM list_table WHERE key = 'key1';
 key  | unnest
------+--------
 key1 | val1
 key1 | val2
 key1 | val3
 key1 | val1
(4 行)

値 val1、val2、val3、val1 を登録し、データを取得すると、値が登録順に並び、重複する値 val1 が残っています。取得したデータは unnest 関数で行の集合に展開できます。

hash 型

hash はフィールドと値の文字列の組み合わせからなる集合を表すデータ型で、PostgreSQL ではフィールドと値を交互に並べた text 型の配列に対応します。

=# CREATE FOREIGN TABLE hash_table (key text, val text[])
     SERVER redis_server
     OPTIONS (database '2', tabletype 'hash');
CREATE FOREIGN TABLE
=# INSERT INTO hash_table
     VALUES ('key1', '{fld1,val1,fld2,val2,fld3,val3,fld1,val4}');
INSERT 0 1
=# SELECT * FROM hash_table WHERE key = 'key1';
 key  |               val
------+---------------------------------
 key1 | {fld1,val4,fld2,val2,fld3,val3}
(1 行)

=# SELECT key, json_object(val) FROM hash_table WHERE key = 'key1';
 key  |                     json_object
------+-----------------------------------------------------
 key1 | {"fld1" : "val4", "fld2" : "val2", "fld3" : "val3"}
(1 行)

=# SELECT key, (json_each_text(json_object(val))).*
     FROM hash_table WHERE key = 'key1';
 key  | key  | value
------+------+-------
 key1 | fld1 | val4
 key1 | fld2 | val2
 key1 | fld3 | val3
(3 行)

フィールドと値の組み合わせ fld1 と val1、fld2 と val2、fld3 と val3、fld1 と val4 を登録し、データを取得すると、フィールド fld1 が重複する値 val1、val4 はあとから登録した値 val4 で上書きされています。取得したデータは json_object 関数で JSON オブジェクトに変換し、さらに json_each_text 関数でフィールドと値からなる行の集合に展開できます。

set 型

set は順序づけがなく、重複がない文字列の集合を表すデータ型で、PostgreSQL では値を並べた text 型の配列に対応します。

=# CREATE FOREIGN TABLE set_table (key text, val text[])
     SERVER redis_server
     OPTIONS (database '3', tabletype 'set');
CREATE FOREIGN TABLE
=# INSERT INTO set_table
     VALUES ('key1', '{val1,val2,val3,val1}');
INSERT 0 1
=# SELECT * FROM set_table WHERE key = 'key1';
 key  |       val
------+------------------
 key1 | {val1,val3,val2}
(1 行)

値 val1、val2、val3、val1 を登録し、データを取得すると、重複する値 val1 が取り除かれ、1 つになっています。

zset 型

zset はスコアで順序づけした、重複がない文字列の集合を表すデータ型で、PostgreSQL では値を並べた text 型の配列に対応します。

zset 型の使い方は基本的に set 型と同じです。スコアは登録順に 0、1、2、… が割り当てられます。スコアを PostgreSQL で扱うには、singleton_key オプション を指定する必要があります。

tablekeyprefix オプション

tablekeyprefix は指定した接頭辞をもつキーに対象データを絞り込むオプションで、1 つのデータベース内に異なる種類のデータをもたせ、別テーブルとしてアクセスするのに役立ちます。

=# CREATE FOREIGN TABLE keyprefix_table (key text, val text)
     SERVER redis_server
     OPTIONS (database '4', tablekeyprefix 'keyprefix_table:');
CREATE FOREIGN TABLE
=# INSERT INTO keyprefix_table VALUES ('keyprefix_table:key1', 'val1');
INSERT 0 1
=# INSERT INTO keyprefix_table VALUES ('keyprefix_table:key2', 'val2');
INSERT 0 1
=# INSERT INTO keyprefix_table VALUES ('key3', 'val3');
ERROR:  key 'key3' does not match table key prefix 'keyprefix_table:'
=# SELECT * FROM keyprefix_table;
     key          | val
----------------------+------
 keyprefix_table:key2 | val2
 keyprefix_table:key1 | val1
(2 行)

=# \! redis-cli -n 4 SET key3 val3
OK
=# \! redis-cli -n 4 KEYS \*
1) "keyprefix_table:key2"
2) "key3"
3) "keyprefix_table:key1"
=# SELECT * FROM keyprefix_table;
     key          | val
----------------------+------
 keyprefix_table:key2 | val2
 keyprefix_table:key1 | val1
(2 行)

tablekeyprefix オプションを指定すると、指定した接頭辞 keyprefix_table: をもつキー keyprefix_table:key1、keyprefix_table:key2 のデータしか登録できず、接頭辞をもたないキー key3 の登録はエラーになります。\! は PostgreSQL 外のコマンドを実行するコマンドで、Redis 上のデータを直接操作し、接頭辞をもたないキー key3 を登録し、データを取得すると、接頭辞をもたないキー key3 は結果に現れません。

大量のキーをもつデータベースでは、tablekeyprefix オプションではキーの検索に時間がかかるため、tablekeyset オプションでキーを集合に含まれるものに限ったほうがよいでしょう。

tablekeyset オプション

tablekeyset は指定したキーをもつ集合に含まれるキーに対象データを絞り込むオプションで、tablekeyprefix オプションと同じく、1 つのデータベース内で異なる種類のデータを扱うのに使います。

=# CREATE FOREIGN TABLE keyset_table (key text, val text)
     SERVER redis_server
     OPTIONS (database '5', tablekeyset 'keyset_table_keys');
CREATE FOREIGN TABLE
=# INSERT INTO keyset_table
     VALUES ('key1', 'val1'), ('key2', 'val2'), ('key3', 'val3');
INSERT 0 3
=# SELECT * FROM keyset_table;
 key  | val
------+------
 key3 | val3
 key2 | val2
 key1 | val1
(3 行)

=# \! redis-cli -n 5 SREM keyset_table_keys key2
(integer) 1
=# \! redis-cli -n 5 SMEMBERS keyset_table_keys
1) "key3"
2) "key1"
=# SELECT * FROM keyset_table;
 key  | val
------+------
 key3 | val3
 key1 | val1
(2 行)

tablekeyset オプションを指定すると、指定したキー keyset_table_keys をもつ集合に登録したキー key1、key2、key3 が自動的に登録され、取得されるデータは集合に含まれるキーに限られます。Redis 上のデータを直接操作し、キー key2 を削除し、データを取得すると、削除したキー key2 は結果に現れなくなります。

singleton_key オプション

singleton_key は指定したキーの単一データを展開して対象データにするオプションで、tableytpe オプション指定なしの string 型は 1 行 1 列、指定ありの list または set 型は行の集合、hash 型はフィールドと値からなる行の集合、zset 型は値とスコアからなる行の集合に展開されます。

=# CREATE FOREIGN TABLE singleton_table (val text, sc numeric)
     SERVER redis_server
     OPTIONS (database '6', tabletype 'zset', singleton_key 'singleton_table');
CREATE FOREIGN TABLE
=# INSERT INTO singleton_table
     VALUES ('val1', 10), ('val2', 20), ('val3', 30);
INSERT 0 3
=# SELECT * FROM singleton_table;
 val  | sc
------+----
 val1 | 10
 val2 | 20
 val3 | 30
(3 行)

=# UPDATE singleton_table SET sc = 40 WHERE val = 'val1';
UPDATE 1
=# SELECT * FROM singleton_table;
 val  | sc
------+----
 val2 | 20
 val3 | 30
 val1 | 40
(3 行)

singleton_key オプションと併せて tabletype オプションに zset 型を指定すると、PostgreSQL でスコアを扱えるようになります。スコアは PostgreSQL では numeric 型に対応します。ORDER BY 句で並び順を指定しなければ、データはスコアの昇順に取得されます。値 val1 のスコアを 10 から 40 に更新すると、並び順が更新したスコア順に変わり、値 val1 は最後に来るようになります。

おわりに

この記事では、Redis 用外部データラッパ redis_fdw の概要、インストール、基本的な使い方、テーブルオプションについて説明しました。redis_fdw を使うことで、高速なデータの読み書きができる Redis と、SQL で複雑なデータの操作ができる PostgreSQL の特長を互いに活かし、さらに利用の幅が広がることでしょう。

SRA OSS では、PostgreSQL や Redis、redis_fdw のサポートをはじめとして、オープンソースに関する様々なサービスを提供しています。SRA OSS のサービスに興味がありましたら、お気軽に こちら からお問い合わせください。

1. PostgreSQL Global Development Group (PGDG) が運営する PostgreSQL 関連パッケージの Yum リポジトリ
2. Fedora Project が運営するエンタープライズ Linux 向け追加パッケージ (Extra Packages for Enterprise Linux; EPEL) の Yum リポジトリ

IvorySQL は HighGo社を中心に開発されているオープンソース（Apache License）の Oracle互換データベースです。2021年 12月にバージョン 1.0 がリリースされました。IvorySQL は PostgreSQL と Oracle互換機能を提供するサードパーティ拡張 orafce の組み合わせをベースとしており、そこに更に独自の Oracle互換機能を追加しています。

本稿では、IvorySQL 1.0 の導入方法、機能、使用方法を解説します。また、Oracle Database 移行先の選択肢としての現時点の見解を記載します。

2021年 1月 25日に IvorySQL 1.1 がリリースされました。本バージョンについてに補足も記載します。

IvorySQL の導入方法

インストール

IvorySQL は github で開発リポジトリが公開されていて、そこからソースコードを取得できます。また、RHEL7、RHEL8 向けの rpmパッケージが HighGo の yumリポジトリで公開されています。

ソースコードからビルドする手順例を以下に示します。

$ git clone https://github.com/IvorySQL/IvorySQL.git
$ cd IvorySQL
$ ./configure --prefix=/usr/local/ivorysql --enable-debug
$ make
$ su -c 'make install'
$ cd contrib
$ make
$ su -c 'make install'

ビルド手順は PostgreSQL と同じです。configure で指定可能なオプションは PostgreSQL と違いありません。contrib が重要ですのでこれもビルド、インストールします。

環境変数としては以下を設定すれば良いでしょう。データが格納されるディレクトリを PostgreSQL と同様に PGDATA に設定します。

export PATH=/usr/local/ivorysql/bin:$PATH
export PGDATA=/DATA/ivdata
export PGUSER=ivorysql

続いて、rpmパッケージから導入する手順を示します。本稿作成に当たっては RHEL 8.x を使用しましたが、RHEL 7.x や互換OS でも手順に違いはありません。

HighGo社の Webページ から、リポジトリ定義のパッケージivorysql-release-1.0-1.noarch.rpmが入手できます。まずはこれをインストールします。

# yum install ivorysql-release-1.0-1.noarch.rpm

この rpmファイルには若干問題あるようで以下のエラーが出ます。

エラー: トランザクション ロックを（/var/lib/rpm/.rpm.lock 上に）作成できません。(リソースが一時的に利用できません)
エラー: /etc/pki/rpm-gpg/HIGHGO-SOFTWARE-GPG-KEY: キー 1 のインポートに失敗しました。
警告: %post(ivorysql-release-1.0-1.noarch) スクリプトの実行に失敗しました。終了ステータス 1

Error in POSTIN scriptlet in rpm package ivorysql-release

そこで、失敗が報告されたキーのインポートを手動で実行しておきます。

# rpm --import /etc/pki/rpm-gpg/HIGHGO-SOFTWARE-GPG-KEY

次に IvorySQL のパッケージをインストールします。

# yum install ivorysql1-server ivorysql1 ivorysql1-libs ivorysql1-contrib

パッケージの構成は PostgreSQL の rpmパッケージを踏襲したものとなっています。IvorySQL を稼働させるための OSユーザ ivorysql が作られ、ivorysqlユーザのシェル設定に PGDATA環境変数が予め設定されています。また、追加のシェル設定を .pgsql_profile から読み込むようになっています。

PATH環境変数は設定されないので以下のように追加しておきます。

# su - ivorysql
$ export PATH=/usr/local/ivorysql/ivorysql-1/bin:$PATH
$ cat > .pgsql_profile <<'EOF'
export PATH=/usr/local/ivorysql/ivorysql-1/bin:$PATH
EOF

セットアップ

initdb でデータベースインスタンスの初期データを作成します。Oracle互換機能を使うにはオプションに「--compatible-mode oracle」を指定します。デフォルトは互換モードではない「postgres」です。今のところ、すなわち IvorySQL 1.0 では、これは postgresql.conf の設定 compatible_mode の初期値を与えているだけです。それ以外のオプションは PostgreSQL の initdb と同じです。

$ initdb -D $PGDATA -U ivorysql --locale=C --encoding=UTF8 --compatible-mode oracle

pg_ctl コマンドでサービスを起動します。pg_ctl コマンドの使い方も PostgreSQL と同じです。

$ pg_ctl -D $PGDATA -l $PGDATA/start.log start

createdbコマンドでテスト用データベース ivdb1 を作って、psqlコマンドでデータベースに接続します。この辺りも PostgreSQL と変わるところがありません。

$ createdb ivdb1
$ psql ivdb1
psql (14.0)
"help"でヘルプを表示します。

ivdb1=#

最初に行うべきことは orafce拡張の導入です。IvorySQL の Oracle互換機能のいくつかは orafce の中で提供されています。（→ v1.1 からは orafce は自動でロードされるようになっています）

ivdb1=# CREATE EXTENSION orafce;

また、orafce で提供されるデータ型や関数、演算子などの互換オブジェクトをスキーマ修飾無しに使えるようにするため、search_path設定に oracleスキーマを加えます。pg_catalog よりも手前に置くことで、同名の組み込みオブジェクトよりも Oracle互換オブジェクトが優先して使われます。ここではデータベースに対して search_path のデフォルト値として設定することにします。また、ユーザと同名のivorysqlスキーマも作成しておきます。

ivdb1=# SET search_path TO "$user", oracle, pg_catalog, public;
ivdb1=# ALTER DATABASE ivdb1 SET search_path TO "$user", oracle, pg_catalog, public;
ivdb1=# CREATE SCHEMA ivorysql;

なお、github での開発者のコメントによると IvorySQL 2.0 では、compatible_mode = oracle であれば search_path の変更をしなくとも互換オブジェクトが使われるようにするようです。

ここまでの手順で IvorySQL を使用する準備ができました。

Oracle互換機能

IvorySQL には様々な Oracle互換機能が含まれています。ドキュメントに記載されている IvorySQL 独自の互換機能の他、orafce で提供されている機能もあります。

本節では IvorySQL で提供されている Oracle互換機能の中から主なものを見ていきます。

パッケージ

IvorySQL の最も有力な機能がパッケージのサポートです。パッケージとはストアドプロシージャや関数、データ型、変数、カーソルをまとめたものです。

パッケージは、名前空間を区切って機能の整理を良くするのみならず、特有の振る舞いを持ちます。このためネイティブの PostgreSQL の機能だけを使って移行しようとすると、同じ動作が再現できず、しばしば移行の難所となります。

同一セッション内の同一パッケージ内において、関数とプロシージャからカーソルと変数に共有してアクセスが可能で、これらに対する操作はコミット／ロールバックの影響を受けないという振る舞いをします。

いくつかサンプルを示します。コード中のコメントに説明を記載しています。

$ cat pkg1.sql

CREATE OR REPLACE PACKAGE pkg1 AUTHID DEFINER IS -- パッケージ宣言
  PROCEDURE f_plus(p1 integer);    -- 変数に引数値を加えるプロシージャ
  FUNCTION f_incr RETURN integer;  -- 変数に 1 を足して、値を返す関数
END;

CREATE OR REPLACE PACKAGE BODY pkg1 AS           -- パッケージ本体定義
  v_num integer;    -- パッケージ変数／直接アクセスはできない
  PROCEDURE f_plus(p1 integer) IS
    BEGIN
      v_num := v_num + p1;
    END;
  FUNCTION f_incr RETURN integer IS
    BEGIN
      v_num := v_num + 1;  
      RETURN v_num;
    END;
  BEGIN             -- セッション中、最初の使用時に実行されるブロック
    v_num := 0;     -- パッケージ変数を初期化
  END;

上記のパッケージを読み込んで使用します。

ivdb1=# \i pkg1.sql

ivdb1=# SELECT pkg1.f_incr;
 f_incr
--------
 1
(1 行)

ivdb1=# BEGIN;
ivdb1=*# SELECT pkg1.f_incr;
 f_incr
--------
 2
(1 行)

ivdb1=*# CALL pkg1.f_plus(10);
ivdb1=*# SELECT pkg1.f_incr;
 f_incr
--------
 13
(1 行)

ivdb1=*# ROLLBACK;

ivdb1=# SELECT pkg1.f_incr;
 f_incr
--------
 14
(1 行)

パッケージ変数が関数やプロシージャの間で共有されていることと、明示的トランザクション内でのパッケージ変数への操作が ROLLBACK されても取り消されていないことが、確認できます。

次はカーソルを使った例です。

$ cat pkg2.sql

-- 操作する 10行データを持つテーブルを用意
DROP TABLE IF EXISTS tq;
CREATE TABLE tq (id int, v text);
INSERT INTO tq SELECT g, md5(g::text) FROM generate_series(1, 10) g;

CREATE OR REPLACE PACKAGE pkg2 AUTHID DEFINER IS -- パッケージ宣言
  CURSOR cur1 RETURN tq%ROWTYPE; -- (カーソル戻り値は %ROWTYPE 必須)
  FUNCTION f_next RETURN text; -- カーソルの次の行を返す関数
  FUNCTION f_prev RETURN text; -- カーソルの前の行を返す関数
END;

CREATE OR REPLACE PACKAGE BODY pkg2 IS -- パッケージ本体定義
  CURSOR cur1 RETURN tq%ROWTYPE IS SELECT id, v FROM tq ORDER BY id;
  FUNCTION f_next RETURN text IS
    rec tq%ROWTYPE;
    BEGIN
      FETCH cur1 INTO rec;
      RETURN rec.id || ': ' || rec.v;
    END;
  FUNCTION f_prev RETURN text IS
    rec tq%ROWTYPE;
    BEGIN
      FETCH PRIOR IN cur1 INTO rec;
      RETURN rec.id || ': ' || rec.v;
    END;
  BEGIN
    OPEN cur1;
  END;

上記を読み込みして実行してみます。

ivdb1=# \i pkg2.sql

ivdb1=# SELECT ivorysql.pkg2.f_next;
       f_next
-------------------------------------
 1: c4ca4238a0b923820dcc509a6f75849b
(1 行)

ivdb1=# SELECT ivorysql.pkg2.f_next;
       f_next
-------------------------------------
 2: c81e728d9d4c2f636f067f89cc14862c
(1 行)

ivdb1=# SELECT ivorysql.pkg2.f_next;
       f_next
-------------------------------------
 3: eccbc87e4b5ce2fe28308fd9f2a7baf3
(1 行)

ivdb1=# SELECT ivorysql.pkg2.f_prev;
       f_prev
-------------------------------------
 2: c81e728d9d4c2f636f067f89cc14862c
(1 行)

カーソルを複数の関数から共有している動作が確認できます。上記例では行っていませんが、明示的なトランザクション内の関数実行をロールバックしても、カーソルの位置は変わりません。

また、上記例ではスキーマ名の修飾を加えて、パッケージ関数を呼び出しています。パッケージはスキーマに属するオブジェクトです。

パッケージ内の関数やプロシージャは plisql（PL/iSQL）という手続き言語で記述します。今のところこれはパッケージに対応している以外は PL/pgSQL とほぼ同じもので、PL/SQL で書かれたコードはそのままでは動作しません。

定義されているパッケージの一覧は以下の問い合わせで確認できます。今のところ psql の \d コマンドはパッケージに対応していません。

ivdb1=# SELECT pkgname, pkgnamespace::regnamespace, pkgowner::regrole
          FROM pg_package;
 pkgname | pkgnamespace | pkgowner
---------+--------------+----------
 pkg2    | ivorysql     | ivorysql
 pkg1    | ivorysql     | ivorysql
(2 行)

また、1.0バージョンではパッケージの宣言と定義を psql のプロンプトで直接入力するとうまく動作しません。ファイルから読み込む形で使用する必要がありました。

UPDATE、DELETE の互換構文サポート

IvorySQL は UPDATE文、DELETE文における、Oracle 特有の構文をサポートしています。

UPDATE文で以下のように更新対象テーブルの別名が指定できます。

ivdb1=# CREATE TABLE t1 (id int, v text);
ivdb1=# INSERT INTO t1 VALUES (1, 'AA'), (2, 'BB'), (3, 'CC');

ivdb1=# UPDATE t1 a SET a.v = 'XX' WHERE a.id = 1;

また、DELETE文で以下のように FROM を省略できます。

ivdb1=# DELETE t1 WHERE id = 2;

これらは compatible_mode設定が oracle ではなく postgres であっても、動作します。

シーケンスの互換構文サポート

IvorySQL はシーケンス操作について、Oracle の構文をサポートしています。PostgreSQL の書き方も引き続き利用可能です。

ivdb1=# CREATE SEQUENCE seq1;

ivdb1=# SELECT seq1.nextval;
 nextval
---------
 1
(1 row)

ivdb1=# SELECT seq1.currval;
 currval
---------
 1
(1 行)

ivdb1=# SELECT nextval('seq1');
 nextval
---------
 2
(1 行)

こちらも compatible_mode設定に関わりなく、常にこのように動作します。

バイト単位文字数のサポート

文字列型に関する Oracle と PostgreSQL の違いは、Oracle では NCHAR、NVARCHAR2、VARCHAR2 という PostgreSQL には無いデータ型が使われることと、データ型に指定する文字列長の単位がデフォルトではバイト単位（PostgreSQL では必ず文字単位）であるということです。

IvorySQL では、orafce拡張により VARCHAR2型と NVARCHAR2型が提供されます。また、設定nls_length_semantics に char または byte を設定することで、文字列長の単位を文字単位またはバイト単位に指定できます。

単体配布されている orafce でも VARCHAR2型は提供されますが、以下のようにバイト単位での上限を超えた文字を切り捨てる動作になっていました。エラーになるのが Oracle互換の動作です。

orafce=# SELECT VARCHAR2(10) 'あいうえお';
 varchar2
----------
 あいう
(1 行)

（本動作は v1.1 で IvorySQL動作も orafce同様に文字を切り捨てる動作の方に変更されました）

IvorySQL で nls_length_semantics = byte を指定すると、バイト単位文字列長を超えたときには以下のようにエラーになります。また、NVARCHAR2型を使った場合、これは文字列長が必ず文字単位になるデータ型ですので、エラーになりません。

ivdb1=# SET nls_length_semantics TO byte;
ivdb1=# SELECT VARCHAR2(10) 'あいうえお';
ERROR: value too long for type varchar2(10 byte)

ivdb1=# SELECT NVARCHAR2(10) 'あいうえお';
 nvarchar2
------------
 あいうえお
(1 行)

nls_length_semantics設定は CHAR型、VARCHAR型の動作にも同様に影響します。

一方で nls_length_semantics = byte のときに、必ず文字単位であるはずの NCHAR型においてもバイト単位として扱われてしまいます。これは、IvorySQL や orafce による拡張が無くとも、PostgreSQL において NCHAR型が CHAR型の別名として受け入れられていることに起因すると考えられます。今後 IvorySQL が明示的に NCHAR型をサポートすることで、このような不整合が解消されることが望まれます。

対応していないOracle互換動作

本節では IvorySQL 1.0 ではサポートされていない、いくつかの機能について記載します。

NUMBERデータ型

IvorySQL のドキュメント上のサンプルではしばしば NUMBER型が登場しますが、今のところこれは IvorySQL 1.0 では提供されません。ネイティブの PostgreSQL に移植するときのように NUMERIC、integer、bigint などのいずれか数値データ型を選んで NUMBER型の代わりに使用する必要があります。

また、NUMERIC型を使う場合には注意が必要です。oracle互換のデータ型や演算子を透過的に使うために本例では search_path設定に oracleスキーマを含めていましたが、そうしていると数値リテラルを使った式で、使用する演算子を特定できずに以下のようなエラーを起こします。

ivdb1=# CREATE TABLE t_num (numcol numeric, v text);
ivdb1=# INSERT INTO t_num VALUES (1, 'AAA'), (2, 'BBB'), (3, 'CCC');

ivdb1=# SELECT * FROM t_num WHERE numcol = 1;
ERROR: operator is not unique: numeric = integer

ivdb1=# SET search_path TO "$user", public; -- search_path から oracle を外せば動作
ivdb1=# SELECT * FROM t_num WHERE numcol = 1;
 numcol | v
--------+-----
      1 | AAA
(1 行)

これは numcol = 1 ではなく numcol = '1' と書くか、数値部分をプリペアドステートメントのパラメータとして渡す限りは問題となりません。

NUMBER型は、開発中バージョンのドキュメントには対応型として明示的に記載があり、今後のバージョンで追加される予定のようです。（→ こちらは 1.1バージョンで追加されました。）

NULL と 空文字列の同一視

Oracle特有の振る舞いに、文字列データ型において NULL と空文字列（”）を同一視するということがあります。文字列連結では NULL が空文字列として扱われる一方、その他の文字列関数や演算子、NOT NULL制約では空文字列が NULL として扱われます。

この非互換性について IvorySQL固有のサポートは無く、ドキュメントにも言及がありません。しかしながら、同梱の orafce拡張に含まれる関数や演算子を通していくらかの互換動作が利用可能です。
例えば、orafce.varchar2_null_safe_concat設定を on にすることで、NULL値を含む VARCHAR2型の連結を以下のように実行できます。orafce.varchar2_null_safe_concat = off なら、この SELECT結果は NULL です。

ivdb1=# CREATE TABLE t_concat (c1 varchar2, c2 varchar2);
ivdb1=# INSERT INTO t_concat VALUES ('ABC', NULL);
ivdb1=# SET orafce.varchar2_null_safe_concat TO on;

ivdb1=# SELECT '{' || c1 || c2 || '}' as concat FROM t_concat;
 concat
--------
 {ABC}
(1 row)

一方で orafce で提供される oracle互換版の文字列処理関数であっても、「SELECT length('') FROM dual」が NULL になる、といった互換動作にはなりません（0になります）。また、NOT NULL制約に空文字列が投入不能、という動作にもなりません。

まとめ

IvorySQL にはここでは紹介できなかった互換機能も多数含まれています。見てきた通り、魅力的な互換機能を有する一方、まだまだ発展途上の部分も多くあるソフトウェアといえます。

オープンソースソフトウェアであることに加え、ネイティブ PostgreSQL に対する拡張モジュールではなく、データベース全体として提供される形態であるため、新たな互換機能の追加に仕組み上の制限が無いという点は魅力的です。今後の発展に期待したいところです。

IvorySQL 1.1

2022年 1月 25日に IvorySQL 1.1 がリリースされました。以下の機能追加と修正が適用されており、本稿で問題として挙げた点のいくつかは既に改善されています。

• NUMBER型のサポート
• orafceの自動ロード
• Oracle互換モードではsearch_path設定をしなくとも自動的に互換オブジェクトを使用
• バイト単位文字数のサポートについて挙動が変更されました
• そのままでは動作しないドキュメント上のサンプルを修正

この記事では pgAdmin 4 の概要、インストールおよび起動・アクセス、DB サーバ登録の手順を説明します。

pgAdmin 4 とは

pgAdmin 4 は pgAdmin Development Team によって開発され、PostgreSQL と同じく PostgreSQL ライセンス で公開されています。Linux や Windows、macOS 上で動作し、PostgreSQL 10 以降に対応しています。PowerGres など、PostgreSQL ベースのデータベースでも利用できます。

pgAdmin 4 のおもな機能は以下のとおりです。

• SQL 実行機能
• データグリッド表示・編集機能
• 実行計画グラフィカル表示機能
• アクセス権限対話型設定機能
• 手続き言語 PL/pgSQL デバッグ機能
• スキーマ差分管理機能
• 自動 VACUUM 管理機能
• 監視ダッシュボード機能
• メンテナンス実行機能
• ジョブスケジュール実行機能
• データベースオブジェクト管理機能

pgAdmin 4 の名前についている 4 は pgAdmin の 4 世代目を表します。単にpgAdmin と書いてある場合は、1 世代前の pgAdmin III (3) を指している場合もあるので、注意してください。バージョン番号は 4 とは別についています。最新バージョンは 2022 年 1 月時点で 6.3 で、名前を含めて書くと pgAdmin 4 v6.3 になります。

pgAdmin 4 には 2 つのモードがあります。デスクトップモードはユーザが pgAdmin 4 を起動し、利用するモードです。それに対して、サーバモードは pgAdmin 4 を Web アプリケーションとして起動しておき、ユーザが Web ブラウザでログインし、利用するモードです。サーバモードは Web モードとも呼ばれます。

pgAdmin 4 のインストール

pgAdmin 4 のソースコードや各プラットフォーム向けのバイナリは ダウンロードページ で入手できます。ここでは Red Hat 系 Linux と Windows へのインストール手順を説明します。

Red Hat 系 Linux へのインストール

pgAdmin 4 は Red Hat 系 Linux として RHEL/CentOS 7 および 8、Rocky Linux 8、Fedora 33 および34 に対応しています。

Red Hat 系 Linux へのインストール手順は以下のとおりです。

1. PostgreSQL のリポジトリをインストールしている場合は、インストール対象から pgAdmin を外します。リポジトリの設定ファイルは /etc/yum.repos.d ディレクトリに格納されていて、ファイル名は RHEL/CentOS/Rocky Linux の場合は pgdg-redhat-all.repo、Fedora の場合は pgdg-fedora-all.repo です。ファイルを編集し、[pgdg-common] セクションに exclude=pgadmin* の行を追加します。

   [pgdg-common]
   name=PostgreSQL common RPMs for RHEL/CentOS $releasever - $basearch
   baseurl=https://download.postgresql.org/pub/repos/yum/common/redhat/rhel-$releasever-$basearch
   enabled=1
   gpgcheck=1
   gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG
   repo_gpgcheck = 1
   exclude=pgadmin*
   

   この設定を行っておかないと、リポジトリのインストール後に pgAdmin 4 をインストールしようとしても、なぜかリポジトリをインストールしようとし、リポジトリがインストール済みで、インストールが進まない状態になってしまいます。

   (以下、例示のため、実行しない)
   $ sudo yum -y install pgadmin4
   Last metadata expiration check: 0:00:27 ago on 2021年12月29日 04時02分58秒.
   Package pgadmin4-redhat-repo-0.9-2.noarch is already installed.
   Dependencies resolved.
   Nothing to do.
   Complete!
   

2. pgAdmin 4 のリポジトリをインストールします。リポジトリの URL は OS によって異なり、新しいバージョンがリリースされている場合もあるので、RPM 向けダウンロードページ を確認してください。以下は RHEL/CentOS/Rocky Linux の場合です。

   $ sudo yum -y install https://ftp.postgresql.org/pub/pgadmin/pgadmin4/yum/pgadmin4-redhat-repo-2-1.noarch.rpm
   (省略)
   Installed:
     pgadmin4-redhat-repo-2-1.noarch
   
   Complete!
   

3. pgAdmin 4 をインストールします。何をインストールするかによってパッケージが異なります。デスクトップモードのみの場合は pgadmin4-desktop、サーバモードのみの場合は pgadmin4-web、両方ともの場合は pgadmin4 です。ここでは両方ともインストールします。

   $ sudo yum -y install pgadmin4
   (省略)
   Installed:
     apr-1.6.3-12.el8.x86_64
     apr-util-1.6.1-6.el8.x86_64
     apr-util-bdb-1.6.1-6.el8.x86_64
     apr-util-openssl-1.6.1-6.el8.x86_64
     centos-logos-httpd-85.8-2.el8.noarch
     httpd-2.4.37-43.module_el8.5.0+1022+b541f3b1.x86_64
     httpd-filesystem-2.4.37-43.module_el8.5.0+1022+b541f3b1.noarch
     httpd-tools-2.4.37-43.module_el8.5.0+1022+b541f3b1.x86_64
     libatomic-8.5.0-4.el8_5.x86_64
     mailcap-2.1.48-3.el8.noarch
     mod_http2-1.15.7-3.module_el8.4.0+778+c970deab.x86_64
     pgadmin4-6.3-1.el8.noarch
     pgadmin4-desktop-6.3-1.el8.x86_64
     pgadmin4-server-6.3-1.el8.x86_64
     pgadmin4-web-6.3-1.el8.noarch
     python3-mod_wsgi-4.6.4-4.el8.x86_64
     xdg-utils-1.1.2-5.el8.noarch
   
   Complete!
   

   これで Red Hat 系 Linux へのインストールは完了です。

4. サーバモードをインストールした場合は、セットアップスクリプトを実行します。スクリプトでは semanage コマンドで SELinux の設定を行うので、コマンドがない場合はインストールしておきます。パッケージは RHEL/CentOS 7 の場合は policycoreutils-python、それ以外の場合は policycoreutils-python-utils です。スクリプトの途中で pgAdmin 4 のログインに使用する Email アドレス、パスワードの入力が求められるので、入力します。また、Web サーバが起動していない場合は、サービスを有効にし、起動するかの確認が求められるので、そうする場合は y、そうしない場合は n を入力します。ここでは y を入力します。

   $ sudo /usr/pgadmin4/bin/setup-web.sh
   Setting up pgAdmin 4 in web mode on a Redhat based platform...
   Creating configuration database...
   NOTE: Configuring authentication for SERVER mode.
   
   Enter the email address and password to use for the initial pgAdmin user account:
   
   Email address: (Email アドレスを入力)
   Password: (パスワードを入力)
   Retype password: (パスワードをもう一度入力)
   pgAdmin 4 - Application Initialisation
   ======================================
   
   Creating storage and log directories...
   Configuring SELinux...
   The Apache web server is not running. We can enable and start the web server for you to finish pgAdmin 4 installation. Continue (y/n)? y
   Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.
   Apache successfully enabled.
   Apache successfully started.
   You can now start using pgAdmin 4 in web mode at http://127.0.0.1/pgadmin4
   

Windows へのインストール

pgAdmin 4 は Windows として Windows 8 以降および Windows Server 2012 以降に対応しています。

pgAdmin 4 は、Windows では PostgreSQL に付属しているので、PostgreSQL のインストール時にチェックを外さなければ、インストールされています。バージョンは PostgreSQL リリース時の最新ですが、その後、アップデートされないので、少し古い場合があります。PostgreSQL 14.1 に付属の pgAdmin 4 はバージョン 6.1 で、6.3 の 2 つ前のバージョンです。

pgAdmin 4 は PostgreSQL とは別に単体でもインストールできます。Windows へのインストール手順は以下のとおりです。

1. インストーラをダウンロードします。Windows 向けダウンロードページ にアクセスし、インストールするバージョンのリンクをたどります。

   

   リンク先でインストーラのファイルをダウンロードします。ここでは v6.3 をインストールするので、pgAdmin 4 v6.3 のリンクをクリックし、pgadmin4-6.3-x64.exe のファイルをダウンロードします。

   

2. ダウンロードしたファイルをダブルクリックし、インストーラを起動します。

   

3. インストールモード選択のダイアログが表示されるので、個人向けにインストールする場合は Install for me only、全ユーザ向けにインストールする場合は Install for all users をクリックします。ここでは個人向けにインストールします。

   

4. インストーラが起動されるので、Next をクリックします。

   

5. ライセンスの内容が表示されるので、確認し、同意する場合は I accept the agreement を選択し、Next をクリックします。ライセンスに同意しなければ、インストールできません。

   

6. インストール先のフォルダのパスを入力するか、Browse… をクリックし、フォルダを選択し、Next をクリックします。個人向けにインストールする場合のデフォルトは C:\Users\ユーザ名\AppData\Local\Programs\pgAdmin 4\v6 で、ここではデフォルトのままにします。

   

7. スタートメニューのフォルダ名を入力するか、Browse… をクリックし、フォルダを選択し、Next をクリックします。フォルダを作成したくない場合は Don’t create a Start Menu folder にチェックを入れます。デフォルトは pgAdmin 4 で、ここではデフォルトのままにします。

   

8. これでインストールの準備は完了です。インストールの設定が表示されるので、確認し、問題なければ、Install をクリックします。問題があれば、Back をクリックし、前に戻って設定を変更します。

   

9. インストールが開始されるので、完了するまでしばらく待ちます。

   

10. これで Windows へのインストールは完了です。Finish をクリックすると、インストーラが閉じられます。

    

pgAdmin 4 の起動・アクセス

pgAdmin 4 の利用にあたり、デスクトップモードでの起動方法と、サーバモードでのアクセス方法を説明します。

デスクトップモードでの起動

デスクトップモードで pgAdmin 4 を起動するには、Red Hat 系 Linux では RHEL/CentOS/Rocky Linux 8 の場合には画面左上のアクティビティをクリックし、画面左のダッシュ内、一番下のグリッド (9 つの丸からなるアイコン) をクリックすると、画面中央にアプリケーションの一覧が表示されるので、その中から pgAdmin 4 をクリックします。

または以下のコマンドを実行します。

$ /usr/pgadmin4/bin/pgadmin4

Windows では pgAdmin 4 を個別にインストールした場合にはスタートメニューのアプリケーションの一覧から pgAdmin 4 フォルダ内の pgAdmin 4 をクリックします。

デスクトップモードで起動すると、最初にマスタパスワードの設定を行います。マスタパスワードは DB サーバのパスワードを暗号化するのに利用します。ここで指定したマスタパスワードは次回から起動時に入力が求められます。

表示言語はデフォルトで英語になっています。日本語に変更するには、File メニューの Preferences をクリックし、Miscellaneous 内の User language を開き、表示言語として Japanese を選択し、Save をクリックします。

表示言語の設定を反映するには、pgAdmin 4 を再起動する必要があります。

サーバモードでのアクセス

サーバモードで pgAdmin 4 にアクセスするには、Red Hat 系 Linux では Web ブラウザで http://(ホスト名または/ IP アドレス)/pgadmin4 の URL にアクセスします。ログイン画面が表示されるので、インストール時に指定した Email アドレス、パスワードを入力し、表示言語として Japanese を選択し、Login をクリックします。

Windows でもサーバモードで起動できますが、Web サーバがフレームワークに付属のテスト用なので、別途 Apache HTTP Server をインストールし、利用したほうがよいでしょう。その手順について、ここでは説明を省略しますが、興味があれば マニュアル を参照してください。

DB サーバの登録

Windows では自動的にローカルホストの DB サーバを検出し、登録してくれますが、検出されなかった場合や Red Hat 系 Linux の場合には、手動で DB サーバを登録します。

DB サーバの登録手順は以下のとおりです。

1. ダッシュボードのクイックリンク内の新しいサーバを追加をクリックします。

   

2. 登録するサーバの設定を入力し、保存をクリックします。最低限入力が必要な設定は General タブの名前、接続タブのホスト名/アドレスです。名前は識別子として使用する DB サーバの名前、ホスト名/アドレスは接続先の DB サーバのホスト名/アドレスです。ここでは、あらかじめ作成済みの PostgreSQL 14 の DB サーバを登録するため、まず、General タブで名前として PostgreSQL 14 を入力します。

   

   次に、接続タブでホスト名/アドレスとして localhost、パスワードを入力し、パスワードを保存を有効にします。

   

   ポート番号やユーザ名がデフォルトと異なる場合には、それらに合わせて設定を入力してください。

3. DB サーバの登録が完了すると、画面左のブラウザ内の指定したサーバグループ内に指定した名前で DB サーバが表示されます。ここではサーバグループ Servers 内に DB サーバ PostgreSQL 14 が表示されます。

   

   おわりに

   この記事では PostgreSQL 用の GUI 管理ツール pgAdmin4 の概要と、インストールおよび起動・アクセス、DB サーバ登録の手順を説明しました。pgAdmin 4 は多くの機能を備えていて、個々の機能は説明できていませんが、GUI なので直感的に操作できると思います。

   pgAdmin 4 は基本的にコマンド操作に不慣れなユーザ向けですが、それだけでなく、実行計画グラフィカル表示機能や手続き言語 PL/pgSQL デバッグ機能など、コマンドでは実現できない機能も提供しているので、GUI だと毛嫌いせずに一度利用してみてもよいでしょう。

この記事では、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 の備える時系列データ向けの分析機能について紹介します。