YugabyteDBの拡張機能（YugabyteDB Meetup #2 発表資料）

© 2023 NTT DATA Corporation
YugabyteDBの拡張機能
YugabyteDB Meetup #2
2023/6/14
NTTデータ技術開発本部
笠原辰仁

© 2023 NTT DATA Corporation 2
はじめに
• 自己紹介
• 笠原辰仁 (KASAHARA Tatsuhito) @kasa_zip (Twitter)
• NTTデータ技術革新統括本部技術開発本部
• PostgreSQLのサポートや周辺ツールの開発などを18年以上
• 最近はYugabyteDBなどの分散SQLデータベース/NewSQLなども調査・検証
本日はPostgreSQLユーザの視点でYugabyteDBの拡張機能(Extension)の特徴などを
お話します。PostgreSQLやYugabyteDBの基本的な話は省いていますのでご容赦ください。
本日の内容は2023年6月の時点の情報となります。またYCQLの話は含んでいません。
この資料は後日に公開します。

目次
• Extensionについて
• YugabyteDBで利用できるExtension
• YugabyteDBで独自に改良しているExtension
• YugabyteDBでサポートされると嬉しいExtension

Extensionについて

ExtensionはPostgreSQLの拡張機能を利用し、ユーザ定義の独自機能を含む
PostgreSQLへの機能追加を行うためのパッケージフレームワーク、あるいは拡張機能そのものを
指す。(本資料では拡張機能全般をExtensionと呼んでいる)
YugabyteDBはPostgreSQLと高い互換性を持っているため、PostgreSQLで利用可能な
Extensionをほぼそのまま利用することが可能。Extensionには大きく以下の3種類がある。
1. DBにオブジェクトを登録し、ユーザがそれを利用するもの
• (例 pgcrypto, pg_trgm
2. shared_preload_librariesなどに登録し、透過的に作用するもの
• (例 passwordcheck, auto_explain
3. 上記2つを併せ持つもの
• (例 pg_stat_statements, pg_hint_plan

DBにオブジェクトを登録し、ユーザがそれを利用するもの
DBにユーザ定義のオブジェクトを登録し、ユーザがそれを利用するもの。PostgreSQLはもともと
ユーザ定義のテーブルやビュー、データ型、(集約)関数、演算子、さらには新規のインデックスや
KVS/Columnarなどのデータモデルを作成し拡張できる。
多くの拡張機能はこのタイプ。利便性を高める関数やビュー、業務に特化した特殊なデータ型な
どが利用可能になる。PL/pgSQLなどのプロシージャ言語の他、CやRustなどでも作成可能。
PostgreSQL
CREATE EXTENSION xxxxx;
CREATE TABLE (col xxxx);
SELECT xxxxx();
【CREATE EXTENSIONの背後で関数などの作成が実施される】
CREATE TYPE xxxx;
CREATE FUNCTION xxxx();
・・・

DBにオブジェクトを登録し、ユーザがそれを利用するもの
ノード#1
YB-Master
YB-Tserver
ノード#2
YB-Tserver
ノード#3
YB-Tserver
YugabyteDBではSQLをTserver(postgresプロセス)で実施する。DB内に作成するテーブル
や関数などの情報はメタデータとしてMasterが管理する。そのため、DBに関数などを登録する
ExtensionはどこかのTserver上で実施すれば全てのTserverで利用可能になる。
CREATE EXTENSION xxxxx;
【関数などはMasterへ登録される】
CREATE TYPE xxxx;
CREATE FUNCTION xxxx();
・・・
CREATE TABLE (col xxxx);
SELECT xxxxx();

shared_preload_librariesなどに登録し、透過的に作用するもの
PostgreSQLのコード内部に定義されている様々なHookを利用する。 Hookは関数ポインタの
形でユーザが処理を差し込むことができるため、アドバンスな性能情報や内部処理のユーザカスタ
マイズが可能になる。shared_preload_librariesに拡張機能のライブラリを指定することで、
PostgreSQLのプロセスがForkされる際にHookの処理がロードされ有効化される。
PostgreSQL
Parse
Analyze/Rewrite
Plan
Execute
ExecutorStart_hook()
ExecutorEnd_hook()
shared_preload_libraries=
‘My_Extension’
My_ExecutorStart_hook()
My_ExecutorEnd_hook()
PostgreSQLの内部処理をフックして、独自の処理を差し込める。
例えばExecutorStart(クエリの実際の処理開始)でタイムスタンプを
取得し、ExecutorEnd(クエリの処理終了)で開始時との時間差分で
所要時間の計測などを行う、など。
Query
Result

shared_preload_librariesなどに登録し、透過的に作用するもの
YugabyteDBでも設定方法や作用はPostgreSQLと同様。shared_preload_librariesは
各Tserver個別で設定するため、例えば既存クラスタに追加のExtensionを導入する際は全て
のTserverの設定変更が必要。
ノード#1
YB-Tserver
ノード#2
YB-Tserver
ノード#3
YB-Tserver
Hookを利用するExtensionは各Tserverの(ysql_pg_confに指定される)shared_preload_librariesに
設定されることで有効化。そのため設定していないTserverでは無効になる。

2つを併せ持つもの
Hookを用いて取得される内部情報は、多くのケースで共有バッファなどに蓄積される。これら情
報の取得や情報のリセットなどをSQLで実施できるように、専用のビューや関数もセットで提供さ
れることが多い。
PostgreSQL
Parse
Analyze/Rewrite
Plan
Execute
ExecutorEnd_hook()
pg_stat_statements
pgss_ExecutorStart()
pgss_ExecutorEnd()
Query
Result
Hash Table
pg_stat_statemens view
pg_stat_statemens.reset() func
CREATE EXTENSION
pg_stat_statements;
SELECT * FROM
pg_stat_statements;
Hookで取得した情報を共有バッファ上のハッシュテー
ブルへ蓄積し、それらをCREATE EXTENSIONで
導入されるビューの形で参照させたりする。
(注意：pg_stat_statementsは他にも多数のHook
を使っている。図は簡略化している。)

2つを併せ持つもの
YugabyteDBではHookで取得される情報はTserver個別となる。例えばクエリの実行回数や累積所
要時間などのクエリの稼働統計情報を記録するpg_stat_statementsであれば、あるTserverで実行
されたクエリの性能統計情報は、そのTserver上でのみ記録している。そのためpg_stat_statements
の情報をユーザが直接参照している場足、クラスタ全体の情報を集約するのはユーザが行うことになる。
ノード#1
YB-Tserver
Query A
Query Aの稼働
統計情報を記録
Query C
ノード#3
YB-Tserver
Query Cの稼働
ノード#2
YB-Tserver
Query Bの稼働
Query B
各Tserverノード上で実行されたクエリの稼働統計情報は、それぞれ
のTserverでのみ保持される(メモリ上のデータでありTableやTabletの
形で保持されるもぼではないためレプリケーションはされない)

Extensionの挙動に作用する設定パラメータなどの種類や使い方もPostgreSQLと同様。例えば、
auto_explain.log_min_durationによる設定をユーザ(ROLE)毎に設定して実行計画ログを
出力する閾値を異なるものにする、なども可能。
このように自由度の高いユーザ定義のオブジェクト作成や内部処理に干渉できるHookなどの活用
により様々な拡張機能が開発・利用できる。Extensionに関する設定や利用方法、ノウハウは
PostgreSQLとほぼ同様のものが使える。
-- app_user1にはauto_explainによる実行計画情報の出力閾値を10秒に設定
ALTER ROLE app_user1 SET auto_explain.log_min_duration TO ‘10s’;
-- app_user2にはauto_explainによる実行計画情報の出力を無効にする設定
ALTER ROLE app_user2 SET auto_explain.log_min_duration TO -1;

YugabyteDBで利用できるExtension

YugabyteDBではいくつかのPostgreSQL向けのExtensionをサポートしている。また、
YugabyteDB独自のExtensionも提供(あるいは開発中)。
https://docs.yugabyte.com/preview/explore/ysql-language-features/pg-extensions/
代表的なExtension 備考
PostgreSQLに同梱されており
YugabyteDBに同梱しているもの
pg_stat_statements, auto_explain,
pgcrypto, passwordcheck
YugabyteDB独自の機能付与を行って
いるものあり(後述)
Third-Party-ToolでYugabyteDB
に同梱しているもの
pg_hint_plan, orafce, pg_audit
Third-Party-ToolでYugabyteDB
で利用可能
PostGIS, pgsql-postal 手動でExtensionを入手し各Tserverへ
インストール(共有ライブラリなどの配置)を
しておく
YugabyteDB独自のもの yb_pg_metrics, ycql_fdw
YugabyteDBでは「pg_stat_statements, pg_audit, yb_pg_metrics, pg_hint_plan」がデフォルトで
shared_preload_librariesに設定されている。

ここ1年くらいでも利用可能なExtensionが増えており、新規のExtensionの導入の議論も行わ
れている。
ここ最近サポートされたもの
• v2.17
• [16092] [YSQL] Import HyperLogLog extension (postgresql-hll) ★カーディナリティ(ユニーク数)推定
• v2.15
• [2778] Add support for HypoPG extension★仮想インデックスによるプランチューニング
サポートに向けて議論されているもの(一部抜粋)
• [YSQL] Support pg_partman extension ★パーティション管理
• [New Feature] support for pgvector extension ★ベクトル情報の格納
• [New Feature] Add support for the Apache age extension to enable graph operations
★グラフモデルとアクセス用の機能

YugabyteDBで独自に改良しているExtension

YugabyteDBで独自に改良しているExtension
YugabyteDBではPostgreSQLのExtensionを独自に改良しているものがある。そのため
PostgreSQLユーザからは(場合によっては良い意味で)異なる仕様に見える。
本日はpasswordcheckとpg_stat_statementsの2つを紹介。

passwordcheckの改良
passwordcheckは文字通りパスワードの強度チェックを行うためのExtension。
CREATE ROLE(USER)実行時に「check_password_hook」というHookを介して独自のパスワード
チェックをPostgreSQLで実現できる。
PostgreSQLのpasswordcheckはハードコードされた「文字数(8文字)」と「英数字と記号の併用」の
みチェックしている。そもそもユーザがコードをカスタマイズして利用する前提の作り。
一方YugabyteDBは「文字数」「記号利用有無」「大文字利用有無」「小文字利用有無」「ユーザ名が
パスワードに含まれるか」がGUCパラメータ(Gflags)により設定可能な形で作られている。(ユーザ名がパ
スワードに含まれているかどうかの判断のみ、ハードコードされている)
CREATE ROLE
check_password_hook
PostgreSQLのpasswordcheck
check_password()
YugabyteDBのpasswordcheck
check_password()
パスワード文字数と英数字と記号
併用がされているか確認
passwordcheck.minimum_length
passwordcheck.restrict_lower
・・・
文字数や大文字小文字の利用
有無などを設定パラメータに従って
確認

pg_stat_statementsの改良
pg_stat_statementsの作りはPostgreSQLとほぼ同様だが、メトリクスの形でTserverが公開してい
るエンドポイント(:13000/statements)からもJSON形式で情報を取得できるようになっている。
YugabyteDB (Tserver)
Parse
Analyze/Rewrite
Plan
Execute
ExecutorEnd_hook()
pg_stat_statements
pgss_ExecutorStart()
pgss_ExecutorEnd()
Query
Result
Hash Table
pg_stat_statemens view
/statements でのJSON
情報でのエクスポート
SELECT * FROM
pg_stat_statements;
curl
http://xxxxx/statements
(注意：YugabyteDBでもPostgreSQL同様に
pg_stat_statementsは他にも多数のHookを使って
いる。図は簡略化している。)

◆ curlによる取得例
$ curl -s http://<Tserver稼働ホスト>:13000/statements | jq '.statements[0]'
{
"query_id": -5817076229292125425,
"query": "SELECT c.oid::pg_catalog.regclass FROM pg_catalog.pg_class c, pg_catalog.pg_inherits i
WHERE c.oid=i.inhparent AND i.inhrelid = $1 AND c.relkind != $2 ORDER BY inhseqno",
"calls": 1,
"total_time": 0.19514599999999999,
"min_time": 0.19514599999999999,
"max_time": 0.19514599999999999,
"mean_time": 0.19514599999999999,
"stddev_time": 0.0,
"rows": 0
}

また、独自に「レイテンシ(ms)のレンジとcall数」をヒストグラムとして記録する改良がv2.19で実施されており、90%ile
値などを取得できるようになっている。
https://github.com/yugabyte/yugabyte-db/commit/2fd44b1f8337fa21f4ca61569231a70f1987beb8
【Github上のCommit Messageより転載】
yugabyte=# select query, calls, yb_latency_histogram from pg_stat_statements;
-[ RECORD 1]-----------------------------------------------------------------
query | select pg_sleep($1)
calls | 9
yb_latency_histogram | [{"[0.1,0.2)": 4}, {"[0.2,0.3)": 1}, {"[0.8,0.9)": 1}, {"[1677721.6,)": 3}]
「レイテンシ(ms)のレンジとcall数」が複数のBucketで記録される。データ型はJSONB。
pg_stat_statementsでは各クエリ(ID)別にmin/max/mean/stddevは記録されるが、ヒストグラム
相当の分布情報を復元するのは難しいためDBAにはありがたい改良点。

YugabyteDBでサポートされると嬉しいExtension

YugabyteDBでサポートされると嬉しいExtension
PostgreSQLを利用しているプロジェクトでは、以下のYugabyteDBでは未サポートの
Extensionを使うケースがある。
• pg_bigm
• Pgroonga
これらは全文検索(Full Text Search)用のExtensionで、N-Gramや形態素解析での全文
検索を補助するための関数や演算子、インデックスアクセスメソッドを提供する。
YugabyteDBではpg_trgmというPostgreSQLのExtensionをサポートしているが、日本語
で多用される2文字検索ができない。YugabyteDBでもpg_bigm or PGroongaがサポート
されるとユースケースの幅が広がる。

おわりに
PostgreSQLのほとんどのExtensionがYugabyteDBでも同じように動くのは、PostgreSQL
ユーザとして既存のアプリケーションの作りや設計を流用しやすく有難い。
また、PostgreSQLコミュニティとしては非推奨機能(※)ではあるが、エンタープライズ領域で利用
することが多いpg_hint_planなどのサードパーティーツールがデフォルトで利用可能になっている
こともメリットと感じる。
さらに様々なExtensionがサポートされると、YugabyteDBの利用ケースの広がりそうで楽しみ。
(※) 本質的なクエリ記述の問題やPlannerの不具合を隠ぺいしてしまう、などの負の作用があるため。
https://wiki.postgresql.org/wiki/Not_Worth_Doing#Features_We_Do_Not_Want

YugabyteDBの拡張機能（YugabyteDB Meetup #2 発表資料）

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to YugabyteDBの拡張機能（YugabyteDB Meetup #2 発表資料）

Similar to YugabyteDBの拡張機能（YugabyteDB Meetup #2 発表資料） (20)

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation (20)

Recently uploaded

Recently uploaded (8)

YugabyteDBの拡張機能（YugabyteDB Meetup #2 発表資料）