Ruby on Railsアプリケーションでテーブルを3つのテーブルに分割する

Question

Streamという名前のクラスがデータベースに多数あり、さらに多くのレコードが常に追加されています。 streamsテーブル内のフィールドのうち、ratingは、-1,0,1、またはnullにすることができます。私は、「評価された」と評価が-1,0または1であり、「評価されていない」と評価されていると評価します。今のところ、ストリームテーブルには24Mのレコードがあります。 20Mは定格、4Mは定格ではない。評価されていないレコードについては、ストリームテーブルを頻繁に照会する必要があります。問題は、そのような大きなテーブルを照会するのに時間がかかることです。

ストリームテーブルを3つの別々のテーブルに分割することを考えました。定格ストリームテーブル、未評価ストリームテーブル、古い未評価ストリームテーブルがあります。それが動作する方法は、新しいストリームが作成されます。新しいレコードは未評価な​​ので、未評価のストリームテーブルに配置されます。定格の場合は、定格ストリームテーブルに移動します。 1週間以上評価されていない場合は、古い未評価ストリームテーブルに移動されます。

buzz.rated_streams.first 
interest.unrated_streams.first 
user.old_streams.first 
RatedStream.find(1).buzz 
UnratedStream.find(2).interest 
OldStream.find(3).user 

レートがありませんストリームテーブル

がはるかに高速に照会することができます：私はまだのように、シームレスに Streamクラスのメソッドとの関連付けを使用できるようにする必要があります。定格ストリーム表は分析に役立ちます。古い未評価ストリームテーブルは古いデータのダンプになります。

私はいくつかの質問があります。テーブルを分割するのは良い考えですか？もしそうなら、私はすべてを破壊から守るためにそれをやるでしょうし、Streamクラスと同じ方法と関連付けを使用しますか？テーブルを分割するのが悪い考えであれば、どうすればいいですか？

Answer 1

私はこれがバアアードのアイデアだと思います。多くのカスタムコード（動作保証されていない）。

代わりにratingにインデックスを作成する必要があります。これにより、クエリに関するすべての問題が解決される可能性があります（coveredにすることもできます）。

Answer 2

使用しているDBは不明ですが、パフォーマンスを向上させるためにテーブルを分割する可能性があります。

Answer 3

良いデザインは、400万件の一致を持つブール値のプロパティを頻繁にクエリする必要がある理由によって異なります。料金を支払う予定のストリームリストを維持していますか？ 「未評価のストリーム数」カウンタを表示していますか？他のプロパティでもクエリしていますか？

最初と仮定すると、あなたは

• ような何かを行うことができstreamsテーブル内のストリームに関する情報のほとんどを持っています。
• 譲受人等により、優先度、割り当てられた評価者、譲渡日、インデックスを持ちbelongs_to :streamsとstreams_tasksテーブルを作成しbelongs_to :streamsと評価
• を持ってstreams_ratingsテーブルを作成します。
• ストリームを検索するには、StreamTask.first(:assignee => 'unassigned').streamと指定する必要があります。名前付きスコープを使用すると、これをスムーズにすることができます。
• 設定が完了し、新しいStreamRatingを作成し、そこStreamTask

Answer 4

を削除するには、私はそれがとても遅かった実行していたクエリを記述するための別の方法であることが判明しました。代わりに2分以上かかる：

ユーザー。streams.unrated.all（：条件=> ""、：オーダー=> "ID DESC"：限界=> 10）

これは、ほぼ瞬時に動作：

user.streams.unrated.findを（：条件=> ""、：order => "id DESC"、：limit => 10）

私はその違いを知ることができません。彼は最高の答えだったので、私はセルジオに小切手を渡した。