Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Serializabilityとは何か
Search
Takashi HOSHINO
January 13, 2023
Technology
0
160
Serializabilityとは何か
Serializability理論でよく使われるページモデルの簡単な解説と、ページモデルで困る例をいくつか紹介し、それらを統一的に解釈できるようにViewの再解釈を試みる。
Takashi HOSHINO
January 13, 2023
Tweet
Share
More Decks by Takashi HOSHINO
See All by Takashi HOSHINO
Fairer and More Scalable Reader-Writer Locks by Optimizing Queue Management
starpos
0
150
データベース論文朝輪のススメ
starpos
0
620
Lock Algorithm 色々
starpos
0
94
Other Decks in Technology
See All in Technology
Adapty_東京AI祭ハッカソン2025ピッチスライド
shinoyamada
0
220
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
11
78k
後進育成のしくじり〜任せるスキルとリーダーシップの両立〜
matsu0228
7
3.2k
三菱電機・ソニーグループ共同の「Agile Japan企業内サテライト」_2025
sony
0
130
社内お問い合わせBotの仕組みと学び
nish01
1
530
セキュアな認可付きリモートMCPサーバーをAWSマネージドサービスでつくろう! / Let's build an OAuth protected remote MCP server based on AWS managed services
kaminashi
3
260
Vibe Coding Year in Review. From Karpathy to Real-World Agents by Niels Rolland, CEO Paatch
vcoisne
0
110
AI時代だからこそ考える、僕らが本当につくりたいスクラムチーム / A Scrum Team we really want to create in this AI era
takaking22
7
4k
Wasmのエコシステムを使った ツール作成方法
askua
0
110
Shirankedo NOCで見えてきたeduroam/OpenRoaming運用ノウハウと課題 - BAKUCHIKU BANBAN #2
marokiki
0
170
"プロポーザルってなんか怖そう"という境界を超えてみた@TSUDOI by giftee Tech #1
shilo113
0
170
生成AIとM5Stack / M5 Japan Tour 2025 Autumn 東京
you
PRO
0
240
Featured
See All Featured
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
The Invisible Side of Design
smashingmag
301
51k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Site-Speed That Sticks
csswizardry
11
890
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
900
Designing for humans not robots
tammielis
254
26k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Building Applications with DynamoDB
mza
96
6.7k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.7k
Transcript
Serializabilityとは何か サイボウズ・ラボ 星野 喬 1 rev20230113
自己紹介 • 星野 喬 (@starpoz) • サイボウズ・ラボ (2009〜) • 最近の活動
• トランザクション処理などの研究 • セキュリティキャンプ データベースゼミ講師 (2018〜2022) • 「データベースシステム自作入門」 https://github.com/starpos/develop-transaction-system/releases • サイボウズ・ラボユース • 「C++初心者からの脱出」同人誌 • https://github.com/starpos/get-out-of-cpp-beginners 2
トランザクション処理 • トランザクション • データベース上の一連の操作をひとまとまりにした単位 • (この資料では Tx と略す) •
トランザクション処理 • データベースに対する複数のトランザクションを正しく実行し、結果が Tx 単位で残る (ACID を短く説明) • アプリケーションソフトウェアやそれを使う人の利便性のため • 効率良く処理するという大前提はある • 効率良く • ハードウェア(CPU、メモリ、ディスク、ネットワーク機材など)を活用して • 良い性能(高スループット、低レイテンシ)で • (無駄遣いせずに) 3
正しい実行とは? • ユーザ/アプリケーションの要件を満たす実行のうち、 アプリケーション側が担わなくてすむように DBMS が頑張る部分 • Consistency: データを正しい状態に保つための補助 •
Isolation: Tx を並行(並列)実行したときの正しさを担保 • C と I は共同で正しさについての役割を担う • 諸説あり: https://fauna.com/blog/demystifying-database-systems-introduction-to- consistency-levels • Consistency という言葉に込められた様々な意味(文脈依存) • 最新の値を読める(Non-stale reads)こと • 外部の因果関係と矛盾しないこと • 複数レプリカが同じ内容に収束すること • …… 4
Serializabilityとは何か? • 直列化可能性 (Serializability の訳) • Tx 集合があたかも直列実行されたかのように(並行)実行されること • 直列実行:
Tx をひとつずつ実行すること • 直列実行したら正しく動くという仮定を置いている • 各 Tx にとっては世界でデータベースを読み書きしているのは自分だけとい う仮定の元で実行できる、つまり任意の不変条件を検証可能 • Serializability (を実現する技術)はあくまで便利な道具である点に注意 • 世界は Serializable ではない。例えば Git repository の履歴は Merge commit が作れる。 つまり、一部のアプリケーションにとって Serializability は余計なお世話。 • Serializability はデータや Tx の正しさを担保するための極端な性質ともいえる • 直列実行で済む要件の場合は迷いなく直列実行すべき 5
トランザクションの直列実行 • トランザクション 𝑡𝑖 をひとつずつ順番に実行する • 𝑡𝑖 はデータベース状態 𝑠𝑖−1 を読んで、計算し、書き、𝑠𝑖
を生成する • 結果として対応する Tx 全順序(状態の全順序)がひとつ決まる • 世界に自分しかいないので、どう読むか、どう書くかという詳細に踏み込む 必要がない • これだけだと、どのように並行に読み書きするかという議論ができないので、 もう少し詳細なモデルを作る必要がある 6 𝑠0 𝑠1 𝑡1 𝑡2 𝑠2 𝑡𝑁 𝑠𝑁 …
ページモデル • データベースをページの集合として捉える • ページは読み(R) or 書き(W) の操作 (Op) ができる
• Tx は、ページと操作のペアの集合と捉える • Single-version モデル: 各ページ上の Op の(実行)順序を主に扱う • 𝑟1 𝑥 𝑤1 𝑦 𝑟2 𝑥 𝑟2 𝑦 𝑤2 (𝑦) (ここでは Op 列順 = Op 実行順序とする) • Multi-version モデル: View を主に扱う • 𝑟1 𝑥0 𝑤1 𝑦 𝑟2 𝑥0 𝑟2 𝑦1 𝑤2 (𝑦) (Op 順序はない or 重要ではない) 7 ページモデルの詳細については Transactional Information Systems (Weikum and Vossen, Amazon) などを参照。 表記も概ねその作法に従っている。 ページ: 𝑥, 𝑦 𝑡1 = 𝑟1 𝑥 𝑤1 𝑦 (𝑥 を読んで、𝑦 を書く) 𝑡2 = 𝑟2 𝑥 𝑟2 𝑦 𝑤2 𝑦 (𝑥 と 𝑦 を読んで、𝑦 を書く) 𝑇 = {𝑡1 , 𝑡2 }
View • View: 各 Read op について、どの Tx が書いた値を読んだかの対応 •
同一ページについての Write op を含む(自分自身でない) Tx が対応する • Reads from 関係とも言う: 𝑡𝑖 reads 𝑥 from 𝑡𝑗 や 𝑡𝑖 reads from 𝑡𝑗 など • 𝑟𝑖 𝑥𝑗 は 𝑡𝑗 の書いた 𝑥 を 𝑡𝑖 が読んだことを指す • 𝑟𝑖 (𝑥) は View が与えられてないか自動的に決まることを意味する • 直列実行における View 制約 • 直前にそのページを書いた Tx を View の対象とする (Tx 列から一意に決まる) • 𝑡1 𝑡2 のとき 𝑟1 𝑥0 𝑤1 𝑦 𝑟2 𝑥0 𝑟2 𝑦1 𝑤2 𝑦 となる • Single-version モデルには直列実行と同様の View 制約がある • Op 順序から View が一意に決まる (Standard version function と呼ばれる) • Multi-version モデルでの View の扱い • Serializability 判定問題において、View は与えられるもの • Concurrency Control プロトコルにおいて、View は自分で決めるもの 8
View Serializable • View が同じ直列実行が存在するような(並行)実行のこと • 𝑟2 𝑥0 𝑟1 𝑥0
𝑤1 𝑦 𝑟2 𝑦1 𝑤2 𝑦 は、 𝑟1 𝑥0 𝑤1 𝑦 𝑟2 𝑥0 𝑟2 𝑦1 𝑤2 𝑦 = 𝑡1 𝑡2 という View が同じ直列実行が 存在するから View serializable • CV-rule: Tx 集合上の半順序 𝑅 について、 • C-rule: 𝑡𝑖 reads from 𝑡𝑗 のとき、𝑡𝑗 <𝑅 𝑡𝑖 • V-rule: 𝑡𝑖 reads from 𝑡𝑗 かつ 𝑡𝑘 が同一ページを書いているとき、𝑡𝑘 <𝑅 𝑡𝑗 ∨ 𝑡𝑖 <𝑅 𝑡𝑘 • CV-equivalent Theorem • C-rule と V-rule を満たす半順序 R が存在 View serializable • View があれば View serializable かどうか決まるので、Single-version でも Multi-version でも使える 9 もう少し詳しく知りたい人はこちら: https://qiita.com/starpoz/items/266ab514bbc308d438a6
Conflict Serializable • 競合関係(Conflicts)が同じ直列実行が存在するような(並行)実行のこと • Reader-writer Lock の理屈で競合関係を考える • 原則として
Single-version モデルで有効 • Operation 順序を 𝑂 とする(Tx 集合を 𝑇、op(𝑇) = ⨆ {𝑜 ∈ 𝑡 ∣ 𝑡 ∈ 𝑇)、𝑂 ⊂ 𝑜𝑝(𝑇) × 𝑜𝑝(𝑇)) • Multi-version でもうまく 𝑂 相当の情報を与えて Conflicts を定義すれば議論は可能 • 𝑝𝑖 𝑥 <𝑂 𝑞𝑗 𝑥 となる 𝑥 が存在する 𝑖, 𝑗 について 𝑡𝑖 , 𝑡𝑗 ∈ conf𝑝𝑞 (𝑇, 𝑂) • ただし、(𝑝, 𝑞) は (𝑤, 𝑟), (𝑤, 𝑤), (𝑟, 𝑤) のいずれか、𝑜1 <𝑂 𝑜2 は 𝑜1 , 𝑜2 ∈ 𝑂 の意味 • conf 𝑇, 𝑂 ≔ conf𝑤𝑟 𝑇, 𝑂 ∪ conf𝑤𝑤 𝑇, 𝑂 ∪ conf𝑟𝑤 (𝑇, 𝑂) • Conflict-equivalent Theorem • conf 𝑇, 𝑂 が半順序 Conflict serializable • Conflict serializable ならば View serializable • 逆は必ずしも成り立たない 10
ページモデルで扱いづらいもの • データベースレコードの読み書きよりも抽象度の高い操作 • ページモデルによる素朴な解釈では、レコードをページとみなす • 例1: Predicate reads •
例2: 口座間の資金移動 • 例3: SQL Insert/Delete の最適化 11
例1: Predicate Reads • 物理的に存在しないレコードも含めて読む • Table full scan や
Range scan など • 問題: Phantom anomaly • 𝑡1 : Table に 4 を Insert • 𝑡2 : Table の Full scan 結果 1, 5 • 𝑤1 𝑧 𝑟2 (𝑥0 , 𝑦0 ) と解釈してしまうと、𝑡1 𝑡2 は OK (View が一致する直列実行) となってしまう • しかし、𝑡1 𝑡2 直列実行による 𝑡2 の Full scan 結果は 1, 4, 5 となるはず • 物理的に存在しないレコードについて直接 Lock することなどができない • 典型的な Phantom anomaly 回避方法 • 存在しないレコードに対応するデータ構造単位をページとみなす • Table を読んだ(Full scan) vs Table を書いた(Insert) • Tree index の Leaf node を読んだ(Range scan) vs Leaf node を書いた(Insert) 12 𝑠0 : {1,5} 𝑠1 : {1,4,5} 𝑡1 𝑡2 ? 参考: Adya による Predicate の扱い http://pmg.csail.mit.edu/pubs/adya99__weak_consis-abstract.html
例2: 口座間の資金移動 • データベース状態: 𝑠 = {𝐴, 𝐵} 預金額を表す非負整数 2
口座分 • 操作: 口座間の資金移動(引き出し+預け入れ) • 例 • 𝑠0 = 𝐴: 0, 𝐵: 100 • 𝑡1 : 𝐵 から 𝐴 に 10 移動 • 𝑡2 : 𝐵 から 𝐴 に 20 移動 • 𝑡3 : 𝐴 から 𝐵 に 30 移動 • ページモデルで表現: A,B を Read および Write (Read-modify-write) • 𝑟1 𝐴0 , 𝐵0 𝑤1 (𝐴, 𝐵)𝑟2 𝐴1 , 𝐵1 𝑤2 (𝐴, 𝐵)𝑟3 𝐴2 , 𝐵2 𝑤3 (𝐴, 𝐵) • この表現だと 𝑡1 𝑡2 𝑡3 しか OK にできないが、𝑡2 𝑡1 𝑡3 も OK としたい (実際の実行順序が 𝑡1 𝑡2 𝑡3 だとしても、𝑡2 𝑡1 𝑡3 が OK だったと言える表現が望ましい) 13 𝑠0 : {𝐴: 0, 𝐵: 100} 𝑠1 : {𝐴: 10, 𝐵: 90} 𝑡1 𝑠2 : {𝐴: 30, 𝐵: 70} 𝑠3 : {𝐴: 0, 𝐵: 100} 𝑡2 𝑡3 参考(例のみ、提案モデルは異なる): https://dl.acm.org/doi/10.1145/3486601.3486707
例3: SQL Insert/Delete • SQL Insert/Delete は条件付き操作 • 対応するレコードが存在しないときのみ Insert
可能 • 対応するレコードが存在するときのみ Delete 可能 • ページモデルでの素朴な解釈では Read-modify-write 扱いとなる • 例 • 初期状態: 𝑥 に対応するレコードが存在 • 𝑡1 = 𝑟1 𝑥 𝑤1 (𝑥) 𝑥 に対応するレコードを Delete する操作 • 𝑡2 = 𝑤2 (𝑥) Upsert (存在していたら Update、していなかったら Insert) • 𝑟1 𝑥0 𝑤1 (𝑥)𝑤2 𝑥 としてしまうと、𝑡1 𝑡2 のみが OK となるが、 本来 𝑡2 𝑡1 も OK として問題ないはず 14
解決方針: View の抽象化 • View は「Tx の実行を再現するための十分条件」であると再定義する • 再現性がある(View の一致)とは、再現に必要なデータベース状態の観測結果
が一致すること • 再現に影響しない観測行為を実際には行っていたとしても View には含まれない • View serializable は「View が同じ直列実行が存在するような(並行)実行」な ので、 View の定義があればページモデルに依存せず使える 15 𝑠𝑖−1 𝑠𝑖 𝑡𝑖 状態の観測結果 状態変更の再現 呼び出し側への返り値の再現 呼び出し側からの入力(固定)
例1〜3の再解釈 • 例1: Predicate Reads • 𝑡1 : Insert 4
• 𝑡2 : Full scan 結果 {1,5}。(再現条件そのもの) • 𝑡1 𝑡2 は、再現のための観測結果({1,4,5})が一致しないので NG (View が一致しない直列実行) • 例2: 口座間の資金移動 • 𝑠0 = 𝐴: 0, 𝐵: 100 • 𝑡1 : 𝐵 から 𝐴 に 10 移動。再現条件は 𝐵 ≥ 10。 • 𝑡2 : 𝐵 から 𝐴 に 20 移動。再現条件は 𝐵 ≥ 20。 • 𝑡3 : 𝐴 から 𝐵 に 30 移動。再現条件は 𝐴 ≥ 30。 • 𝑡1 𝑡2 𝑡3 も 𝑡2 𝑡1 𝑡3 も OK • 例3: SQL Insert/Delete • 𝑡1 : 𝑥 が存在していたら Delete。再現条件は 𝑥 が存在していること。 • 𝑡2 : 𝑥 の Upsert。再現条件ナシ (どんなデータベース状態に対しても必ず実行可能) • 𝑡1 𝑡2 も 𝑡2 𝑡1 も OK 16
まとめ • Serializability の議論にはページモデルが使われてきた • ページモデルで扱いづらい事例がいくつかある • View を抽象化することでこれらの事例を統一的に扱えるようになる 17