この連載はOSSコンソーシアム データベース部会のメンバーがオープンソースデータベースの毎月の出来事をお伝えしています。

［MySQL］2022年5月の主な出来事

2022年5月のMySQLの製品リリースは、ありませんでした。4月末のMySQL 8.0.29のリリースに合わせて、これまでプレビュー版だったMySQL Operator for k8sがGAリリースとなりました。諸般の事情で製品発表が5月にずれ込んでしまいました。

MySQL Operator for k8sはオラクルのMySQL開発チームが開発するKubernetes用のオペレーターで、Kubernetesを利用中の環境でInnoDB Clusterを用いた高可用性構成を実現するものです。

日本MySQLユーザ会　MySQLリリースノートでわいわい言う勉強会 8.0.29

3ヵ月ごとのMySQLのマイナーバージョンアップにあわせて、日本MySQLユーザ会副代表の坂井さんが中心となって開催しているオンラインイベントが「MySQLリリースノートでわいわい言う勉強会」略してMyリノベです。5月23日に8.0.29のリリースにあわせた勉強会が開催されました。ALTER TABLEでの列の削除時にALGORITHM=INSTANTが利用可能となって高速に列の削除が可能になった点や、またutf8がutf8mb3へのエイリアスになっているおりutf8mb3に統一する方向ではあるものの統一が不十分である点などが取り上げられていました。

MySQL Operator for k8sのGAリリース

MySQL Operator for k8s は2018年にプロジェクトが始まり、一度休止を挟んで4月にGAリリースとなりました。MySQL Operator for k8sは主に以下の機能を持っています。

• MySQLサーバーやMySQL Routerの自動デプロイや管理
• 障害が発生したMySQLサーバーの復旧
• バックアップ
• ノード台数の拡張や縮小
• ローリングアップグレード

MySQLサーバーの高可用性構成であるInnoDB Clusterを利用することで自動的なフェイルオーバーが行われます。またMySQL Operator for k8sのイメージを利用してMySQL Shellを含むコンテナを作成して、MySQLサーバーへの接続や管理にMySQL Shellを利用することが推奨されています。特定のポッドのトラブル対応などためにInnoDB ClusterのコンテナにもMySQL Shellが含まれているのでそちらを利用することも可能です。

MySQL Operator for k8sはUniversal Permissive License （⁠UPL）, Version 1.0の元でオープンソースとして提供されるコミュニティ版と、サポートサービスを受けられる商用版が用意されています。商用版では今後MySQL Enterprise Editionのセキュリティ機能を利用可能となる予定となっています。コミュニティ版はGitHub上で公開されているのでぜひお試しください。リファレンスマニュアルもMySQL Operator for k8s専用の独立したものが公開されています。

なお現在のバージョンのMySQL Operator for k8sではInnoDB Clusterのシングルプライマリーモードのみに対応し、マルチプライマリーモードには対応していません。また他のレプリケーション方式もサポートされていません。

［PostgreSQL］2022年5月の主な出来事

5月はお知らせしたい情報が盛りだくさんです。そのため、次号以降に繰り越させてもらったものもありますがご容赦ください。

まずは、本家開発コミュニティから次期メジャーバージョン15の最初のベータ版が発表されました。また、現行バージョンのマイナーバージョンアップも出ています。国内からは、注目の拡張モジュールpg_ivmが登場。そして、今回のメインは5月20日に開催されたPostgreSQLエンタープライズ・コンソーシアム（PGECons）の成果発表セミナーの報告です。

次期メジャーバージョン PostgreSQL 15のベータ版が登場

5月19日、PostgreSQL Global Development Groupは次のメジャーバージョンであるPostgreSQL 15の最初のベータリリースを発表しました。ただし、一部の機能や改善はベータ期間中に変更される可能性があります。このバージョン15で実現される新機能や改善点については、次回以降に順次取り上げたいと思います。リリースノート以外にも、PostgreSQLに注目している方たちの検証結果なども集まってくるでしょう。なお、正式リリースは2022年の秋〜冬の見込みです。

PostgreSQL 14.3などサポート中バージョンのアップデート

5月12日には、現在の最新バージョン14のアップデート版14.3と、その他のサポート中の全バージョンの最新版（13.7、12.11、11.16、10.21）がリリースされました。このリリースには、過去3ヵ月に報告された多数の修正点が含まれています。また、リリースされたすべてのバージョン系列に共通のセキュリティ修正も含まれていますので要注意です（日本PostgreSQLユーザ会の情報⁠）⁠。この脆弱性（CVE-2022-1552）については、EDBのブログに詳しく解説されています。

pg_ivm（マテリアライズドビューを高速に増分更新する拡張モジュール）

IVM（Incremental View Maintenance）とは、マテリアライズドビューをリアルタイムで高速に更新する機能です。このIVM機能を、PostgreSQLの拡張モジュールとして提供するpg_ivmが正式リリースとなりました。このpg_ivmの開発では、PostgreSQLエンタープライズ・コンソーシアムが開発を支援しており、後述するPGECons成果報告会のCR（Community Relations）部会でも説明します。また、この連載でもときどき紹介させていただいている@nuko_yokohamaさんのブログでも早々にチャレンジされています。

PGECons成果報告会が開催されました

5月20日、PostgreSQLエンタープライズ・コンソーシアム（PGECons）の成果発表セミナーが開催されました。今年のセミナーも昨年と同様にオンライン開催となり、約150名の聴講エントリがあったようです。昨年の報告でも同じことを書きましたが、通常の会場開催の場合に催される打ち上げ懇親会は、残念ながら今年もおあずけでした。懇親会はOSSコミュニティ活動の大事な一部分です。来年こそは再開できることを願います。

PGEConsは、技術部会の3つのワーキンググループ（WG）が技術的な検証活動などを行っており、他に広報部会とCR（Community Relations）部会があります。今年も技術部会の3つのWGとCR部会から密度の高い調査・検証成果が発表されました。

以下に発表された活動成果の概要を紹介しますが、幅の広い多数のテーマで、高密度のものばかりです。ここで詳しく紹介することは叶いません。詳細についてはすでに公開している発表スライドをご参照いただければと思います。また、成果報告書についてもこの記事が公開される頃には、PGEConsのWebサイトから参照いただけるようになると思います。

バージョン間での性能比較

新技術検証WG（WG1）のSRA OSS, Inc. 日本支社 佐藤友章さんから、メニーコアCPUでのバージョン13と14の性能比較検証が報告されました。これは、PGEConsの恒例の活動である定点観測として行われた検証です。

検証に用いた環境はAmazon Web Service上で、DBサーバのスペックはCPUコア数が32、メモリが128GiB、測定にはpgbenchを用いています。また検証に使用した設定内容（postgresq.conf）の詳細も示されています。

検証結果ですが、参照系ではバージョン14の方がわずかに（2％ほど）性能が悪くなる結果となっています。更新系ではバージョンによる性能差はほとんど無い結果が示されました。参照系での若干の性能差が出た理由の解明にも挑んでいます。FlameGraph（フレームグラフ）を表示させることにより、index_fech_heap関数の部分で差が出ていることが示されました。このindex_fech_heap関数ですが、バージョン14では共有バッファアクセスの品質改善がされていて、それに伴うオーバヘッドが若干増えたと推察されるとのこと。

なお、この処理は更新処理でも影響はあるはずなのですが、アクセスするデータ量が参照系ほど多くないので影響が小さかったのだろうということです。ちなみに、FlameGraphとは、処理を実行されるときに呼び出される関数の処理に掛かった時間を積み上げたグラフで、炎のように見えるので「Flame」と名付けられているのだと発表の中で説明されていました。

なお、以前はWindowsでも性能を検証していましたが、今回は手が回らずできなかった様です。是非一緒に活動してくれるメンバを増やしたいとのことです。

拡張機能開発ことはじめ

課題検討WG（WG3）の日鉄ソリューションズ株式会社、永井光さんから、PostgreSQLの拡張機能の開発手順や、今回の検証で行った開発の経緯が紹介されました。ちょっと珍しい内容ですが、それだけ価値ある発表だと感じます。拡張機能の開発に挑戦される方が増えるきっかけになるのではないかと思います。

前半は、拡張機能開発の基本手順の説明です。ここではHookを用いて既存の拡張機能であるauto_explainの機能を変更することを例に説明されました。HookはPostgreSQL内で共有されているポインタで、ここに独自関数の呼び出しを割り込ませることができます。

なお、パブリッククライドサービスで用意されたPaaSとしてのPostgreSQLの場合には、ベンダ側が用意した拡張機能しか使えない場合が多いので要注意だそうです。拡張機能を独自に開発する際に作成するのは、controlファイル、SQLファイル（CREATE EXTENSIONの際に実行されるSQL⁠）⁠、Cファイル（C言語で実装されたプログラム⁠）⁠、Makefileの4種類。Amazon EC2で拡張機能組み込みを実施した場合のサンプルファイルの内容と、実施手順の例が示されました。

後半は、auto_explainの改造（魔改造？）に挑戦する報告です。開発したものを実行してみると実行計画のテーブルへのINSERT時にエラーが起こってしまうといった問題も経験し、gdbでステップ実行しながら原因究明をしたとのこと。拡張機能の作り方はわかってしまえば難しくはなさそうですが、役に立つ機能を実装するためには独特な制約もある様で、挑戦される方には今回の報告は参考になるでしょう。

shared_buffersの適正値

同じく課題検討WG（WG3）のヤマトシステム開発株式会社（所属：ヤマト運輸株式会社）鳥居英明さんから、バッファサイズを指定するパラメータであるshared_buffersの値をどの様にするのが良いのかの調査と検証結果が報告されました。

PGEConsが2019年度に実施した「機械学習を用いたPostgreSQLパラメータのチューニング検証」で得られた最適値はシステムメモリの50%でした。しかし、PostgreSQLマニュアル（13.1）ではシステムメモリに40%以上割り当てても性能は向上しないと書かれています。開発コミュニティのマニュアルではシステムメモリの25%が妥当な初期値だとされています。そこで検証によって設定方針を見つけようというのが、今回の検証のスタートだったようです。

検証環境は、システムメモリ16GBに対して、shared_buffersの値を4GB、8GB、12GB（25％:小、50％:中、75％:大）として検証しています。PostgreSQLのバッファ戦略として、OSのページキャッシュもDBのバッファの延長として考えています。

ではここから検証結果を要約します。読み込み、書き込み、並行実行性では、個別の検証ケース毎に、性能が良いのがサイズ大（75％）の場合だったりサイズ小（25％）だったりとなるケースもあるものの、全般的には影響は小さいか、または影響なしという結果でした。ところが、メモリ利用効率ではバッファサイズの影響が大きく表れていました。サイズ中（つまりDBバッファが50％の場合で、結果としてOSキャッシュもおよそ50％）の場合は、最悪の場合には同じデータがバッファとキャッシュの両方に重複して載ってしまって最も効率が悪い状態になります。このメモリ効率が悪いサイズ中（50％）の場合が、性能的にも早くに性能低下が始まっていました。 ただ、この性能検証結果は、どんな条件の場合でもこれと同じ結果になるというものではないことに留意が必要でしょう。この記事の報告では省略していますが、OSのページキャッシュ活用のメリットやデメリット、PostgreSQLのデータキャッシュアーキテクチャやバッファマネージャについての仕組みについても報告されています。単に検証結果だけを憶えるのではなくて、仕組みを理解した上で結果を理解するべきものです（簡単ではありませんが⁠）⁠。是非、報告書の本編を参照いただいて理解をしていただきたいと思います。

PostgreSQLへの移行手引き

移行WG（WG2）のNECソリューションイノベータ株式会社 黒澤彰さん、富士通Japan株式会社 多田明弘さんから、2021年リリースのPostgreSQL 14を踏まえて、これまでの移行WGの成果物との違いや注意点などについて報告されました。

移行WGでは、2017年度成果発表会にて「移行のポイントや注意点」として商用DBからPostgreSQLの移行の現実が報告されました。このときのPostgreSQLのバージョンは9.5が対象でした。そのときの報告と現在のPostgreSQL 14ではいろいろな差異が出てきています。

たとえば、パラレルクエリは9.6で追加されましたが、バージョンが上がるとパラレルクエリが使えるケースが増えているなど、機能が単に追加されただけではなく、機能レベルが上がってきています。仕様面から見ると、異種DBMSとの比較では基本的には仕様の差は残っていて、それらの仕様の違いが互換性の無い点として残っています。

また、「⁠PostgreSQL自習書」がレベルアップされました。第1版の作成時に「DB技術者の移行」（⁠既存のシステムで設計・開発・運用をしてきた移行元のDB技術者からPostgreSQLの技術者に技術者自身が移行してもらうこと）がコンセプトでした。このコンセプトを踏襲しつつ、第2版では「商用運用」と「移行」を重点にレベルアップされており、ミッションクリティカルな要件に対応する運用管理ノウハウの拡充や、「⁠トラブル時の調査手順」の新章の追加などがされています。また、「⁠Oracle技術者のためのPostgreSQL自習書」の名称の通り、Oracleからの移行注意点を拡充したものになっています。

開発コミュニティとのリレーションでの取り組み ―IVM機能の開発支援

CR（Community Relations）部会を代表してSRA OSS, Inc. 日本支社 石井達夫さんから部会で行った活動のいくつかが報告されました。CR部会の目的は、エンタープライズ領域へのPostgreSQLの適用に向けて、グローバルで進められている開発コミュニティに技術的課題をフィードバックすることです。開発コミュニティとしてもユーザ企業の声が聞けるメリットがあり、両者の橋渡しをする役割をCR部会が担っています。

発表ではCR部会の活動として3項目が紹介されましたが、この記事ではIVM（Incremental View Maintenance）機能の開発を支援する活動についてお知らせします。IVMとは、マテリアライズドビューをリアルタイムで高速に更新する機能です。この機能をPostgreSQL開発コミュニティに提案中で、CR部会メンバー企業がレビューに参加するなどして本体組み込みのIVM開発を支援しているそうです。残念ながら次期のPostgreSQL 15（2022年冬リリース予定）には入らないことになりましたが、本体への組み込みではなく拡張モジュールとしてリリースすることになりました。この拡張モジュールが「pg_ivm」です。

pg_ivmはコミュニテイに提案しているIVMの機能を拡張モジュールとして実装したもので、現状のPostgreSQLでもIVMを利用したいとの声がありました。このpg_ivmを使ってもらうことを通じて、IVMへの理解やフィードバックが得られることを期待しているとのことです。現状では機能制約があり、使用できるSELECTは、内部結合、外部結合、DISTINCTに限られ、集約は未対応になっています。今後は対応可能バージョンを増やし、また、使用できるSELECT文も増やしていきたいとのことです。

2022年6月以降開催予定のセミナーやイベント、ユーザ会の活動

オープンソースカンファレンス 2022 Online Hokkaido/Kyoto

経験豊かな講師に訊く！ PostgreSQL 入門セミナー（Webinar）

Postgres Vision 2022

MySQL 8.0 入門セミナー速習版 - インストール編 for Linux & アーキテクチャ編

IO性能が高いMySQLのマネージドサービス、MySQL Database Serviceのご紹介