量が多いのでゆっくり時間かけて読んでいく。ある程度読んだら記事にしてまとめる方針で！

データ指向: データの量や複雑さ、変化の速度が主な課題であるアプリケーションのこと
NoSQL、メッセージキュー、キャッシュ、検索インデックス、バッチなどなど、データ指向アプリケーションを支援するツールや技術がある
これらがどのように動作するのかだけでなく、なぜそのように動作するのかを理解していく！！！

第1章

演算指向ではなくデータ指向、CPUの処理能力ではなくデータ量や複雑さが大きな問題となる

信頼性

信頼性とは、大まかに言うと「何か問題が起きたとしても正しく動作し続けること」
フォールトが障害を招かないようにするのが大事。意識的にフォールトを作ることで耐障害性の仕組みをテストできる(例としてNetflixのChaos Monkeyがあるらしい)
以下のような原因がある

• ハードウェアの障害
• ソフトウェアのエラー
• ヒューマンエラー

スケーラビリティ

• 負荷の表現
  • 負荷のパラメータによって表現する
  • この数値はシステムのアーキテクチャによって異なる
  • Twitterの例
    • 最初は、単純にリレーショナルに設計して新しいツイートを挿入していた
    • ユーザーがポストしたら、そのユーザーをフォローしているユーザーのタイムラインにキャッシュするようにすることで負荷が減少
      • 書き込みの処理を重くし、読み込みの処理を減少させるのがよい
    • フォロワーの数が分布が重要な論点になる
    • 最終的には、1と2のハイブリッドになったらしい
• パフォーマンスの表現
  • バッチ処理システム: スループット(処理能力みたいなもの)
  • オンラインシステム: レスポンスタイム
    • 平均値、パーセンタイル
• 負荷への対処のアプローチ
  • スケールアップ(垂直、マシンを強力にする)
  • スケールアウト(水平、分散させる)

メンテナンス性

• 運用性
• 単純性
• 進化性

第二章

リレーショナルモデルとドキュメントモデル

リレーショナルデータベースは1980年半ばから圧倒的なシェア

• NoSQLの誕生
  • 最初は目を引きやすいTwitterのハッシュタグとして使われたらしい！！
• オブジェクトとリレーショナルのミスマッチ
  • リレーショナルデータベースだと、オブジェクト指向言語の、アプリケーションコード内のオブジェクトと、データベースモデルの間に変換レイヤーが必要になってしまう(インピーダンスミスマッチ)
• 多対一と多対多の関係
• 今日のリレーショナルデータベースとドキュメントデータベース
  • リレーショナルの細分化は、スキーマが混み入り不必要に複雑になることがある
  • ドキュメントだと、ネストが深ければ直接参照できず、pathを指定しないといけない
  • 多対多だと、ドキュメントの整合性を保つのが大変