azure - どのような場合に SQL Azure を使用し、いつテーブル ストレージを使用する必要がありますか?

Question

どのような場合に SQL Azure を使用し、いつテーブル ストレージを使用する必要がありますか? 私が考えていたのは、テーブル ストレージをトランザクション処理シナリオ (デビット クレジット アカウントのようなシナリオなど) に使用し、レポートなどのトランザクション目的でデータが使用されない場合は Sql Azure を使用することです。どう思いますか？

Answer 1

これは素晴らしい質問であり、ソリューション アーキテクトが Azure 向けに設計する際に下さなければならない決定の 1 つです。

考慮すべき複数の側面があります。マイナス面として、SQL Azure はギガバイトのストレージに対して比較的高価であり、スケーリングがあまりうまくいかず、データベースあたり 150 ギグに制限されています。ただし、これは非常に重要です。SQL に対するトランザクション料金はありません。 Azure と開発者は、それに対してコーディングする方法を既に知っています。

ATS はまったく別の動物です。メガ スケーラビリティが可能で、保存するのは非常に安価ですが、頻繁にアクセスするにはコストがかかります。また、ノードを操作するには、かなりの量の CPU パワーが必要です。基本的に、すべてのリレーショナル アクティビティの委任がコンピューティング ノードに引き渡されるため、コンピューティング ノードが強制的にミニ db サーバーになります。

したがって、私の意見では、頻繁にアクセスされ、大きなスケーラビリティを必要とせず、サイズがそれほど大きくないデータは、SQL Azure に向けるべきであり、それ以外の場合は Azure Table Services に向けるべきです。

具体的な例として、金融取引からの取引データは ATS に最適な場所ですが、メタ情報 (アカウント プロファイル、名前、住所など) は SQL Azure に最適です。

Answer 2

Igor と Mark は素晴らしい回答をしてくれました。もう少しだけ追加させてください...

SQL データベース (旧称 SQL Azure) では、最大 500 GB のデータベースを使用できるようになりました。それを超えるには、データを分割する必要があります。 注: 当初、SQL フェデレーションを使用したシャードを提案しましたが、この機能は廃止されました。

ATS は、パーティション レベルでのトランザクション (エンティティ グループ トランザクション) を提供します。詳細については、この MSDN の記事を参照してください。これは SQL Azure トランザクションほど堅牢ではありませんが、1 つのトランザクションでバッチ操作を行うことができます。

編集この質問が尋ねられてから1年以上経ちました（そして答えられました）。比較ポイントの 1 つは価格設定でした。SQL Azure は依然として ATS よりも高価ですが、SQL Azure のコストはこの 1 年間で大幅に低下しました。データベースの価格は段階的になり、100 MB で 4.99 ドルから 150 GB で 225 ドルまで上昇します (昨年の 1 GB あたり 9.99 ドルから大幅に値下げされました。価格の詳細はこちら.

EDIT 2014年8月もう1年後、別の更新。Web/ビジネス層は引き続き存在しますが、廃止されます (SQL フェデレーションは使用できなくなります)。新しい Basic、Standard、および Premium レベルが利用可能になりました (詳細については、こちらを参照してください)。

Answer 3

これらの回答の一部は完全ではないように思われるので、2 セント追加します。

Azure テーブルの良い点:

• 長所は、小さなデータをたくさん保存できることです。Azure テーブルは Azure Blob に基づいていますが、より小さなデータを対象としています
• Azure SQL Server よりもはるかに安価
• パーティション キーと行キーの両方がわかっている場合、データ アクセスは非常に高速です。
• Entity transactions2 つの異なる「スキーマ」を同じパーティション キーに配置すると、可能になります。
• 行の合計サイズが 980K 未満の場合 (SQL 行)
• 各プロパティが 64K 未満 (SQL 列)
• 貧乏人の SQL のように振る舞うことができます。

Azure テーブルの悪い点:

• SQL は弱点です。大規模な SQL テーブルでこれを使用することを期待しないでください。パフォーマンスの問題が発生します。
• 限られた SQL が利用可能です。Linq で実装する以外に、どのようなタイプの結合も期待しないでください。
• Azure Table SQL は、無限の量のデータを格納する能力と同様にスケーリングしません
• WHERE 句でパーティション キーと行キーの両方を指定しない場合は常に、低速のテーブル スキャンが発生することが予想されます。
• 行を追加すると、テーブル スキャンのパフォーマンスが低下することが予想されます
• 行を追加すると、Azure テーブル クエリが高速になるとは思わないでください
• 要するに、Azure テーブルを使用して SQL のように振る舞う場合は、大量のデータを追加しないでください。大量のデータ (ギガバイト) がある場合は、それに対して高パフォーマンスの SQL クエリを取得することを計画しないでください。これらの通常の SQL 機能が必要ない場合は、お金を節約できます。

Answer 4

トランザクションに関しては、その逆です。SQL Azure はトランザクションをサポートしています。テーブルストレージはそうではありません。

SQL Azure は基本的に Windows Azure 内で実行される SQL Server であるため、SQL Server を使用する既存のアプリケーションがある場合、SQL Azure は適切な移行パスを提供します。ただし、SQL Azure で使用できるデータベースのサイズには制限があるため (現在は 150 GB)、スケーリングできる量には制限があります。

一方、テーブル ストレージは非常にスケーラブルですが、別の考え方が必要です。リレーショナル データベースではありません。たとえば、この記事を参照してください: http://msdn.microsoft.com/en-us/magazine/ff796231.aspx

Answer 5

本当の答えは、「Azure Table Storage を使用しないように全力を尽くす」ことです。リレーショナル DB から SQL を使用しない DB に移行するときはいつでも、もちろん、ストレージ アーキテクチャについての考え方を変える必要があります。しかし、ATS の問題は、単に「考え方を変える」必要があるだけではありません。他の人が指摘しているように、これは単なる「No-SQL」データ ストアではなく、No-SQL ストアの特に発育不全で障害があり、機能が非常に少ないインスタンスです。ATS について「別の考え方」をする必要があるという問題ではありません。それは、ATS が仕事をするために必要なツール (他の SQL を使用しないデータ ストアが提供するツール) を提供しないという問題です。

ATS の唯一の利点は、大量のデータを非常に迅速に、最小限のストレージ料金で格納できることです。ただし、そのパーティション キー/行キー ストレージ モデルと魔法のように一致するユース ケースが幸運にもない限り、基本的にそのデータを再び取得することは期待できません。そうしないと (そうする人はほとんどいないと思いますが)、多くのパーティション スキャンを実行し、自分でデータを処理することになります。

それ以上に、Azure Table Storage は開発の面で行き詰まりを迎えているようです。Azure フィードバック フォーラム ( http://feedback.windowsazure.com/forums/217298-storage/suggestions/396314-support-secondary-indexes )の "Support Secondary Indexes" リクエストを見ると、セカンダリ インデックスは 2011 年まで約束されていましたが、進展はありませんでした。また、Table Storage に対するその他の上位の要求についても進展がありません。

Scott Guthrie が優れた人物であることはわかっているので、Table Storage の前線でのこの停滞が、Azure がそれを修正し、本当に素晴らしいものを思いつくための序章になることを願っています。それが私の希望です（ただし、そうであるという証拠はありません）。ただし、現時点では、他に選択肢がない限り、Azure Table Storage は使用しないことを強くお勧めします。Azure SQL を使用します。MongoDB または他の No-SQL DB の独自のインスタンスを使用します。または Amazon DynamoDB を使用します。ただし、Azure テーブル ストレージは使用しないでください。