主要NoSQLプロダクトリファレンス: Redis・Cassandra・DynamoDB・MongoDB・Neo4j を中心に

NoSQL は KVS / ワイドカラム / ドキュメント / グラフという別々のデータモデル群の総称であり、「NoSQL を使う」だけでは技術選定の議論になりません。本記事はプロダクト視点で各 NoSQL の特徴・機能・主な使い道・落とし穴をリファレンスとして整理します。

データモデル単位の整理は『NoSQLの4分類を整理する: KVS・ワイドカラム・ドキュメント・グラフの本質的な違い』で扱っています。

対象は以下の 12 プロダクトで、前半は主要プロダクトを個別に解説し、後半は採用機会が比較的少ないプロダクトを主流プロダクトとの差分の形で言及します。

• 個別解説
  • Redis / Cassandra / Amazon DynamoDB / MongoDB / Neo4j / Couchbase / Microsoft Azure Cosmos DB
• 比較言及
  • Memcached / HBase / Riak / CouchDB / OrientDB

ユースケース起点での逆引き選定は『ユースケース別NoSQL選定ガイド: 「こういうときはどのNoSQL？」を逆引きする』で扱っています。

Redis（KVS / データ構造サーバ）

概要

イタリア人プログラマー Salvatore Sanfilippo（antirez）が 2009 年に開発を始めたインメモリ KVS です。NoSQL 分類上は KVS ですが、値として複雑なデータ構造（リスト・セット・ハッシュ・ソート済みセット等）を直接扱えるデータ構造サーバとしての性格が強いという特徴があります。AWS の ElastiCache、Azure Redis Cache などマネージドサービスとしても提供されています。

データモデル

キーに対して以下の型を値として持てます。これが Redis を「データ構造サーバ」たらしめている特徴です。

型	概要
Strings	最大 512MB のバイナリセーフ文字列。INCR / DECR で数値カウンタとしても使える
Lists	リンクドリスト。先頭・末尾アクセスは高速、中間挿入は遅い
Sets	順序なし集合。共通部分・併合などの集合演算をサポート
Hashes	フィールドと値のマップ。1キー内にオブジェクトをまとめて表現できる
Sorted Sets	スコア付きセット。スコア順にソートされ、追加・削除・存在確認が対数時間
Bitmaps	Strings をビットマップとして扱うコマンド群。約 42 億ビットを 1 キーで管理可能
HyperLogLog	ユニーク要素数を推定する特殊型。メモリ一定で 99% 程度の精度

主要機能

• 永続化
  • RDB（スナップショット）と AOF（コマンドログ追記）の 2 方式
  • RDB はファイル小・障害時のロスト幅大、AOF はファイル大・障害時のロスト幅小（fsync ポリシー次第）
• トランザクション（MULTI / EXEC）
  • コマンドをキューに溜めて一括実行し Isolation を保証する
  • ロールバック機能がなく、エラーになったコマンドの前後はそのまま実行される（RDB の感覚で使うと事故の元）
• Lua スクリプト
  • 条件検索や集計（DISTINCT・ORDER BY 相当）はデフォルトで存在しないため、Lua で実装する
  • MULTI / EXEC と同様に直列化される
• Pub/Sub
  • メッセージブローカ用途
• TTL
  • EXPIRE コマンドでキーに有効期限を設定可能（2.6 でミリ秒単位）
• レプリケーション
  • マスタースレーブ非同期
  • スレーブの下にスレーブを連ねた階層構造も可能
• Redis Cluster（3.0〜）
  • 16384 個のハッシュスロットを各マスターに割り当てるシャーディング機能
  • リシャーディングは無停止で実行可能
• Redis Sentinel
  • マスタースレーブの監視・自動フェイルオーバ
  • 3プロセス以上の合議で動く

整合性・スケーラビリティ

クラスタアーキテクチャはマスタースレーブ型で、Redis Cluster 利用時はハッシュスロットの分割で書き込みも複数マスターに分散できます。レプリケーションは非同期のため、マスター故障時にスレーブ未同期のデータはロストしうる仕様です。WAIT コマンドで同期化できますが、パフォーマンスとのトレードオフになります。

主な使い道

• キャッシュ（Web アプリ・セッション）
• カウンタ（INCR / DECR）
• タイムライン / 直近 N 件取得（Lists の LPUSH + LRANGE）
• ランキング / リアルタイムスコアボード（Sorted Sets）
• ユニークアクセス数（Sets で正確に / HyperLogLog で推定）
• タギングシステム（Sets）
• メールフラグ等の大規模 Bool 管理（Bitmaps）
• メッセージブローカ（Pub/Sub・Streams）
• オブジェクト集約（Hashes）

注意点・落とし穴

• インメモリ前提
  • 単体構成ではメモリサイズが上限
  • スケールには Redis Cluster が必要
• トランザクションのロールバック不可
  • エラーが出ても前後のコマンドはそのまま実行される
• Redis Cluster の制約
  • 複数キー操作（MSET / MGET）は同一スロットでないと不可
  • 回避策はハッシュタグ {tag} で同一スロットに寄せる
• 永続化なしマスターの自動再起動の罠
  • 永続化を切っているマスターが再起動すると空データがスレーブに連携され全消失する
  • 永続化なしでレプリ運用するなら自動再起動を無効化必須
• セキュリティ機能が乏しい
  • パスワード平文送信、暗号化機能なし
  • 信頼された環境前提の設計で、ファイアウォール / SSL（spiped 等）で守る
• クラスタとスタンドアロンで挙動差
  • スタンドアロンで動いていたコードが Cluster で動かない（複数キー操作等）こともある

Apache Cassandra（ワイドカラム）

概要

Facebook で開発され、2008 年にオープンソース化されたマスターレス型の分散データベースです。Amazon の Dynamo 論文と Google の Bigtable 論文の系譜を組み合わせた設計で、大量書き込み・線形スケーラビリティ・継続的可用性を志向します。商用版として DataStax Enterprise が存在します。

データモデル

階層はキースペース → テーブル → 行（パーティション）→ カラムです。

• キースペース
  • RDB のデータベース相当
  • レプリケーション戦略はこのレベルで定義
• パーティションキー
  • テーブルの各行が必ず持つキー
  • これでどのノードにデータが置かれるかが決まる
• プライマリキー
  • 「パーティションキー単独」または「パーティションキー + クラスタカラム」の組み合わせ
  • 後者ではパーティション内に複数行を持つ入れ子構造になる

スキーマレスではなく CQL でテーブル定義してから利用しますが、行ごとに異なるカラムが存在してよく、疎なデータが効率的に格納できます。

主要機能

• CQL（Cassandra Query Language）
  • SQL に酷似した DDL / DML / SELECT
  • JOIN・GROUP BY はサポートされない
  • SUM / AVG / MIN / MAX や ORDER BY も大幅な制限あり
• 書き込みパス
  • コミットログ追記 → memtable（メモリ）→ しきい値で SSTable としてディスクへ書き出し
  • 定期的にコンパクションで複数 SSTable を統合（『ストレージエンジンの2大潮流: B-tree と LSM tree の構造比較』参照）
• 読み取りパス
  • ブルームフィルタで対象 SSTable を絞り込んでからディスク読み込み
• マスターレスのリングクラスタ
  • ノード同士はゴシッププロトコルで状態を伝播
  • クライアントはどのノードに接続しても処理可能（コーディネータ機能を全ノードが持つ）
• マルチデータセンタレプリケーション
  • 自動・透過的に行われ、地域跨ぎでも ETL 不要
• 軽量トランザクション（LWT）
  • IF NOT EXISTS 等の条件付き書き込み
  • すべての該当ノードへ問い合わせるためパフォーマンス低下あり

整合性・スケーラビリティ

マスターレス型の典型例で、単一障害点がありません。ノード追加で線形スケールし、ノード数 N に対して書き込みスループットが N 倍になる予測可能性を持ちます。

整合性は結果整合性 + 調整可能整合性です。各操作で整合性レベルを指定でき、W + R > N の条件を守れば強整合性を担保できます（『結果整合性とBASE特性: 強整合性とのトレードオフと調整可能整合性（W+R>N）』参照）。

整合性レベル	特性
ANY	任意ノードに書ければOK。可用性最高、整合性最低
ONE / TWO / THREE	指定数のノードを確認
QUORUM	過半数を確認。バランス型
ALL	全ノード確認。整合性最高、可用性最低
LOCAL_QUORUM / EACH_QUORUM	データセンタ別の過半数
SERIAL / LOCAL_SERIAL	軽量トランザクション用の直列化整合性

主な使い道

• IoT・センサーデータ（高速書き込み）
• メッセージング（携帯電話・通信プロバイダ等の基盤として実例多数）
• 製品カタログ・リテール
• ユーザアクティビティ追跡・モニタリング（メディア・ゲーム・動画・音楽サイト）
• ソーシャルメディア分析・レコメンド
• 時系列データ（ワイドロー設計と必要カラムだけ読む特性が時系列に好適）

注意点・落とし穴

• 複数行・複数テーブルにまたがるトランザクションは不可
  • ロック / ロールバックという概念自体がない
• JOIN・参照整合性なし
  • クエリパターン先決でテーブル設計する必要がある
• インデックスは推奨されない
  • 用意はあるが NoSQL 一般としてあまり使わない
• マルチデータセンタはバックアップではない
  • 人為的な大量削除はレプリで他 DC にも伝播する
  • スナップショット / インクリメンタルバックアップは別途必要
• クエリ駆動設計
  • 「どんなクエリで読むか」を先に決めてからテーブルを設計する思想
  • RDB と発想が逆

Amazon DynamoDB（ワイドカラム / KVS / マネージド）

概要

AWS が提供するフルマネージド NoSQL です。Amazon が EC サイト運営で培った Dynamo 論文の系譜にあり、AWS が DB エンジンそのものを提供する点で他の AWS DB サービス（RDS / ElastiCache / Redshift など）と異なります。バックアップ・レプリケーション・バージョンアップ等の運用は AWS が担います。

データモデル

階層はテーブル → 項目（アイテム）→ 属性（アトリビュート）で、各アイテムが持つ属性は項目ごとに違ってよい構造です。

• データ型
  • 単一型（String / Number / Binary / Boolean / Null）
  • 多値型（StringSet / NumberSet / BinarySet）
  • ワイドカラム型（Map / List）
• DynamoDB JSON
  • Map / List で JSON ドキュメントをそのまま格納可能
• キー
  • 「ハッシュキーのみ」または「ハッシュキー + レンジキー」の 2 通り
  • 3 つ以上の複合キーが要る場合は工夫（テーブル分割 / 属性をマージしたコンポジットパーティションキー）が必要

主要機能

• インデックス
  • ローカルセカンダリインデックス（LSI、ハッシュキーの範囲内）
  • グローバルセカンダリインデックス（GSI、テーブル全体）
• DynamoDB Streams
  • 項目レベルの変更履歴を時系列で保持
  • ほぼリアルタイムで変更前後を取得可能
  • Kinesis 系と類似のシャード構造
• API
  • テーブル CRUD（CreateTable 等）
  • 項目 CRUD（PutItem / GetItem / UpdateItem / DeleteItem）
  • 検索（Scan / Query）
  • バッチ（BatchGetItem / BatchWriteItem）
• 条件付き書き込み（ConditionExpression）とアトミックカウンタ（UpdateExpression）
• ACID トランザクション（TransactWriteItems / TransactGetItems）
  • 複数項目・複数テーブルにわたるトランザクション処理を実行可能
• DynamoDB Accelerator（DAX）
  • インメモリキャッシュレイヤを前段に置きマイクロ秒応答を実現
• オプティミスティックロック
  • 高レベル API の @DynamoDBVersionAttribute で実現
• DynamoDB Local
  • 開発・評価用にローカル動作可能

整合性・スケーラビリティ

書き込みは複数アベイラビリティゾーン（AZ）に分散され、2 AZ に書けた時点で ACK を返します。読み込みは結果整合性がデフォルトで、強整合性が必要な場合は Consistent Read オプションを指定します。

スループットはキャパシティーユニット（RCU / WCU）で制御します。

• RCU（読み込み）
  • 4KB の項目に対して 1 秒あたり 1 回の強整合読み込み、または 2 回の結果整合読み込み
• WCU（書き込み）
  • 1KB の項目に対して 1 秒あたり 1 回の書き込み

容量モードはプロビジョンド（事前にキャパシティを確保）とオンデマンド（リクエスト単位の従量課金）の 2 種から選択します。スパイクが読みにくいワークロードはオンデマンド、定常負荷が読めるワークロードはプロビジョンド + Auto Scaling が一般的です。

スループットはパーティションに均等に按分されるため、特定キーへのアクセス集中（ホットパーティション）が発生すると 1/N しか性能が出ません。ハッシュキー設計が性能の核となります。

マルチリージョン要件には Global Tables が用意されており、複数リージョン間でアクティブ-アクティブのレプリケーションを構成できます。

主な使い道

• AWS 上のシステムのデータストア（他の AWS サービスとの連動性が高い）
• データドリブンなシステム基盤
• ユーザの利用頻度に応じた課金体系のサービス（従量課金との親和性が高く、収益性のあるモデルを構成しやすい）
• 管理用メタデータや RESTful アプリのバックエンド

注意点・落とし穴

• ホットパーティション
  • アクセス集中が起きないハッシュキー設計が必須
• キーの組み合わせ制約
  • ハッシュキー単独 or ハッシュ+レンジの 2 通りのみ
  • 3 キー以上は工夫が必要
• 大量更新・削除に弱い
  • PutItem 以外はキー指定必須
  • Batch も BatchGetItem 100 件 / BatchWriteItem 25 件が上限
• JOIN 不可、関数 / 集計は限定的
  • アプリ側で組み立てるか、別途集計用のストアを用意する
• クラウド依存
  • AWS 以外で動かせない、独自カスタマイズが効かない、API にない操作はできない
• コスト見積もりの難しさ
  • キャパシティ料金が大きく、性能と費用のトレードオフ
  • 長期利用ならリザーブドキャパシティで割安化
• DB 自体の稼働監視は不可
  • 監視は CloudWatch メトリック（プロビジョン / 消費 / Throttle / レイテンシ / 4xx / 5xx）で行う

MongoDB（ドキュメント）

概要

2007 年から 10gen 社（後の MongoDB, Inc.）を中心に開発されているドキュメント DB です。NoSQL の中で広く使われている代表的なプロダクトの一つで、バイナリを置くだけでインストール完了する導入の容易さ、RDB 利用者にも理解しやすい設計から急速に普及しました。マネージドクラウドサービスの MongoDB Atlas も提供されています。

データモデル

階層はmongod プロセス → データベース → コレクション → ドキュメント（BSON）です。BSON は JSON にバイナリエンコードと型拡張を加えたもので、値には配列やサブドキュメント（入れ子 JSON）を持てます。

スキーマ定義不要が原点ですが、ドキュメントバリデーションで列の存在や値の型をチェックして決められた構造の JSON のみ受け付ける運用も可能です。

主要機能

• Mongo クエリ言語
  • db.users.find({"age":30}) のように JSON 条件を渡す
  • $set / $push 等の更新演算子、upsert、distinct、limit / skip / sort などを備える
• インデックス
  • 単一・複合・マルチキー（配列要素）・地理空間・テキスト（日本語非対応）・ハッシュ
  • 属性として TTL / パーシャル / ユニーク / スパースを指定できる
• Aggregation Pipeline
  • $match / $project / $group / $unwind / $lookup（他コレクションの Left Outer JOIN）等を組み合わせた集計
• マルチドキュメントトランザクション
  • レプリカセットでは 4.0 から、シャードクラスタでは 4.2 から ACID トランザクションをサポート
  • 複数ドキュメント・複数コレクションにまたがる更新をアトミックに実行可能
• レプリカセット
  • プライマリ 1 台 + セカンダリ複数で構成
  • プライマリ障害時はセカンダリ間で選挙を行い新プライマリを選出
  • セカンダリには arbiter（投票のみ）/ hidden（同期のみ）/ delayed（遅延同期）の特殊種別がある
• シャーディング
  • シャードキーの範囲を「チャンク」として分散配置
  • チャンクが偏ったら自動再配置、大きすぎたら自動 2 分割
  • クライアントは mongos ルータにアクセス、配置情報は設定サーバに保存
• 整合性オプション
  • write concern（W値: 何台のセカンダリに書けたら ACK を返すか）と read concern を指定
  • W=2 / W=majority など柔軟に設定できる
• GridFS
  • 16MB 以上のファイルを自動分割してシャーディングで分散保存する API

整合性・スケーラビリティ

書き込みはプライマリのみで受け付けます（マルチマスターではありません）。書き込み可用性は新プライマリ選出までの間ダウンタイムがあり、マルチマスター系の NoSQL より低めです。読み込みは設定でセカンダリにも分散できますが、結果整合性となります。

水平スケールはシャーディング（書き込み）+ セカンダリ読み込み（読み込み）で実現します。書き込みロックはドキュメント単位で取得されます。

主な使い道

• Web アプリ・オンラインゲームのバックエンド（スケールアウトと半構造データの両立）
• ログ蓄積（Fluentd で集めて MongoDB に格納する組み合わせが定番。TTL インデックスで古いログ自動削除）
• 大容量ファイル保管（GridFS 経由）
• 地図アプリ（地理空間クエリ・インデックス）
• CMS・カタログ（スキーマが頻繁に変わるコンテンツ）

注意点・落とし穴

• JOIN は集計（$lookup）以外できない
• 参照整合性なし
  • 関連ドキュメントの一貫した削除・更新は不可
• トリガ / ストアドプロシージャ / シーケンス / ビュー / 副問い合わせなし
• テキストインデックスは日本語非対応
• マルチマスターレプリケーションではない
  • プライマリしか書けないため、書き込み可用性は新プライマリ選出までの間ダウンする
• インデックスを使わないソートに 32MB のメモリ制限
• シャードキー選定が運命を分ける
  • 不適切だとホットシャードが発生し、後から変更も難しい
• マルチドキュメントトランザクションは万能ではない
  • 利用できるが、アトミックなのは単一ドキュメント前提のスキーマ設計を優先するのが王道

Neo4j（グラフ）

概要

Neo Technology 社が 2003 年から開発しているグラフ DB です。汎用グラフ DB の代表的なプロダクトであり、SQL ライクで論理構成能力の高いCypher クエリ言語を持ち、データベースとしての完成度が高いプロダクトです。

データモデル

プロパティグラフモデルを採用します。RDB と異なり、関係性そのものが「情報」として扱われる点が特徴です（RDB では関係性は単なる紐付け手段）。

構成要素	役割
ノード	RDB のレコード相当。属性（プロパティ）を複数持てる
関係性（Relationship）	ノード間の永続化された結合。方向とタイプを持ち、属性も持てる
ラベル	同じ種類のノードを識別。RDB のテーブル / パーティション相当
プロパティ	RDB のカラム相当。ノード・関係性両方に持てる

スキーマレスで、CREATE database / CREATE table のような事前定義はありません。

主要機能

• Cypher クエリ言語
  • MATCH (a:Person)-[:KNOWS]->(b:Person) のようなパターンマッチで記述
  • CRUD + WITH（クエリブロック間でリストを引き渡すパイプ）/ UNION / UNWIND / CASE 等を備える
  • GROUP BY が存在せず、集合関数の前にくる識別子が暗黙的にグループキーになる
• インデックス
  • 検索開始ノードを探すために属性に対して宣言
  • 複合キーは作れない
• 制約（CONSTRAINT）
  • 属性の一意性
• 実行計画
  • RULE BASE / COST BASE（2.2.x 以降のデフォルト）
  • EXPLAIN / PROFILE で確認
• ACID トランザクション
  • ネイティブ Java API・REST API いずれでも対応
• HA Cluster
  • マスター 1 台 + 複数スレーブのクォーラム構成（3 台以上の奇数台推奨）
  • マスター障害時の切替は数秒以内
• Causal Cluster
  • コアサーバ（書き込みクラスタ）+ 読み取りレプリカからなるクラスタ構成
  • 因果整合性（Causal Consistency）を提供する
• Graph Data Science
  • 経路探索・PageRank・コミュニティ検出などのグラフアルゴリズムを提供するライブラリ
• アクセス手段
  • Web UI（GUI）/ Neo4j シェル（CUI）/ ライブラリ（Java Native API）/ REST API / Bolt プロトコル

整合性・スケーラビリティ

ここがグラフ DB の核心です。シャーディング不可で、単一ノードに収まるデータ量・メモリ量が上限となります。スケール手段は以下の 2 つに限られます。

1. HA クラスタ: 読み書きの負荷分散
2. キャッシュシャーディング（エンタープライズ版のみ）: HA クラスタ内の Neo4j インスタンス間でサブグラフを分散キャッシュ

「NoSQL だからスケーラブル」という直感は Neo4j には当てはまりません。書き込みのスケールアウトは RDB より難しく、Neo4j を選ぶ理由は関係性の表現力と探索性能であって、スケーラビリティではない点に注意が必要です。

主な使い道

• 経路探索（「ある駅から別の駅への最短経路」など）
• ソーシャルネットワークの関係性解明（「友達の友達の友達」）
• 詐欺検知（不審な取引パターンの探索）
• レコメンド（関連性に基づく推薦）
• ナレッジグラフ（データ間の繋がりから新しい発見・価値を生む業務）

注意点・落とし穴

• 集計レポーティングには不向き
  • 完全な OLTP エンジンで、DWH 的な集計関数は提供していない
• メモリ前提
  • グラフはメモリに展開される
  • 属性数・属性値長は小さい方が望ましい
• ビッグデータ系には全く向かない
  • ログ解析等は他 DB を選ぶべき
• データ数の上限
  • ノード 340 億 / 関係性 340 億 / 属性最大 2,740 億件 / 関係性タイプ 65,000 種類
• 属性キーのタイポで構文エラーが出ない
  • 結果が NULL になるだけで、NULL が出たらタイポを疑う
• GROUP BY なし
  • 集合関数の暗黙集約に慣れる必要がある
• 複合キーインデックスなし
  • インデックスも制約も 1 属性のみ
• データモデル設計が肝
  • 「繋がりが価値を生むか」で郵便番号などをノードにするか属性にするかを決める
  • 形式論ではなく価値創出の観点で設計する

Couchbase（ドキュメント）

概要

分散キャッシュの Memcached と Apache CouchDB が融合して誕生したドキュメント DB です（名前から CouchDB を連想しがちですが別物）。Memcached 互換プロトコルによる低レイテンシ・高スループットと、JSON ドキュメントへの SQL ライクなクエリを両立します。クラウド／オンプレ向けの Couchbase Server に加え、モバイル向けの Couchbase Lite + Sync Gateway も提供されています。

データモデル

データはバケットに格納します。バケット内にユニークなキー（最大 250 バイト）とバリュー（最大 20MB、バイナリ可）を保存します。バリューを JSON にすると項目単位のクエリや部分更新が可能になります。1 バケットには 1,024 個の vBucket があり、キーのハッシュで自動マッピングされます。

各ノードはマネージドキャッシュ（RAM）と永続化用ディスクを持ち、クライアントのアクセスは常にキャッシュ経由となります。書き込みもまずキャッシュへ反映し、ディスク永続化・レプリケーション・インデックス反映はすべて非同期というメモリファースト設計です。

主要機能

• N1QL（ニッケル）
  • JSON 用の SQL ライククエリ言語
  • WHERE / ORDER BY / JOIN / NEST / UNNEST 等
  • RDB 経験者の学習コストが低い
• Global Secondary Index（GSI、4.0〜）
  • N1QL 高速化用
• View（差分 Map/Reduce）
  • GROUP BY 集計など N1QL が苦手な領域向け
• Memcached 互換 API
  • 既存 Memcached からの移行が容易
• XDCR（クロスデータセンタレプリケーション）
  • 異なる DC / リージョン間の同期
  • 双方向 XDCR でマルチマスター構成も可能
  • 衝突解決が「多く更新された方が勝つ」と直感に反するため、キー空間を分けるのがベストプラクティス
• 多次元スケーリング
  • Data / Query / Index の 3 サービスを別ノードへ配置可能（4.0 以降）

整合性・スケーラビリティ

同一キーのアクティブな vBucket は常に 1 ノードが担当し、キーアクセスは強い一貫性を持ちます（CAP 上は CP）。レプリカは可用性目的で参照には使われません。View / GSI は非同期反映のため結果整合性となります。RYOW（Read Your Own Writes）は N1QL ScanConsistency=request_plus などで担保します。

ノード追加 / 削除 + リバランスで vBucket を再配置し、無停止で線形に伸縮できます。

主な使い道

• インタラクティブな Web システム
• 高機能なキャッシュ（既存 RDB / レガシーシステムの手前）
• メインのデータベース
• コンテンツのメタデータストア（本体は CDN / S3、メタデータは Couchbase）
• モバイル / IoT（Couchbase Lite + Sync Gateway でエッジ - バックエンド同期）

Microsoft Azure Cosmos DB（旧 DocumentDB / マルチモデル）

概要

Microsoft が提供するフルマネージド NoSQL です。当初はDocumentDBというドキュメント DB として登場し（2014 年プレビュー / 2015 年 GA）、2017 年に Azure Cosmos DB にリネーム + マルチモデル化されました。現在はドキュメント API（旧 DocumentDB）に加え、MongoDB API・Cassandra API・Gremlin（グラフ）API・Table API・PostgreSQL 互換 API などを単一サービスでサポートしています。

データモデル

階層はデータベースアカウント → データベース → コレクション（コンテナ）→ ドキュメント（アイテム）です。コレクション配下にストアドプロシージャ・トリガ・UDF を持ちます。

ドキュメントはユーザ作成の JSON で、スキーマ定義不要です。デフォルトで全プロパティにインデックスが自動作成されます。

主要機能

• DocumentDB SQL
  • SQL ベースの独自クエリ言語
  • 階層ナビゲーション・自己 JOIN（単一ドキュメント内）・空間クエリ・UDF 呼び出しに対応
• JavaScript ストアドプロシージャ / トリガ / UDF
  • DB エンジンと同じメモリ空間で動作
  • 複数ドキュメントの更新を 1 ストアドプロシージャに束ねれば All or Nothing が保証される
• インデックス自動作成
  • 全プロパティを対象
  • Consistent / Lazy / None モードあり
  • 種類はハッシュ / 範囲 / 空間
• トリガ
  • 作成 / 更新 / 削除の pre / post で実行可能
  • 関連処理と同一トランザクション
• 楽観的同時実行制御
  • HTTP ETag で実現

整合性・スケーラビリティ

整合性レベルはStrong / Bounded Staleness / Session / Consistent Prefix / Eventualの 5 段階で、データベースアカウント単位で設定します（リクエスト単位で下げることも可能）。デフォルトは Session です。

レプリケーションは 1 プライマリ + 2 以上のセカンダリで Azure Service Fabric 上にフェイルオーバ自動化されます。スケールアウトはハッシュ / 範囲のパーティション分割で実現し、マルチリージョン構成にも標準で対応します。

主な使い道

• Web / モバイルアプリのバックエンド
• IoT のデバイステレメトリ
• マルチテナントアプリ（テナント ID をパーティションキー）
• 時系列データ（タイムスタンプで範囲パーティション）
• ユーザプロファイル / カタログデータ

比較言及プロダクト

業務・面接で出会う頻度がやや低い 5 プロダクトを、上記との対比で要点だけまとめます。

Memcached（KVS）

• 純粋な KVS で、Redis のような複雑なデータ構造（List / Hash / Sorted Set 等）は持たない
• 永続化なし（プロセス停止でデータ消失）
• マルチスレッド設計（Redis はシングルスレッド）
• 単機能ゆえに Redis よりシンプルで運用負荷が低いが、Redis でできる「カウンタ」「ランキング」「Pub/Sub」などはできない
• Redis が登場した今の選択肢として残る理由は、「キャッシュ専用で機能を増やしたくない」「Memcached 互換プロトコルが必要」場面

HBase（ワイドカラム）

• Cassandra と同じく BigTable 論文系譜のワイドカラム DB
• 大きな違いはマスタースレーブ型（Cassandra はマスターレス）であること
• Hadoop / HDFS エコシステム前提で動く
• 「Hadoop 環境で使う」「マスタースレーブ運用に慣れている」場面では選択肢になるが、新規採用の主流は Cassandra / DynamoDB

Riak（KVS / ワイドカラム）

• Cassandra と同じく Dynamo 論文系譜のマスターレス NoSQL
• 結果整合性 + 調整可能整合性
• 商用サポートを提供していた Basho 社が 2017 年に解散しており、新規採用の選択肢としては縮小傾向
• Cassandra との位置付けの違いは、Cassandra より KVS 寄りでデータモデルがシンプルな点

CouchDB（ドキュメント）

• Apache 配下のドキュメント DB
• HTTP / JSON ベースの API
• MVCC（Multi-Version Concurrency Control）と双方向の同期レプリケーション機能が特徴
• MongoDB の台頭で新規採用は減ったが、オフライン同期が要るアプリ（モバイル）では選択肢になりうる
• 名前が似ている Couchbase は別物（Couchbase は Memcached + CouchDB の融合系譜）

OrientDB

• グラフ + ドキュメントのマルチモデル DB
• 単一のクエリ言語で両モデルを扱える点が特徴
• 汎用グラフ DB の主流が Neo4j に集中する中、マルチモデル機能を活かす場面で選択肢になる程度

プロダクト早見表

プロダクト	カテゴリ	クラスタ型	ストレージ	整合性	代表的な使い道
Redis	KVS（データ構造サーバ）	マスタースレーブ + Cluster	インメモリ + RDB/AOF	非同期レプリ（弱）	キャッシュ・セッション・カウンタ・ランキング・Pub/Sub
Memcached	KVS（純粋）	クライアント側分散	インメモリのみ	なし	キャッシュ専用
Cassandra	ワイドカラム	マスターレス（リング）	LSM-tree（SSTable）	結果整合 + 調整可能	IoT・時系列・メッセージング・大量書き込み
HBase	ワイドカラム	マスタースレーブ	LSM-tree	強整合	Hadoop 環境
DynamoDB	ワイドカラム / KVS（マネージド）	マスターレス（AWS 側）	AWS 内部	結果整合（強整合は明示）	AWS 環境の汎用 NoSQL
Riak	KVS	マスターレス	LevelDB / Bitcask 等	結果整合 + 調整可能	Cassandra 系の代替
MongoDB	ドキュメント	マスタースレーブ（レプリカセット）	WiredTiger	プライマリ強整合 / セカンダリ結果整合	Web バックエンド・カタログ・ログ
Couchbase	ドキュメント	マスターレス（vBucket 単位）	メモリファースト + ディスク	キーは強整合 / View・GSI は結果整合	高機能キャッシュ・モバイル同期
CouchDB	ドキュメント	マルチマスター（同期レプリ）	MVCC	結果整合	オフライン同期アプリ
Cosmos DB	マルチモデル（マネージド）	マスタースレーブ + マルチリージョン	Azure 内部	5 段階で選択	Azure 環境の汎用 NoSQL
Neo4j	グラフ	マスタースレーブ（HA Cluster）	グラフネイティブ	ACID	レコメンド・経路探索・詐欺検知
OrientDB	グラフ + ドキュメント	クラスタあり	独自	ACID	グラフとドキュメントを単一 DB で扱う場合

まとめ

NoSQL は「製品単位」で機能・整合性・クラスタ構成・想定ユースケースが大きく異なります。技術選定ではデータモデル分類だけでなくプロダクトの個別特性まで見る必要があります。

• Redis / Cassandra / DynamoDB / MongoDB / Neo4j が主要 5 製品で、業務・面接で頻出するため特性を押さえておく
• インメモリ系（Redis / Memcached）は永続化のトレードオフを理解する
• マスターレス系（Cassandra / DynamoDB / Riak）は線形スケールが効くが結果整合性
• マスタースレーブ系（MongoDB / HBase / Neo4j）は書き込みがプライマリに集中する
• マネージド系（DynamoDB / Cosmos DB）はクラウド依存と引き換えに運用負荷が下がる
• グラフ DB（Neo4j）はスケーラビリティではなく関係性表現が選定理由
• 各プロダクトは継続的に機能追加されているため、トランザクション対応範囲・整合性オプション・マルチリージョン対応など重要機能は採用検討時に最新ドキュメントで確認する

参考書