1.ストレージの種類と特徴

現在、主に使用されているデータストアは、RDBMSとNoSQLに分けられます。それぞれの特性を見てみましょう。

RDBMS

長い歴史を持つ成熟した技術

• リレーション（Relation）に基づいて重複保存を最小限に抑える
• 高い信頼性を持つ
• 比較的高い性能と多様な機能を持つ
• 管理の利便性が高く、追加の管理コストが相対的に小さい

変更や拡張が難しい

• 高性能装置が必要で、リソース消費が多く費用が高い
• スキーマ（Schema）の変更が困難
• テーブルが大きくなるほど遅くなる
• 拡張が困難
• RDBMSは基本的に単一装置で運営されるもので、そのほとんどが水平拡張が困難であったり、制限的である
  • 拡張性不足を解決するには別途方法の検討が必要で、例として次のようなものがある
    • シャーディング（Sharding）：アプリケーションで関連ロジックを開発したり、別途ミドルウェアを使用する
    • 読み取りレプリカ（Read replica）：複製を利用した読み取り負荷分散が可能だが、この場合、一貫性が損なわれることがある（レプリケーションの遅延が発生する可能性あり）

NoSQL

変更や拡張が比較的簡単

• 関係のないデータ処理に最適化されている（データタイプ別に適した製品が異なる）
  • KVS（Key Value Store）
    • 照会基準であるKeyとその値Valueがペアになって構成されているデータタイプに最適化されたストレージ
    • 例）Redis、memcached
  • ドキュメントストア（Document Store）
    • JSONのように可変的な文書構造を持つデータタイプに最適化されたストレージ
    • 例）MongoDB
  • ワイドカラム型ストア（Wide Column Store）
    • テーブルの行ごとにカラムの名前とフォーマットが独立したテーブルのようなカラムファミリー（Column family）を含むデータタイプに最適化されたストレージ
    • 例）Cassandra、HBase
• スキーマレス（Schemaless）：スキーマがなく、そのためリレーションもない
• 高い拡張性を持ち、次のような機能がサポートされることがある
  • 自動シャーディング（Auto Sharding）
  • サービス中断のないシャード追加

開発/運用コストの追加

• 限定的な一貫性：分散しているストレージの他の複製位置への反映が遅れることがあり、サービスでこれを容認しない場合は使用が難しい
• 開発コストの追加：JOINやトランザクションをサポートしないため、必要な場合はアプリケーションで当該機能を実装する必要がある
• 管理コストの追加：構成が複雑で管理ツールや運営に必要な機能が不足している場合があり、管理コストが大きくなる場合がある

NoSQLが生まれた理由

すべてのデータの信頼性がRDBMSレベルである必要はなく、信頼性を多少犠牲にしても、より優れたパフォーマンスや拡張性が必要な場合があります。また、RDBMSはスキーマが途中で変更されたとき、管理する難易度が高く、これを克服するためにスキーマレスが必要となります。関係性がないデータやその量も多いため、データタイプに応じて便利に使えるように分化されました。

2.ストレージの選択基準

データサイズの分散が不要なほど小さく、アクセスが頻繁でなければ、汎用性の高いRDBMSを使うことお勧めします。また、高い一貫性が必要ならRDBMSをお勧めします。もしNoSQLを使用する場合は、一貫性が保証できるようにアプリケーションで関連機能の追加開発が必要です。またRDBMSでは、データサイズが大きくシャーディングを必要とする場合、アプリケーションでシャーディングロジックを開発する必要があります。非常に多くのデータを保存し、それらの分析/統計処理が必要な場合は、関連機能をサポートするNoSQLを考慮に入れることができますが、システムの複雑度が高く、管理コストが多少高くなることがあります。

3.ストレージの選択例

ギルド戦のあるカジュアルゲームを例に挙げてみましょう。
次のように論理DBが分かれています。それぞれのDBに適したストレージを選択してみましょう。

各DBは、次のような特徴があります。

• Shard index DB
  • ユーザーのシャード位置情報を保存する
  • Read負荷中心
  • 読み取りの一貫性が重要
• Common DB
  • 内部テーブルの性質上、場合によっては追加分割が可能（ユーザー情報、ランキング、ギルド）
  • テーブルの性質によって、Read負荷またはRead/Write負荷が発生
  • 一部のクエリはトランザクションが必要
• Game DB
  • ユーザーの増加に応じてデータおよび負荷増加。シャーディング対象
  • 一部のクエリはトランザクションが必要
• Log DB
  • ユーザー数/ログ保存日数に応じてデータ増加
  • Write負荷中心
  • 統計/分析が必要

各DBに適したストレージを下表にまとめます。

注1）
RDBMSは、ユーザーキー基盤のシャーディング機能をアプリケーションで開発する必要があります。
NoSQLは自動シャーディングがサポートされますが、トランザクションなどの一貫性が必要な場合、アプリケーションでその機能を実装する必要があります。

注2）
ログは時間の経過とともに増え続けるので、保管期間を導入して全体のデータサイズを制限する必要があります。
RDBMSは、保管すべきデータ量が多い場合、ログなどのコールド（Cold）データの保持には、低性能の大容量機器にアーカイブストアを追加設定することをお勧めします。
データ量が非常に多い場合はNoSQLのうち大量ログ処理に特化した製品の使用をお勧めします。