33

読み取りパフォーマンスを大幅に改善することを目標に、社内で CQRS システムの読み取り部分を実装しようとしています。現在、読み取りは、SQL Azure データベースからのある程度の逆シリアル化を含む、正規化されたデータに対して Linq-to-SQL クエリを実行する Web サービスを介して行われます。

データの単純化された構造は次のとおりです。

  • ユーザー
  • 会話 (同じ受信者へのメッセージのグループ化)
  • メッセージ
  • 受信者 (ユーザーのセット)

これを非正規化状態に移動して、ユーザーがメッセージのフィードを表示するように要求したときに、次のいずれかから読み取るようにします。

Azure Table Storage に保持される非正規化表現

  • PartitionKey としての UserID
  • RowKey としての ConversationID
  • エンティティとして保存された、変更されやすい揮発性データ
  • エンティティで JSON としてシリアル化されたメッセージ
  • エンティティで JSON としてシリアル化されたメッセージの受信者
  • これに関する主な問題は、Table Storage (960KB) の行のサイズが制限されていることです。
  • また、「揮発性データ」列に対するクエリは、キーの一部ではないため遅くなります。

Azure Table Storage に保持されている正規化された表現

  • 会話の詳細、メッセージ、受信者の別の表
  • Conversation テーブルに格納されているメッセージと受信者のパーティション キー。
  • それを禁止します。これは上記と同じ構造に従います
  • 最大行サイズの問題を回避します
  • しかし、正規化された状態は、非正規化されたテーブルのパフォーマンスの向上を低下させますか?

また

SQL Azure で保持される非正規化表現

  • 複合主キーとして保持される UserID & ConversationID
  • 別の列に格納された、変更されやすい揮発性データ
  • 列に JSON としてシリアル化されたメッセージ
  • 列に JSON としてシリアル化されたメッセージの受信者
  • 非正規化データの索引付けと構造に対する最大の柔軟性
  • Table Storage クエリよりもはるかに遅いパフォーマンス

私が尋ねているのは、Table Storage または SQL Azure で非正規化構造を実装した経験がある人がいるかどうかです。どちらを選びますか? または、私が見逃したより良いアプローチはありますか?

私の直感では、Table Storage の正規化された (少なくともある程度) データが適していると思います。ただし、ユーザーのすべてのデータを取得するために 3 つのクエリを実行すると、パフォーマンスの向上が低下するのではないかと心配しています。

4

3 に答える 3

22

Azure テーブルを検討する主な要因は、読み取りパフォーマンスを大幅に改善することです。SQL Azure を使用するシナリオでは、「SQL Azure で保持される非正規化表現」の下の最後のポイントによると、「はるかに遅くなります」。個人的には、いくつかの理由からこれは非常に驚くべきことであり、この主張がどのように行われたかについて詳細な分析を求める. 私のデフォルトの立場は、ほとんどの場合、SQL Azure の方がはるかに高速であるというものです。

私がこの主張に懐疑的であるいくつかの理由を次に示します。

  • SQL Azure は、ネイティブで効率的な TDS プロトコルを使用してデータを返します。Azure テーブルは、より詳細な JSON 形式を使用します。
  • 主キーを使用しているか、SQL Azure にインデックスがある限り、SQL Azure の結合/フィルターは非常に高速です。Azure テーブルにはインデックスがなく、結合はクライアント側で実行する必要があります
  • Azure テーブルによって返されるレコード数の制限 (一度に 1,000 レコード) は、多くのレコードをフェッチするために複数のラウンドトリップを実装する必要があることを意味します

カスタム ビルドのインデックスを保持する追加のテーブルを作成することにより、Azure テーブルでインデックスを偽装することはできますが、そのインデックスを維持する責任はユーザーにあります。これにより、操作が遅くなり、注意しないと孤立したシナリオが作成される可能性があります。

最後になりましたが、Azure テーブルの使用は通常、ストレージ コストを削減しようとしている場合 (SQL Azure よりも安価です)、および SQL Azure が提供できるよりも多くのストレージが必要な場合に意味があります (ただし、フェデレーションを使用して、単一データベースの最大ストレージ制限)。たとえば、10 億件の顧客レコードを保存する必要がある場合、Azure Table を使用することは理にかなっています。しかし、速度を上げるためだけに Azure Tables を使用することは、私の考えではかなり疑わしいです。

もし私があなたの立場なら、私はその主張に非常に厳しく疑問を呈し、アーキテクチャを完全に変更する前に、SQL Server/SQL Azure に固有のパフォーマンスのボトルネックに達していることを実証できる専門的な SQL 開発スキルをスタッフに持っていることを確認します。

さらに、パフォーマンスの目標を定義します。100 倍高速なアクセス時間を見ていますか? 代わりにキャッシングを検討しましたか？データベースで適切にインデックスを使用していますか?

私の2セント... :)

于 2012-07-09T13:26:23.127 に答える