3

私は Django プロジェクトを開始しており、行数が多すぎる可能性がある複数のテーブルを分割する必要があります。私はここや他の場所でスレッドを調べ、Django の複数データベースのドキュメントに従いましたが、すべてがどのようにつながっているかはまだわかりません。私のモデルには、シャーディングによって壊れる関係があるため、オプションは、それぞれのモデルのシャーディングを忘れて外部キーを削除することのようです。

議論のために、古典的なAuthot、Publisher、およびBookのシナリオを考えてみましょう。ただし、本のコピーとそれらを所有できるユーザーを投入してください。本とユーザーをシャーディングする必要があるとしましょう。どのようにアプローチしますか？ユーザーは、同じデータベースにない書籍のコピーを所有している場合があります。

一般的に、ルーティングとシャーディング自体に使用したベスト プラクティスは何ですか? Django データベース ルーターを使用したり、シャーディング ロジックに基づいてコマンド内のデータベースを手動で選択したり、それを達成するために ORM の一部をオーバーライドしたりしましたか?

問題があれば、UbuntuでPostgreSQLを使用しています。

どうもありがとう。

4

2 に答える 2

4

過去に Postgresql Table Partitioningを使用して同様のことを行いましたが、これは同じ DB でテーブルを分割するだけです。これは、テーブルの検索時間を短縮するのに役立ちます。django コードをあまり変更する必要がないため、これも素晴らしいことです。(制約に使用しているフィールドでクエリを実行してください)。

しかし、それはシャーディングではありません。

まだ見ていない場合は、Sharding Postgres with Instagram をチェックしてください。

于 2012-11-29T08:06:10.657 に答える
1

@DanielRosemanに同意します。また、行数が多すぎます。インデックス作成に注意すれば、多くの行をパフォーマンスの問題なく処理できます。インデックス付きの値を小さくしてください (int)。他の数百万行のテーブルと結合した場合でも、1 秒未満の応答を生成する 4 億行を超えるテーブルがあります。

ユーザーを複数のテーブルに分割して、ユーザーオブジェクトが一般的に使用されるもののコアを持ち、「プロファイル」情報が別の場所にあるようにする方が理にかなっている場合があります (標準 Django セットアップ)。コピーは、大量のデータを持つ本を参照する小さなテーブルになります。最近 DB サーバーに投入できる RAM の量を考えると、あまりにも前にシャーディングするのは間違っているように思えます。

于 2012-11-30T05:25:10.947 に答える