24

リレーショナルの世界から来ると、Azure テーブル ストレージの場合は明らかに大きく異なります。私が遭遇した最初の大きな問題は、多対多の関係を適切に保存する方法です。

たとえば、ユーザーとユーザーが所有する本を追跡するシステムがあるとします。ここで、ユーザーが所有する書籍 ID のリストを基本的に格納するユーザーに文字列プロパティを設定することを提案する SO に関する別の投稿を見つけました。これがデータの保存方法として受け入れられている場合があることは理解していますが、問題は、Azure では 64 KB のデータしか String に保存できないことです。これにより、ユーザーが潜在的に所有できる書籍の数が制限されます。

別の考えられる解決策は、データを重複させることです。システム内のすべての既知の書籍を格納するテーブルがあるとします。ただし、User を Book に関連付ける必要がある場合、OwnedBooks という別のテーブルに Book データをコピーします。これは、OwnedByUserID プロパティも持っていることを除いて、基本的に Book テーブルとまったく同じです。

他に考えられる解決策はありますか？

この問題以外に、Azure テーブル ストレージを使用する際の他のパタ​​ーンやプラクティスについて何か良い提案はありますか?

4

2 に答える 2

16

これには多くの解決策があります - もちろんすべて欠点があります:-)

  1. RDBMS の場合と同様に、単純なマッピング テーブルを使用します。各行には Book キーと User キーが含まれます。

    次に、ユーザーのすべての本を検索するには、マッピング テーブルで Book キーを選択し、それらのキーごとに、Books テーブルから Book エンティティを選択します。非同期フェッチを使用して書籍の取得を並行して行うことはできますが、それでも、このソリューションは明らかにスケーリングしません。

  2. 上記のようにマッピング テーブルを使用しますが、必要なすべての Book データもマッピング テーブルに含めます。これは、OwnedBooks テーブルで既に提案した非正規化または「重複データ」ソリューションです。

    この方法の主な欠点は、Book データのいずれかを更新する必要がある場合、多くのエンティティを更新する可能性があることです。また、それらは Book 自体とは別のテーブルにあるため、エンティティで完了することができません。単一のトランザクション/バッチ (そして、ユーザー ID をマッピング テーブルのパーティション キーとして使用すると思いますが、これにより、そのテーブルでの単一のバッチ更新が既に排除されています)。

  3. User の単一のプロパティに結合された Book キーを格納します。繰り返しますが、あなたはすでにこの方法を提案しています。

    Azure が現在「含む」タイプのクエリをサポートしていないという事実がなければ、これは実際にはそれほど悪くはありません。つまり、部分文字列を検索することはできません。特定の本を所有していた場合、これは不可能です。興味深いことに、Google App Engine はストレージ システムでこれをかなり透過的にサポートしており、リストのインデックスも作成します。いずれにしても、このメソッドでも各 Book のデータを取得する必要があります。

  4. Azure テーブル ストレージの "スキーマレス" の性質を利用して、関連する Book キーを個別のプロパティとして格納します。たとえば、1 つの User エンティティは次のようになります。

    { Name: "User1", Book_4325: true, Book_5123: true }

    別の例は次のようになります。

    { Name: "User2", Book_5346: true, Book_8753: true, Book_6135: true }

    次に、特定の本を所有するすべてのユーザーを見つけたい場合は、その特定のプロパティが true である場所を選択できます (実際に存在する必要があるだけです)。

    これの明らかな欠点は、少しもろく、プロパティ名のキーをいじる必要があり、これには StorageClient の標準メソッドを使用できないことです。独自のメソッドを作成する必要があります。また、Azure はエンティティで 255 個のプロパティのみをサポートします。そうは言っても、試したことはありませんが、非常にうまくスケーリングできると思います。

これらすべてのオプションの中で、現在 Azure でサポートされており、通常はより少ないクエリですべてを達成できるという事実のために、オプション 2 を選択するのが最適だと思います。

アトミック トランザクションが窓の外にあることを考慮して、ユース ケースを精査して、いつ、どのようにデータを更新するかを決定する必要があります。「結果整合性」が維持され、マッピング テーブルが常に 100% 最新であるとは限らないことを考慮して、問題なく使用できることはほぼ保証できます。

プライマリ テーブルと同時にマッピング テーブルのデータを更新するのにコストがかかりすぎる場合は、メッセージをキューに入れ、worker ロールを取得して更新を非同期で実行することができます。

于 2009-07-12T07:06:53.613 に答える
9

あなたはそうしない。ベスト プラクティスに関するセクションがある、Azure テーブルに関する優れた包括的なホワイト ペーパー(.docx リンク) を次に示します。ただし、非リレーショナル プロパティ バッグまたは ORM タイプの設計には Table を使用する必要があります。クラウドでリレーショナルが必要な場合は、SQL Azure データベースを使用する必要があります。

これは、スキーマ フリー ストレージとリレーショナル ストレージに関する別の優れた記事です。これは別のスキーマ フリー クラウド ストレージ オファリング用ですが、概念は同じです。

于 2009-07-12T00:33:22.277 に答える