この連載はOSSコンソーシアム データベース部会のメンバーがオープンソースデータベースの毎月の出来事をお伝えしています。前回紹介した連載100回記念セミナー第1弾につづく第2弾について報告します。

連載100回記念第2弾「OSSデータベースは100ヶ月後も生き残れるか？」

前回にお知らせしたとおり、1月27日のオープンソースカンファレンス（OSC）2024 Osaka（大阪開催）にて本連載の100回を記念した企画セミナーの第2弾を実施しました。今回のOSC 2024 Osakaは4年ぶりに展示とセミナーの両方が会場で開催することになり、OSSコンソーシアムメンバに加えてオープンソースソフトウェア協会（OSSAJ）にもご協力いただいてセミナーを開催しました。第1弾は12月開催のOSC 2023 Fukuoka（福岡開催）において、連載期間の100ヶ月（約9年間）のOSSデータベースの変化を振り返るものでした。そこで第2弾の今回は、これから100ヶ月後を想像しながら、OSSデータベースを取り巻く状況がどう変わりそうかをテーマにしました。

データベースシステムに限らず、現在ITシステムに大きな影響を与えつつあるホットな話題はChatGPTと代表とする生成AI・大規模言語モデルでしょう。生成AIが席巻して従来のITシステムの作り方を変えてしまい、従来型のデータベースシステムの位置づけが変わったり淘汰されたりしないだろうかという問題についてパネル討論を行いました。登壇メンバはこの連載で執筆しているメンバにゲストを加えた4人です。

• 梶山 隆輔（Oracle Corporation MySQL GBU、OSSコンソーシアム データベース部会）
• 溝口 則行（TIS株式会社、OSSコンソーシアム データベース部会）
• 竹岡 尚三（株式会社アックス、OSSコンソーシアム AI IoT Robotics Automotive部会）
• 大釜 秀作（住友電気工業株式会社、オープンソースソフトウェア協会 理事・事務局長）

まず最初に、MySQLやPostgreSQLでも生成AIへの対応や共存を進めていることを示しました。ベクトルストア、ベクトル型データ表現への対応がその典型です。ベクトルストアは画像、文書ファイルなどの非構造データ、多次元データの格納に最適化したもので、キーワードの完全な一致よりも意味的な 類似性の検索を行います。レコメンデーションシステム、画像/音声認識、自然言語処理などの機械学習のモデルを活用するアプリケーションでの利用が想定されます。

さて、SQLのかわりに自然言語での問い合わせが可能になって、ITシステムに情報提示を求める入口が変わりつつあります。これまでの代表的な条件指定画面では、「⁠名前は？」「⁠地域は？」「⁠人数は？」のように項目立てした検索条件を指定するのが一般的でした。ITシステムを設計する際に画面設計から始めるのは良くある方法ですが、この条件指定方法では内部のデータをどのように持てば良いかがとてもわかりやすいものでした。

ところが生成AI時代には「何を手伝えばいいですか？」や「お困り事は何ですか？」と、好きなように指示できる入力エリアが1つあるだけです。これから構築するITシステムの実現イメージをこんな風に要求されたら、データ設計は何から始めたら良いでしょうか。この問についてパネリストからの意見をまとめると次のようなものです。

今までの設計の仕方を続けようとした場合、たしかにちょっと悩んでしまう面もありそうです。けれど、新しい入口、新しい情報提示の仕方を考える際に、生成AIなどの新しいAI技術が設計者を助けてくれるようにもなるはずです。どのような技術を採用したら良いか、またデータの持ち方の設計（スキーマ設計など）をどうしたら良いかをアドバイスしてくれることを期待できるのではないかというのです。今までの仕事の仕方をしていると“⁠おまんまを食いっぱぐれる⁠”かもしれませんが、変化を受け入れて、変化に対応していく必要があるのでしょう。

ところで、上記の課題設定の中で、テキストエリアがひとつだけの条件指定を先進的な例のように示しましたが、項目立てをした条件指定の方が使いやすかったり正しい答えが得られやすいのではないかという意見が会場から投げかけられました。たしかに、プロンプトエンジニアリングに代表されるように自由に問い掛けるというのは逆にテクニックが必要な面もありますし、現在の生成AIが間違った回答をすることもよく話題になりますので、従来型の方が間違いが起こりにくいという面もあるでしょう。異なる意見としては、指定する条件項目を分割して問い掛ける画面はIT屋にはわかりやすいけれど、一般の方には圧迫感・強制感があるのではないだろうかとい見方もあります。また自然言語による問い合わせの使い勝手や正確性は今よりもはるかに進歩する期待もあります。つまり、どちらか一方が良いものというわけではないので、現実にはその中間的なところに解決方法があるのではないでしょうか。

最後にパネリストに問い掛けたのは、「⁠従来型のRDBは過去の遺物のように扱われることならないか？」という点です。従来型RDBが無くなるかということではなくて、昨今にCOBOLが悪者扱いされてしまっているように、世の中にはたくさん存在しているけれど新たに習得しようとする技術者がいなくなるということが懸念されないでしょうか。

この問については、異なる視点がいろいろありそうです。ひとつはYes（そのようになる）側の意見で、前述のようにツールの癖を考慮した設計をしたりチューニングテクニックを駆使したりというのは新しいAI技術に頼ることに期待できるので、DB技術者に求められるスキルが変わるだろうという意見です。別の見解としては、従来型の構造を持った（データ型や項目が明確な）データベースが必要になる場面もまだまだたくさんあるというもので、IoT分野など膨大な数値データなどを捌く分野がその一例でしょう。でも、そのような分野でも、技術者が知恵と経験で対処してきたやり方から、高度なAIに助言を求めるやり方が増えていそうです。

生成AIなどの高度なAI技術にデータベース技術者の仕事が今すぐ奪われることはなさそうですが、100ヶ月後には私たち仕事の仕方もかなり変わっているような気がします。

このパネル討論で使用したスライド資料（ベクトル型データなどの参考資料や討論の論点）は、OSSコンソーシアムのWebページで公開します。

［MySQL］2024年1月の主な出来事

1月にはMySQLのイノベーション・リリースであるMySQL 8.3.0と、MySQL 8.0のマイナーバージョン8.0.36、および各クライアントプログラムがリリースされました。MySQL HeatWaveでもMySQL 8.3.0と8.0.36が利用できるようになっています。MySQL 8.3.0は新しいリリースモデルとなって3回目のリリースです。MySQL 8.3.0および8.0.36それぞれでOpenSSLのライブラリがバージョンアップしていますので、セキュリティの観点からもバージョンアップをお勧めします。

なおMySQL 5.7は2023年10月にリリースされたMySQL 5.7.44をもってSustaining Supportのフェーズに移行したため、セキュリティ・パッチやマイナーバージョンはリリースされません。MySQL 5.7をご利用中の方はMySQL 8.3または8.0へのメジャーバージョンアップを早急に検討してください。

MySQL 8.3.0の新機能と変更点

主な変更点は下記の通りです。

• 機能変更
  • GTID （⁠global transaction identifier）が拡張され、グループ化されたトランザクションを識別するためのタグが追加可能に
  • MySQL 8.2で非推奨となったシステム変数binlog_transaction_dependency_trackingのデフォルトをWRITESETに変更
  • EXPLAIN文のJSON形式の出力フォーマットが新しくなるためフォーマットのバージョンを識別するシステム変数explain_json_format_versionの追加
• 削除された主なパラメータや機能
  • FLUSH HOSTS （⁠8.0.23で非推奨⁠）⁠ → TRUNCATE TABLE performance_schema.host_cacheを利用
  • すでに非推奨となっていた複数のレプリケーション関連のシステム変数やステータス変数、 --slave-rows-search-algorithms、 log_bin_use_v1_events、 --relay-log-info-file、 --relay-log-info-repository、 --master-info-file、 --master-info-repository、 transaction_write_set_extraction、 group_replication_ip_whitelist、 group_replication_primary_member
  • InnoDBの利用が必須となったためシステム変数--innodbと --skip-innodbが廃止
  • システム変数--character-set-client-handshakeおよび--old-style-user-limits

機能の追加と削除は下記を参照してください。

• MySQL 8.3 Reference Manual : What Is New in MySQL 8.3

システム変数とステータス変数の変更は下記を参照してください。

• MySQL 8.3 Reference Manual : Server and Status Variables and Options Added, Deprecated, or Removed in MySQL 8.3

このほかMySQL Shell 8.3.0ではクライアントサイド認証でのwebauthnをサポートしました。

［PostgreSQL］2024年1月の主な出来事

PostgreSQLのリリースは1月もありませんでした。かわりに年始にうれしいニュースがありました。

PostgreSQLが「DBMS of the Year 2023」を受賞

年始の1月2日、OSS・商用を問わずにあらゆるDBエンジン（DBMS）のランキングを毎月発表しているdb-engines.comによる、いわば年間大賞である「DBMS of the Year 2023」にPostgreSQLが選定されたことが発表されました。PostgreSQLの受賞は過去10年間で2017年、2018年、2020年につづき4度目です。発表記事によれば、受賞につながった成功要因は「最前線のDBMSテクノロジを維持しながら同時に信頼性が高く安定したプラットフォームを提供」と記されています。信頼性と安定性というここ数年間のPostgreSQLの特徴が表れていると感じます。

なお、2023年の2位はDatabricks、3位はGoogle BigQueryとのこと。また、2022年と2021年のDBMS of the YearはSnowflakeでした。これらの結果はクラウドサービスがデータベース分野でも主流になりつつあることがよくわかります。

PostgreSQLがCVE（Common Vulnerabilities and Exposures）の採番機関に

1月18日、PostgreSQLがCVE （⁠Common Vulnerabilities and Exposures）の採番機関（CNA；CVE Numbering Authority）となったことが発表されました。これにより独自のCVE番号を割り当て、PostgreSQLやPostgreSQLと密接に関連するプロジェクトのCVE情報を公開できるようになりました。

IPA（独立行政法人情報処理推進機構）の共通脆弱性識別子CVE概説によると、CVE（共通脆弱性識別子；Common Vulnerabilities and Exposures）は、個別製品中の脆弱性を対象として、米国政府の支援を受けた非営利団体のMITRE社が採番している識別子です。そして、CVE番号付け機関（CNA）は、CVEプログラムによって認可されたベンダー、研究者、オープンソース、CERTなどで、脆弱性にCVE IDを割り当てて独自の対象範囲内でCVEレコードを公開する組織です。

PostgreSQL関連で割り当てられているCVE番号はセキュリティ情報にまとめられています。

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

オンサイト（会場）開催が復活しつつあります。また、利便性のあるオンライン開催もこの3年間で定着し、オンサイト／オンライン／ハイブリットが混在するようになってきました。興味を持たれて参加したいイベントの開催形態にご注意ください。

ベクトル型データの利活用がもたらすもの ～EPAS16 Advanced Securityの重要性～

2023年度JEITA ソフトウェアエンジニアリング技術ワークショップ ～生成AIによってソフトウェアエンジニアリングはどう変貌するか～

Cloud Optimization Forum ～お客様事例⁠：コストだけではなかった⁠。MySQLをOCIへ移行してみて分かったこと～

HeatWavejp主催 HeatWavejp Meetup #06 MySQL HeatWave へのデータ同期はどうするの！？

Oracle MySQL入門セミナー　セキュリティー＆バックアップ基礎編

ITmedia DX Summit Vol.19（データ基盤/活用）

第45回 PostgreSQLアンカンファレンス@オンライン

サポート事例から学ぶ！PostgreSQL 多機能ミドルウェア Pgpool-II の最適解

db tech showcase 2023 アーカイブ動画

オープンソースカンファレンス2024