0

SQL azure でのシャーディングの概念は、現時点で 50Gb の DB サイズ制限を超えるための最も推奨されるオプションの 1 つです。シャーディングの重要な戦略は、アトミック ユニットと呼ばれる関連するレコードを 1 つのシャードにグループ化することです。これにより、アプリケーションは 1 つの SQL azure インスタンスに対してクエリを実行するだけでデータを取得できます。

ただし、ソーシャル ネットワーキング アプリなどのアプリケーションでは、エンティティとレコードが相互に接続されているため、アトミック ユニットを 1 つのシャードにグループ化することは簡単ではありません。そのようなシナリオに基づく推奨されるアプローチは何でしょうか?

また、シャード DB では、テーブルにどの主キーを使用する必要がありますか? Big Int または GUID。現在、BIGINT ID 列を使用していますが、何らかの理由でデータをマージする場合、異なるシャードの値が競合するために問題が発生します。GUID (UniqueIdentifier) を推奨する人がいると聞いたことがありますが、これがパフォーマンスにどのように影響するか心配です。UniqueIdentifier 列を使用してオンプレミスの SQL サーバーにインデックスを作成することはできません。UniqueIdentifier 列を使用する場合、Azure SQL が同様の戦略をどのように実装するのか疑問に思います。

4

1 に答える 1

0

ソーシャル ネットワーキング アプリの場合、SQL の使用を事前に断念し、代わりに MongoDB や Azure Table Storage などの noSQL ソリューションを活用します。これらの正規化されていないが安価なシステムにより、さまざまなインデックス作成のニーズに合わせてカスタマイズされた複数のエンティティ データセットを作成できます。

したがって、次のようなものではなく... User1 -< relationshiptable -< User2

代わりに、Users User1's Friends User2's Friends のようなテーブルが必要です。

ユーザー 1 と 2 が両方とも友人である場合、その関係を定義するエントリは 1 つではなく 2 つになります。ただし、特定のユーザーの友達のリストを取得するのは簡単です。また、一度に複数のインデックス テーブルを検索することで、タスクを並行して実行できるようになりました。

このプロセスは非常にうまく拡張できますが、関係を維持する方法により多くの時間を費やす必要があります。確かに、これは単純化された例です。ユーザーベース全体の検索などのタスクについて話し始めると、事態はさらに複雑になります。

于 2011-02-11T14:31:56.387 に答える