#book #r2025  # なぜこの本を読んだか 昔にちょっと読んでから、ずっと読もう読もうと思って本で有休消化期間で時間ができたので満を辞して読んだ。 # 何が書かれている本か ソフトウェアエンジニアリングでよく言われる、メンテナンス性やトレードオフの議論をデータベースを中心に議論している。 データベースもそれこそいわゆる1つのインスタンスで動作している RDB から NoSQL から始まり、冗長化のための分散やパフォーマンスのための分散システムまで触れており、原著が [Designing Data-Intensive Applications](https://www.oreilly.com/library/view/designing-data-intensive-applications/9781491903063/) にある通り 2017年にも関わらず OLAP (online analytics processing) のためのデータウェアハウスや ETLプロセスからディメンションモデルにまで触れていて非常に幅広い話題を取り扱っていてすごいの一言である。 # メモ 情報量が多いのと淡々と事実をそれぞれの話題に対して説明しているので本書を読むのをおすすめする。 一部特に目を引いたものだけメモ > CAP は、しばしば一貫性、可用性、分断耐性 の3つの中から2つを選択することとされています。 > しかしこれは誤解を招きます。 > ネットワークの分断はフォールトの一種なので、選択に関係するようなものではなく、好むと好まざるとに関わらず生じるものです。 > ネットワークが正常に動作しているなら、システムは一貫性 (線形可能性) と完全な可用性をどちらも提供できます。 > ネットワークにフォールトが生じると、線形可能性と完全な可用性のどちらかを選択しなければなりません。 > したがって、CAPを表現するならネットワーク分断を所持た時に一貫性と可用性のどちらを選ぶのか、という方が良いでしょう。 > 形式的に定義されたCAP定理の対象範囲は非常に狭いものであり、考慮しているのは1つの一貫性モデル (すなわち線形可能性) と1種類のフォールト (ネットワーク分断、すなわちノード郡が生きていてもお互い切り離されてしまっている状態)だけです。 > CAP定理はネットワークの遅延、落ちているノード、あるいはその他のトレードオフについては何も語ってません。 このあたりは歴史も含めて知らないことばかりだったので勉強になった。 実際こういう話題もありなるほどなあとなった - [CAP定理を見直す。“CAPの3つから2つを選ぶ”という説明はミスリーディングだった](https://www.publickey1.jp/blog/13/capcap32.html) - [12年後のCAP定理: "法則"はどのように変わったか](https://www.infoq.com/jp/articles/cap-twelve-years-later-how-the-rules-have-changed/) # 感想 - 2017年に書かれている本ではあるがまだまだ知識として活きるものが多い (というかほとんどが活きる) のはデータベースがそれだけ枯れた技術だからなのだろう - 今新しい販が書かれるなら TiDB などについて触れることになるんだろうか - 自分はそれこそ [[90 scraps/books/アジャイルデータモデリング]] やそれに類する発表などでディメンションモデルの詳細を知ったくらいなので実は界隈では一般的だったのかもしれないが、2017年にこの議論に触れているというのは単純に驚きだった - 分散システムにおいては、薄々感じていたがリアルタイムでの反映ではなく一定の結果整合性を許容するというのが人類にとって大きなマインドシフトだったんだなあと感じたりもした