🦔

PostgreSQL アンカンファレンス参加メモ

に公開
PostgreSQL
PostgreSQL
イベント参加レポート
tech

イベントについて

https://pgunconf.connpass.com/event/368191/

セミナー室での小規模ですが DB ベンダーの方が参加したりと有識者豊富なイベントでした
OSS-DB Gold 取得を直近目指しているので興味あって参加しました

市ヶ谷@東京 開催です
午前もくもく会いって午後時間空いたので寄り道してきました

アプリケーションの技術よりも原理とかを追うのが好きです

知見

DocumentDB について

https://documentdb.io/

AWS DocumentDB が最初に思いつきそうですが、Microsoft が 2025年 1月に発表しました。
PostgreSQL DB 上での NoSQL です。

https://zenn.dev/tzkoba/articles/f34277f9663ce8

OSS の NoSQL といえば MongoDB が筆頭格でしたが、2018年に SSPL ライセンスとしました。
SSPL: (ちゃんと把握できていないですが)かなり制約の厳しいライセンス. らしい

AWS DocumentDB と名前被っているのが厄介ですね

PostgreSQL に DocumentDB が立てれて何が嬉しいのか、ですが、
嬉しいというより、MongoDB のライセンスが変化した結果、選択肢として残るのが PostgreSQL DocumentDB、という現状なのかなと思います。

NoSQL の OSS はいくつかあるようですが、Document 指向 x NoSQL となると

  • MongoDB
  • PostgreSQL DocumentDB

の選択肢があり、MongoDB のライセンスが厳しい以上、残る選択肢が PostgreSQL DocumentDB しかない、という点で価値があるんじゃないか、という見解です。

今回のDocumentDBではNoSQLの標準となることを目標にオープンソース（MITライセンス）で公開されています。

ref: https://zenn.dev/tzkoba/articles/f34277f9663ce8

物理/論理レプリケーション について

https://kinsta.com/jp/blog/postgresql-replication/

pstgresql のレプリケーションについて解説記事

レプリケーションの技術は全然知らないので、ここから先は「らしい」ばかりです

PostgreSQL には 論理/物理 レプリケーションがあるらしい
物理レプリケーションは、その仕組み的に、プライマリDB とレプリカDB は整合性が担保されるらしい
論理レプリケーションは、レプリカDB に対して書き込み等を行ったりが可能なので、整合性の破綻が可能.

この論理レプリケーションの整合性を担保する方法は何か、という話でした

制約として

  • DB 間の帯域幅は狭い
  • 常にデータ更新があるため 静止点 が無い

という中で、レコードごとにハッシュ化してその結果を比較する、という方法を提案されていました。

select md5($table_name) from $table_name;

select 句にテーブル名を宛てることが可能なんですね

postgres=# select * from orders;
 order_id | customer_id |         order_date         | total_amount |  status   | shipping_address_id 
----------+-------------+----------------------------+--------------+-----------+---------------------
        1 |           1 | 2025-10-04 05:36:52.626598 |     46300.00 | Shipped   |                   1
        2 |           2 | 2025-10-04 05:36:52.629059 |      3500.00 | Delivered |                   3

postgres=# select orders from orders;
                         orders                         
--------------------------------------------------------
 (1,1,"2025-10-04 05:36:52.626598",46300.00,Shipped,1)
 (2,2,"2025-10-04 05:36:52.629059",3500.00,Delivered,3)

postgres=# select md5(orders::text) from orders;
               md5                
----------------------------------
 e5c9ccbc312b915a4d95fd11e18252e6
 b82f5436e1747c6f9d4ec4dd86d2bd21

パフォーマンスチューニングについて

PostgreSQL の実行計画に関わる n_distinct について、まずはその計算式について紹介されていました
ただし PostgreSQL のこの計算式は甘いところが多く、実際の値とはかけ離れていた。
その結果、効率の悪い実行計画が採用されてしまっていた。
(レコード数 1000万 has 4億 レコード くらいの規模感)

対応として

  • hint で教える
    • ORM によっては対応できない
  • stas target を大きくする
    • が、あまり改善されず
  • n_distinct を手動で変更する

意図しない実行計画になったときの対策について、さまざまな意見交換がありました。
hint 使ったり view 使ったり, ...

得られた TODO

学ぶことばかり

  • postgres DB のレプリケーションについて調査
  • OSS ライセンスの種類について改めて調査
  • NoSQL の下記の種類それぞれの特性について調査
    • ドキュメント指向型
    • キーバリュー型
    • ワイドカラムストア
    • グラフ型
  • seq scan とは
  • DB の 実行計画 について
  • n_distinct について
    • 計算式把握
  • stats target とは

Discussion