データ ストア モデルについて

  • [アーティクル]

現代のビジネス システムで管理する異種データの量は急速に増加しています。 この多様性は、単一のデータ ストアがいつも最善のアプローチであることを意味しません。 代わりに、異なる種類のデータを、それぞれ特定のワークロードや使用パターンに重点を置いた異なるデータ ストアに格納する方が適切です。 ポリグロット パーシステンスという用語は、さまざまなデータ ストア テクノロジを組み合わせて使用するソリューションを表すために使われます。 そのため、主なストレージ モデルとそのトレードオフについて理解しておくことが重要です。

要件に応じた正しいデータ ストアを選択することは、重要な設計上の意思決定です。 SQL および NoSQL データベースの文字通り何百もの実装の中から選択することになります。 データ ストアは、多くの場合、データの構造とサポートする操作の種類によって分類されます。 この記事では、最も一般的ないくつかのストレージ モデルについて説明します。 特定のデータ ストア テクノロジで、複数のストレージ モデルをサポートしていることがあるので注意してください。 たとえば、リレーショナル データベース管理システム (RDBMS) では、キー/値のストレージやグラフ ストレージもサポートしていることがあります。 実際に、1 つのデータベース システムで複数のモデルをサポートする、いわゆるマルチモデル サポートに対する一般的な傾向があります。 ただし、概要的にさまざまなモデルを理解しておくことも役に立ちます。

特定のカテゴリのすべてのデータ ストアが、同じ機能セットを提供するとは限りません。 ほとんどのデータ ストアは、データをクエリして処理するサーバー側機能を提供します。 この機能は、データ ストレージ エンジンに組み込まれている場合があります。 他の例では、データのストレージ機能と処理機能が分離され、処理と分析のための複数のオプションがある場合もあります。 データ ストアは、さまざまなプログラムおよび管理インターフェイスもサポートします。

一般に、要件に最適なストレージ モデルを検討することから始める必要があります。 次に、機能セット、コスト、および管理しやすさなどの要因に基づいて、そのカテゴリ内の特定のデータ ストアを検討します。

注意

クラウド導入に関するデータ サービス要件の特定と確認の詳細については、Azure 向けの Microsoft クラウド導入フレームワークに関するページを参照してください。 同様に、ストレージ ツールとサービスの選択について学習できます。

リレーショナル データベース管理システム

リレーショナル データベースでは、行と列がある一連の 2 次元テーブルとしてデータを編成します。 ほとんどのベンダーが、データを取得し、管理するために Structured Query Language (SQL) の言語を提供しています。 RDBMS は一般に、情報の更新用に、ACID (原子性、一貫性、独立性、永続性) モデルに準拠する、トランザクションの一貫性があるメカニズムを実装します。

RDBMS は一般に、データ構造が事前定義されている Schema on Write モデルをサポートしており、すべての読み取りまたは書き込み操作でそのスキーマを使用する必要があります。

強力な一貫性の保証が重要な場合、このモデルはきわめて有益です。このモデルでは、すべての変更がアトミックで、トランザクションは常にデータを一貫性のある状態のままにします。 ただし、RDBMS を水平方向にスケールアウトするには、通常は必ず何らかの方法でデータをシャード化する必要があります。 また、RDBMS 内のデータは正規化の必要がありますが、これは、必ずしもすべてのデータ セットに適しているとは限りません。

Azure サービス

ワークロード

  • レコードが頻繁に作成および更新される。
  • 1 つのトランザクションで複数の操作を完了する必要がある。
  • データベースの制約を使用して、リレーションシップが強制的に適用される。
  • クエリのパフォーマンスを最適化するために、インデックスが使用される。

データ型

  • データは高度に正規化される。
  • データベース スキーマが必要であり、強制的に適用される。
  • データベース内のデータ エンティティ間の多対多リレーションシップ。
  • 制約はスキーマで定義され、データベース内の任意のデータに適用される。
  • データには、高度な整合性が必要である。 インデックスおよびリレーションシップは、正確に維持される必要がある。
  • データには、強固な一貫性が必要である。 全データがすべてのユーザーおよびプロセスと 100% 整合性があることを保証した方法で、トランザクションが処理される。
  • 個々のデータ エントリのサイズが小規模から中規模である。

例

  • 在庫管理
  • 注文管理
  • レポート データベース
  • 会計

キー/値のストア

キー/値のストアによって、各データの値が一意キーに関連付けられます。 ほとんどのキー/値のストアは、簡単なクエリ、挿入、および削除操作のみをサポートしています。 (部分的または完全に) 値を変更するには、アプリケーションで値全体の既存のデータを上書きする必要があります。 ほとんどの実装で、1 つの値の読み取りや書き込みは、アトミック操作です。

アプリケーションが任意のデータを値のセットとして格納できます。 すべてのスキーマ情報がアプリケーションによって提供される必要があります。 キー/値のストアは単純にキーによって、値を取得または格納します。

Diagram of a key-value store

キー/値のストアは、単純なルックアップを実行するアプリケーション用に高度に最適化されていますが、さまざまなキー/値のストア間でデータのクエリを実行する必要がある場合は、あまり適していません。 キー/値のストアは、値によるクエリ実行用には最適化されていません。

1 つのキー/値のストアでは、個々のコンピューター上の複数のノード間でデータを簡単に分散できるため、きわめてスケーラブルにすることができます。

Azure サービス

ワークロード

  • データ アクセスにはディクショナリなどの単一のキーが使用される。
  • 結合、ロック、統合は必要ない。
  • 集計メカニズムは使用されない。
  • 一般に、セカンダリ インデックスは使用されない。

データ型

  • 各キーが単一の値に関連付けられている。
  • スキーマの適用はない。
  • エンティティ間にリレーションシップはない。

例

  • データ キャッシュ
  • セッションの管理
  • ユーザーの基本設定とプロファイルの管理
  • 製品推奨と広告提供

ドキュメント データベース

ドキュメント データベースには、名前付きフィールドとデータで構成された "ドキュメント" のコレクションが格納されています。 データは、単純な値、またはリストや子コレクションなどの複雑な要素です。 ドキュメントは一意キーによって取得されます。

通常、ドキュメントには、顧客や注文などの単一のエンティティのデータが含まれます。 RDBMS 内の複数のリレーショナル テーブル間に分散されている情報が、ドキュメントに格納されている場合があります。 それぞれのドキュメントの構造が同じである必要はありません。 アプリケーションは、ビジネス要件の変更に応じて、さまざまなデータをドキュメントに格納できます。

Diagram of a document store

Azure サービス

ワークロード

  • 挿入や更新の操作は共通である。
  • 非オブジェクト リレーショナル インピー ダンスは適合しない。 ドキュメントには、アプリケーション コードで使用されるオブジェクト構造のほうがより適合します。
  • 個々のドキュメントが取得され、単一のブロックとして書き込まれる。
  • データは、複数のフィールドにインデックスを必要とする。

データ型

  • 非正規化された方法で、データを管理できる。
  • 個々のドキュメント データのサイズは比較的小さい。
  • 各ドキュメントの種類で、独自のスキーマを使用できる。
  • ドキュメントには、省略可能なフィールドを含めることができる。
  • ドキュメント データは半構造化されている。つまり、各フィールドのデータは、厳密には定義されていません。

例

  • 製品カタログ
  • コンテンツ管理
  • 在庫管理

グラフ データベース

グラフ データベースは、ノードとエッジの 2 種類の情報を格納します。 エッジによって、ノード間のリレーションシップが指定されます。 ノードもエッジも、そのノードまたはエッジに関する情報を提供するプロパティを持つことができ、テーブルの列に似ています。 エッジは、リレーションシップの性質を示す方向を持つこともできます。

グラフ データベースは、ノードとエッジのネットワークに対してクエリを効率的に実行し、エンティティ間のリレーションシップを分析できます。 次の図にグラフとして構築された組織の職員のデータベースを示します。 エンティティは従業員や部門で、エッジは社内の直属の上下関係と従業員が勤務する部署を示しています。

Diagram of a document database

この構造により、"Sarah に直接または間接的に報告するすべての従業員を見つける" または "John と同じ部門で働いている人" などのクエリの実行が簡単になります。多数のエンティティとリレーションシップを持つ大規模なグラフでは、複雑な分析をすばやく実行できます。 多くのグラフ データベースは、リレーションシップのネットワークを効率的に走査するために使用できるクエリ言語を提供しています。

Azure サービス

ワークロード

  • データ項目間に多数のホップが関連しているデータ項目間の複雑なリレーションシップ。
  • データ項目間のリレーションシップは動的であり、時間と共に変化する。
  • オブジェクト間のリレーションシップは最上位の扱いになり、外部キーと走査のための結合は必要ない。

データ型

  • ノードとリレーションシップ。
  • ノードは、テーブル行または JSON ドキュメントに似ている。
  • リレーションシップはノードと同様に重要であり、クエリ言語で直接公開される。
  • 複数の電話番号の保持者など、複合オブジェクトは、走査可能なリレーションシップと組み合わせて、個々のより小さなノードに分割される傾向がある。

例

  • 組織図
  • ソーシャル グラフ
  • 不正行為の検出
  • 推奨エンジン

データ分析

データ分析ストアは、データの取り込み、保存、および分析のための大規模な並列ソリューションを提供します。 データは、スケーラビリティを最大限に高めるために複数のサーバーに分散されます。 区切りファイル (CSV)、parquet、ORC などの大きなデータ ファイル形式が、Data Analytics で広く使用されています。 履歴データが格納されるのは、通常、BLOB ストレージ、Azure Data Lake Storage Gen2 などのデータ ストアです。その後、これらは外部テーブルとして、Azure Synapse、Databricks、または HDInsight によってアクセスされます。 パフォーマンスのために parquet ファイルとして格納されているデータを使用する一般的なシナリオについては、Synapse SQL での外部テーブルの使用に関するページをご覧ください。

Azure サービス

ワークロード

  • データ分析
  • 企業の BI

データ型

  • 複数のソースからの履歴データ。
  • 通常は、"star" または "snowflake" スキーマで非正規化され、ファクト テーブルおよびディメンション テーブルで構成されている。
  • 通常は、スケジュールに基づいて新しいデータと共に読み込まれる。
  • 多くの場合、ディメンション テーブルにはエンティティの複数の履歴バージョンが含まれ、"緩やかに変化するディメンション" として参照される。

例

  • エンタープライズ データ ウェアハウス

列ファミリのデータベース

列ファミリのデータベースは、データを行と列に編成します。 列ファミリのデータベースは、その最も単純な形式では、少なくとも概念的にリレーショナル データベースによく似ています。 列ファミリのデータベースの真の能力は、スパース データの構築のための非正規化されたアプローチにあります。

列ファミリのデータベースは、行と列を含む表形式データを保持するものと考えることができますが、列は列ファミリと呼ばれるグループに分類されます。 各列のファミリは論理的に相互に関連する列のセットを保持し、一般にユニットとして取得または操作されます。 個別にアクセスされるその他のデータは、個別の列ファミリに格納できます。 列ファミリ内では、新しい列を動的に追加することができ、行をスパースにする (つまり、行のすべての列に値を持つ必要がない) ことができます。

次の図は、Identity と Contact Info の 2 つの列ファミリのある例を示しています。 単一のエンティティのデータは、各列ファミリに同じ行キーを持ちます。 列ファミリ内の任意の特定のオブジェクトの行を動的に変えることができるこの構造は、列ファミリ アプローチの重要な利点であり、この形式のデータ ストアが、構造化された揮発性データの格納に最適とされます。

Diagram of a column-family database

キー/値のストアまたはドキュメント データベースとは異なり、ほとんどの列ファミリのデータベースは、ハッシュを計算するのではなく、キー順序でデータを格納します。 多くの実装で、列ファミリ内の特定の列に対してインデックスを作成できます。 インデックスを使用すると、行キーではなく、列値によってデータを取得できます。

一部の実装では、複数の列ファミリにまたがる行全体で原子性を提供するものもありますが、行の読み取りと書き込みの操作は通常、単一の列ファミリでアトミックです。

Azure サービス

ワークロード

  • ほとんどの列ファミリ データベースでは、極めて高速で書き込み操作を実行する。
  • 更新および削除の操作は、ほとんど行われない。
  • 高いスループットと低い待機時間でのアクセスを提供するように設計されている。
  • より大規模なレコード内にある特定のフィールド セットへの簡単なクエリ アクセスをサポートしている。
  • 極めて高い拡張性。

データ型

  • データは、キー列と 1 つまたは複数の列ファミリで構成されたテーブルに格納される。
  • 特定の列は、個々の行別に変更できる。
  • 個々のセルには get および put コマンド経由でアクセスできる。
  • スキャン コマンドを使って、複数の行が返される。

例

  • Recommendations
  • パーソナル化
  • センサー データ
  • テレメトリ
  • メッセージング
  • ソーシャル メディア分析
  • Web 分析
  • アクティビティの監視
  • 天気およびその他のタイム シリーズ データ

検索エンジンのデータベース

検索エンジンのデータベースを使用すると、アプリケーションによって、外部データ ストアで保持されている情報を検索できます。 検索エンジンのデータベースは、膨大な量のデータのインデックスを作成し、これらのインデックスへのほぼリアルタイムのアクセスを提供できます。

インデックスは、多次元にすることができ、大量のテキスト データ間でフリーテキスト検索をサポートできます。 インデックス作成は、検索エンジンのデータベースによってトリガーされるプルモデルを使用するか、外部のアプリケーション コードによって開始されるプッシュ モデルを使用して実行できます。

検索は、完全でもあいまいでも可能です。 あいまい検索では、一連の用語に一致するドキュメントを検索し、それらがどの程度一致しているかを計算します。 一部の検索エンジンは、シノニム、ジャンル拡張 (たとえば、dogs を pets に一致させる)、およびステミング (同じ語幹を持つ単語を照合する) に基づいて一致を返すことができる言語分析もサポートします。

Azure サービス

ワークロード

  • 複数のソースおよびサービスからのデータ インデックス。
  • クエリはアドホックであり、複雑になる場合がある。
  • フルテキスト検索が必要になる。
  • アドホックのセルフ サービス クエリが必要になる。

データ型

  • 半構造化または非構造化テキスト
  • 構造化データへの参照を備えたテキスト

例

  • 製品カタログ
  • サイトの検索
  • ログ記録

タイム シリーズ データベース

時系列データは、時間別に整理された値のセットです。 時系列データベースは通常、大量のデータを多数のソースからリアルタイムに収集します。 更新はまれであり、削除は多くの場合に一括操作として行われます。 一般的に、時系列データベースに書き込まれるレコードは小さいですが、多くの場合はレコード数が多く、データ全体のサイズが急激に大きくなることがあります。

Azure サービス

ワークロード

  • レコードは通常、時系列で追加される。
  • 操作の大部分 (95 99%) は書き込みである。
  • 更新はとんど行われない。
  • 削除は一括で、連続したブロックまたはレコードに対して行われる。
  • データは、時系列の昇順または降順のどちらかで (多くの場合、並行で) 読み込まれる。

データ型

  • 主キーおよび並べ替えのメカニズムとして使用されているタイムスタンプ。
  • タグによって定義されるのは、種類、配信元など、エントリに関する追加情報です。

例

  • 監視およびイベント テレメトリ。
  • センサーまたはその他の IoT データ。

オブジェクト ストレージ

オブジェクト ストレージは、大規模なバイナリ オブジェクト (イメージ、ファイル、ビデオおよびオーディオ ストリーム、大規模なアプリケーション データ オブジェクトおよびドキュメント、仮想マシン ディスク イメージ) の格納と取得に最適です。 このモデルでは、区切りファイル (CSV)、parquet、ORC などの大規模なデータ ファイルも一般的に使用されます。 オブジェクト ストアは大量の非構造化データを管理できます。

Azure サービス

ワークロード

  • キーによって識別される。
  • コンテンツは通常、区切り記号、イメージ、ビデオ ファイルなどのアセットである。
  • コンテンツは持続性があり、任意のアプリケーション層の外部に存在する必要がある。

データ型

  • データ サイズが大きい。
  • 値は非透過的である。

例

  • イメージ、ビデオ、office ドキュメント、PDF
  • 静的 HTML、JSON、CSS
  • ログおよび監査ファイル
  • データベースのバックアップ

共有ファイル

場合によっては、単純なフラット ファイルを使用することが、情報の格納と取得の最も効率的な手段である可能性があります。 ファイル共有を使用すると、ネットワーク経由でファイルにアクセスできます。 適切なセキュリティおよび同時実行アクセス制御メカニズムがあれば、この方法でデータを共有することにより、分散型サービスが可能になり、単純な読み取りおよび書き込み要求などの基本的な低レベルの操作のための高度にスケーラブルなデータ アクセスを提供します。

Azure サービス

ワークロード

  • ファイル システムと対話する既存アプリからの移行。
  • SMB インターフェイスが必要である。

データ型

  • フォルダーの階層セット内のファイル。
  • 標準の I/O ライブラリを使ってアクセスできる。

例

  • レガシ ファイル
  • 多数の VM またはアプリ インスタンスからアクセス可能な共有コンテンツ

各種データ ストレージ モデルを理解したうえで、次の手順でワークロードとアプリケーションを評価し、特定のニーズを満たすデータ ストアを決定します。 このプロセスについて不明な点がある場合は、データ ストレージ デシジョン ツリーを使用してください。

次のステップ