昨年の #66 以来、1 年ぶりの LT 参加となりました。
JAWS-UG横浜 #79 AWS re:Invent 2024 re:Cap Database - connpass
（最近embed:cite形式で埋め込めないことが増えた…）
今回は、自分の LT と大栗さんの LT、そして re:Invent 2024 期間の Database アップデート振り返り、でした。
（re:Invent 2024 期間の Database アップデート振り返りについては数も少なかったのでここでは省略します）
自分の LT
これが終わったので来週の #jawsug_yokohama re:Invent2024 DB Recapネタを考えないと
— hmatsu47(まつ) (@hmatsu47) 2025年1月4日
たぶん大栗さんAurora DSQLのワークショップの話をされるんだろうなあ
（こっちはAurora DSQLを外してDynamoDB Global TablesのMRSCの話をしたほうが良いかな…）
（前年同様タグを間違えていますが）事前にこんなことを考えていたので、昨年末の名古屋 Recap で話した Aurora DSQL を外してテーマを決めました。
後ろ 2 つは個人的な関心範囲のネタです。
DynamoDB Global Tables の Multi-Region strong consistency（MRSC : 通称 Mercy）について、特にポイントになるのは
- リージョン間レプリケーション自体は非同期
- 「どこまでデータの更新が進んでいるか」をロギング（ジャーナル）システム（MRJ）が管理している
- 読み取り時は MRJ にハートビートを送り、そのコールバックが戻ってきたタイミングで「読み取り対象のデータがすべて（読み取り元のリージョンへの書き込みが完了して）読み取れる状態になった」と判定してデータを読み取る
あたりですかね。
（書き込み側の「2/3 リージョン・2/3 ゾーンへの書き込みができたら完了」というのは割とオーソドックスな考え方なので）
DynamoDB Global Tables
— nao (@nao_rapid) 2025年1月11日
非同期で強整合性なんですね。相反するように見えましたが内部動作を確認すると分かりやすいです。#jawsug #jawsugyokohama
Iwamiさんのまとめ資料、要チェック！https://t.co/aQlatKWlu9#jawsug #jawsugyokohama
— nao (@nao_rapid) 2025年1月11日
口頭で話したのを nao さんに拾っていただきましたが、今回の DynamoDB Global Tables MRSC に限らず、AWSJ 石見さんによる Zenn の生成記事群は要チェックです。
pgvector 0.8.0 の改良についてはわかりづらそうだったので加えてみました（AWS 本体のアップデートとは言えない気もしますが）。
ベクトルストアについて、Database を主戦場としている方々にはちょっととっつきづらいと思うので、BuriKaigi2025 に CfP を出したら通りました。
2/1（土）、JAWS-UG 栃木のキックオフ（#0）と被ってしまっていますが、予定が空いている方は富山（県立大）まで寒ブリを食べにきてください。
ブリ食べたいな#jawsug #jawsugyokohama
— Hajime Oguri a.k.a. Guri (@maroon1st) 2025年1月11日
そして 3 つ目のテーマは我らが（？）MySQL の話、おそらく 8.4 で戸惑うポイント第 1 位！の caching_sha2_password 認証プラグインのデフォルト化。
もっとも RDS for MySQL 8.4 は本家 MySQL とは違って mysql_native_password 認証プラグインをデフォルト無効化しない（無効化自体ができない）ので、このタイミングでデフォルトが変わったことに気づかず、8.0 以前から（ユーザーも含めて）マイグレーションで移行してきて次のマイグレーションで初めて問題に突き当たる、という流れになるかもしれません。
caching_sha2_password、MySQL8.4は追いかけてなかったけど、暗号強度以外にもパフォーマンスやライブラリ依存の回避など利点ありそう。ちゃんと調べておかないといけないな。#jawsug #jawsugyokohama
— Ryo Suzuki (@suzryo) 2025年1月11日
こちらの MySQL 8.4 以降との付き合い方については、2/22（土）開催の PHP カンファレンス名古屋 2025 で話します（こちらは Security-JAWS と被ってしまった）。
大栗さんの LT
事前に Aurora DSQL の話とは聞いていたのですが、Aurora DSQL に限定せず「マルチリージョン」という切り口でお話をされました。
Aurora DSQL における大きなポイントは、やはり楽観的同時実行制御（OCC）ですね。
DSQLの楽観的同時実行制御は名古屋Recapの1本目のときに話をしたhttps://t.co/gjFGXxloQj
— hmatsu47(まつ) (@hmatsu47) 2025年1月11日
#jawsugyokohama #jawsug
もちろん、それ以外にも（主に分散データベースならではの）制約がいくつかあります。
Aurora Limitless Databaseとの違い。これ見てもDSQLがかなり振り切ってることがわかるなぁ。
— A.Niida (@nid777) 2025年1月11日
#jawsugyokohama pic.twitter.com/mgOv5M2LEu
シーケンスや外部キー制約は分散DBには難しい
— hmatsu47(まつ) (@hmatsu47) 2025年1月11日
（的なつぶやきn回目）
#jawsugyokohama #jawsug
マルチリージョンがテーマだったので、わたしが話した DynamoDB Global Tables の MRSC の話や、MemoryDB Multi-Region の話も出てきました。
MemoryDB mutli region
— s.hiruta (@web_se) 2025年1月11日
MemoryDB Multi-Region uses the Conflict-free Replicated Data Type (CRDT) to reconcile between conflicting concurrent writeshttps://t.co/xrjh0lr54R
#jawsugyokohama
複数のリージョンでMemoryDBのデータを使いたいケースってなんだろ？#jawsug #jawsugyokohama
— たけすし (@_takemon) 2025年1月11日
MemoryDB に限らず「マルチリージョンのメリットを感じない」という意見が優勢でしたが、途中でどなたかが言われた「アメリカのような国土の広さとリージョン展開ならアリかも」という意見に同意、です（それを言おうとしたタイミングで言われた）。
あと、Aurora DSQL については、どうやら「DynamoDB (Global Tables) のリレーショナル版」という使われ方を意図されている雰囲気がある、という話も出ました。
それを考えると、可能な限りトランザクションを使わず全てのコマンド・クエリ（SQL 文）をオートコミットで投げてしまう、というポリシーで使う（そうすれば更新時の競合→リトライも最小限）のもアリかな？と思います。
DSQLでロングランクエリが発生するたび後続クエリのエラー確率は上がる。性能劣化がエラー検知・発報のトリガーになりかねない。もちろんリトライのトリガーにもなる。#jawsug #jawsugyokohama
— nao (@nao_rapid) 2025年1月11日
もしかすると少し誤解を持たれた方もいらっしゃるのでは？と思いますが、Snapshot Isolation なので、読み取りがロングクエリになったとしても不整合や更新の競合には影響せず、ロングトランザクションのほうを回避すべき、という話ですね。
