Yabu.log

ITなどの雑記

CC本読み会第11回に参加

Concurrency Control and Recovery in Database Systemsという本を読む読書会に参加しました。なお11回からの途中参入になります。

p77の3.10 distributed two phase lockingから読みました。

本書について

Concurrency Control and Recovery in Database Systems

Concurrency Control and Recovery in Database Systems

データベースの基礎理論を扱う古典になります。

私が今ポチったからアマゾンのマケプレの在庫1個になっちゃいましたwwww

と希少品を自慢したいところですが、ご安心ください。こちらから書籍と全く同内容のPDFがダウンロードできます。

内容ですが、本当に「基礎」という感じです。

超絶技術を扱っているわけではありませんが、簡単という意味でもありませんが、 データをどう保護するか、という点で非常に本質的な知識だという印象です。

私に限らずどうしても昨今のエンジニアはツールとかフレームワークに関心が言ってしまい,こういう「基礎」の部分ががいい加減になりがちですね。

感想

11回目から初参加になります。こちらは分散システムの読書会と違って、

  • DBという自分の得意分野である
  • 分散本ほど周りの参加者が読み込んでいない
  • 分散本は36回もすでに経過しているところに途中参入した。

などの点から案外ついていけるのでは?と思っていましたが、

本書の扱うテーマはRDBMSの内部構造のものがテーマななので全くの専門外でした。

そのため非常に難しかったです。私が得意だったDBの知識というものはあくまで業務システムから利用する側の知識でしかなかったり、

そもそもの知識量が資格の勉強やここ1年くらいで頑張って身につけたものに過ぎなかったのです。*1

ちょうど1年前にこんな記事

qiita.com

を書いている程度の状態だったので、周りの参加者のレベルを考えるともっと精進する必要があります。

トランザクション設計はもちろん業務システムの要件として確認しますが、 ミドルウェアが担保しているトランザクションというのが自分には全く知識外でした。

質問をしましたが、「自明!」という感じの回答が帰ってきたので、本書の前のパートに書かれているのかもしれません。しっかり復習して次回は挑みたいと思います。

ライブロックも単語は知っていますが、内容は知りません。

ノート

  • global serializable

    • local serializable
      • localのものを足し混んでgrobalのserializableになるような単純なものではない。
  • global なserializableを保証するのは難しい

  • Effective Javaに乗っているJavaのSerializationの代替

    • 私がこの記事で書いている内容を話して見ました。

yuyubu.hatenablog.com

  • protcol bufferでも遅い

  • castor

    • 神林さんが詳しいらしい
    • Object指向のDBで使う
  • CorbaではJavaなどのserializeなどの意味でマーシャライズという言葉を使う

  • 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:たまに評価されることもありますが、流石に倍以上のエンジニア歴を持っていて、本当のテクニカルな分野でシビアなものが必要とされる世界で生き残ってきた人には到底叶いません