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
lock in depth #TechLunch
Search
Livesense Inc.
PRO
April 23, 2014
Technology
77
0
Share
lock in depth #TechLunch
2012/04/04(水) @ Livesense TechLunch
発表者:桂 大介
Livesense Inc.
PRO
April 23, 2014
More Decks by Livesense Inc.
See All by Livesense Inc.
Rubyはただの⾔語に⾮ず
livesense
PRO
0
50
28新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
0
61
27新卒_総合職採用_会社説明資料
livesense
PRO
0
4.9k
27新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
0
9.4k
株式会社リブセンス・転職会議 採用候補者様向け資料
livesense
PRO
0
390
株式会社リブセンス 会社説明資料(報道関係者様向け)
livesense
PRO
1
1.7k
データ基盤の負債解消のためのリプレイス
livesense
PRO
0
620
26新卒_総合職採用_会社説明資料
livesense
PRO
0
13k
株式会社リブセンス会社紹介資料 / Invent the next common.
livesense
PRO
2
64k
Other Decks in Technology
See All in Technology
Amazon CloudFrontにおけるAIボットアクセス制御のポイント
kizawa2020
2
120
ルール・ロール・ツールを創る / Creating Rules, Roles and Tools
ks91
PRO
0
150
DI コンテナ自動生成ツールを実装してみた / intro-autodi
uhzz
0
820
データ分析基盤の信頼を支える視点と設計
yuki_saito
1
550
実例から学ぶ GuardDuty(SSH BruteForce)調査の全体フローと勘所【SecurityJAWS】
cscengineer
PRO
0
190
Sansan Engineering Unit 紹介資料
sansan33
PRO
1
4.5k
TSKaigi 2026 - 10秒のビルドを1秒へ:tsdownが切り拓く2026年のTypeScriptライブラリ開発
teamlab
PRO
1
120
Terragrunt x Snowflake + dbt で作るマルチテナントなデータ基盤構築プラットフォーム
gak_t12
0
540
【2026年版】プロジェクトマネジメント実践論|現役エンジニアが語る!~チームでモノづくりをする時のコツとは?~
mixi_engineers
PRO
1
130
既存プロダクトQAから新規プロダクトQAへ
ryotakahashi
0
180
TypeScriptで実現する既存APIを活用したリモートMCPサーバー構築 / TSKaigi 2026
soarteclab
1
190
Python開発環境にハーネス適用を検討する
yuuka51
0
370
Featured
See All Featured
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
2
200
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.2k
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
570
Future Trends and Review - Lecture 12 - Web Technologies (1019888BNR)
signer
PRO
0
3.5k
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
120
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
70
39k
Git: the NoSQL Database
bkeepers
PRO
432
67k
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
750
The Anti-SEO Checklist Checklist. Pubcon Cyber Week
ryanjones
0
140
Skip the Path - Find Your Career Trail
mkilby
1
120
How to Build an AI Search Optimization Roadmap - Criteria and Steps to Take #SEOIRL
aleyda
1
2k
Balancing Empowerment & Direction
lara
6
1.1k
Transcript
lock in depth
[email protected]
ACID • Atomicity トランザクションが「全て実行される」か「全く実行さ れない」ことを保証する • Consistency 整合性制約を満たす • Isolation
トランザクション中の過程が他から隠蔽される • Durability トランザクションが完了したら結果は永続する
• Exclusive lock and Shared lock • Read lock and
Write lock • Two-Phase Locking • Optimistic lock and Pessimistic lock • Timestamp Lock • Table-level lock and Row-level lock • Multiple granularity locking • Intention lock • Next key lock • Gap lock Lock
eXclusive and Shared lock • 排他/専有(X)ロックと共有(S)ロック • 共有ロック中は共有ロックのみ取得可 • 排他ロック中はどちらのロックも取得不可
• 共有ロック=読み込みロック • 排他ロック=書き込みロック
Two-phase locking(2PL) • ロックの取得と開放は2つのフェイズに分かれて いる • 取得の順番が違うとデッドロックが起こる • Expanding phase(Growing
phase) ロックが取得されていくフェイズ • Shrinking phase ロックが開放されるフェイズ
Pessimistic Lock • 悲観的ロック(悲観的並行制御) • トランザクション開始時に対象のロックを取得 • 取得出来ない場合は待つorエラー投げる • ロックを取得
• 安心して更新
Optimistic Lock • 楽観的ロック(楽観的並行制御) • トランザクション開始時のバージョン番号を取得 • ロックは特に取らない • トランザクション進める
• トランザクション終了時に開始時から更新されて いるかをチェック • 変更されていたらエラー投げる(orリトライ)
Optimistic Lock その2 • 実装はtimestampかバージョン番号 • ActiveSupportはlock_versionカラムを用意する と勝手にOptimistic Lockをかける •
cf. ActiveRecord::Locking::Optimistic • http://api.rubyonrails. org/classes/ActiveRecord/Locking/Optimist ic.html
Table-level lock • MyISAMでお馴染みテーブルロック • MEMORYもテーブルロック • 省メモリ、高速 • UPDATE,
DELETEがないときは使える
• 行ロック • ロックコンフリクトが少ない • InnoDB他メジャーなやつはだいたい行ロック • メモリを多く消費する • テーブル全体をロックするクエリが多いときはパ
フォーマンスが低い Row-level lock
Transaction Isolation Level • トランザクションが同時に実行されたときに、どれ くらい分離されるか(影響されないか) • ANSI/ISO SQL標準では4つ定められている •
Serializable • Repeatable Read • Read Committed • Read Uncommitted
Serializable • それぞれのトランザクションは逐次実行した場合 と同じ結果となる • 分離レベルは一番高い • 安全だが低性能
Repeatable Read • 同じ行のデータはトランザクション内で変更され ない • 同じ検索条件で新しい行が出てくること (Phantom Read)がある •
InnoDBのデフォルト分離レベル
Read Committed • コミット済みのデータのみ読み取る • 一度読み込んだデータをもう一度読み込むと データの内容が変更または削除されていること (Non-Repeatable Read)がある •
Phantom Readもある
Read Uncommitted • コミットされてなくても読み込む(Dirty Read) • Phantom, Non-Repeatableもある
トランザクション分離レベル Phantom Read Non- Repetable Read Dirty Read Serializable ×
× × Repeatable Read ◦ × × Read Committed ◦ ◦ × Read Uncommitted ◦ ◦ ◦
InnoDB • 分離レベルは全て対応 • デフォルトはREPEATABLE READ • 全ての接続を変更するときはmy.cnfで • SET
SESSION TRANSACTION ISOLATION LEVEL [LEVEL] でセッションのみも変更可 • SELECT @@tx_isolation; で確認
mysql> select @@tx_isolation; +-----------------+ | @@tx_isolation | +-----------------+ | REPEATABLE-READ
| +-----------------+ 1 row in set (0.03 sec)
InnoDB Locks • Record Lock インデックスレコードのロック • Gap Lock インデックス間、最初のインデックスの前、最後のイ
ンデックスの後ろのギャップのロック • Next Key Lock インデックスとインデックスの前のギャップの組み合 わせ
Next Key Lock DEMO
LOCK IN SHARE MODE FOR UPDATE • SELECTと同時にロックを取得 • LOCK
IN SHARE MODE は共有 • FOR UPDATEは排他
FOR UPDATE使わないと... 1. AがBEGIN, SELECT 2. BがBEGIN, UPDATE, COMMIT 3.
AがUPDATE, COMMIT REPEATABLE READだとAが読むデータは3でも 変わらないが、実際データは変更されている。 →1のSELECTをFOR UPDATEにすることで2でロッ ク待ちになる SERIALIZABLEだと常にSELECTがLOCK IN SHARE MODE
MVCC • MultiVersion Concurrency Control • 複数バージョンの同時並行性制御
User A User B SET AUTOCOMMIT=0; SET AUTOCOMMIT=0; time |
SELECT * FROM t; | empty set | INSERT INTO t VALUES (1, 2); | v SELECT * FROM t; empty set COMMIT; SELECT * FROM t; empty set COMMIT; SELECT * FROM t; --------------------- | 1 | 2 | --------------------- 1 row in set
次回は... 決戦!モナド