2023.08.17

Google Cloudの新DBMS、AlloyDB for PostgreSQLを触ってみた Vol.4

AlloyDB for PostgreSQL
DBMS
Google Cloud
カラムナーエンジン

まえがき

こんにちは。開発部の高井(Peacock)です。

今回はAlloyDB連載の第4回として、カラムナーエンジン機能を試していきます。

カラムナーエンジン(columnar engine)とは?

公式ドキュメントの冒頭から読み解いてみます。要約すると以下のような感じでしょうか。

通常は行指向型のAlloyDBのテーブルですが、列指向に別のビューを作成・再編成することで大規模データに対して読み取りが高速化される機能です。

特にデータ分析用途を意識している機能のように見えます。

実際に設定してみる

何はともあれ触って試してみたいので、実際にマネジメントコンソールから設定してみます。

いつも通りクラスターの概要画面から、プライマリインスタンスを編集しフラグの欄に google_columnar_engine.enabled を新規追加します。

プライマリインスタンスの再起動が走るので、少し待ってから繋ぎに行きます。

psql コマンドで接続できました。

# PGDATABASE PGHOST PGPASSWORD PGPORT PGUSER環境変数を設定してある状態
$ psql
psql (14.7 (Homebrew), server 14.4)
Type "help" for help.

etude=> \d

手動で対象のテーブル・カラムを追加する必要があるので、CLIでコマンドを叩きます。google_columnar_engine_add 関数に第1引数としてテーブル、以降に対象カラム(省略した場合は全てのカラム)

SELECT google_columnar_engine_add(land_registry_price_paid_uk)

設定直後は自動反映されず、どうやらデフォルトで1時間待つ必要があるようです。

c.f. View information about recommended columns (公式ドキュメント)

etude=> SELECT * FROM g_columnar_schedules;
         schedule_name          |    schedule    |           next_time
--------------------------------+----------------+-------------------------------
 RECOMMEND_AND_POPULATE_COLUMNS | EVERY 1 HOUR   | 2023-06-08 08:10:30.572034+00
 DATABASE_ADVISOR               | EVERY 24 HOURS | 2023-06-08 19:22:35.608991+00
(2 rows)

デフォルトの1時間待つ意外には、手動で以下のSELECT文を叩くことで即時反映も可能です。

SELECT google_columnar_engine_recommend();

では、カラムナーストアに格納されているか確認してみます。

etude=> SELECT database_name, schema_name, relation_name, column_name, size_in_bytes, last_accessed_time FROM g_columnar_columns;
 database_name | schema_name |        relation_name        |    column_name    | size_in_bytes | last_accessed_time
---------------+-------------+-----------------------------+-------------------+---------------+--------------------
 etude         | public      | land_registry_price_paid_uk | price             |      64213751 |
 etude         | public      | land_registry_price_paid_uk | transfer_date     |      56097168 |
 etude         | public      | land_registry_price_paid_uk | postcode          |     330879722 |
 etude         | public      | land_registry_price_paid_uk | property_type     |      27961289 |
 etude         | public      | land_registry_price_paid_uk | duration          |      27960428 |
 etude         | public      | land_registry_price_paid_uk | paon              |     109789188 |
 etude         | public      | land_registry_price_paid_uk | saon              |      60701361 |
 etude         | public      | land_registry_price_paid_uk | street            |     311402185 |
 etude         | public      | land_registry_price_paid_uk | locality          |      77720824 |
 etude         | public      | land_registry_price_paid_uk | city              |      58015131 |
 etude         | public      | land_registry_price_paid_uk | district          |      56679987 |
 etude         | public      | land_registry_price_paid_uk | county            |      28227905 |
 etude         | public      | land_registry_price_paid_uk | ppd_category_type |      27960152 |
 etude         | public      | land_registry_price_paid_uk | record_status     |      27959510 |
(14 rows)

この後紹介する、執筆時点でサポートされている型は全て入っているようです。これはパフォーマンス面でも期待ができそうです。

どんな型を入れられるのか (執筆時2023年6月上旬時点の情報)

公式ドキュメントによると、以下の型はサポートされているようです。結構ありますが、件数下限(5000件以下は適用されない)ようです。やはりデータ分析用途で想定されていそうです。外部キーなども執筆時点ではまだのようです。

bigint
char
date
decimal
double precision
float4
float8
integer
json
jsonb
numeric
real
serial
short
smallint
text
timestamp
varchar

パフォーマンス

第2回で回した計測をベースに、以下のような計測SQLに変えて実行してみました。

SELECT 
    price,
    transfer_date,
    postcode,
    property_type,
    newly_built,
    duration,
    locality,
    city,
    district,
    county
FROM land_registry_price_paid_uk LIMIT 1000000;

例によって実際の計測値は載せられないので、気になる方はコードを書き換えて試してみてください。

実際の数字は例によって掲載できませんが、今回のマシンスペック・サンプルデータでは約2倍ほどのパフォーマンス改善が見られました。

大量のデータを扱う分析系用途だと特に重宝しそうです。