データ ストア モデルについてUnderstand data store models

現代のビジネス システムで管理する異種データの量は急速に増加しています。Modern business systems manage increasingly large volumes of heterogeneous data. この多様性は、単一のデータ ストアがいつも最善のアプローチであることを意味しません。This heterogeneity means that a single data store is usually not the best approach. 代わりに、異なる種類のデータを、それぞれ特定のワークロードや使用パターンに重点を置いた異なるデータ ストアに格納する方が適切です。Instead, it's often better to store different types of data in different data stores, each focused toward a specific workload or usage pattern. ポリグロット パーシステンス という用語は、さまざまなデータ ストア テクノロジを組み合わせて使用するソリューションを表すために使われます。The term polyglot persistence is used to describe solutions that use a mix of data store technologies. そのため、主なストレージ モデルとそのトレードオフについて理解しておくことが重要です。Therefore, it's important to understand the main storage models and their tradeoffs.

要件に応じた正しいデータ ストアを選択することは、重要な設計上の意思決定です。Selecting the right data store for your requirements is a key design decision. SQL および NoSQL データベースの文字通り何百もの実装の中から選択することになります。There are literally hundreds of implementations to choose from among SQL and NoSQL databases. データ ストアは、多くの場合、データの構造とサポートする操作の種類によって分類されます。Data stores are often categorized by how they structure data and the types of operations they support. この記事では、最も一般的ないくつかのストレージ モデルについて説明します。This article describes several of the most common storage models. 特定のデータ ストア テクノロジで、複数のストレージ モデルをサポートしていることがあるので注意してください。Note that a particular data store technology may support multiple storage models. たとえば、リレーショナル データベース管理システム (RDBMS) では、キー/値のストレージやグラフ ストレージもサポートしていることがあります。For example, a relational database management systems (RDBMS) may also support key/value or graph storage. 実際に、1 つのデータベース システムで複数のモデルをサポートする、いわゆる マルチモデル サポートに対する一般的な傾向があります。In fact, there is a general trend for so-called multi-model support, where a single database system supports several models. ただし、概要的にさまざまなモデルを理解しておくことも役に立ちます。But it's still useful to understand the different models at a high level.

特定のカテゴリのすべてのデータ ストアが、同じ機能セットを提供するとは限りません。Not all data stores in a given category provide the same feature-set. ほとんどのデータ ストアは、データをクエリして処理するサーバー側機能を提供します。Most data stores provide server-side functionality to query and process data. この機能は、データ ストレージ エンジンに組み込まれている場合があります。Sometimes this functionality is built into the data storage engine. 他の例では、データのストレージ機能と処理機能が分離され、処理と分析のための複数のオプションがある場合もあります。In other cases, the data storage and processing capabilities are separated, and there may be several options for processing and analysis. データ ストアは、さまざまなプログラムおよび管理インターフェイスもサポートします。Data stores also support different programmatic and management interfaces.

一般に、要件に最適なストレージ モデルを検討することから始める必要があります。Generally, you should start by considering which storage model is best suited for your requirements. 次に、機能セット、コスト、および管理しやすさなどの要因に基づいて、そのカテゴリ内の特定のデータ ストアを検討します。Then consider a particular data store within that category, based on factors such as feature set, cost, and ease of management.

リレーショナル データベース管理システムRelational database management systems

リレーショナル データベースでは、行と列がある一連の 2 次元テーブルとしてデータを編成します。Relational databases organize data as a series of two-dimensional tables with rows and columns. ほとんどのベンダーが、データを取得し、管理するために Structured Query Language (SQL) の言語を提供しています。Most vendors provide a dialect of the Structured Query Language (SQL) for retrieving and managing data. RDBMS は一般に、情報の更新用に、ACID (原子性、一貫性、独立性、永続性) モデルに準拠する、トランザクションの一貫性があるメカニズムを実装します。An RDBMS typically implements a transactionally consistent mechanism that conforms to the ACID (Atomic, Consistent, Isolated, Durable) model for updating information.

RDBMS は一般に、データ構造が事前定義されている Schema on Write モデルをサポートしており、すべての読み取りまたは書き込み操作でそのスキーマを使用する必要があります。An RDBMS typically supports a schema-on-write model, where the data structure is defined ahead of time, and all read or write operations must use the schema.

強力な一貫性の保証が重要な場合、このモデルはきわめて有益です。—このモデルでは、すべての変更がアトミックで、トランザクションは常にデータを一貫性のある状態のままにします。This model is very useful when strong consistency guarantees are important — where all changes are atomic, and transactions always leave the data in a consistent state. ただし、RDBMS を水平方向にスケールアウトするには、通常は必ず何らかの方法でデータをシャード化する必要があります。However, an RDBMS generally can't scale out horizontally without sharding the data in some way. また、RDBMS 内のデータは正規化の必要がありますが、これは、必ずしもすべてのデータセットに適しているとは限りません。Also, the data in an RDBMS must normalized, which isn't appropriate for every data set.

Azure サービスAzure services

ワークロードWorkload

  • レコードが頻繁に作成および更新される。Records are frequently created and updated.
  • 1 つのトランザクションで複数の操作を完了する必要がある。Multiple operations have to be completed in a single transaction.
  • データベースの制約を使用して、リレーションシップが強制的に適用される。Relationships are enforced using database constraints.
  • クエリのパフォーマンスを最適化するために、インデックスが使用される。Indexes are used to optimize query performance.

データ型Data type

  • データは高度に正規化される。Data is highly normalized.
  • データベース スキーマが必要であり、強制的に適用される。Database schemas are required and enforced.
  • データベース内のデータ エンティティ間の多対多リレーションシップ。Many-to-many relationships between data entities in the database.
  • 制約はスキーマで定義され、データベース内の任意のデータに適用される。Constraints are defined in the schema and imposed on any data in the database.
  • データには、高度な整合性が必要である。Data requires high integrity. インデックスおよびリレーションシップは、正確に維持される必要がある。Indexes and relationships need to be maintained accurately.
  • データには、強固な一貫性が必要である。Data requires strong consistency. 全データがすべてのユーザーおよびプロセスと 100% 整合性があることを保証した方法で、トランザクションが処理される。Transactions operate in a way that ensures all data are 100% consistent for all users and processes.
  • 個々のデータ エントリのサイズが小規模から中規模である。Size of individual data entries is small to medium-sized.

Examples

  • 在庫管理Inventory management
  • 注文管理Order management
  • レポート データベースReporting database
  • 会計Accounting

キー/値のストアKey/value stores

キー/値のストアによって、各データの値が一意キーに関連付けられます。A key/value store associates each data value with a unique key. ほとんどのキー/値のストアは、簡単なクエリ、挿入、および削除操作のみをサポートしています。Most key/value stores only support simple query, insert, and delete operations. (部分的または完全に) 値を変更するには、アプリケーションで値全体の既存のデータを上書きする必要があります。To modify a value (either partially or completely), an application must overwrite the existing data for the entire value. ほとんどの実装で、1 つの値の読み取りや書き込みは、アトミック操作です。In most implementations, reading or writing a single value is an atomic operation.

アプリケーションが任意のデータを値のセットとして格納できます。An application can store arbitrary data as a set of values. すべてのスキーマ情報がアプリケーションによって提供される必要があります。Any schema information must be provided by the application. キー/値のストアは単純にキーによって、値を取得または格納します。The key/value store simply retrieves or stores the value by key.

キー/値のストアの図

キー/値のストアは、単純なルックアップを実行するアプリケーション用に高度に最適化されていますが、さまざまなキー/値のストア間でデータのクエリを実行する必要がある場合は、あまり適していません。Key/value stores are highly optimized for applications performing simple lookups, but are less suitable if you need to query data across different key/value stores. キー/値のストアは、値によるクエリ実行用には最適化されていません。Key/value stores are also not optimized for querying by value.

1 つのキー/値のストアでは、個々のコンピューター上の複数のノード間でデータを簡単に分散できるため、きわめてスケーラブルにすることができます。A single key/value store can be extremely scalable, as the data store can easily distribute data across multiple nodes on separate machines.

Azure サービスAzure services

ワークロードWorkload

  • データ アクセスにはディクショナリなどの単一のキーが使用される。Data is accessed using a single key, like a dictionary.
  • 結合、ロック、統合は必要ない。No joins, lock, or unions are required.
  • 集計メカニズムは使用されない。No aggregation mechanisms are used.
  • 一般に、セカンダリ インデックスは使用されない。Secondary indexes are generally not used.

データ型Data type

  • 各キーが単一の値に関連付けられている。Each key is associated with a single value.
  • スキーマの適用はない。There is no schema enforcement.
  • エンティティ間にリレーションシップはない。No relationships between entities.

Examples

  • データ キャッシュData caching
  • セッションの管理Session management
  • ユーザーの基本設定とプロファイルの管理User preference and profile management
  • 製品推奨と広告提供Product recommendation and ad serving

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

ドキュメント データベースには、名前付きフィールドとデータで構成された "ドキュメント" のコレクションが格納されています。A document database stores a collection of documents, where each document consists of named fields and data. データは、単純な値、またはリストや子コレクションなどの複雑な要素です。The data can be simple values or complex elements such as lists and child collections. ドキュメントは一意キーによって取得されます。Documents are retrieved by unique keys.

通常、ドキュメントには、顧客や注文などの単一のエンティティのデータが含まれます。Typically, a document contains the data for single entity, such as a customer or an order. RDBMS 内の複数のリレーショナル テーブル間に分散されている情報が、ドキュメントに格納されている場合があります。A document may contain information that would be spread across several relational tables in an RDBMS. それぞれのドキュメントの構造が同じである必要はありません。Documents don't need to have the same structure. アプリケーションは、ビジネス要件の変更に応じて、さまざまなデータをドキュメントに格納できます。Applications can store different data in documents as business requirements change.

ドキュメント ストアの図

Azure サービスAzure service

ワークロードWorkload

  • 挿入や更新の操作は共通である。Insert and update operations are common.
  • 非オブジェクト リレーショナル インピー ダンスは適合しない。No object-relational impedance mismatch. ドキュメントには、アプリケーション コードで使用されるオブジェクト構造のほうがより適合します。Documents can better match the object structures used in application code.
  • 個々のドキュメントが取得され、単一のブロックとして書き込まれる。Individual documents are retrieved and written as a single block.
  • データは、複数のフィールドにインデックスを必要とする。Data requires index on multiple fields.

データ型Data type

  • 非正規化された方法で、データを管理できる。Data can be managed in de-normalized way.
  • 個々のドキュメント データのサイズは比較的小さい。Size of individual document data is relatively small.
  • 各ドキュメントの種類で、独自のスキーマを使用できる。Each document type can use its own schema.
  • ドキュメントには、省略可能なフィールドを含めることができる。Documents can include optional fields.
  • ドキュメント データは半構造化されている。つまり、各フィールドのデータは、厳密には定義されていません。Document data is semi-structured, meaning that data types of each field are not strictly defined.

Examples

  • 製品カタログProduct catalog
  • コンテンツ管理Content management
  • 在庫管理Inventory management

グラフ データベースGraph databases

グラフ データベースは、ノードとエッジの 2 種類の情報を格納します。A graph database stores two types of information, nodes and edges. エッジによって、ノード間のリレーションシップが指定されます。Edges specify relationships between nodes. ノードもエッジも、そのノードまたはエッジに関する情報を提供するプロパティを持つことができ、テーブルの列に似ています。Nodes and edges can have properties that provide information about that node or edge, similar to columns in a table. エッジは、リレーションシップの性質を示す方向を持つこともできます。Edges can also have a direction indicating the nature of the relationship.

グラフ データベースは、ノードとエッジのネットワークに対してクエリを効率的に実行し、エンティティ間のリレーションシップを分析できます。Graph databases can efficiently perform queries across the network of nodes and edges and analyze the relationships between entities. 次の図にグラフとして構築された組織の職員のデータベースを示します。The following diagram shows an organization's personnel database structured as a graph. エンティティは従業員や部門で、エッジは社内の直属の上下関係と従業員が勤務する部署を示しています。The entities are employees and departments, and the edges indicate reporting relationships and the departments in which employees work.

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

この構造により、"Sarah に直接または間接的に報告するすべての従業員を見つける" または "John と同じ部門で働いている人" などのクエリの実行が簡単になります。This structure makes it straightforward to perform queries such as "Find all employees who report directly or indirectly to Sarah" or "Who works in the same department as John?" 大量のエンティティとリレーションシップを含む大規模なグラフでは、きわめて複雑な分析をすばやく実行できます。For large graphs with lots of entities and relationships, you can perform very complex analyses very quickly. 多くのグラフ データベースは、リレーションシップのネットワークを効率的に走査するために使用できるクエリ言語を提供しています。Many graph databases provide a query language that you can use to traverse a network of relationships efficiently.

Azure サービスAzure services

ワークロードWorkload

  • データ項目間に多数のホップが関連しているデータ項目間の複雑なリレーションシップ。Complex relationships between data items involving many hops between related data items.
  • データ項目間のリレーションシップは動的であり、時間と共に変化する。The relationship between data items are dynamic and change over time.
  • オブジェクト間のリレーションシップは最上位の扱いになり、外部キーと走査のための結合は必要ない。Relationships between objects are first-class citizens, without requiring foreign-keys and joins to traverse.

データ型Data type

  • ノードとリレーションシップ。Nodes and relationships.
  • ノードは、テーブル行または JSON ドキュメントに似ている。Nodes are similar to table rows or JSON documents.
  • リレーションシップはノードと同様に重要であり、クエリ言語で直接公開される。Relationships are just as important as nodes, and are exposed directly in the query language.
  • 複数の電話番号の保持者など、複合オブジェクトは、走査可能なリレーションシップと組み合わせて、個々のより小さなノードに分割される傾向がある。Composite objects, such as a person with multiple phone numbers, tend to be broken into separate, smaller nodes, combined with traversable relationships

Examples

  • 組織図Organization charts
  • ソーシャル グラフSocial graphs
  • 不正行為の検出Fraud detection
  • 推奨エンジンRecommendation engines

データ分析Data analytics

データ分析ストアは、データの取り込み、保存、および分析のための大規模な並列ソリューションを提供します。Data analytics stores provide massively parallel solutions for ingesting, storing, and analyzing data. データは、スケーラビリティを最大限に高めるために複数のサーバーに分散されます。The data is distributed across multiple servers to maximize scalability. 区切りファイル (CSV)、parquetORC などの大きなデータ ファイル形式が、Data Analytics で広く使用されています。Large data file formats such as delimiter files (CSV), parquet, and ORC are widely used in data analytics. 履歴データが格納されるのは、通常、BLOB ストレージ、Azure Data Lake Storage Gen2 などのデータ ストアです。その後、これらは外部テーブルとして、Azure Synapse、Databricks、または HDInsight によってアクセスされます。Historical data is typically stored in data stores such as blob storage or Azure Data Lake Storage Gen2, which are then accessed by Azure Synapse, Databricks, or HDInsight as external tables. パフォーマンスのために parquet ファイルとして格納されているデータを使用する一般的なシナリオについては、Synapse SQL での外部テーブルの使用に関するページをご覧ください。A typical scenario using data stored as parquet files for performance, is described in the article Use external tables with Synapse SQL.

Azure サービスAzure services

ワークロードWorkload

  • データ分析Data analytics
  • 企業の BIEnterprise BI

データ型Data type

  • 複数のソースからの履歴データ。Historical data from multiple sources.
  • 通常は、"star" または "snowflake" スキーマで非正規化され、ファクト テーブルおよびディメンション テーブルで構成されている。Usually denormalized in a "star" or "snowflake" schema, consisting of fact and dimension tables.
  • 通常は、スケジュールに基づいて新しいデータと共に読み込まれる。Usually loaded with new data on a scheduled basis.
  • 多くの場合、ディメンション テーブルにはエンティティの複数の履歴バージョンが含まれ、"緩やかに変化するディメンション" として参照される。Dimension tables often include multiple historic versions of an entity, referred to as a slowly changing dimension.

Examples

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

列ファミリのデータベースColumn-family databases

列ファミリのデータベースは、データを行と列に編成します。A column-family database organizes data into rows and columns. 列ファミリのデータベースは、その最も単純な形式では、少なくとも概念的にリレーショナル データベースによく似ています。In its simplest form, a column-family database can appear very similar to a relational database, at least conceptually. 列ファミリのデータベースの真の能力は、スパース データの構築のための非正規化されたアプローチにあります。The real power of a column-family database lies in its denormalized approach to structuring sparse data.

列ファミリのデータベースは、行と列を含む表形式データを保持するものと考えることができますが、列は 列ファミリ と呼ばれるグループに分類されます。You can think of a column-family database as holding tabular data with rows and columns, but the columns are divided into groups known as column families. 各列のファミリは論理的に相互に関連する列のセットを保持し、一般にユニットとして取得または操作されます。Each column family holds a set of columns that are logically related together and are typically retrieved or manipulated as a unit. 個別にアクセスされるその他のデータは、個別の列ファミリに格納できます。Other data that is accessed separately can be stored in separate column families. 列ファミリ内では、新しい列を動的に追加することができ、行をスパースにする (つまり、行のすべての列に値を持つ必要がない) ことができます。Within a column family, new columns can be added dynamically, and rows can be sparse (that is, a row doesn't need to have a value for every column).

次の図は、IdentityContact Info の 2 つの列ファミリのある例を示しています。The following diagram shows an example with two column families, Identity and Contact Info. 単一のエンティティのデータは、各列ファミリに同じ行キーを持ちます。The data for a single entity has the same row key in each column-family. 列ファミリ内の任意の特定のオブジェクトの行を動的に変えることができるこの構造は、列ファミリ アプローチの重要な利点であり、この形式のデータ ストアが、構造化された揮発性データの格納に最適とされます。This structure, where the rows for any given object in a column family can vary dynamically, is an important benefit of the column-family approach, making this form of data store highly suited for storing structured, volatile data.

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

キー/値のストアまたはドキュメント データベースとは異なり、ほとんどの列ファミリのデータベースは、ハッシュを計算するのではなく、キー順序でデータを格納します。Unlike a key/value store or a document database, most column-family databases store data in key order, rather than by computing a hash. 多くの実装で、列ファミリ内の特定の列に対してインデックスを作成できます。Many implementations allow you to create indexes over specific columns in a column-family. インデックスを使用すると、行キーではなく、列値によってデータを取得できます。Indexes let you retrieve data by columns value, rather than row key.

一部の実装では、複数の列ファミリにまたがる行全体で原子性を提供するものもありますが、行の読み取りと書き込みの操作は通常、単一の列ファミリでアトミックです。Read and write operations for a row are usually atomic with a single column-family, although some implementations provide atomicity across the entire row, spanning multiple column-families.

Azure サービスAzure services

ワークロードWorkload

  • ほとんどの列ファミリ データベースでは、極めて高速で書き込み操作を実行する。Most column-family databases perform write operations extremely quickly.
  • 更新および削除の操作は、ほとんど行われない。Update and delete operations are rare.
  • 高いスループットと低い待機時間でのアクセスを提供するように設計されている。Designed to provide high throughput and low-latency access.
  • より大規模なレコード内にある特定のフィールド セットへの簡単なクエリ アクセスをサポートしている。Supports easy query access to a particular set of fields within a much larger record.
  • 極めて高い拡張性。Massively scalable.

データ型Data type

  • データは、キー列と 1 つまたは複数の列ファミリで構成されたテーブルに格納される。Data is stored in tables consisting of a key column and one or more column families.
  • 特定の列は、個々の行別に変更できる。Specific columns can vary by individual rows.
  • 個々のセルには get および put コマンド経由でアクセスできる。Individual cells are accessed via get and put commands
  • スキャン コマンドを使って、複数の行が返される。Multiple rows are returned using a scan command.

Examples

  • RecommendationsRecommendations
  • パーソナル化Personalization
  • センサー データSensor data
  • テレメトリTelemetry
  • メッセージングMessaging
  • ソーシャル メディア分析Social media analytics
  • Web 分析Web analytics
  • アクティビティの監視Activity monitoring
  • 天気およびその他のタイム シリーズ データWeather and other time-series data

検索エンジンのデータベースSearch Engine Databases

検索エンジンのデータベースを使用すると、アプリケーションによって、外部データ ストアで保持されている情報を検索できます。A search engine database allows applications to search for information held in external data stores. 検索エンジンのデータベースは、膨大な量のデータのインデックスを作成し、これらのインデックスへのほぼリアルタイムのアクセスを提供できます。A search engine database can index massive volumes of data and provide near real-time access to these indexes.

インデックスは、多次元にすることができ、大量のテキスト データ間でフリーテキスト検索をサポートできます。Indexes can be multi-dimensional and may support free-text searches across large volumes of text data. インデックス作成は、検索エンジンのデータベースによってトリガーされるプルモデルを使用するか、外部のアプリケーション コードによって開始されるプッシュ モデルを使用して実行できます。Indexing can be performed using a pull model, triggered by the search engine database, or using a push model, initiated by external application code.

検索は、完全でもあいまいでも可能です。Searching can be exact or fuzzy. あいまい検索では、一連の用語に一致するドキュメントを検索し、それらがどの程度一致しているかを計算します。A fuzzy search finds documents that match a set of terms and calculates how closely they match. 一部の検索エンジンは、シノニム、ジャンル拡張 (たとえば、dogspets に一致させる)、およびステミング (同じ語幹を持つ単語を照合する) に基づいて一致を返すことができる言語分析もサポートします。Some search engines also support linguistic analysis that can return matches based on synonyms, genre expansions (for example, matching dogs to pets), and stemming (matching words with the same root).

Azure サービスAzure service

ワークロードWorkload

  • 複数のソースおよびサービスからのデータ インデックス。Data indexes from multiple sources and services.
  • クエリはアドホックであり、複雑になる場合がある。Queries are ad-hoc and can be complex.
  • フルテキスト検索が必要になる。Full text search is required.
  • アドホックのセルフ サービス クエリが必要になる。Ad hoc self-service query is required.

データ型Data type

  • 半構造化または非構造化テキストSemi-structured or unstructured text
  • 構造化データへの参照を備えたテキストText with reference to structured data

Examples

  • 製品カタログProduct catalogs
  • サイトの検索Site search
  • ログ記録Logging

タイム シリーズ データベースTime series databases

時系列データは、時間別に整理された値のセットです。Time series data is a set of values organized by time. 時系列データベースにより、通常、多数のソースから大量のデータがリアルタイムで収集されます。Time series databases typically collect large amounts of data in real time from a large number of sources. 更新はまれであり、削除は多くの場合に一括操作として行われます。Updates are rare, and deletes are often done as bulk operations. 時系列データベースに書き込まれるレコードは通常小さいですが、多くの場合にレコード数が多く、合計データ サイズが急速に増大する可能性があります。Although the records written to a time-series database are generally small, there are often a large number of records, and total data size can grow rapidly.

Azure サービスAzure service

ワークロードWorkload

  • レコードは通常、時系列で追加される。Records are generally appended sequentially in time order.
  • 操作の大部分 (95 99%) は書き込みである。An overwhelming proportion of operations (95-99%) are writes.
  • 更新はとんど行われない。Updates are rare.
  • 削除は一括で、連続したブロックまたはレコードに対して行われる。Deletes occur in bulk, and are made to contiguous blocks or records.
  • データは、時系列の昇順または降順のどちらかで (多くの場合、並行で) 読み込まれる。Data is read sequentially in either ascending or descending time order, often in parallel.

データ型Data type

  • 主キーおよび並べ替えのメカニズムとして使用されているタイムスタンプ。A timestamp is used as the primary key and sorting mechanism.
  • タグによって定義されるのは、種類、配信元など、エントリに関する追加情報です。Tags may define additional information about the type, origin, and other information about the entry.

Examples

  • 監視およびイベント テレメトリ。Monitoring and event telemetry.
  • センサーまたはその他の IoT データ。Sensor or other IoT data.

オブジェクト ストレージObject storage

オブジェクト ストレージは、大規模なバイナリ オブジェクト (イメージ、ファイル、ビデオおよびオーディオ ストリーム、大規模なアプリケーション データ オブジェクトおよびドキュメント、仮想マシン ディスク イメージ) の格納と取得に最適です。Object storage is optimized for storing and retrieving large binary objects (images, files, video and audio streams, large application data objects and documents, virtual machine disk images). このモデルでは、区切りファイル (CSV)、parquetORC などの大規模なデータ ファイルも一般的に使用されます。Large data files are also popularly used in this model, for example, delimiter file (CSV), parquet, and ORC. オブジェクト ストアは大量の非構造化データを管理できます。Object stores can manage extremely large amounts of unstructured data.

Azure サービスAzure service

ワークロードWorkload

  • キーによって識別される。Identified by key.
  • コンテンツは通常、区切り記号、イメージ、ビデオ ファイルなどのアセットである。Content is typically an asset such as a delimiter, image, or video file.
  • コンテンツは持続性があり、任意のアプリケーション層の外部に存在する必要がある。Content must be durable and external to any application tier.

データ型Data type

  • データ サイズが大きい。Data size is large.
  • 値は非透過的である。Value is opaque.

Examples

  • イメージ、ビデオ、office ドキュメント、PDFImages, videos, office documents, PDFs
  • 静的 HTML、JSON、CSSStatic HTML, JSON, CSS
  • ログおよび監査ファイルLog and audit files
  • データベースのバックアップDatabase backups

共有ファイルShared files

場合によっては、単純なフラット ファイルを使用することが、情報の格納と取得の最も効率的な手段である可能性があります。Sometimes, using simple flat files can be the most effective means of storing and retrieving information. ファイル共有を使用すると、ネットワーク経由でファイルにアクセスできます。Using file shares enables files to be accessed across a network. 適切なセキュリティおよび同時実行アクセス制御メカニズムがあれば、この方法でデータを共有することにより、分散型サービスが可能になり、単純な読み取りおよび書き込み要求などの基本的な低レベルの操作のための高度にスケーラブルなデータ アクセスを提供します。Given appropriate security and concurrent access control mechanisms, sharing data in this way can enable distributed services to provide highly scalable data access for performing basic, low-level operations such as simple read and write requests.

Azure サービスAzure service

ワークロードWorkload

  • ファイル システムと対話する既存アプリからの移行。Migration from existing apps that interact with the file system.
  • SMB インターフェイスが必要である。Requires SMB interface.

データ型Data type

  • フォルダーの階層セット内のファイル。Files in a hierarchical set of folders.
  • 標準の I/O ライブラリを使ってアクセスできる。Accessible with standard I/O libraries.

Examples

  • レガシ ファイルLegacy files
  • 多数の VM またはアプリ インスタンスからアクセス可能な共有コンテンツShared content accessible among a number of VMs or app instances

各種データ ストレージ モデルを理解したうえで、次の手順でワークロードとアプリケーションを評価し、特定のニーズを満たすデータ ストアを決定します。Aided with this understanding of different data storage models, the next step is to evaluate your workload and application, and decide which data store will meet your specific needs. このプロセスについて不明な点がある場合は、データ ストレージ デシジョン ツリーを使用してください。Use the data storage decision tree to help with this process.