エクスポート (0) 印刷
すべて展開

Windows Azure テーブル ストレージと Windows Azure SQL データベースの比較

更新日: 2014年1月

執筆者: Valery Mizonov、Seth Manheim

校閲者: Brad Calder、Jai Haridas、Paolo Salvatori、Silvano Coriani、Prem Mehra、Rick Negrin、Stuart Ozer、Michael Thomassy、Ewan Fairweather

このトピックでは、 でサポートされる テーブル ストレージと、以前は "SQL Azure" として知られていた Microsoft Azure SQL データベースの 2 種類の構造化ストレージを比較します。この記事の目標は、これらの類似点と相違点を理解できるように、それぞれのテクノロジの比較を提供することです。この分析は、特定の要件を満たす最適なテクノロジはどちらかについて十分な情報を得たうえで決定を行うのに役立ちます。

データ ストレージと永続性のオプションを検討する場合、 では、Microsoft Azure SQL データベースと テーブル ストレージの 2 つのクラウドベース テクノロジから選ぶことができます。

Microsoft Azure SQL データベース は、SQL Server の主要な機能をクラウドに拡張するリレーショナル データベース サービスです。Azure SQL データベースを使用すると、リレーショナル データベース ソリューションのプロビジョニングと配置をクラウドで行うことができます。このメリットには、管理されたインフラストラクチャ、高可用性、スケーラビリティ、使い慣れた開発モデル、データ アクセス フレームワークおよびツールが含まれ、従来の SQL Server 環境に見られるものと似ています。また、Azure SQL データベースでは、移行、エクスポート、およびオンプレミス SQL Server データベースの Windows Azure SQL データベースとの実行中の同期 (SQL データ同期を使用) を可能にする機能も提供されます。

テーブル ストレージは、ISO 27001 認定を受けたフォールト トレラントな NoSQL キー値ストアです。 テーブル ストレージは、大量の非リレーショナル データを格納する必要があり、そのデータのために追加の構造を必要とするアプリケーションにとって役立ちます。テーブルでは、単純なデータアクセス パターンを使用するアプリケーションにおいて、スキーマ化されていないデータに対するキーベースのアクセスを低コストで提供します。 テーブル ストレージはスキーマを使用せずに構造化されたデータを格納しますが、データ間のリレーションシップを表す方法は用意されていません。

いくつかの重要な違いがあるにもかかわらず、Microsoft Azure SQL データベースと テーブル ストレージはともに月単位で 99.9% の SLA が提供される、可用性に優れたマネージ サービスです。

Azure SQL データベースと同様に、 テーブル ストレージも構造化されたデータを格納します。Azure SQL データベースと テーブル ストレージの主な違いは、Azure SQL データベースは SQL Server エンジンに基づくリレーショナル データベース管理システムであり、標準のリレーションの原理と手法に基づいているということです。そのため、SQL データベースでは、Transact-SQL クエリ、ACID トランザクション、およびストアド プロシージャを使用してサーバー側で実行されるリレーショナル データ管理機能が使用できます。

テーブル ストレージは柔軟なキーと値のストアであり、これによってクラウド アプリケーションを簡単に作成することができ、特定の一連のスキーマにアプリケーション データ モデルをロック ダウンする必要がありません。Windows Azure テーブル ストレージはリレーショナル データ ストアではなく、Azure SQL データベースと同じリレーショナル データ管理機能 (結合やストアド プロシージャなど) は使用できません。 テーブル ストレージはサーバー側クエリのサポートに制限がありますが、トランザクション機能は提供されます。また、 テーブル ストレージでは、同じテーブル内の異なる行に異なる構造を含めることができます。 テーブルのこのスキーマのない性質により、単純なリレーショナル データを効率的に格納および取得することもできます。

豊富なリレーショナル機能を必要としない大規模なデータセットをアプリケーションで格納および取得する場合、 テーブル ストレージの方が適している可能性があります。スキーマ化されたデータセットについてのデータ処理がアプリケーションで必要となり、実質的にリレーショナルである場合は、Azure SQL データベースの方がニーズに合う可能性があります。Azure SQL データベースと テーブル ストレージのどちらを使用するか判断するには、他の要因もいくつか考慮する必要があります。それらの考慮事項の一部については、次のセクションに示します。

特定のソリューションの目的に合うデータ ストレージ テクノロジを判断する場合、ソリューション設計者および開発者は次の推奨事項を検討する必要があります。

ソリューション設計者または開発者として、次の場合に テーブル ストレージの使用を検討してください

  • アプリケーションで、コストを抑えつつ非常に大きい (テラバイト単位で表される) データ ボリュームを格納する必要がある場合。

  • アプリケーションで大規模なデータセットを格納および取得し、サーバー側の結合、セカンダリ インデックス、または複雑なサーバー側ロジックを要求する複雑なリレーションシップがない場合。

  • 一様でないオブジェクト、デザイン時に既知でない可能性がある構造を格納する柔軟なデータ スキーマをアプリケーションが必要とする場合。

  • ビジネス上、特定の準拠のニーズに合わせるために地理的な場所をまたぐ災害復旧機能が必要になる場合。 テーブルは、同じ大陸の何百キロも離れた 2 つのデータ センター間で地理分散されます。このレプリケーションにより、大きな災害時のデータの持続性が向上します。

  • シャーディングまたはパーティション分割のロジックを実行する必要なく 150 GB を超えるデータを格納する必要がある場合。

  • データセットを手動でシャーディングする必要なく高レベルのスケーリングを実現する必要がある場合。

ソリューション設計者または開発者として、次の場合に Microsoft Azure SQL データベースの使用を検討してください

  • スキーマ化され、高度に構造化されたリレーションシップを含むデータセットについてのデータ処理がアプリケーションで必要な場合。

  • データが実質的にリレーショナルであり、データを一意にするルール、参照制約、主キーまたは外部キーを使用して整合性を確保するためにリレーショナル データ プログラミング モデルの主な原則が必要になる場合。

  • データ ボリュームで、1 単位の同じ場所に配置されたデータセット (多くの場合 1 つのデータベースになります) が 150 GB を超えない場合。ただし、複数のセットにデータをパーティション分割すると、この制限を超えることができます。この制限は今後変更される可能性があります。

  • 既存のデータ処理を中心とするアプリケーションで既に SQL Server を使用しており、既存のデータ アクセス フレームワークを使用して構造化データにクラウドベースでアクセスする必要がある場合。同時に、アプリケーションでオンプレミスと 間のシームレスな移植性が必要になる場合。

  • アプリケーションで T-SQL ストアド プロシージャを利用してデータ層内の計算を実行する予定があり、そのためにアプリケーションとデータ ストレージ間のラウンド トリップを最小限に抑える場合。

  • アプリケーションで、空間データ、豊富なデータ型、および結合、集計、複雑な述語を含む一貫したクエリ セマンティクスを使用する高度なデータ アクセス パターンのサポートが必要な場合。

  • すぐに使用できるレポート ツールを使用したデータ モデルについての視覚化およびビジネス インテリジェンス (BI) レポート機能がアプリケーションで必要な場合。

noteメモ
多くの アプリケーションは両方のテクノロジを使用できます。このため、これらのオプションを組み合わせての使用を検討することをお勧めします。

以下のセクションの表では機能を論理的にグループ化しており、 テーブル ストレージと Microsoft Azure SQL データベースの両方で使用できる機能を一見して比較することができます。

ここでは、 テーブル ストレージと Azure SQL データベースで提供される基本的なストレージ機能の一部を比較します。

 

比較条件 テーブル ストレージ Azure SQL データベース

データのリレーションシップ

不可

テーブル ストレージにはデータ間のリレーションシップを表す方法が用意されていません。テーブルのスキーマのない性質を使用して必須の形式でデータを構成すると、単純なリレーションシップを取得できます。

Azure SQL データベースでは、SQL Server と同様に、外部キーを使用してさまざまなテーブルに格納されているデータ間のリレーションシップを定義することができます。

サーバー側の処理

不可

insertupdatedeleteselect などの基本操作はサポートされますが、結合、外部キー、ストアド プロシージャ、トリガー、またはストレージ エンジン側の処理はサポートされません。

ストアド プロシージャ、ビュー、複数のインデックス、結合、集計などの標準的な SQL Server の機能が提供されます。

トランザクションのサポート

限定的

同じテーブルと同じパーティションでのエンティティのトランザクションがサポートされます。トランザクションでは最大 100 個の操作がサポートされます。オプティミスティック同時実行がサポートされます。詳細については、TechNet の「「エンティティ グループ トランザクションの実行」。

同じデータベース内での一般的な ACID トランザクションがサポートされます。データベース間のトランザクションはサポートされません。Azure SQL データベースでは、オプティミスティック同時実行もサポートされます。

地理分散

既定では、テーブルはその他の地区にレプリケートされます。このレプリケーションにより、高度な災害復旧機能が提供されます。

不可

このドキュメントの作成時点では、Azure SQL データベース インスタンスはその他の地区にレプリケートされません。この動作は、今後変更される可能性があります。

テーブル スキーマ

緩和されている

各エンティティ (行) にさまざまなプロパティを含めることができます。たとえば、同じテーブルにおいて、ある行に注文情報を格納し、別の行に顧客情報を格納できます。

管理されている

テーブル全体の固定スキーマは一度定義しますが、いつでも変更できます。すべての行はスキーマの規則に従う必要があります。柔軟性が必要な場合は、XML 型またはスパース列を使用することを検討してください。

オンプレミスで使用される既存のデータ ストアとの類似性

不可

現在オンプレミスの選択肢がないクラウドベースのストレージです。

一部の制限事項が SQL Server と同じです。詳細については、TechNet の「「一般的なガイドラインと制限事項」。

スケールアウト

自動

PartitionKey プロパティに基づいてパーティション分割されます。1 つのテーブルが異なるストレージ デバイスの異なるパーティションに格納されることもあります。この構造により、クライアントは並行してデータにアクセスすることができます。

手動

SQL フェデレーションやカスタムのシャーディング アプローチを使用して、管理されたデータベース インスタンスのグループ全体でシャーディングされます。

データ型

単純

サポートされるデータ型の詳細情報については、「追加情報」セクションの表を参照してください。

単純、複雑、およびユーザー定義

Azure SQL データベースでは、カスタムのユーザー定義型など、データ型の豊富なセットがサポートされています。

  • のテーブルを作成するときは、列を定義する必要はありません。テーブル自体は構成されず、デザイン時のスキーマはありません。列名はテーブルに格納されているエンティティ (行) の一部であり、1 つのテーブル内でエンティティごとに異なるようにすることができます。 のテーブルには、同じプロパティ名でプロパティ値の種類が異なる 2 つのエンティティを含めることもできます。ただし、プロパティ名は 1 つのエンティティ内で一意である必要があります。

  • テーブル ストレージでは、クエリの結合および集計、複数のテーブル間で変更を調整するトランザクションなどのリレーショナル機能がサポートされません。同じパーティション キーを持つ テーブルに格納されているエンティティは、ストアで同時に機能します。エンティティ グループ トランザクションを使用すると、これらのエンティティを効率的に取得し、1 つの要求でこれらを変更することができます。

  • エンティティ グループ トランザクションを使用する場合に注意する必要がある制限事項がいくつかあります。これらの制限事項には 4 MB の最大バッチ サイズが含まれており、バッチ内のすべてのエンティティが同じパーティション キー値を共有する必要があります。詳細については、TechNet の「この記事

  • テーブル ストレージの型は 1 つのクラスター化インデックスを提供し、結果は PartitionKey および RowKey で常に昇順に並べ替えられます。PartitionKey および RowKey の値により、テーブルの行は一意に識別されます。同じ PartitionKeyRowKey を持つ 2 つの行を作成しようとすると、例外が生成されます。

  • この記事では、Azure SQL データベースとオンプレミス SQL Server の選択のためのデシジョン ツリーを提供しています。これらの判断基準は Azure SQL データベースと テーブル ストレージにも適用できます。

  • 両方のテクノロジに適用されるスループットの条件は、多数の変数を含む複雑な式です。これらの要因には、クエリの種類とその複雑さ、データ アクセス パターン、結果セットのサイズ、ストレージ インフラストラクチャに対する近接、およびネットワーク待機時間が含まれます。関連するインジケーターをより適切に高い信頼性で測定するには、アプリケーションの特定のクラスの個々の詳細を考慮して、常に独自のパフォーマンス テストを実行することをお勧めします。Windows Azure テーブルのベスト プラクティスの詳細情報については、このブログ投稿を参照してください。

  • 次の表は、 テーブルのプロパティ値でサポートされるデータ型を示しています。Azure SQL データベースでサポートされるデータ型の一覧については、「データ型 (Azure SQL データベース)」を参照してください。

     

    プロパティの型 詳細

    Binary

    最大 64 KB のバイトの配列。

    Bool

    ブール値。

    DateTime

    UTC 時刻として表される 64 ビット値。サポートされる値の範囲は 1/1/1601 ~ 12/31/9999 です。

    Double

    64 ビットの浮動小数点値。

    GUID

    128 ビットのグローバル一意識別子。

    Int

    32 ビットの整数。

    Int64

    64 ビットの整数。

    String

    UTF 16 でエンコードされた値。文字列値のサイズは、最大 64 KB です。

ここでは、 テーブル ストレージと Azure SQL データベースで提供される高度な機能を比較します。

 

比較条件 テーブル ストレージ Azure SQL データベース

オンプレミス アプリケーションまたは非 プラットフォームでホストされているアプリケーションからのアクセス

一貫性モデル

強力

強力

Windows Communication Foundation (WCF) Data Services クライアントのサポート

REST クライアントのサポート

追加設定なしで REST ベースのアクセスがサポートされます。

SQL データベースの上に OData のレイヤーを追加することにより、REST ベースのアクセスがサポートされます。

ファイアウォールによる保護 (制限された IP 範囲のアクセス)

不可

ポータルから、またはコマンドライン ツールを使用して構成可能な Windows Azure ファイアウォールを使用します。

トランザクションの調整動作

詳細については、TechNet の「 このブログ投稿

詳細については、TechNet の「 この記事

フォールト トレランス

高度なフォールト トレランスを提供するため、格納されるデータはその地区内で 3 回レプリケートされ、400 マイル (644 km) 以上離れた別の地区でさらに 3 回レプリケートされます。

Azure SQL データベース インスタンスの 3 つのコピーが選択したデータ センター内で保持されます。

ログ記録とメトリック

詳細については、TechNet の「 このブログ投稿

不可

トランザクション ログ

不可

トランザクション ログのサイズは最大 10 GB で、1 つのトランザクションに 1 GB の制限があります。

  • 組み込みのファイアウォール機能を使用すると、ネットワーク レベルで Azure SQL データベース インスタンスへのアクセスを制限できます。また、 ポータルを使用してファイアウォールのアクセス ルールを構成できます。一方、 ストレージ アカウントのエンドポイントに HTTP/HTTPS を介して接続できるクライアントは テーブルへのアクセス権を取得できます。

  • テーブル ストレージでは、テーブルの 1 つのエンティティのすべての insert/update/delete トランザクションとエンティティ グループ トランザクションに ACID を備えたトランザクションを保証します。サービスに対する個々のクエリ要求にはスナップショット分離が提供されます。クエリでは、クエリの開始時からトランザクションを通じてパーティションの一貫性のあるビューが維持されます。アプリケーション開発者は、複数のテーブル間で一貫性を維持する必要があります。

  • テーブルはログ記録をサポートしているため、サービスに対して実行されたすべての要求を確認することができます。ログ記録では、サービスに対する要求の集計されたメトリックも提供されます。

  • Microsoft Azure SQL データベースでは現在、ログ記録とメトリックが提供されていませんが、クエリ パフォーマンスの問題の診断、データベース接続の監視、アクティブなトランザクションの表示、およびクエリ プランの検査を実行するための動的管理ビュー (DMV) のサブセットが用意されています。

  • Microsoft Azure SQL データベースは SQL Server エンジンの上に構築されているため、TempDB やトランザクション ログなどの一部の概念は引き続き関連します。トランザクション ログが予期せず拡大することを防ぐため、Azure SQL データベースでは、ログ サイズに 10 GB の制限が適用されます。これらのトランザクション ログは Azure SQL データベース インフラストラクチャによって管理され、ユーザーが直接アクセスすることはできません。 テーブル ストレージにトランザクション ログに相当する機能はありません。 テーブル ストレージでサポートされるログ記録およびメトリック機能は、変更される実際のデータではなくサービスに対する要求が追跡されるため、トランザクション ログとは異なります。

  • マルチテナント環境でリソースの過剰な使用を防ぐため、 テーブル ストレージと Azure SQL データベースではともに、システムのしきい値を制御するメカニズムが使用されます。このメカニズムは調整と呼ばれ、その動作は 2 つのサービスで異なります。たとえば、Azure SQL データベースでは、ソフト調整ハード調整の 2 つの調整方法が使用されます。これらの調整メカニズムの詳細については、この記事で説明しています。

ここでは、容量および適用する可能性があるクォータの観点から テーブル ストレージと Azure SQL データベースを比較します。ここに示したすべての機能およびクォータは今後変更される可能性があります。

 

比較条件 テーブル ストレージ Azure SQL データベース

[行の最大サイズ]

1 MB

プロパティ数は PartitionKeyRowKeyTimestamp の 3 つの必須プロパティを含め 255 個以内。

2 GB

最大 1024 列まで含めることができます (スパース列を使用する場合は 30,000 列)。varchar(max)varbinary(max)xmltext、または image の列を使用すると、最大 2 GB の行外ストレージが提供されます。

最大データ サイズ

テーブルあたり 200 TB

2012 年 6 月 8 日以降に作成されたストレージ アカウントの場合、1 つのストレージ アカウント (テーブル、BLOB、およびキューを含む) に最大 200 TB の BLOB、キュー、およびテーブル データを格納できます。その日より前に作成されたストレージ アカウントの場合、合計容量は 100 TB です。したがって、 テーブルの最大サイズは 200 TB です。

データベースあたり 150 GB

データベースの最大許容サイズは今後増加する場合がありますが、より大きなデータセットを格納するには SQL フェデレーション (またはカスタム シャーディング) の使用を検討してください。

クエリごとに取得される最大行数

1,000

1 つの要求への応答には 1,000 以内の行 (エンティティ) が返されます。クエリにこの量よりも多い結果がある場合は、クエリが追加の要求を続けることができるように継続トークンが返されます。

無制限

正しくチューニングしない場合、接続とクエリのタイムアウトによってフェッチされる行数が制限される場合があります。

  • テーブル ストレージでは、クエリに追加の結果があることを示すために応答ヘッダーに継続トークンを使用します。継続トークンによってパラメーター化された別の要求を発行すると、これらの結果を取得できます。このシナリオにより、1,000 個のエンティティの制限を超える項目を取得することができます。スナップショットの一貫性は要求ごとに維持されますが、クエリの継続トークン要求間では維持されません。

  • テーブルの行 (エンティティ) のすべてのフィールド (プロパティ) の合計サイズは 1 MB を超えることはできません。この制限には、プロパティ名のサイズ、プロパティ値または型が含まれ、2 つの必須のキーのプロパティ (PartitionKey および RowKey) が含まれます。

  • Azure SQL データベースは現在、最大 5 GB のデータベース (Web Edition の場合)、または最大 150 GB のデータベース (Business Edition の場合) をサポートしています。データベースのサイズを指定されたしきい値内に維持するため、開発者はデータベースを監視する必要があります。Azure SQL データベースの最大サイズは管理操作であらかじめ構成されており、格納されるデータ ボリュームが増えても自動的には加算されません。詳細については、TechNet の「「ALTER DATABASE (Azure SQL データベース)」(Azure SQL データベース ドキュメント)。

  • 標準の Azure SQL データベース テーブルの列数は 1024 に制限されます (オンプレミス SQL Server と同様)。スパース列を使用すると、テーブルには最大 30,000 列まで含めることができ、このうち最大 1023 列を非スパースにすることができます。ただし、少なくとも 28,976 列はスパース列である必要があります。1 つの非スパース列は、列の合計数が 1024 を超える場合に必須となる列セットに使用されます。

ここでは、 テーブル ストレージと Azure SQL データベースで提供される管理機能を比較します。

 

比較条件 テーブル ストレージ Azure SQL データベース

管理プロトコルおよびツール

HTTP/HTTPS 経由の REST

Windows Azure ストレージ エクスプローラーを使用するか、Cloud Storage Studio などの別のサードパーティ ツールを使用できます。

ODBC/JDBC

HTTP/HTTPS 経由の REST

Management Portal または SQL Server Management Studio を使用して Azure SQL データベース インスタンスを管理できます。

データ アクセス

OData プロトコル インターフェイス

HTTP(S) REST API、または Windows Azure SDK に含まれている WCF Data Services の .NET クライアント ライブラリを使用してデータにアクセスできます。

ODBC/JDBC

SQL Server と通信する ADO.NET、ODBC などの既存のテクノロジを使用して記述されたアプリケーションを使用すると、最小限のコード変更で Azure SQL データベース インスタンスにアクセスできます。

Java API のサポート

Node.js API のサポート

PHP API のサポート

LINQ のサポート

Python のサポート

不可

オフラインの開発エクスペリエンス

SDK に含まれるローカル ストレージ エミュレーターによって提供されます。

不可

SQL Express または SQL Server の他のエディションは別の製品であり、Microsoft Azure SQL データベース環境の完全なシミュレーションは提供されません。

  • Azure SQL データベースをローカル SQL Server インストールでシミュレートすることはできますが、その場合、調整、その他の適用される制限事項など、クラウドベースのサービスにのみ適用される動作をレプリケートすることはできません。

  • Microsoft Azure SQL データベースには、Web ベースの対話形式のクエリ環境が用意されています。Azure SQL データベースには、SSMS、ODBC をサポートするサード パーティの RDBMS クエリ ツールなどのアドホック クライアント コンソール ツールからもアクセスできます。

  • T-SQL の機能は、SQL Server と Azure SQL データベースで異なります。一部の機能は制限されてサポートされておらず、一部には重要な違いがあります (データベースとフェデレーションの作成など)。

ここでは、 テーブル ストレージと Azure SQL データベースでサポートされる認証および承認機能について説明します。

 

比較条件 テーブル ストレージ Azure SQL データベース

[認証]

対称キー

Shared Access Signature

512 ビットの HMAC キーを使用してユーザーを認証します。

SQL 認証

標準の SQL 認証を使用してユーザーを認証します。

ロールベースのアクセス

不可

標準の SQL データベースとアプリケーション ロールがサポートされます。

Windows Azure Active Directory (以前の ACS) のサポート

不可

不可

ID プロバイダー フェデレーション

不可

不可

  • Azure SQL データベースでサポートされるロールベースのアクセスでは、読み取り専用、書き込み専用、および読み取り/書き込みのモードを構成する十分な柔軟性がサポートされます。この機能により、個々のアプリケーションの必要に応じて豊富なデータ アクセス オプションのセットを提供できます。

  • フェデレーション、証明書ベース、または Active Directory の認証は現在どちらのテクノロジでもサポートされていないため、セキュリティ資格情報 (たとえば、HMAC キーまたは SQL ユーザー名とパスワード) は暗号化などの適切な保護手段でカバーされるようにする必要があります。この保護は、これらの資格情報へのアクセスが IT の準拠の対象になる場合に特に重要です。

  • テーブル ストレージは、テーブル SAS (Shared Access Signature) と呼ばれる署名された URL ベースのアクセスを提供します。SAS により、ストレージ アカウントのシークレット キーを明らかにすることなくクライアントに時間ベースのアクセスを許可することができます。詳細については、このブログ投稿を参照してください。

ここでは、 テーブル ストレージと Azure SQL データベースをコストの観点から比較します。ここに示したすべてのコストは、今後変更される可能性があります。

 

比較条件 テーブル ストレージ Azure SQL データベース

ストレージ コスト

$0.125

1 日の平均に基づく 1 か月あたりに格納された 1 GB あたりのコスト。

料金の詳細については、「価格の概要」を参照してください。

データベースのサイズに基づき段階分けした料率の課金。

料金の詳細については、「価格の概要」を参照してください。

トランザクション コスト

$0.01

ストレージ トランザクション 100,000 あたりのコスト。

$0.00

Azure SQL データベースはトランザクション数に対して課金しません。

課金可能な操作

すべて

ストレージ コストに加え、テーブルに対するトランザクションのボリュームに基づいてトランザクション コストが計算されます。

なし

コストはトランザクションのボリュームに依存せず、データベース サイズにのみ依存します。

Egress コスト

$0.12 - $0.19

1 GB あたり、累進的な地域固有のスケールに基づく

$0.12 - $0.19

1 GB あたり、累進的な地域固有のスケールに基づく

  • Egress コストは、インターネットを介して データセンターから転送されたデータの合計に基づきます。この量は、アプリケーションがクエリを実行し、それぞれのデータ サービスから結果を受け取るときに、指定された請求期間で計算されます。

  • Azure SQL データベースとは異なり、 テーブル ストレージではトランザクション単位のコストが適用されます。この課金モデルは、ストレージ トランザクションの頻度をコスト関連の考慮事項に含める必要があることを意味します。

テーブル ストレージと Microsoft Azure SQL データベースを使用する状況についての判断はさまざまな要因に依存します。これらの要因は、アプリケーション、アーキテクチャ、ワークロード、およびデータ アクセス パターンの個々のニーズに大きく依存する場合があります。ここでは、主ないくつかの考慮事項についてまとめます。

テーブル ストレージでは、大規模に拡張可能なテーブルに大量のデータをクラウドで格納することができます。これらのテーブルには、テラバイト単位のデータと十億単位のエンティティを格納できます。このレベルのスケーラビリティを実現するため、 テーブル ストレージはスケールアウト モデルを使用してエンティティを複数のストレージ ノードに分散しています。強力な一貫性を備えてこの非常に大きなスケールをサポートするために、NoSQL データ モデルを使用しています。コストを抑えて大量の非リレーショナルまたは単純なデータ モデルの永続性を必要とする場合は、 テーブル ストレージの使用を検討してください。

Microsoft Azure SQL データベースは、クラウド プラットフォームに拡張された SQL Server データベース エンジンとして考えることができます。使い慣れた SQL Server の開発エクスペリエンス、豊富なクエリ セマンティクス、分離レベルが異なる ACID トランザクションのサポート、および複雑なデータ処理機能が提供されます。データが高度にリレーショナルであり、これらの機能と組み合わせられたリレーショナル データ管理を必要とする場合は、Azure SQL データベースが適している可能性があります。

特定のテクノロジを使用する状況についての判断は必ずしも 2 択ではなく、いつも 1 つのテクノロジを優先して決定できるものではありません。2 つのテクノロジのバランスの取れた組み合わせがソリューションの要件に最も適しているかどうかを評価し、解決する特定の問題に対応するためにそれぞれの領域に両方を適用することを検討することができます。

2 つのテクノロジをより深く理解することにより、 で使用するデータ ストレージ テクノロジとその状況について、より多くの十分な情報を得たうえでの決定を行うことができます。

関連項目

表示:
© 2014 Microsoft