0-1時ぐらいに寝て7時半に起きた。よく眠れたか眠れてないかもわからないような目覚め方をして少しぼおっとしてた。朝ゆっくりしてもいいかと思いつつ準備して移動したら9時前にはオフィスにいたので普通の日とそう変わらない一日の始めだった。夜にジョギング行こうかと思ってたけど、ちょうど通り雨が降ったりやんだりしててやめた。代わりに雨やんでからオフィス行って調べてものしてた。

データ指向アプリケーションデザイン⌗

7.3を読んで7章トランザクションを読み終えた。トランザクションの章は言葉も知らないし、あまりクリティカルなアプリケーションの開発に関わってこなかったのでそこまで意識したことがなかった。トランザクションで問題が発生する分離レベルと典型的なパターンが体系的に整理されていてすごく勉強になった。結果的にトランザクションを使わないとしても、トランザクションの要否や起きうる整合性の問題を理解しておくとデータ定義やアプリケーションの設計にも活かせる気がする。7章まで読んだ中でもっとも知らないことが多かった。約300ページなのでだいたい半分読み終えた。まだまだ先は長い。

トランザクションの開始時点でロックをかけるべきオブジェクトが存在せず、あるトランザクションでの書き込みが他のトランザクションの検索クエリの結果を変化させてしまう問題を ファントム と呼ぶ。ファントムの対策の1つとして、あらかじめそのデータを作っておき SELECT FOR UPDATE でロックを取得するやり方を 衝突の実体化 (materializing conflicts) と呼ぶらしい。グループウェアの開発をしていた頃、1つのスレッドしかトランザクションを実行できないことを保証するための切り札として、ロック用途のテーブルを設けておき、そのロックを獲得したスレッドだけ処理できるようにしていた。当時はわからなかったけど、あれは衝突の実体化という手法だったんだといま気付いた。

データベースのクラッシュや整合性に関する問題に対する信頼性を保つために、それらの問題を単純化するために、この数十年にわたって選択されてきた仕組みが トランザクション である。トランザクションは、アプリケーションが複数の読み書きを論理的な単位としてまとめる方法である。概念的には、トランザクション中のすべての読み書きは1つの操作として実行される。トランザクションは抽象化のレイヤーであり、アプリケーションはある種の並行性の問題や、ある種のハードウェアやソフトウェアの問題が存在しないかのように振る舞えるようになる。

トランザクションは全体として成功（ コミット（commit） ）もしくは失敗（ 中断（abort） 、 ロールバック（rollback） ）する。トランザクションが失敗した場合には、アプリケーションは安全にリトライできる。トランザクションは自然法則ではなく、データベースにアクセスするアプリケーションのためのプログラミングモデルをシンプルにするという目的を持って生み出された。トランザクションを利用すれば、ある種の潜在的なエラーの状況や並行性の問題はデータベースが面倒を見てくれるので、アプリケーションはそれらを気にしなくてよくなる（このことは 安全性の保証 と呼ばれる）。

トランザクションが提供する安全性の保証は ACID で示される。

原子性 (Atomicity)⌗
  • 原子（アトミック） はそれ以上小さな部分に分割できないものを指して使われる言葉
  • マルチスレッドのプログラミングにおいては、あるスレッドがアトミックな処理を実行しているというなら、それは他のスレッドからはその処理の半分だけ完了した途中の状態を見る方法が存在しないことを意味する。システムが取りえる状態は、その処理が始まる前と終わった後の状態だけであり、その中間の状態になることはない
    • 前にメモリモデルの文脈で、あるプロセスが書き込み完了したデータが、他のプロセスからも確実に読めることをアトミックな操作と習ったことがある
  • 原子性と並行性は関係がない
  • エラーの際にトランザクションを中断し、そのトランザクションのすべての書き込みを破棄できることが、 ACID の原子性を決定づける特徴と言える
    • アプリケーションがリトライしても安全であることを保証する
    • 中断可能性（abortability） の方が原子性よりも良い言葉だったと思われる

一貫性 (Consistency)⌗

  • 一貫性は多くの意味で使われる
    • とくに日本語では整合性とも訳される
  • 非同期のレプリケーションシステムでは結果整合性の問題が発生する (5章)
  • コンシステントハッシュ法は、リバランシングのためにいくつかのシステムで利用されているパーティショニングのアプローチ
  • CAP 定理では、一貫性という言葉は線形化可能性の意味で使われる (9章)
  • ACID の文脈における一貫性は、データベースが「良い状態」にあることを示すアプリケーション固有の概念を指す

同じ言葉を少なくとも4つの異なる意味で使われている。ACID における一貫性という概念は、データについて常に真でなければならない何らかの言明（ 不変性 ）があることを指す。たとえば、会計システムの場合、すべてのアカウントでまとめれば常に貸方と借方は等しくならなければならない。この一貫性の概念はアプリケーション固有の不変性の概念に依存しており、一貫性を保つようにトランザクションを適切に定義することはアプリケーションの責任となる。原子性、分離性、永続性はデータベースの特性だが、一貫性は（ ACID という考え方においては）アプリケーションの特性である。したがって、 C は実際には ACID に属していない。

分離性 (Isolation)⌗

多くのデータベースは、同時に複数のクライアントからアクセスされる。データベース中の同じレコードにアクセスするときに並行性の問題（レース条件［ race condition ］）が生じる可能性がある。データベース中に保存されているカウンタを、2つのクライアントが同時にインクリメントすると仮定する。それぞれのクライアントは現在の値を読み取り、1を加え、新しい値を書き戻す。ACID における分離性とは、並行して実行されたトランザクションがお互いから分離されており、お互いのつま先を踏みつけあうようなことがないという意味である。実際の運用では、パフォーマンスの制約から分離レベルによって保証される分離性が変わってくる。

永続性 (Durability)⌗

データベースシステムが目的とするのは、データを失う恐れなく保存できる安全な場所を提供すること。永続性は、トランザクションのコミットが成功したら、仮にハードウェアの障害やデータベースのクラッシュがあったとしても、そのトランザクションで書き込まれたすべてのデータは失われないことを約束する。

用語の整理⌗

トランザクションはデータモデルがどういったものであるかにかかわらず、価値あるデータベースの機能と言える。並行に実行されたトランザクションがお互いに影響しあわない分離性における保証を 分離レベル と呼ぶ。

  • read committed
  • スナップショット分離（repeatable read とも呼ばれる）
  • 直列化可能

これらの分離レベルに対してトランザクションで発生する様々なレース条件がある。

  • ダーティリード
    • あるクライアントが他のクライアントのまだコミットされていない書き込みを読める
    • read committed 分離レベル及びそれ以上に強い分離レベルはダーティリードは生じない
  • ダーティライト
    • あるクライアントが他のクライアントによるまだコミットされていない書き込みの内容を上書きしてしまう
    • ほぼすべてのトランザクションの実装は、ダーティライトを生じない
  • 読み取りスキュー（nonrepeatable read）
    • クライアントが異なる時刻にデータベースの異なる部分を見ること
    • この問題の最も一般的な回避策はスナップショット分離によるもので、これはトランザクションがある時点での一貫したスナップショットから読み取りを行えるようにする
    • 通常、MVCC（multi-version concurrency control）を利用して実装される
  • 更新のロスト
    • 2つのクライアントが並行して read-modify-write サイクルを実行するとき、片方が他方の書き込みをその変更内容を考慮せずに上書きしてしまい、データが失われること
    • スナップショット分離レベルの実装にはこの異常を自動的に回避してくれるものもあるが、明示的なロック（ SELECT FOR UPDATE ）をしなければならない実装もある
  • 書き込みスキュー
    • トランザクションが何かを読み取り、その値に基づいて判断を下し、その結果をデータベースに書き込む
    • この状況で、書き込みが行われた時点で判断の根拠となったプレミスが真ではなくなっている場合を指す
    • 直列化可能分離レベルのみがこの異常を回避できる
  • ファントムリード
    • トランザクションが何らかの検索条件にマッチするオブジェクトを読み取り、他のクライアントはその検索結果に影響する書き込みを行う
    • スナップショット分離レベルは単純なファントムリードを回避してくれるが、書き込みスキューを伴うファントムに対してはインデックス範囲ロックのような特別な対応が必要となる

弱い分離レベルは、これらの異常のいくつかを防いでくれるが、それ以外はアプリケーション開発者に対処する必要がある（たとえば明示的なロックなど）。すべての問題に対する保護を提供してくれるのは直列化可能分離レベルのみ。直列化可能なトランザクションの実装方法は、3 種類ある。

  • トランザクションを順次実行する
    • それぞれのトランザクションをきわめて高速に実行でき、加えて単一の CPU コアで十分処理できる程度にトランザクションのスループットが低いのであれば、これはシンプルで効果的な選択肢となる
  • ツーフェーズロック
    • 数十年にわたって直列化可能分離レベルの実装において標準的な方法であった
    • パフォーマンス上の特性から多くのアプリケーションがツーフェーズロックの利用は避けている
  • 直列化可能スナップショット分離（SSI、serializable snapshot isolation）
    • 新しいアルゴリズムであり、これまでのアプローチが持つ欠点のほとんどを回避している
    • SSI は楽観的アプローチを取っており、トランザクションはブロックされることなく処理を進められる
    • トランザクションはコミットの時点でチェックされ、その実行が直列化可能になっていなければ中断される

改正法人税法等の説明会⌗

改正法人税法等の説明会 に参加してきた。所感からまとめるとこんな感じ。

  • 神戸文化ホールについて
    • 電源がない
    • FREESPOT が提供されていてフリー wifi として利用できるが、通信品質は不安定
      • スマホでテザリングもやってみたが、電波状態がよくなくてもっと不安定
    • ラップトップ向きの場所ではない
  • 税制を身近にするイベントとしては参加してもよい
  • もらった資料をたんたんと説明するだけなのでイベントに参加することで得られる付加価値はとくにない
  • 気分転換や時間があれば参加すればいい、忙しかったら参加しなくてもよさそう

公益社団法人 神戸納税協会 という組織がある。年会費 (うちの会社だと7,800円) がいるのでいまは入らないけど、無料税務相談があるので余裕ができたら困ったときの相談相手になってもらう意図で入会してもよいかもしれない。冒頭の神戸税務署長の挨拶で法人税の申告における e-tax の利用率は 88.4% だと話してた。うちは紙で申請しているので意外とみんな e-tax 使っているんだなと自社を恥じた。だって Windows マシンないとできへんねんもん。参加したことによる学びとして書いていくとこれらかな。

  • 「研究開発費」は会計上の用語、「試験研究費」は税法上の用語
  • DX 投資促進税制の創設

内容は基本知らないことなので、知らないことに触れるイベントという点では斬新ではあった。ほうほうと聞いてただけなんだけど。直接うちの会社に影響を与える税法の改正はインボイス制度ぐらいかな。