6

Windows Azure ではハイブリッド アーキテクチャを使用しており、ほとんどのエンティティを SQL Azure データベースに格納していますが、大量のストレージ スペースを必要とする可能性のあるものはすべて Azure Table Storage に投入しています。

ただし、このアーキテクチャでは、Azure Table Storage に関するあらゆる種類の問題に直面しています。これは、せいぜい未熟で不完全な製品のように思えます。最大の制限は、実用上、書き込み専用のデータ ストアであることです。コンセンサスは、その書き込み機能は非常にうまく拡張できるが、クエリ機能とインデックス機能は驚くほど限られているということです (何年にもわたるユーザーの不満と Microsoft の約束にもかかわらず)) 私は、基本的に緊急時にのみ ATS からデータを取得しようとするべきであるという結論に達しました。複雑でリアルタイムのトランザクション アプリケーションからデータを取得することは、本来よりもはるかに困難です。もちろん、データの複数のコピーを維持する、コピーごとに異なるインデックス作成戦略を使用する、クエリを分割して並列に実行するなどの回避策がありますが、クラウド サービスの全体的なポイントがそれを最小限に抑えることである場合、複雑さが増します。

とは言っても、私たちは今のところ Azure に取り組んでおり、できれば実際にこの道を実際に運用している人々から、代替案と落とし穴が何であるかについて良い感覚を得たいと思っています.

VM または他のクラウドのいずれかで実行できるNoSQL オプションがたくさんあることは十分承知しています (たとえば、この質問: What NoSQL solutions are out there for .NET? にリストされているすべてのオプション)。 . しかし、Azure の PAAS モデルにうまく適合するものがあるかどうかを知りたいと思っています。つまり、私が Azure を使用していて、自分の VM を管理したくなく、ATS によって約束された (完全に提供されることはありませんが) ほぼ自動でほぼ無限のスケーラビリティにできるだけ近いものが必要な場合、どのようなオプションがありますか?人々は貴重だと思いましたか？MongoDB/Azure ラッパーはシンプルで実行可能な代替手段ですか? それとも、弾丸をかじって自分の VM をスピンアップする必要がありますか? それとも AWS に切り替えますか? それとも Azure SQL を使い続けますか?

(サイズ要件の感覚をつかむために: 10 億行以上を格納する必要があると考えています。巨大ではありませんが、無視できるほどでもありません。)

4

4 に答える 4

1

これが投稿されて以来、Azure は NoSQL で大きな進歩を遂げています。Azure 内から Raven と MongoDB をアドオンとしてスピンアップできるようになりました。最近、彼らは独自の製品である "Azure DocumentDB" を発表しました。パブリック プレビュー中 - ブログはこちら: http://azure.microsoft.com/blog/2014/08/21/new-azure-services-and-updates-expand-openness-choice-and-flexibility/

詳細情報とドキュメントは、http: //azure.microsoft.com/en-gb/services/documentdb/で入手できます。

他の人が言及したように、可能な検索/インデックスソリューションとしてのLucene。検索に Lucene インデックスを使用する Azure Websites に Web サイトがあり、Web サイトの Web スペースにインデックスを直接格納してクエリを実行できるため、専用の VM は必要なく、インデックスを公開する方法について心配する必要もありませんでした。ワイヤーを渡って。複数の Web ボックスを維持したい場合 (スケーリング時) には、これは明らかに扱いにくいものですが、可能性として知っておく価値があるかもしれません。私の Web インスタンスには 50 GB のディスク容量がありましたが、そのうちのごく一部しか Web サイトで使用されていないため、Lucene インデックスはそれを利用しています。これが正式な作戦だとは聞いたことがないよ、YMMV。

于 2014-09-19T15:57:29.350 に答える
1

ちょっと話題がずれてるかも。

ATS が優れたツールであるユースケースがいくつかあります。

1 つのケースは、通常は XML (JSON) シリアライズされたオブジェクトとして通常の RDB 内に格納するメタデータを格納することです。これらはデータであり、インデックスを作成する必要はありませんが、構造化されています。たとえば、すべてのクライアント メタ データ。SQL ではなく ATS を使用する理由は、移動中にそのようなデータの列を追加、削除する ATS の機能です。そのため、メタ データ構造を変更するたびに、すべてのクライアント レコードをループして、XML (JSON) を逆シリアル化し、データ ツリーを再作成し、XML (JSON) にシリアル化し、テーブルに戻す必要はありません。これは完璧です。コインの欠点は、従来の XML (JSON) シリアル化を使用して実現できるツリー構造ではなく、メタ データのフラット構造を維持する必要があることです。

2 番目のケースは、データが多すぎる場合に必要のない RDBM からのデータを格納することです。たとえば、銀行システムでの 5 年以上前のトランザクションのリストなどです。これらは実際に保存する必要があるデータですが、アクティブな形式ではありません。これらのデータは、結合/場所の条件を遅くするため、毎日のベースでは必要ありません。これらのデータを元に戻したり、別の RDBM に移動して、年に 1 回行われるオフライン分析を行ったりすることができます。また、データを ATS に保存すると、RDBM 内にデータを残すよりもはるかに安価になります。

于 2014-09-22T13:45:34.210 に答える