SQLとNoSQLの違い — 買い物リストの保存方法から選ぼう

ひよこ

ひよこの買い物リストを保存したいんだけど、SQLとNoSQLはどう違うの？

ペンギン先生

ひよこの買い物リストを、行と列の表として保存するか、一つの文書にまとめるかを考えてみよう。この比較のSQLはSQLを使うRDB、NoSQLはドキュメント型などの非リレーショナルDBのことだよ。

ひよこ

スキーマを決めるって、ちょっとめんどくさそう…。NoSQLなら自由に入れられるなら、全部NoSQLでよくない？

ペンギン先生

柔軟でも設計は必要だよ。例えばMongoDBでは同じコレクションに異なる項目のドキュメントを入れられるけれど、よく使う検索や更新に合わせて構造を考える。必要ならスキーマ検証も使えるんだ。一方、関係のあるデータを表に分けて結合したいときはRDBが候補になるよ。

ひよこ

ACIDっていう保証は、SQLだけにあるの？

ペンギン先生

ACIDは原子性・一貫性・分離性・耐久性の頭文字だよ。例えば送金の引き落としと入金を同じトランザクションにまとめれば、片方だけ確定するのを防げる。MongoDBにも複数ドキュメントのACIDトランザクションがあるから、NoSQLだから使えないとは言えない。保証の範囲や読み書きの設定も確認しよう。

ひよこ

じゃあ、古いデータが見えるかどうかも製品によるの？

ペンギン先生

そうだね。例えばDynamoDBのテーブルは、結果整合性のある読み取りと、強い整合性のある読み取りを選べる。ただしグローバルセカンダリインデックスは結果整合性のみだよ。「NoSQLは全部同じ保証」とせず、どこをどう読むかまで確認する必要があるんだ。

ひよこ

「サーバーを横に増やす」ってどういうこと？

ペンギン先生

1台のCPUやメモリを強化するのが垂直スケーリング、台数を増やして負荷を分けるのが水平スケーリングだよ。MongoDBではシャーディングでデータを分散できる。ただし分散キーや問い合わせ方によって負荷が偏るし、複数サーバー間の処理にもコストがある。無限に、同じ効率で拡張できるという意味ではないよ。

ひよこ

代表的なデータベースって何があるの？

ペンギン先生

RDBの例がPostgreSQLで、ドキュメント型の例がMongoDBだよ。ただしPostgreSQLにもJSONやJSONB型があり、表の列にJSONを格納できる。「形が変わるデータだから必ずNoSQL」という選び方はできないんだ。

ひよこ

そんなに種類があるんだね…。結局、どっちを選べばいいの？

ペンギン先生

まず、どの単位でデータを読み書きするか、どこまで一括で確定したいか、どんな検索が必要かを整理しよう。例えば商品ごとに項目が違うカタログならドキュメント型を検討できる。複数のDBを併用する方法もあるけれど、データ連携や運用の負担が増えるので、最初から必須ではないよ。

ひよこ

SQLを使いながら水平スケーリングすることもできる？

ペンギン先生

できるよ。GoogleのSpannerはSQLとACIDトランザクションを備え、データを分散して水平スケーリングする例だね。「SQLかNoSQLか」は入口の分類。最後は製品ごとの保証、必要な構成、実際の処理での性能や費用を比べて選ぼう。

まず、同じ買い物を二つの形で見る

「ひよこが、りんごを2個買う」という記録を考えます。表なら注文と商品を別の表にして結び付けられます。ドキュメント型では、一緒によく読む注文と明細を一つの文書にまとめる設計もできます。

{
  "buyer": "ひよこ",
  "items": [
    {
      "name": "りんご",
      "quantity": 2
    }
  ]
}

これは構造の例です。このJSONを見ただけでMongoDBに保存されたことにはなりません。RDBにもJSONを扱える製品があります。

表から必要な行を取り出す

SQL入門などの練習用DBで、次を試せます。

CREATE TABLE shopping_demo (
  buyer TEXT,
  item TEXT,
  quantity INTEGER
);
INSERT INTO shopping_demo
VALUES ('ひよこ', 'りんご', 2);
SELECT item, quantity
FROM shopping_demo
WHERE buyer = 'ひよこ';

りんご | 2 が結果です。同名の表がない新しい練習用DBで行います。ここでは問い合わせの入口を試すだけで、本番のキー・制約・索引の設計は別に必要です。

読み書きの単位から選ぶ

NoSQLの柔軟な構造にも設計と検証は必要です。NoSQL全体が一つのデータモデルではなく、ドキュメント、キーと値など方式と製品が異なります。

もう少し詳しく：二分しない保証

MongoDBにも複数ドキュメントのACIDトランザクションがあり、PostgreSQLにもJSON/JSONBがあります。DynamoDBではテーブルとLSIに強い整合性の読み取りを選べますが、GSIとストリームは結果整合性の読み取りです。

RDBは縦にしか拡張できない、NoSQLは無限に水平拡張できる、とも言えません。Spannerのような分散RDBもあり、シャーディングには分散キーや偏りの検討が必要です。必要な処理での性能・費用・運用を製品ごとに確認しましょう。

ペンギン先生のまとめ

「SQLとNoSQL」って出てきたら「データの形と、読み書きのまとまりから選ぶ」と思えばだいたいOK！ まず保存したい買い物と、取り出したい結果を書いてみよう。

参考資料

• PostgreSQL: Concepts — 行・列・型を持つRDBの基本。
• PostgreSQL: Transactions — 送金例とトランザクションの範囲。
• MongoDB: Data Modeling — 柔軟なスキーマと設計・検証の必要性。
• MongoDB: Transactions — ACID、読み書き設定、分散処理のコスト。
• MongoDB: Sharding — 水平分散とシャードキー。
• DynamoDB: Read consistency — テーブルとインデックスの整合性の違い。
• PostgreSQL: JSON Types — JSON・JSONB型。
• Google Cloud: Spanner — SQL・ACIDと水平スケーリングを備える製品例。