1

これが私のスキーマであると仮定します:

class modelA(models.Model):
  b = models.ManyToManyField(through='linkModel')

class modelB(models.Model):
  name = models.CharField()

class linkModel(models.Models):
  a = models.ForeignKey(modelA)
  b = models.ForeignKey(modelB)
  (other link-relevant stuff)

A にリンクする B のインスタンスを検索しているときに、どの時点でクエリ パフォーマンスの問題が発生すると予想できますか。また、その逆も同様です。10万行？何百万？

ManyToMany の代わりに単一の ForeignKey リレーションを使用すると (場合によってはスキーマを再配置できる可能性があります)、パフォーマンスが向上しますか?

4

2 に答える 2

4

私がよく知らないフレームワークの動作によっては、結合が実行のためにバッキング データベース サーバーに渡される場合があります。その場合、インデックス作成の効率は O(log n) であり、チョークポイントは結合ではなく結果セットのサイズであることがわかります。

適切なスキーマ設計とインデックス作成を想定すると、バルク データ操作のパフォーマンスは常にワーキング セットのサイズによって制限されます。

データベース サーバー、フレームワーク、およびアプリケーション ロジックの特定の組み合わせに適用される決定的な答えを得るには、テストを実行する必要があります。

途中で大規模で複雑なアプリケーションをテストする必要は必ずしもありません。興味深いアプリケーション コードを抜粋して、テスト アプリにすることができます。ただし、大量のデータが必要になります。

誰かが特定のシナリオを既にテストしていることを期待している場合は、構成を詳細に説明する必要があります。サンプル アプリケーション ロジックは既に用意されています。これは良い出発点です。

驚くほど多くのものが干渉する可能性があります。たとえば、Microsoft SQL Server 2008 データベースで自動縮小オプションをオンにすると、膨大なオーバーヘッドが発生し、TPM の数値が約 3 分の 1 に減少します。これらを見つけて文書化する必要があります。

于 2012-08-02T00:06:41.500 に答える
2

Peter Wone の発言に加えて、JOIN の両方の「方向」を最適に実行するためにデータベースに存在する「理想的な」ジャンクション テーブル構造を次に示します。

  • 2 つの FK の組み合わせである複合 PK を持っています。
  • PK の正確な「逆」である代替インデックスがあります。
  • リーディング エッジ フィールドの繰り返しによるオーバーヘッドを最小限に抑えるために、両方のインデックス (プライマリと代替) が圧縮されます。
  • 代理キーはありません (したがって、3 番目のインデックスは必要ありません)。
  • クラスター化されています。代替インデックスにはすでにすべての PK フィールドが含まれているため (逆の順序で)、クラスター化されたテーブルの代替インデックスに通常関連するオーバーヘッドはありません。また、JOIN をカバーするため、二重ルックアップはありません。

そのための Oracle 構文は次のようになります。

CREATE TABLE LINK_MODEL (
    MODEL_A_ID INT,
    MODEL_B_ID INT,
    PRIMARY KEY (MODEL_A_ID, MODEL_B_ID),
    FOREIGN KEY (MODEL_A_ID) REFERENCES MODEL_A (MODEL_A_ID),
    FOREIGN KEY (MODEL_B_ID) REFERENCES MODEL_B (MODEL_B_ID)
) ORGANIZATION INDEX COMPRESS;

CREATE INDEX LINK_MODEL_IE1 ON LINK_MODEL (MODEL_B_ID, MODEL_A_ID) COMPRESS;

LINK_MODELこれにより、特定の A の B をクエリするには、テーブル ヒープへのアクセスなし (テーブル ヒープはまったくない) であるインデックスの単純な範囲スキャンのみが必要になります。指定された B の As を照会するには、LINK_MODEL_IE1テーブル ヒープへのアクセスなしで、 に対する単純な範囲スキャンが必要です。

残念ながら、すべてのデータベースがクラスタリングとインデックス圧縮をサポートしているわけではありませんが、DBMS と ORM で可能な限り多くのことを実装する必要があります。

于 2012-08-02T08:47:06.080 に答える