4

次のようなテーブルのカテゴリでトピックにタグを付ける方法を収集します。

ID | topic_id | votes_Category_1 | votes_Category_2 |.......... | votes_Category_12

履歴上の理由から、このテーブルを 1 時間ごとにダンプします。テーブルに 200 万行が含まれているとします。履歴テーブルに 1 時間ごとにダンプされます。

列 Category_13 を追加したい場合、このソリューションは柔軟ではないため、これについて考えています。

ID | topic_id | Category_id | vote_count

このソリューションでは、トピックごとに 12 行が作成され、構造化と柔軟性が向上しますが、1 時間ごとに 2,400 万行をダンプする必要があります。

各カテゴリのベスト 10 のトピックが必要です。ケース 2 では、投票 (category_id=x および topic_id=y) で Max を使用すると、ケース 1 よりも遅くなるかどうか疑問に思います。

どちらが良いでしょう パフォーマンスの観点から：

  1. 14 列で 200 万行を作成するには
  2. 4 列で 2,400 万行を作成するには

ありがとうございました

4

1 に答える 1

3

検索パターンを見て、アプローチを決定します。

  1. カテゴリ別にトピックを取得する場合は、2番目のアプローチを使用します。カテゴリフィールドにインデックスを定義して、特定のカテゴリのすべてのレコードがディスクに連続して（比較的）保存されるようにします。これにより、ディスクページの数が少なくなります。取得されます。これは、すべてのカテゴリを列として持つテーブルのレコードサイズと比較してレコードサイズが小さいためでもあります。利点は、カテゴリを簡単に追加できる柔軟性です。欠点は、データの合計サイズに影響する（ID、TopicID）列データの繰り返しです。

  2. トピックごとに取得する場合は、トピックのインデックスを定義する最初のアプローチを使用します。これにより、各カテゴリの（ID、TopicID）列値の繰り返しが減り、保存されるデータの合計サイズが減ります。行数は1時間あたり数百万であるため、このサイズの削減は重要です。欠点は、新しいカテゴリのスキーマを変更する必要があることです。

編集：編集からの検索パターンを考慮します：

カテゴリごとに上位のトピックとその値を取得するので、ケース1ではvotes_Category_xで並べ替えます。

私はこれを次のように理解していますFind the top N topics with largest number of votes in a given category

ケース2では、各topic_idのmax（category）を探します。

そしてこれはSELECT TopicID, MAX(votes) FROM TABLE GROUP BY TopicID, Category。

レコードのサイズは200万行と2400万行で異なりますが、そうです、IDとTopicIDが繰り返されるため、レコードごとに8バイトずつデータサイズが確実に増加します。

最初のテーブルにはサイズごとに200万レコードが格納さ60 bytes (4*15 ints)れ、2番目のテーブルにはサイズごとに2400万レコードが格納され16 bytes (4*4 ints)ます。2番目のテーブルは、1時間ごとにそれぞれ~62のページを追加します。4KBある期間にわたる懸念のようです。2番目のアプローチの場合、インデックスはカテゴリ別に編成されているため、これは中央にデータが挿入されることによる断片化にも影響します。

テーブル構造の1つに進む前に、これをよりよく理解し、カテゴリを追加する頻度を検討するために、いくつかのパフォーマンステストを実行する価値があるかもしれません。

于 2012-10-20T12:10:38.680 に答える