今更ながらデータ指向アプリケーションデザインを読んでいる。第I部 データシステムの基礎まで読んだ。とにかく面白くて良い。
自分は「3章 ストレージと抽出」がもっとも面白いと感じ、とくにSSTableとLSMツリーというシンプルなアルゴリズムで多くの問題を解決できていることに感動を覚えた。昔もマージソートに感動した覚えがあるけど、今回もマージソートはすごいという気持ちになる。また列指向データベースの基本的な考え方や圧縮効率を学べたのも良かった。
「4章 エンコーディングと進化」においては、変化しやすさを担保するための後方互換性(= 新しいコードが古いデータを読める)と前方互換性(=古いコードが新しいデータを読める)についてまとめた上で、いくつかのデータフローの中で何を満たすべきなのかがまとめられていた部分が良かった。たとえばデータベースとのやりとりだと何があれば前方・後方互換性が保たれるか、REST APIだとどうか、非同期のメッセージパッシングの送受信だとどうかなどが具体的に語られていた。
まだまだ先は長いけど地道に読んでいこうと思う。
読書ノート
### 1章 信頼性、スケーラビティ、メンテナンス性に優れたアプリケーション
- 本書はソフトウェアシステムにおける重要な3つの課題に焦点 315
- 信頼性
- フォールとがあっても正しく動き続ける
- スケーラビリティ：負荷の増大に対してシステムが対応できる能力
- メンテナンス性
- 運用性：運用チームが扱いやすい
- 単純性：新しいエンジニアが理解しやすい
- 進化性：システムを変更しやすい
- レスポンスタイムはクライアント側で計測しなければ、ユーザーの視点に立てない 596
### 2章 データモデルとクエリ言語
- グラフストアは、頂点と辺の概念がある 1462
- 任意の頂点を辺によって接続できる
- 任意の頂点に対する入出力の辺を効率的に見つけ出せる。グラフを探索できる
- 辺に異なるラベルを使うことで、単一グラフの中にさまざまな情報を保存する
まとめ 1761
- リレーショナルデータベース以外だと、以下の二つに分かれる
- ドキュメントデータベース：データが自己完結しているドキュメント群で、リレーションがそれほど存在しないものをターゲット
- グラフデータベース：あらゆるもの同士に関係が存在するようなユースケース
- データのほとんどが多対多の場合リレーションモデルは不得意
### 3章 ストレージと抽出
ハッシュインデックスとlog-structuredなデータ保存
- log-structuredな仕組みでのデータファイルのコンパクションおよびマージ処理 2019
- ログがあるサイズになったらファイルをクローズする
- 凍結されたセグメントでは最新の値だけ残しマージする。複数のセグメントも最新のものは後のファイルに入っているはずなので、それを踏まえてマージ
- ハッシュインデックスでは各セグメントにインメモリのハッシュテーブルがある 2019
- キーに対する値を見つけるには、最新セグメントのハッシュマップチェック -> なければ2番目の、...
- log-structuredな仕組みでは、レコードの削除を特別な削除レコード追加で代替できる 2041
- log-structuredな追記のみの仕組みのメリット 2041
- セグメントの追記とマージはシーケンシャルな処理なためランダムな書き込みより高速
- 並行処理やクラッシュリカバリがシンプル
- データファイルのフラグメンテーションが少ない
- ハッシュテーブルのインデックスの制約 2068
- メモリ内にキーが収まらなくなるとだめ
- 範囲クエリの効率が悪い
- -> SSTableとLSMツリーへ
SSTableとLSMツリー
- ソート済み文字列テーブル(Sorted String Table、SSTable) 2068
- セグメントファイルのフォーマットに2条件を追加
- キーでソートされていることという条件を追加
- マージされたそれぞれのセグメントファイル中には、それぞれキーは一度だけしか現れないという条件を追加
- SSTableの利点 2095
- マージソートできるためメモリ効率が良い
- 全てのキーをインデックスに残さなくても、一部だけでどのあたりにそのキーがあるか分かる
- どうやってキーごとにソートしてデータを保存する？ 2113
- 書き込み時点ではメモリで管理、一定より大きくなったらディスクにセグメントとして書き込み
- クラッシュからの復帰のためだけにディスク上に全ての書き込みを即座に追記するファイルを用意。セグメントをディスクに書き込むたびに削除
- このようなSSTableとコンパクション・マージを踏まえたインデックス構築のような構造をLSMツリー（Log-Structured Merge-Tree）と呼ぶ 2136
- 存在しないキーのルックアップの高速化のためにブルームフィルターが使われる 2164
- LSMツリーは通常書き込みを高速に処理でき、Bツリーは読み取りが高速に行えるものとみなされている 2243
オンライン分析処理（OLAP）と列指向データベース
- データウェアハウスではしばしば大量の列を持つことが多い。100〜数百。アクセスパターンは数列しかなく、それを効率化するために列指向データベースが使われる 2578
- 列指向ストレージの考え方：1つの行に含まれる全ての値をまとめて保存するのではなく、それぞれの列に含まれる全ての値をまとめて保存する 2605
- 列指向ストレージは圧縮に適している 2626
- 行数よりも列の中身の種類数の方が少ないことが多いため
- ランレングスエンコーディング
- WHERE句でのOR条件はビットのORに、AND条件はビットのANDにマッピング可能
- 列ストレージでSSTableのような順序強制の仕組みを使うと列の圧縮を助けられる 2670
- 列ごとに圧縮されていると、ソートされたテーブルの途中に行を挿入しづらい。これはLSMツリーのようにインメモリストアに書き込み -> 十分に貯まったらディスク上の列ファイルとマージ圧縮という方法を使う 2702
- 読み込みは列データとメモリの両方から見る
まとめ
- ストレージエンジンは、トランザクション処理（OLTP）に最適化されたものと、分析（OLAP）に最適化されたものの2つに分類
- OLTPでは莫大なリクエストと少数のレコード
- OLAPでは少量のクエリと、多くのレコードスキャン
- ディスクの帯域がボトルネックになるので列指向が使われる
- 気づき: Web APIはOLTP、バッチ処理はOLAP
- OLTPには2つの考え方のストレージエンジン
- log-structured：ファイルへの追記と古くなったファイルの削除だけ行える。SSTable、LSMツリー
- インプレース更新：ディスクを更新可能な固定サイズのページの集合として扱う。Bツリー
### 4章 エンコーディングと進化
- ごく一時的な目的の場合以外では、特定の言語の組み込みエンコーディングは使うべきでない 3013
- 多言語とのポータビリティ
- 前方および後方互換性の不足
- 効率性
- Protocol Buffersなどのバイナリフォーマット 3114
- 前方後方互換性を維持するためには 3155
- フィールド名は変えられるが、フィールドのタグは変更できない
- フィールドの追加
- 新しいタグ番号なら、古いコードはそのフィールドを単純に無視するため問題ない。アノテーションからスキップするバイト数を把握できる。この特性で前方互換性が保たれる
- タグ番号が変わらないので後方互換性は保たれる。しかし新しいフィールドは必須にできない（MySQLのスキーマと同じ）
- フィールドの削除
- 必須フィールドは削除できない、オプションフィールドは削除できる
- JSONなどのスキーマレスなテキスト形式と比較して、スキーマありのバイナリエンコーディングの優れた性質 3342
- はるかにデータがコンパクト。フィールド名が必要ない
- スキーマ自体がドキュメントになる
- スキーマの変更をみるだけで前方後方互換性の維持チェックをデプロイ前にできる
- コード生成しやすい
データフローと前方後方互換性
- データベースの場合、後方互換性は必須、前方互換性が求められることもしばしばある 3397
- 新しいフィールドのことを解釈できなくても、古いコードが新しいフィールドに手を加えてはならない
- RPCやRESTの場合、すべてのサーバーがまずアップデートされ、クライアントはその後にアップデートされるという仮定をおいてシンプルにしてもいい 3569
- 保つ必要があるのは古いクライアントからのリクエストを新しいサーバーが解釈できることと、新しいレスポンスを古いクライアントが壊れずに解釈できること
- この特性はRPCが使うエンコーディング特性が引き継がれる
- 気づき: メッセージブローカーの場合は、RPCのレスポンスがない版として考えたらいい？ 3597
- 分散アクターフレームワークとかだと難しいとかもある
まとめ
- ローリングアップグレードをする場合、システム内を流れるすべてのデータは、後方互換性と前方互換性が保たれる方法でエンコードされなければならない
- 後方互換性 = 新しいコードが古いデータを読める
- 前方互換性 = 古いコードが新しいデータを読める
- データエンコーディングの互換性について
- プログラミング言語固有のエンコーディングは、しばしば前方および後方互換性を欠いている
- JSONなどのテキストフォーマットの互換性は利用の方法に依存する
- Protocol Buffersなどのスキーマを持つバイナリフォーマットでは、前方および後方互換性の背マンティクスが明確に定義されている
- 互換性について、それぞれのデータフローで気をつける必要がある
- データベースの書き込みと読み取り
- RPCやREST APIのリクエストとレスポンス
- 非同期のメッセージパッシングの送信と受信
