読書会(データ指向アプリケーションデザイン)第5回議事録

=================================================================
Java読書会BOF「データ指向アプリケーションデザイン」を読む会第5回
=================================================================

.. csv-table:: 開催概要

  "日時", "2021年02月27日 10:00 - 17:00"
  "場所", "川崎市教育文化会館第3会議室"
  "出席者(敬称略)","高橋(徹)、高橋(智)、岩室、松永、遠藤、平山、吉本、加藤"

第7章トランザクション
======================

7.2 弱い分離レベル
------------------

7.2.1 Read Committed
~~~~~~~~~~~~~~~~~~~~

本日は、p.255 の 7.2.1.3 read committed の実装から

* おさらい: Read Committed はダーティーリード、ダーティーライトが生じないことを保証する
* インクリメントみたいな操作は大丈夫なのか？

  * 一回 ``SELECT`` してからインクリメントした値を ``UPDATE`` する
  * ``SELECT ... FOR UPDATE`` で行をロックして更新するとかも

* デッドロックはどうやって回避する？

  * 循環関係を調べればよい
  * あとに出てきそう (p.279)

7.2.2 スナップショット分離とリピータブルリード
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* 図7-6、Bob のコミットより前に Alice の ``SELECT`` があるのがポイント

  * 2行を1度に ``SELECT`` すれば問題なさそう

* Read Committed でもバックアップで不整合になる？

  * 全 ``SELECT`` でバックアップするなら、図7-6相当の途中状態も拾ってしまい、一貫性のない状態をバックアップすることになるだろう
  * Write ahead log もあれば最終的な状態は整合した状態にできる

* Read Committed とスナップショット分離の位置関係、7章冒頭の地図が理解の助けになる
* MVCC を使う＝スナップショット分離というわけではない？

  * 本文にもあるが、クエリごとに個別のスナップショットを使えば Read Committed、トランザクション全体に渡って同じスナップショットを使うとスナップショット分離

* 世の中の DB はたいていデフォルトで Read Committed のようだが、書き込みが激しい DB だとスナップショット分離がないと問題が顕在化しそう、DB の分離性の設定に注意を払わなければいけない
* トランザクション ID が 32bit というのは厳しそう

  * ``VACUUM`` するしかないのか
  * 実際には PostgreSQL は 20 億に到達した時点で ``VACUUM`` が実行されるようだ
  * ``VACUUM`` 前のトランザクション ID は凍結したフラグになる

7.2.3 更新のロストの回避
~~~~~~~~~~~~~~~~~~~~~~~~

* read-modify-write サイクルが平行していることをどう検知している？

  * read したときのレコードの ID とトランザクション ID を覚えておいて、 write するときに調べたりしているのではないか
  * MySQL は更新のロストが回避できないというのは本当か？ → ``FOR UPDATE`` による悲観的ロックで回避するしかない (検証は **宿題1**)

* compare-and-set は更新ロストの自動検知がないと厳しいのでは

  * 更新ロストができない MySQL では問題があるような
  * デフォルトの MySQL では ``UPDATE`` と ``DELETE`` はリピータブルリードではなく Read Committed 相当になるそうだ

* Riak で自動的にマージできないときはどうするんだっけ

  * 後勝ちを正としつつデータ構造の工夫で負けたほうも取得できるようにしてアプリケーションに解決させるような話が前の章にあったが、それかもしれない

7.2.4 書き込みスキューとファントム
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

7.3 直列化可能性
----------------

7.3.1 完全な順次実行
~~~~~~~~~~~~~~~~~~~~

7.3.2 ツーフェーズ (2相) ロック (2PL)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* 述語ロックを導入すると、毎回現在有効な全ての述語ロックをスキャンしたりするのだろうか

  * そうらしい、その解決策がインデックス範囲ロック

7.3.3 直列化可能なスナップショット分離 (SSI)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* この仕組みの初出が 2008 年の論文というのが意外

  * Java 5 で ``java.util.concurrent`` が導入されたのは 2004 年だし、並列処理の研究や技術革新がはじまり出した時期とも言えるかもしれない
  * mutex で相互排他する時代から、抽象的な方法でエレガントに実現するのが良いと言われ出した時代

まとめ
~~~~~~

* SSI の意味するものを試してみたい、PostgreSQL で ``serializable`` にすればよいのか？ (検証は **宿題2**)

  * PostgreSQL の Wiki が詳しい: https://wiki.postgresql.org/wiki/SSI

第8章分散システムの問題
========================

* この格言は何だろう？

  * Web 上の記事のようだ: https://aphyr.com/posts/281-jepsen-on-the-perils-of-network-partitions

8.1 フォールトと部分障害
------------------------

* DC 障害といえば、先日の Azure の東日本リージョンの障害は色々なところに影響があった

8.1.1 クラウドコンピューティングとスーパーコンピューティング
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

8.2 信頼性の低いネットワーク
----------------------------

* どこまで到達しているか調べるのは骨が折れる

  * 手元に機器がある環境ならポートミラーリングできるハブでパケットキャプチャしたりできるが、クラウドだとそうもいかない

8.2.1 ネットワークのフォールトの実際
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

8.2.2 フォールトの検出
~~~~~~~~~~~~~~~~~~~~~~

8.2.3 タイムアウトと限度のない遅延
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

----

次回は、 p.309 の 8.2.4 同期ネットワークと非同期ネットワークから

----

[ 戻る ]