第2章：RDBは強い。NoSQLは“便利そう”だけど、現実はシビア
第2章：RDBは強い。NoSQLは“便利そう”だけど、現実はシビア
本記事は『データ指向アプリケーションデザイン（DDIA）』第2章の読書メモです。
自分なりに読みながら思考をめぐらせた“設計寄り視点”での気づきをまとめています。
図2: クエリ I/O フロー（Client → Query Engine → Storage → Disk）
「RDBは万能」ってやっぱ思ってしまう
自分自身が思ってたけど、「RDBってやっぱ万能だよな」って再認識した章だった
もちろん万能って言うのは語弊があるし、「なおスケールするかは無視するものとする🙄」って内心ツッコんでる
NoSQLが悪いわけじゃなくて、NoSQLって言葉の射程が広すぎるってのが問題かな
用途に合えば便利なんだけど、万能感を求めると破綻する
JSONで全部持てたら便利だけど、実際はそんなにうまくいかない
たとえば請求書みたいなデータをまるっと1つのドキュメントで持てたら、確かに読み込み時のパフォーマンスは強い
でも：
- 一部だけ編集したいときしんどい
- キー検索や分析には向いてない
- 正規化を崩すRDBと似た構造になりがち
って話があるし、結局「使えるけど、用途次第」という前提が外せない
ヘテロジニアスなスキーマって何が嬉しいの？
1レコードだけ構造違う、とかできるらしいけど、それが現実でどう嬉しいのかはピンとこない
むしろ構造違いがあるって、後からメンテが破綻する予感しかない
最近のRDB（PostgreSQLとか）でもJSON型あるし、
「それ、NoSQLじゃないとできない話？」って疑いたくなる
ネットワークモデルのつらみ
ネットワークモデルはざっと見ただけでタコ足配線になってて、
「どこがどこに繋がってるのか」一つ一つチェックしないと分からないのがダルそう
短期的にはありだけど、中長期ではメンテが爆発する未来が見える
宣言型 vs 命令型：並列実行に優位なのはどっち？
- 宣言型（SQLとか）は、オプティマイザが並列化を“いい感じに”やってくれる
- 命令型は、自分で並列処理の順番も考えないといけない
つまり宣言型が強いというより、「オプティマイザが賢いこと前提でのアーキテクチャ」なんだなと再認識
裏で何してるかをちゃんと知っておくと、ブラックボックスに振り回されずに済む
MapReduce、まだピンと来ないけど…
たとえば「全部 select * で引っ張ってきて、あとで group by すれば？」って気持ちになる
たぶん、今後の章で分散処理や巨大データセットとの関係でありがたみが出てくるやつかな
グラフDB、出番は限られてそう
関係が超複雑なデータ（SNSの友達つながり、レコメンド系）なら使えるかもしれないけど、
業務系アプリだと、そこまでノードとエッジが入り乱れる状況ってあまりなさそう
一応、「一気に関連データを芋づる取得する」みたいな要件があるなら可能性はあるかも
✍️ まとめ：「NoSQL」は選択肢。でも“とりあえず”では使えない
NoSQLは魅力的なキーワードだけど、
- 自由度が高すぎて構造がバラけがち
- パフォーマンス最適化は自分で責任取る必要がある
- 検索や更新のしづらさは、後から地味に効いてくる
ってことで、実際は適切な設計知識がある人にしか扱えない側面が強い
RDBの方が「不自由なぶん、安全」っていうのが現場目線では大きい。
NoSQLを使うときこそ、「なぜそれを選ぶのか？」を問い直すことになりそう
💡 設計Tips
- 「NoSQL」は選択肢の一つだが、“とりあえず選ぶ”には自由度が高すぎる
- 柔軟性とメンテナンス性はトレードオフ。便利そうでも運用時のコストを想像したい
- RDBの“不自由さ”は、ある種の設計アフォーダンスになっている
Discussion