CC本読み会第11回に参加
Concurrency Control and Recovery in Database Systemsという本を読む読書会に参加しました。なお11回からの途中参入になります。
p77の3.10 distributed two phase lockingから読みました。
本書について
Concurrency Control and Recovery in Database Systems
- 作者: Philip A. Bernstein,Vassos Hadzilacos,Nathan Goodman
- 出版社/メーカー: Addison-Wesley
- 発売日: 1987/02/01
- メディア: ハードカバー
- この商品を含むブログを見る
データベースの基礎理論を扱う古典になります。
私が今ポチったからアマゾンのマケプレの在庫1個になっちゃいましたwwww
と希少品を自慢したいところですが、ご安心ください。こちらから書籍と全く同内容のPDFがダウンロードできます。
内容ですが、本当に「基礎」という感じです。
超絶技術を扱っているわけではありませんが、簡単という意味でもありませんが、 データをどう保護するか、という点で非常に本質的な知識だという印象です。
私に限らずどうしても昨今のエンジニアはツールとかフレームワークに関心が言ってしまい,こういう「基礎」の部分ががいい加減になりがちですね。
感想
11回目から初参加になります。こちらは分散システムの読書会と違って、
- DBという自分の得意分野である
- 分散本ほど周りの参加者が読み込んでいない
- 分散本は36回もすでに経過しているところに途中参入した。
などの点から案外ついていけるのでは?と思っていましたが、
本書の扱うテーマはRDBMSの内部構造のものがテーマななので全くの専門外でした。
そのため非常に難しかったです。私が得意だったDBの知識というものはあくまで業務システムから利用する側の知識でしかなかったり、
そもそもの知識量が資格の勉強やここ1年くらいで頑張って身につけたものに過ぎなかったのです。*1
ちょうど1年前にこんな記事
を書いている程度の状態だったので、周りの参加者のレベルを考えるともっと精進する必要があります。
トランザクション設計はもちろん業務システムの要件として確認しますが、 ミドルウェアが担保しているトランザクションというのが自分には全く知識外でした。
質問をしましたが、「自明!」という感じの回答が帰ってきたので、本書の前のパートに書かれているのかもしれません。しっかり復習して次回は挑みたいと思います。
ライブロックも単語は知っていますが、内容は知りません。
ノート
global serializable
- local serializable
- localのものを足し混んでgrobalのserializableになるような単純なものではない。
- local serializable
global なserializableを保証するのは難しい
- 2pcにして2plにする必要がある
- corvaはこの使用
- https://ja.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture
- RMIとIIOPの対立
- GoogleのGRPC
- protocol buffer
- corvaはこの使用
- 2pcにして2plにする必要がある
Effective Javaに乗っているJavaのSerializationの代替
- 私がこの記事で書いている内容を話して見ました。
protcol bufferでも遅い
-
- 神林さんが詳しいらしい
- Object指向のDBで使う
CorbaではJavaなどのserializeなどの意味でマーシャライズという言葉を使う
- トランザクションのserializableという語句と被るから
2PLと2PCはいまだに進歩していない
- 分散合意が関わってくるから
- 2PCのまま
- 人類に分散システムは早い
3-4の章で普通のdeadlockはやっている(きちんと復習すること!)
The global waits-for graph, WFG, is the union of the local WFG,s.
- global dead lockはabortの際にvictimを選ぶ必要がある。
- その情報が必要
- がその情報は送信コストが大きくならないようにpiggybackで送る
- その情報が必要
廃止判断としてp58掲載の
The amount of effort that has already been invested in the transaction. This effort will be lost if the transaction is aborted.
The cost of aborting the transaction. This cost generally depends on the number of updates the transaction has already performed.
The amount of effort it will take to finish executing the transaction. The scheduler wants to avoid aborting a transaction that is almost finished. To do this, it must be able to predict the future behavior of active trans- actions, e.g., based on the transaction’s type (Deposits are short, Audits are long}.
The number of cycles that contain the transact~iion. Since aborting a transaction breaks all cycles that contain it, it is best to abort transac- tions that are part of more than one cycle (if such transactions exist).
のどれを送るかを選択する必要がある 最悪トランザクションそのものを送る羽目になる
- Mysqlはこのような検知はせずにタイムアウトさせる
globalなWFGは見たことがない
分散システムのdead lockの検知は難しいらしい。(タイムアウトがメイン)
今後の分散システムはmany coreが潮流になる。
マルチノードでやっている仕組みをラックの単体のサーバーに持ってきてもうまくいかない
業務要件に依存しないトランザクションの設計?実装?などがあるのか?
- トランザクションマネージャーを自分で書く必要がある
grobalのロックは使わずにlocalのロックを使う
コンカレントな処理由来のバグはベンダーに持っていってもわからないことが多い
- シナリオが複雑
- ハードウェアの障害
- ECCがついているからメモリのビットエラーではない
- Long型がひっくり返って6兆円?
パケットが増えたバグ
ハードウェアのエラーはソフトウェアに変な形ででる
Phantom Deadlock
- delayのdeadlock
- 哲学者の食事のやつ
- ほとんどのWFGの長さは2
For typical appIications, over 90% of WFG cycles are of length two.
90%の数値は計算できる?みたいな話になった。 ここは何を言っているのかさっぱり
- livelock
cyclic restart
タイムスタンプをつけてpriorityにしてlivelockを防ぐ
wait-die
Wait-Die: if ts( T,) < ts( Ti) then T, waits else abort T,. Wound-Wait: if ts( T,) < ts( T,) then abort Tj else T, waits.
- どっちがいいか度々議論になる
- wait-die一択?またはno wait(ここにはない)
no waitが潔い。最近はno wait一択
- たまにwait-dieの実装がある
- Wound-Waitの実装は見たことがない
タイムスタンプはいずれにせよいる
- idでも良い
タイムスタンプはよくカウントアップする
- 5分に一回くらい
- 64bitにすれば良い
- 32bit cpuの時は
- カウントアップに対応した理論の論文がある
- ラウンドアップ?とかいうらしい
論文の査読の話題になりました。(流派で暗黙の前提があるなど)
次回は「3.12 LOCKING PERFORMANCE”」から!
*1:たまに評価されることもありますが、流石に倍以上のエンジニア歴を持っていて、本当のテクニカルな分野でシビアなものが必要とされる世界で生き残ってきた人には到底叶いません