第2章：NoSQLとマルチモデル・データベース

2-1. データモデルごとの使い分け

NoSQLは「RDBではない」という消去法的な名称ですが、実際には大きく4つのモデルに分類されます。

• キー・バリュー型（KVS）:

  • 特徴: 単純な「キー」と「値」のペア。極めて高速。

  • 代表例: Redis, Amazon DynamoDB

  • 用途: セッション管理、キャッシュ、リアルタイムランキング。

• ドキュメント型:

  • 特徴: JSONやBSON形式のデータをそのまま格納。スキーマレス。

  • 代表例: MongoDB, Couchbase

  • 用途: ECサイトの商品カタログ、コンテンツ管理システム（CMS）。

• ワイドカラム型:

  • 特徴: 行ごとに異なる列を持つことができる。大量データの書き込みに強い。

  • 代表例: Apache Cassandra, Google Cloud Bigtable

  • 用途: 時系列データ（IoTログ）、メッセージ履歴。

• グラフ型:

  • 特徴: ノード（点）とエッジ（線）で関係性を管理。

  • 代表例: Neo4j, Amazon Neptune

  • 用途: SNSのつながり、不正検知、レコメンデーションエンジン。

2-2. グラフデータベースの活用

RDBで「友達の友達」のような再帰的な関係を辿る（JOINを繰り返す）と、計算量が爆発的に増えパフォーマンスが劣化します。

• インデックスフリー隣接: グラフDBでは各ノードが隣接するノードへのポインタを直接持っているため、関係性のホップ数が増えても高速にスキャンが可能です。

• ユースケース:

  • 金融取引: 複雑な資金洗浄ルートの特定。

  • ナレッジグラフ: 意味的に関連する情報の紐付け。

2-3. キャッシュ戦略とインメモリDB

パフォーマンスを極限まで高めるためには、ディスクではなくメモリ（RAM）上でデータを扱う戦略が不可欠です。

キャッシュの書き込み戦略

アプリケーションがデータを更新する際、キャッシュとメインDBをどう同期させるかの手法です。

1. Write-through: キャッシュとDBの両方に同時に書き込む。一貫性は高いが、書き込み遅延がある。

2. Write-around: DBにのみ書き込み、キャッシュは更新しない。キャッシュミスが発生した際にDBから読み込む。

3. Write-back (Write-behind): まずキャッシュに書き込み、一定時間後にまとめてDBへ反映する。書き込みは最速だが、DB反映前に障害が起きるとデータ紛失のリスクがある。

2-4. マルチモデル・データベース

最近のトレンドは、一つの製品で複数のモデル（RDB、JSON、グラフなど）を扱える「マルチモデル」化です。

• PostgreSQL: リレーショナルでありながら、JSONB型によるドキュメント管理や、プラグインによるグラフ検索が可能。

• Azure Cosmos DB: キーバリュー、ドキュメント、グラフなど複数のAPIを一つのプラットフォームで提供。

第2章のまとめ

• データの構造と読み書きの頻度に応じて、最適なNoSQLモデルを選択する。

• 関係性が複雑なデータには、JOINではなくグラフデータベースを検討する。

• キャッシュ戦略（Write-through等）を適切に選定し、一貫性と速度のバランスを取る。

• 単一のDBに固執せず、**適材適所（Polyglot）**なアーキテクチャを設計する。