「GPU」×「PG-Storm」で爆速PostgreSQLを体験してみよう

データベース

技術解説

連載 [第5回] :

「PG-Strom」でGPUを活用した超並列処理を試す

2024年6月21日(金)

遠山洋平

連載第5回となる今回は、実際に「PG-Strom」を動かしながら、皆さんにその性能を体験いただくための手順と操作方法を解説します。

はじめに

本連載では、これまでPG-Stromの概要、高速化の原理、ベンチマーク手法やベンチマーク結果などを紹介してきました。大規模での利用になると、NVIDIAのエンタープライズ向けのGPUやNVIDIAのGPUDirect対応の高速なストレージが必要になってきますが、ここまでの連載を通じて、まずはともあれ手元の環境で触ってみたくなってきたのではないかと思います。

そこで今回は、オープンソースで開発され、パッケージも公開されているOSS版のPG-Stromを実際に動かしてみたいと思います。

PG-Stromの動作要件

というわけで、早速触ってみましょう。必要なものは以下のとおりです。なお、WindowsのWSLには対応していないため、Linux版のPostgreSQLとCUDA、GPUドライバーが必要です。

インストールするバージョンのCUDAと互換性のあるLinux
CUDA 12.2Update 1以降^*1に対応するNVIDIAのGPU
CUDA 12.2Update 1以降^*1に対応するLinuxとLinux kernel
インストールしたCUDAバージョンと互換性のあるGPUドライバー

*1: 最近のPG-StromはCUDA 12.3でビルドされているため、推奨はCUDA 12.3です。ただしPG-Strom 5.1では違うバージョンのCUDAが導入されていると再ビルドが走る設計になりましたので、CUDA 12.2Update 1以降が入っていればおおよそ問題はありません。それより前のバージョンについては動作保証されません

PG-Stromは、CUDAとGPUドライバーが正常にLinux上で動作していることが重要です。また、導入するLinuxディストリビューションがCUDAの要件を満たす必要があります。

なお、今回使用するPG-Strom 5.1は、CUDA 12.2以降とPostgreSQL 15以降のバージョンが必要です。今回は例として、PG-Strom 5.1をAlmaLinux 9.3＋CUDA 12.4.1 (CUDA 12.4 Update 1)で利用する方法を紹介します。

AlmaLinuxはNVIDIA CUDAがサポートしているOSの一覧には含まれていませんが、基本的に他のRHELクローンディストリビューションと同等なので、Rocky Linuxの手順を参考にインストールしてみてください。

また、他のLinuxディストリビューションを使う場合は、上記のほか、開発ツールのインストールをしたうえでソースビルドによるインストールをお試しください。著者の環境ではRHEL 8および9、Rocky Linux、AlmaLinux、MIRACLELINUX、UbuntuなどでソースビルドしたPG-Stromの正常動作を確認しています。基本的にはCUDAをサポートするx86_64なLinuxで、CUDA 12.2以降と適切なGPUドライバー、PostgreSQL 15以降がインストールされていれば、どのLinuxディストリビューションでも動作するはずです。

事前準備

RHELやRHELクローンではデフォルトで有効化されているパッケージリポジトリーの他、いくつかのリポジトリーの有効化が必要です。1つはEPEL(Extra Packages for Enterprise Linux)で、もう1つはRed Hat CodeReady Linux Builderです。RHELクローンの場合はpowertoolsやCRBという名前のリポジトリーです。

AlmaLinux 9の場合は、次のように実行してください。

`1`	`$ sudo dnf -y install epel-release`

`2`	`$ sudo dnf config-manager --set-enabled crb`

開発ツールのインストールも必要です。その他、関連するパッケージをインストールします。

`1`	`$ sudo dnf -y groupinstall 'Development Tools'`

`2`	`$ sudo dnf -y install wget git`

なお、このガイドに従ってインストールする場合は、SELinuxについては標準設定から変更する必要はありません。

CUDAのインストール

CUDAは公式サイトの手順に従ってインストールします。Linux版は様々なディストリビューションに対応しているため、導入する「Distribution」を選択すると手順が示されます。AlmaLinuxの場合は(同じRHELクローンである)「Rocky」を選ぶと表示される手順と同様のコマンドを実行すればOKです。

バージョンはインストールしたOSのバージョンを選択します。今回の場合は「9」を選び、Installer Typeは「rpm(local)」を選択します。もしrunfileを使ったCUDAのインストールに慣れている場合は、そちらでインストールしても構いません。

「rpm(local)」を選んだ場合は、次のように実行します。

1$ wget https://developer.download.nvidia.com/compute/cuda/12.4.1/local_installers/cuda-repo-rhel9-12-4-local-12.4.1_550.54.15-1.x86_64.rpm
2$ sudo rpm -i cuda-repo-rhel9-12-4-local-12.4.1_550.54.15-1.x86_64.rpm
3$ sudo dnf clean all
4$ sudo dnf -y install cuda-toolkit-12-4

CUDAのインストール後は互換性のあるGPUドライバーをインストールします。Turing世代以降のGPUの場合は「open kernel module flavor」が利用できます。それより古い世代のGPUを使う場合は「legacy kernel module flavor」を選択してください。

OSS版では特に考慮する必要はありませんが、商用版を使う場合は「open kernel module flavor」が使える世代のGPUを選択しないと、GPU Direct Storageを使うことが難しくなります。

Turing世代以降のGPUでは、次のようにOpen kernel moduleの方をインストールします。

`1`	`$ sudo dnf -y module install nvidia-driver:open-dkms`

Turing世代以前のGPUでは、従来のドライバーをインストールします。

`1`	`$ sudo dnf -y module install nvidia-driver:latest-dkms`

GPUドライバーがインストールされたら、いったん再起動します。再起動後nvida-smiコマンドを実行して、エラーが出ないことを確認してください。

Nouveauドライバーの無効化

LinuxはNVIDIAのGPUが認識されるとデフォルトでNouveauドライバーを有効にします。これは2Dグラフィックのレンダリングには充分機能するドライバーですが、今回はGPUコンピューティングのために使うのと、このドライバーが有効だと困ることもあるため、次の方法で起動時にNouveauドライバーを読み込まないように設定します。

1$ sudo su -
2# cat > /etc/modprobe.d/disable-nouveau.conf <<EOF
3blacklist nouveau
4options nouveau modeset=0
5EOF
6# dracut -f && reboot

PostgreSQLのインストール

次に、PostgreSQLをインストールします。PG-Strom 5.xでサポートされているPostgreSQLは15以降のバージョンです。今回はPostgreSQL 16をインストールする場合を例とします。PostgreSQL 15を使いたい場合は、以下16のところを15に置き換えて実行してください。

インストールするには、PostgreSQLのリポジトリーのパッケージを利用します。AlmaLinux 9の場合は、次のように実行します。

1$ sudo dnf -y install https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm
2$ sudo dnf -qy module disable postgresql
3$ sudo dnf -y install postgresql16-server postgresql16-devel
4$ sudo /usr/pgsql-16/bin/postgresql-16-setup initdb
5$ sudo systemctl enable --now postgresql-16

PG-Stromのインストール

PG-StromのパッケージはRHELおよびRHELクローン向けのrpmパッケージが用意されています。RHELおよびRHELクローンのバージョン8や9であればrpmパッケージでインストールできます。

本連載でこれまで説明してきたように、PG-StromはPostgreSQLの拡張機能として動作します。したがってPG-Stromをインストールする前にPostgreSQLがインストールされている必要があります。例えばPostgreSQL 16がインストールされている環境では、次のようにコマンドを実行します。

01$ sudo dnf -y install https://heterodb.github.io/swdc/yum/rhel9-noarch/heterodb-swdc-1.3-1.el9.noarch.rpm
02$ sudo dnf -y install pg_strom-PG16
03...
04Running transaction
05  Preparing        :                                                       1/1
06  Installing       : pg_strom-PG16-5.1-0.el9.x86_64                        1/1
07  Running scriptlet: pg_strom-PG16-5.1-0.el9.x86_64                        1/1
08  Verifying        : pg_strom-PG16-5.1-0.el9.x86_64                        1/1
09 
10Installed:
11  pg_strom-PG15-5.1-0.el9.x86_64
12 
13Complete!

PG-Strom 5.xはPostgreSQL 15および16に対応しています。PostgreSQL 15をインストールした場合、上記はpg_strom-PG15パッケージをインストールすればOKです。

詳細は取り上げませんが、次の方法でソースからPG-Stromをインストールすることも可能です。ソースビルドを行う場合は、RHELおよびRHELクローン以外のLinuxディストリビューションでも対応するCUDAとCUDAドライバーさえ導入できればPG-Stromを動かすことができます。ソースビルドについては公式のインストールガイドをご覧ください。

PG-Stromインストール後の設定

PG-Stormをインストールしただけでは、まだPostgreSQLでPG-Strom拡張機能は利用できていない状態です。次の設定を行って、PG-Strom拡張機能を有効化できるように、PostgreSQLの設定にPG-Stromに必要な設定を追記します。

1$ sudo su - postgres
2$ vi /var/lib/pgsql/16/data/postgresql.conf
3... (最終行に追記)
4shared_preload_libraries = '$libdir/pg_strom'
5max_worker_processes = 100
6shared_buffers = 8GB
7work_mem = 1GB

追記した設定をPostgreSQLに反映させるため、PostgreSQLサービスを再起動します。

1$ exit
2$ sudo systemctl restart postgresql-16
3$ journalctl -u postgresql-16

journalctl -u postgresql-16を実行した結果、次のような出力があればOKです。

01systemd[1]: Starting PostgreSQL 16 database server...
02postmaster[1326]: 2024-04-09 17:24:06.355 JST [1326] LOG:  redirecting log output to logging collector process
03postmaster[1326]: 2024-04-09 17:24:06.355 JST [1326] HINT:  Future log output will appear in directory "log".
04Apr 09 17:24:07 inspiron-3881.local.tooyama.org systemd[1]: Started PostgreSQL 15 database server.
05systemd[1]: Stopping PostgreSQL 16 database server...
06systemd[1]: postgresql-16.service: Killing process 1516 (postmaster) with signal SIGKILL.
07systemd[1]: postgresql-16.service: Deactivated successfully.
08systemd[1]: Stopped PostgreSQL 16 database server.
09systemd[1]: Starting PostgreSQL 16 database server...
10postmaster[5626]: 2024-04-09 17:40:01.447 JST [5626] LOG:  HeteroDB Extra module is not available
11postmaster[5626]: 2024-04-09 17:40:01.447 JST [5626] LOG:  PG-Strom version 5.1.0 built for PostgreSQL 15 (githash: )
12postmaster[5626]: 2024-04-09 17:40:03.483 JST [5626] LOG:  PG-Strom binary built for CUDA 12.4 (CUDA runtime 12.4, nvidia kmod: 550.54.15)
13postmaster[5626]: 2024-04-09 17:40:03.483 JST [5626] LOG:  PG-Strom: GPU0 NVIDIA GeForce GTX 1650 SUPER (20 SMs; 1725MHz, L2 1024kB), RAM 3732MB (128bits, 5.72GHz), PCI-E Bar1 0MB, CC 7.5
14postmaster[5626]: 2024-04-09 17:40:03.485 JST [5626] LOG:  [0000:00:00.0]
15postmaster[5626]: 2024-04-09 17:40:03.485 JST [5626] LOG:   - [0000:00:01.0]
16postmaster[5626]: 2024-04-09 17:40:03.485 JST [5626] LOG:     - [0000:01:00.0] ... GPU0 (NVIDIA GeForce GTX 1650 SUPER)
17postmaster[5626]: 2024-04-09 17:40:03.485 JST [5626] LOG:   - [0000:00:1b.0]
18postmaster[5626]: 2024-04-09 17:40:03.485 JST [5626] LOG:     - [0000:02:00.0] ... nvme0 (CL1-3D256-Q11 NVMe SSSTC 256GB --> GPU0 [dist=5])
19postmaster[5626]: 2024-04-09 17:40:03.564 JST [5626] LOG:  redirecting log output to logging collector process
20postmaster[5626]: 2024-04-09 17:40:03.564 JST [5626] HINT:  Future log output will appear in directory "log".
21systemd[1]: Started PostgreSQL 16 database server.

もし正常に起動しなかったら

sudo systemctl restart postgresql-16コマンドを実行してサービスが起動しない場合は、次のあたりを確認してください。

まずjournalctl -u postgresql-16で状況を確認
postgresql.confに書き加えた設定に間違いがないことを確認
適切なバージョンのLinux kernelで起動しているか
適切なバージョンのCUDAがインストールされているか
GPUドライバーが適切なバージョンが入っているか

3.についてはdkmsツールを利用することである程度吸収は可能ですが^*2、最も適切なのはインストールしたCUDAのインストールガイドに示されたSystem Requirementsを満たす同じバージョンのLinux kernel、GCC、GLibcの組み合わせの環境に導入することです。

*2: バージョンアンマッチの問題は、DKMSが使える環境であればsudo dkms autoinstall && rebootでだいたい回避できます。EPELリポジトリーにdkmsパッケージがあるので、それを使って対応できます

PG-StromがPostgreSQLで使えるか確認

次のように実行して、モジュールの読み込みができればPG-Stromの環境は準備できています。

01$ sudo su - postgres
02$ psql
03psql (16.2)
04Type "help" for help.
05 
06postgres=# CREATE EXTENSION pg_strom;
07CREATE EXTENSION
08postgres=# \dx
09                                   List of installed extensions
10   Name   | Version |   Schema   |                          Description
11----------+---------+------------+----------------------------------------------------------------
12 pg_strom | 5.1     | public     | PG-Strom - Extension for Big-Data Processing using GPU/DPU/SPU
13 plpgsql  | 1.0     | pg_catalog | PL/pgSQL procedural language
14(2 rows)

postgresデータベースはインストール時にデフォルトで生成されるデータベースです。以降の解説では使いませんので、この確認が終わったら次を実行しておきましょう。

`1`	`postgres=# DROP EXTENSION pg_strom;`

PG-Stromを使ってみよう

ここまででセットアップが終わったので、いよいよ早速使ってみましょう! …と言っても、処理するデータがなければ使えませんよね。そこで、次の方法でテスト用データを手元のPG-Strom環境に作ってみてください。

ログインとデータベースの作成

PostgreSQLをインストールすると、デフォルトでpostgresというユーザーが作られます。今回はpostgresユーザーを使ってアクセスしますが^*3、アクセス方法は通常PostgreSQLを使うときと同じです。suコマンドでpostgresユーザーに切り替えてから実行します。

*3: セキュリティーを考慮すればデフォルトユーザーの利用は極力避けるべきという声が上がりそうですが、今回はローカルでのみ利用することを想定しているためpostgresユーザーを使っていきます

データベースを作成したら\cコマンドでそのデータベースに切り替えて、CREATE EXTENSION pg_stromを実行します。これで、このデータベース内のテーブルでPG-Strom拡張機能を使えるようになります。

1$ sudo su - postgres
2$ psql
3psql (16.2)
4Type "help" for help.
5 
6postgres=# CREATE DATABASE testdb;
7postgres=# \c testdb
8testdb=# CREATE EXTENSION pg_strom;

テストデータを使ってPG-Stromに触れてみる

次のようなコードを使って、テストデータを作成します。GENERATE_SERIESで指定する数値が大きいほどデータサイズも大きくなるため、あらかじめそれらのデータを格納できるだけのストレージの空き領域が必要です。今回の例ではおおよそ2,000万件、1GBくらいのデータが作成されます。

01=# CREATE TABLE uriage1
02(
03  number SERIAL,
04  name VARCHAR(128) NOT NULL,
05  okashi VARCHAR(128) NOT NULL,
06  amount_sold INTEGER NOT NULL
07);
08 
09=# INSERT INTO
10  uriage1 (name,okashi,amount_sold) 
11SELECT
12  (array['Alice', 'Jane', 'Ted', 'Bob'])[ceil(random() * 4)] AS name,
13  (array['Candy', 'Cookie', 'Chocolate', 'Icecream'])[ceil(random() * 4)] AS okashi,     
14  ceil(random() * 100) *10 amount_sold
15FROM
16  GENERATE_SERIES(1, 20000000);
17 
18=# VACUUM uriage1;
19 
20=# \db+
21testdb=# \db+
22                             テーブル空間一覧
23    名前    |  所有者  | 場所 | アクセス権限 | オプション | サイズ  | 説明
24------------+----------+------+--------------+------------+---------+------
25 pg_default | postgres |      |              |            | 1025 MB |
26 pg_global  | postgres |      |              |            | 565 kB  |
27(2 行)

これで、テーブルデータが生成されました。データの準備ができたので、2,000件の中から「Tedさん」が買った商品を検索してみましょう。

1=# SELECT count(name) FROM uriage1 WHERE name='Ted'; 
2  count
3---------
4 5001056
5(1 row)

あっという間に結果が現れると思います。データはランダム生成なので、次の結果は手元で実行したときとは異なる可能性がありますが、実行してすぐ結果が表示されます。

これだけでは分からないのでEXPLAIN ANALYZEを頭に付けて、もう一度クエリを実行してみましょう。GPUという文字が見えていれば、PG-Stromを使ってPostgreSQLのデータを処理できています。

01testdb=# EXPLAIN ANALYZE SELECT count(name) FROM uriage1 WHERE name='Ted';
02                                                                   QUERY PLAN
03----------------------------------------------------------------------------------------------------
04 Aggregate  (cost=55050.48..55050.49 rows=1 width=8) (actual time=669.369..675.559 rows=1 loops=1)
05   ->  Gather  (cost=55050.37..55050.48 rows=1 width=8) (actual time=669.118..675.553 rows=1 loops=1)
06         Workers Planned: 2
07         Workers Launched: 2
08         ->  Parallel Custom Scan (GpuPreAgg) on uriage1  (cost=54050.37..54050.38 rows=1 width=8) (actual time=651.687..651.689 rows=0 loops=3)
09               GPU Projection: pgstrom.nrows(name)
10               GPU Scan Quals: ((name)::text = 'Ted'::text) [plan: 20000070 -> 2106119, exec: 20000000 -> 4997303]
11 Planning Time: 0.070 ms
12 Execution Time: 675.746 ms
13(9 rows)

Arrow形式のデータをPG-Stromで利用する

PG-Stromの「arrow-fdw」というモジュールを使うと、PostgreSQLでArrowデータを扱えるようになります。先ほどのデータをArrowデータにして比較してみましょう。

次のような方法で、まずpg2arrowをインストールしてください。ここではPostgreSQL 15をインストールしていることを例に、インストール方法を紹介します。

重要なポイントは「PG-Stromと同じバージョンのソースからビルドする」ことです。PG-StromのソースはGitHubのPG-Stromプロジェクトで公開されていますが、パッケージについてはHeteroDB Software Distribution Centerで公開されています。ここからソースをダウンロードして、pg2arrowをビルドしてみましょう。

01//インストールしているのはPG-Strom 5.1.0なので
02$ rpm -q pg_strom-PG16
03pg_strom-PG16-5.1-0.el9.x86_64
04 
05//PG-Strom 5.1.0のpg2arrowを導入する
06$ wget https://heterodb.github.io/swdc/tgz/pg_strom-5.1.0.tar.gz
07$ tar zvxf pg_strom-5.1.0.tar.gz
08$ cd pg_strom-5.1.0/arrow-tools
09$ make pg2arrow PG_CONFIG=/usr/pgsql-16/bin/pg_config
10$ sudo install -o root pg2arrow /usr/local/bin/pg2arrow
11 
12//pg2arrow CLIが使えるか確認
13$ pg2arrow --help
14Usage:
15  pg2arrow [OPTION] [database] [username]
16...

インストールが終わったら、pg2arrow CLIを使って用意したテストデータをArrowデータに変換します。pg2arrowのコマンドオプションは大文字小文字の多少の違いはありますが、psql CLIと使い勝手は同じです。

1$ sudo su - postgres
2$ cd /opt/
3$ mkdir arrow1
4$ cd arrow1
5$ time pg2arrow -u postgres -d testdb -c "SELECT * FROM uriage1" -o ./uriage1.arrow
6real    0m6.480s
7user    0m2.552s
8sys 0m0.776s

これで/opt/arrow1/uriage1.arrowにPostgreSQLのテーブルデータがApache Arrowファイルとして出力されます。これをPG-Stromのarrow_fdwでPostgreSQLの外部テーブルとして登録してみましょう。

1$ psql -d testdb
2psql (16.2)
3Type "help" for help.
4 
5testdb=# IMPORT FOREIGN SCHEMA arrow_uriage1
6  FROM SERVER arrow_fdw
7  INTO public
8OPTIONS (file '/opt/arrow1/uriage1.arrow');

複数のテーブルデータを1つのデータとして利用したい場合は、fileの代わりにdirでディレクトリーを指定できます。この場合、ディレクトリーには複数のApache Arrow形式のデータを保存します。Apache Arrow形式はデータの圧縮もサポートしますが、PG-Stromで利用できるのは非圧縮のデータのみです。また混乱の元になるので、ディレクトリーにはApache Arrow形式のデータ以外は置かないようにしてください。

1IMPORT FOREIGN SCHEMA arrow_uriage_dirs
2postgres-#   FROM SERVER arrow_fdw INTO public 
3postgres-#  OPTIONS(dir '/opt/arrow1');

Arrow形式のデータをPG-Stromで使ってみる

先ほど登録したデータを使ってみましょう。使い方はこれまでの普通にテーブルデータを参照するときと一緒です。同じデータから生成したので当たり前ではありますが、クエリーを実行すると同じ結果になります。

01testdb=# SELECT count(name) FROM uriage1 WHERE name='Ted';
02  count
03---------
04 5001056
05(1 row)
06 
07testdb=# SELECT count(name) FROM arrow_uriage1 WHERE name='Ted';
08  count
09---------
10 5001056
11(1 row)

テーブルデータとArrowテーブルの比較

次に、テーブルデータとArrowデータを使って、同じクエリを実行してみましょう。1回目は少し時間がかかる傾向がありますが、おおよそ通常のテーブルのデータをArrow化することで、2倍高速にデータ処理できることが分かります。

01//テーブルデータ
02testdb=# EXPLAIN ANALYZE SELECT count(name) FROM uriage1 WHERE name='Ted';
03...
04Execution Time: 661.437 ms
05...
06Execution Time: 514.639 ms
07...
08Execution Time: 534.081 ms
09 
10//Arrowデータ
11testdb=# EXPLAIN ANALYZE SELECT count(name) FROM arrow_uriage1 WHERE name='Ted';
12...
13Execution Time: 422.378 ms
14...
15Execution Time: 247.716 ms
16...
17Execution Time: 235.581 ms

Arrowの結果に注目して、もう1度クエリーを実行してみましょう。注目すべきはfile0の列で、Arrowデータとしては510.22MBの容量のデータですが、今回の検索では147.82MBのサイズだけを読み込んでいるということが分かります。データをフルスキャンして、その中から検索した結果を出すわけではないため速いというわけです。

01testdb=# EXPLAIN ANALYZE SELECT count(name) FROM arrow_uriage1 WHERE name='Ted';
02                                                                     QUERY PLAN
03--------------------------------------------------------------------------------
04 Aggregate  (cost=9532.49..9532.50 rows=1 width=8) (actual time=409.240..409.282
05 rows=1 loops=1)
06   ->  Gather  (cost=9532.38..9532.49 rows=1 width=8) (actual time=409.233..409.
07277 rows=1 loops=1)
08         Workers Planned: 2
09         Workers Launched: 2
10         ->  Parallel Custom Scan (GpuPreAgg) on arrow_uriage1  (cost=8532.38..8
11532.39 rows=1 width=8) (actual time=239.874..239.875 rows=0 loops=3)
12               GPU Projection: pgstrom.nrows(name)
13               GPU Scan Quals: (name = 'Ted'::text) [plan: 20000000 -> 41667, ex
14ec: 20000000 -> 4999138]
15               referenced: name
16               file0: /opt/arrow1/uriage1.arrow (read: 147.82MB, size: 510.21MB)
17               GPU-Direct SQL: disabled (GPU-0; vfs=18922, ntuples=20000000)
18 Planning Time: 0.080 ms
19 Execution Time: 409.384 ms
20(12 行)

簡単な集計をしてみる

用意したデータを使って、簡単な集計を行ってみましょう。ストレージの応答なども関わってきますが、おおよそ最初は少し時間がかかるものの、それ以降は、そのだいたい半分の時間で同じ集計処理を実現できることが分かります。

test1: Icecreamの売上

01testdb=# SELECT sum(amount_sold) FROM arrow_uriage1 WHERE okashi='Icecream';
02    sum
03------------
04 2526466530
05(1 row)
06 
07testdb=# EXPLAIN ANALYZE SELECT sum(amount_sold) FROM arrow_uriage1 WHERE okashi='Icecream';
08...
09Execution Time: 443.496 ms
10Execution Time: 266.840 ms
11Execution Time: 262.736 ms

test2: Aliceさんが買ってくれたものの売上合計

01testdb=# SELECT sum(amount_sold) FROM arrow_uriage1 WHERE name='Alice';
02    sum
03------------
04 2523957610
05(1 row)
06 
07testdb=# EXPLAIN ANALYZE SELECT sum(amount_sold) FROM arrow_uriage1 WHERE name='Alice';
08...
09Execution Time: 421.119 ms
10Execution Time: 264.804 ms
11Execution Time: 264.428 ms

test3: 売上を商品別に集計

01testdb=# SELECT okashi, sum(amount_sold) FROM arrow_uriage1 GROUP BY okashi;
02  okashi   |    sum
03-----------+------------
04 Icecream  | 2526466530
05 Candy     | 2523868990
06 Chocolate | 2524402970
07 Cookie    | 2525721290
08(4 rows)
09 
10testdb=# EXPLAIN ANALYZE SELECT okashi, sum(amount_sold) FROM arrow_uriage1 GROUP BY okashi;
11...
12Execution Time: 719.197 ms
13Execution Time: 536.548 ms
14Execution Time: 536.005 ms

GPUDirect Storageが利用できるようなエンタープライズグレードなNVIDIAのGPUと高速なストレージを組み合わせて使うと、OSS版のPG-StromでSQLクエリーによっては2倍高速だったものが、さらに5倍から10倍以上の速度で検索できるようになります(クエリーやデータの特性によります)。

OSS版のPG-StromではNVMe SSDを1つだけ使えますが、商用版では複数のNVMe SSDを使うことができます。高速なストレージを複数束ねた領域にデータを置き、GPUコアとメモリがたくさん載ったGPUと組み合わせることで集計演算を効率化し、データの読み込み、ランダムアクセスの速度をさらに上げられるようになった結果、高速な処理を実現できるというわけです。

実際に同じクエリーをNVIDIA A100とLocal NVMe SSD×4枚＋GPUDirect Storageが利用可能な環境で実行すると、次のようになります。

01//test1 
02testdb2=# EXPLAIN ANALYZE SELECT sum(amount_sold) FROM arrow_uriage1 WHERE okashi='Icecream';
03...
04Execution Time: 91.038 ms
05Execution Time: 90.831 ms
06Execution Time: 89.886 ms 
07 
08//test2 
09testdb2=# EXPLAIN ANALYZE SELECT sum(amount_sold) FROM arrow_uriage1 WHERE name='Alice';
10...
11Execution Time: 60.314 ms
12Execution Time: 62.816 ms
13Execution Time: 62.469 ms 
14 
15//test3 
16testdb2=# EXPLAIN ANALYZE SELECT okashi, sum(amount_sold) FROM arrow_uriage1 GROUP BY okashi;
17...
18Execution Time: 145.073 ms
19Execution Time: 146.095 ms
20Execution Time: 144.506 ms

「GDSなし」は厳密には一般的な構成のPCとGPUの組み合わせでPG-StromのOSS版を使った構成で、「GDSあり」はPG-Stromの商用版ライセンスがあり、NVIDIA A100 GPUと推奨する構成のマシンにNVMe SSD4枚をRAID0で束ねたストレージをPGDATA領域として構成した環境で比較しています。

本来はGPUも含めて同じハードウェア実装した環境で比較すべきかもしれませんが、一般家庭にNVIDIA A100があるのは極めて稀なので、とりあえずゲーミング用のPC環境で動かしてみたときと、理想的な環境でクエリー実行したときの性能差を表すことにしました。同じArrowデータを使ってクエリーを実行した場合の速度比較をすると、おおよそ次のような結果になります。

比較 (単位:ミリ秒)	test1	test2	test3
GDSなし	324.36	316.78	597.25
GDSあり	90.59	61.87	145.22
速度比較(倍)	3.58	5.12	4.11

今回用意したデータの容量は512MB程度なので、十分GPUのメモリーに載るサイズです。データサイズが大きくなればなるほど、この速度差は大きくなります。

色々なソフトウェアからPG-Stromにつなぐ

PG-StromはPostgreSQLの拡張機能として動作します。それは裏を返せばPostgreSQL Serverをバックエンドに使えるソフトウェアであれば、 PG-StromのArrow toolsを使うことで、さまざまなデータをArrow形式でノードに取り込み、さまざまなアプリケーションからデータ分析に利用できることにもなります。

例えば、次のように、PostgreSQLに対応するBIツールで分析も可能です。TableauやGoogleのLooker、MicrosoftのPowerBIなど、代表的なBIツールに対応^*4しています。

Tableau

Google Looker

MS PowerBI

*4: PostgreSQLのViewの作成が必要です。詳細はCreate Viewを参照

RからPG-Stromに蓄積したデータを使って^*5データ分析に利用することもできます。

VSCodeのR拡張機能を使ってコーディング

RStudioにも対応

*5: RでPostgreSQLとの接続をするにはいくつか方法がありますが、筆者はDBIとRPostgresパッケージを導入して利用できることを確認しています

Python＋Pandasの組み合わせでも利用が可能です。例えば、JupyterLabなどを使ってPostgreSQLデータを使ったデータ分析にもPG-Stromを利用できます。

Jupyter notebookやJupyterLabからも利用できる

ログなどの集計にもPG-Stromを利用できます。PG-StromにはFluentd連携用のプラグインが用意されており、これとFluentdを組み合わせることでリアルタイムのログをArrowデータに流し込み、そのデータを使ってPG-Stromで分析するといったことが可能になっています。

Fluentdを使ったリアルタイムログ分析

このように、PG-StromにはいくつかのApache Arrowをサポートするインターフェイスが備わっています。最初に紹介したpg2arrow、今回紹介しませんでしたが、そのMySQL対応バージョンであるmysql2arrow、Fluentdのプラグインfluent-plugin-arrow-fileなどなど、これらを使うことでPG-Stromがデータ分析基盤になります。

データはPostgreSQLテーブルデータとして認識されるため、SQLクライアントを介してアクセスできるほか、PostgreSQLデータベースをデータとして利用できるようなクライアント、例えばBIツールのようなものを使ってデータ分析などに利用することも可能です。

より本格的に、より大規模なデータを処理対象としたい場合はPG-Stromの商用版ライセンスと推奨される構成を満たす必要はあるものの、今回紹介したように、PG-StromはLinuxとNVIDIA GPU、PostgreSQLがあれば簡単に導入できます。

おわりに

今回は、AlmaLinux＋CUDAの環境で、PG-Stromを活用したPostgreSQLの爆速化について解説しました。今回の記事を読んでいただいたのをきっかけに、ぜひPG-Stromを使い、皆さんご自身でその効果を体験してみてください。

著者

遠山洋平

この著者の記事一覧この著者の
記事一覧

日本仮想化技術株式会社

1981年6月宮城県生まれ。2008年に日本仮想化技術株式会社に入社し、仮想化環境の構築検証・ベンチマークなどに従事。PG-Stromとは仕事で関わったのがきっかけですが、現在はベアメタルの他、DockerやKubernetes、クラウドでPG-Stromが簡単に使えるようになることを夢見て奮闘中。

連載バックナンバー

データベース技術解説

第5回