データベース編 第12章 / 全13章
DBの選び方
CAP定理 ・ スケール ・ 整合性
用途から逆算する「速い・安い・うまい」を全部は選べない。DB選びも、何をいちばん大事にするかで決まる。
図とさわれるデモで確かめる →
ポイント
- お金・在庫など、正確さが最優先 → リレーショナルDB
- 大量アクセス・大量書き込みで、速さと規模が最優先 → NoSQL
- 用途がはっきりしている（検索・時系列・AI） → 特化型を組み合わせる
名前の由来
Consistency一貫性Availability可用性Partition tolerance分断への強さ
CAP定理：ネットワークが分断されたとき、「一貫性」と「可用性」のどちらかを優先するしかない、という考え方。
仕事の現場では
1つのシステムで複数のDBを使い分けるのは普通のことです（注文はRDB、商品検索は全文検索、閲覧履歴はキーバリュー、など）。最初はRDB1つで始め、必要になったら足すのが失敗しにくい進め方です。
くわしく（正確な話）
- 性能を上げる方法は、1台を強くするスケールアップと、台数を増やすスケールアウトの2つ。
- 読み取り専用の複製（レプリカ）を作って負荷を分けることも多い。
- RDBの正確さとNoSQLの拡張性を両立させたものをNewSQL（分散SQL）と呼ぶ（Spannerなど）。
- いまはDBを自分で運用せず、マネージドサービスを使うのが基本。
うまれ：CAP定理は2000年にエリック・ブリューワーが提唱した。
この章の用語（意味と語源）
- CAP定理 キャップていり
分散したDBは「一貫性・可用性・分断への強さ」を同時に全部は満たせない、という考え方。
ネットワークが切れたとき、「止めてでも正しい答え」を優先するか、「古いかもしれないが答え続ける」を優先するかを選ぶことになります。
覚えておく：C / A / P
語源Consistency（一貫性）、Availability（可用性：使える状態であること）、Partition tolerance（分断への耐性）の頭文字。
- スケールアウト / スケールアップ Scale-out / Scale-up
台数を増やして性能を上げる／1台を強くして性能を上げる。
スケールアップは簡単ですが上限があります。スケールアウトは上限がない代わりに、仕組みが複雑になります。
語源scale（規模）を out（外へ＝横に広げる）／ up（上へ＝1台を大きく）。
- レプリカ Replica
DBの複製。読み取りの負荷を分けたり、故障に備えたりする。
語源ラテン語 replicare（折り返す・繰り返す）から。美術品の複製も同じ言葉です。
- NewSQL（分散SQL） ニューエスキューエル
RDBの正確さと、NoSQLのような拡張性を両立させたDB。
覚えておく：例：Spanner、CockroachDB
語源new（新しい）+ SQL。