0

この質問は既に出されていますが、「1 声の回答」は見つかりませんでした。

する方が良いですか：

  • 1 つの大きなテーブル :

ユーザー ID | 属性_1 | 属性_2 | 属性_3 | 属性_4

  • または次の 4 つの小さなテーブル: user_id | 属性_1

ユーザー ID | 属性_2

ユーザー ID | 属性_3

ユーザー ID | 属性_4

1 つの大きなテーブルまたは多数の小さなテーブル ? 各ユーザーは、attribute_X の値を 1 つだけ持つことができます。保存するデータはたくさんあります (1 億人のユーザー)。innoDB を使用しています。パフォーマンスは私たちにとって非常に重要です (10,000 クエリ/秒)。

ありがとう ！

フランソワ

4

2 に答える 2

1

ゼロ、1、または多数の原則に従う場合、つまり、そのようなものは存在しないか、そのうちの 1 つが存在するか、数に制限がないかのいずれかである場合は、常に適切に正規化されたテーブルを作成して、このようなものを追跡します。

たとえば、考えられるスキーマは次のとおりです。

CREATE TABLE user_attributes (
  id INT PRIMARY KEY NOT NULL AUTO_INCREMENT,
  user_id INT NOT NULL,
  attribute_name VARCHAR(255) NOT NULL,
  attribute_value VARCHAR(255),
  UNIQUE INDEX index_user_attributes_name(user_id, attribute_name)
);

これは、ユーザーごとに多くの属性を持つことができる基本的なキー値ストア パターンです。

これに必要なストレージは、 のような永続的に苛立たしい名前を持つ固定列配置よりも高くなりますがattribute1、テラバイト サイズのハード ドライブの時代にはコストが十分に小さいため、問題になることはめったにありません。

通常、挿入時間が問題になるまで、このデータ用に単一のテーブルを作成します。あなたの挿入が速い限り、私はそれについて心配しません。その時点で、必要な場合にのみ、このデータを同一のスキーマを持つ複数のテーブルに分割するシャーディング戦略を検討する必要があります。

1,000 万から 5,000 万行の段階になると思いますが、このテーブルの挿入アクティビティの量が比較的少ない場合は、それ以上になる可能性があります。

読み取りアクティビティを最適化する最善の方法は、キャッシュを使用することであることを忘れないでください。最速のデータベース クエリは、作成しないものです。そのような場合、通常はmemcachedのようなものを使用して以前のフェッチの結果を保存し、書き込み時にこれを無効にします。

いつものように、提案されたスキーマを実稼働スケールでベンチマークします。

于 2012-12-10T22:10:32.230 に答える
0

1つの大きなテーブル：user_id | attribute_1 | attribute_2 | attribute_3 | attribute_4

管理が容易になります。そうしないと、個々のルックアップが多すぎるため、DBに対するプログラミングが複雑になり、アプリケーションエラーが増える可能性があります。

于 2012-12-10T22:24:27.297 に答える