データストア、何をどう使いわけるか

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 NoSQL
データサイズ どれだけ多くのデータを保存できるか 大きくなるほど遅くなる 製品によって異なるが非常に大きなものまで対応する
アクセス頻度 どの程度、頻度にアクセスするか
Hot(頻繁)〜Cold(ほとんどアクセスしない)
Hot 製品によって異なるが、Cold〜Very Hotまで様々
データタイプ どのような形式のデータを保存するのに適切か リレーショナル 非リレーショナル、スキーマレス
一貫性レベル 一貫性がどの程度求められるか トランザクション対応 トランザクション非対応
読み込み遅延が発生する可能性あり
負荷特性 CRUDリクエストをどのよう処理するか 全体的に比較的高い性能 製品によっては、読み取り最適化〜書き込み最適化、および分散処理支援などさまざま
その他   JOIN対応、強力なセキュリティ 高い拡張性、自動シャーディング

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

3.ストレージの選択例

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


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

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

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

項目 Shard index Common Game Log
データサイズ 非常に小さい 比較的小さい 通常 非常に大きい
アクセス頻度 Hot Cold/Hot Hot Hot〜Cold
データタイプ Key-Value リレーショナル/非リレーショナル リレーショナル/非リレーショナル 主に非リレーショナル
一貫性レベル 高い読み取り一貫性 低〜高 低〜高
負荷特性 Read負荷 Read負荷または
Read/Write負荷
Read/Write負荷 Write負荷
おすすめストア RDBMS+Cache RDBMS/NoSQL RDBMS/NoSQL
注1)
RDBMS/NoSQL
注2)

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

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

TOAST Meetup 編集部

TOASTの技術ナレッジやお得なイベント情報を発信していきます
pagetop