0

これはカスタムソーシャルネットワーク用です。すべてのユーザーが「プロファイル設定」を持っています

ユーザーが変更できる設定は約30あるため、いくつかのカテゴリがあります。

  • プロファイル設定
  • SMS | 電子メール通知
  • 承認設定
  • セキュリティ設定
  • アクセス設定

設定を保持するテーブルをいくつか作成しました（ENUMタイプ）

その設定をこのように小さなテーブルにドロップすると（もちろん、一意のユーザーIDがインデックスに登録されます）

（ユーザーIDは、タブ内のすべての場所で主キーです）

CREATE TABLE user_profile_settings ( ... ) type=MyISAM;
CREATE TABLE user_profile_notif ( ... ) type=MyISAM;
CREATE TABLE user_profile_auth ( ... ) type=MyISAM;
CREATE TABLE user_profile_security ( ... ) type=MyISAM;
CREATE TABLE user_profile_access ( ... ) type=MyISAM;

次に、1つのリクエストが一度に複数のテーブルに送られます。これは、ある程度のパフォーマンスの低下も意味します。これの利点は次のとおりです。user_profile_settingsからのみ読み取る必要がある場合は、そのテーブルのインデックス付きIDのみを要求します。

2番目のアプローチは、次のように、ユーザーが持つすべてのユーザー設定に対して1つの行を作成することです。

CREATE TABLE all_user_config ( /***/ ) type=MyISAM;

約30個の列が含まれていますが、システム全体の保守が少し難しくなります。

問題は、どのアプローチが推奨され、10億行に適しているかということです。

4

1 に答える 1

1

個人的には、ENUMフィールドを 1 つの大きなテーブルに保持することをお勧めします。これにより、5 つではなく 1 つの巨大なインデックスをクエリして更新するだけで済みます。これは、やや古いクラス図が Facebook が行っていると主張していることです。または、図が本物である場合、少なくとも以前はそうでした。

推定ユーザー数 (Facebook の現在のユーザー数はわずか 9 億人) を真剣に考えている場合は、MySQL などのリレーショナル データベースを捨てて、SQL を使用しないソリューション (キー バリュー ストアのCassandraやドキュメントなど) を検討することをお勧めします。指向のMongoDB。それらは、巨大なサイズにスケーリングし、リレーショナル データベースよりもスムーズに分散環境に展開する傾向があります。

于 2012-05-05T10:44:47.500 に答える