前回の MySQL ユーザ会会(MyNA 会)の参加レポートのように間を空けすぎると後々アドベントカレンダー記事書きと重なって悲鳴を上げそうなので、今回は終わってすぐに書きました。
今回はオーディエンスとして参加しようと思っていたのですが、枠が空いたままだったので前回から連続しての登壇参加となりました。
まずは、前回「予告」されていた、澤田さんによる「PostgreSQL のソースコードの読み方」のお話。
ディレクトリ別にどのような機能のコードが保存されているのかについての説明に加え、コードを追う場合の実例を示していただきました。
src/backend がサーバ側のコード
— たいき (Taiki) (@taikik1222) 2020年12月7日
src/bin がクライアントのコード
src/common は、サーバとクライアント共通のコード。#pgunconf
palloc()とmfree()
— holic@もうずっと在宅がいい (@keiya_laurel) 2020年12月7日
ポスグレ版のmalloc()とmfree()的な感じ
親のメモリコンテキストを開放すれば子も開放される
便利だな
#pgunconf
#pgunconf で、澤田さんがPostgreSQLのソースコードを読む上でのソースディレクトリ構造や、どこから読み始めるといい、って話をしてくれてる。これMySQL編もやってほしい>MySQLコミュニティでソース読める人。
— atsuizo (@atsuizo) 2020年12月7日
同意。
ドキュメントに書いてないもののロックレベルもソースを読めばわかる、と。#pgunconf
— hmatsu47(まつ) (@hmatsu47) 2020年12月7日
(注)ALTER TABLE の種類別にどのようなロックが掛かるかをソースコードで追って確認しました。
次は、あわっちさんの「データマスキング」についてのお話。
性能調査などで本番相当のデータを使いたいが本番データをそのまま使うと個人情報や機密情報の扱いが問題になるのでマスキングを行うのですが、具体的にどんなことを行うの?という話です。
むかしオライリーから本出てたな…と思ったらもう5年前か。
— hmatsu47(まつ) (@hmatsu47) 2020年12月7日
(マスキングは個人情報だけの保護を意図したものではないけど。)https://t.co/RcKyw5plPu#pgunconf
話の最後は「わたしが欲しいマスキング機能」でした。
ロールでマスキングしたデータか生のデータか自動で出し分けてくれれば便利ですよね。 #pgunconf
— まぐろ; BOOTHに技術書典9新刊あり〼; (椎間板ヘルニア) (@tameguro) 2020年12月7日
3 番目はわたしでした。ネタはこれです。
いつものとおり #pgunconf で話す資料を事前アップロード。
— hmatsu47(まつ) (@hmatsu47) 2020年12月2日
(そしていつものとおり当日までに何度か手を入れる。はず。)https://t.co/CZ3n3kno9b
ちょっと前にバズった記事(わたしではなく他の方の、ですが)の一部を元ネタに、主キー(PK)としてシーケンスを使う vs UUIDv4 を使う小実験をしてみたお話しです。
ブログの技術記事、どうしても鵜呑みにしがちだったり(自分の意見と違うと)逆に全否定しがちだったりするわけですが、そうではなく「自分の利用ケースに合わせて採用する技術・手法などを決めましょう」ということを話してみました。
最後は藤井さんの「pg_standby の削除を検討中」についてのお話。
バックアップ用のサーバにデータを複製する方法として、PostgreSQL ではストリーミングレプリケーションよりも古い 8.3 の時代から用意されていた pg_standby ですが、あまり利用されているとは言い難いし PostgreSQL の開発を進めていく上で支障を生じる部分もあるので可能なら削除したい。…というイメージで聞いていました。
pg_standbyを削除すれば、ウォームスタンバイからの昇格、という特殊条件を考慮せずに済むようになり、PostgreSQLの開発が楽になる。 #pgunconf
— たいき (Taiki) (@taikik1222) 2020年12月7日
前述のとおり今回も登壇枠参加でしたが、
- ちょっと前にバズったネタをベースに、
- ちょっとだけ知っている MySQL と絡めて、
- ちょっとだけ「越境」して、
- ちょっとだけしか触ったことがない PostgreSQL について話す
ことによって、参加者のみなさまからのフィードバックを受けることができ、新たな知識を得ることができました。
なお、Database Internalsという書籍ではこの辺りの問題をRight-Only Appendとして紹介してると思う。postgresだとfastpathという機能?があって、リーフの右端に大量にデータが入る処理の最適化をしてるそう。 #pgunconfhttps://t.co/dzDp0VNU8H
— こば(右)- Koba as a DB engineer (@tzkb) 2020年12月7日
UUIDを主キーにするとインデックスの(リーフページをランダムで触るので)full page writesの影響が大きいという記事を昔見た記憶がある。
— Masahiko Sawada (@masahiko_sawada) 2020年12月7日
#pgunconf
(おまけの Export)
「主キーだいしゅきー」がMySQLコミュニティからPostgreSQLコミュニティに輸出?されたw #pgunconf
— atsuizo (@atsuizo) 2020年12月7日