数百万のユーザーを管理する方法は？

私は本当に大きなものを立ち上げようとしています。サーバーとデータベースを準備する必要があります。

100,000ユーザーの各セットを個別のユーザーテーブルにグループ化したいのですが、適切なユーザーテーブルにログインしようとする1人のユーザーを関連付ける方法がわかりません。

たとえば、ユーザーjay@mail.comがユーザーテーブル＃36に関連していることをどのようにして知ることができますか？

1つのユーザーテーブルに1,000万人のユーザーがいるのと同じでしょうか、それとも100万人のユーザーがいるのでしょうか？

Facebookはどうですか？彼らが9億5,000万のエントリを持つ1つのグローバルユーザーテーブルを持つとは信じられません。

明日は10億人のユーザーがいるわけではなく、MySQLは数百万行を問題なく処理できます。私はユーザーテーブルに500万人のユーザーがいますが、私を信頼しています。心配することもありません。

シャーディングは、必要になるまで心配しないでください。存在する可能性のある問題または存在しない可能性のある問題に対して時期尚早に最適化しようとしており、その過程で、革新できる速度が大幅に低下します。迅速に起動し、問題が発生したらすぐに見つけてください。スケーリングの課題を事前に予測することはできません。

この規模に達した場合、この種の問題を解決するためにかなりのお金とリソースが必要になります。

非常に大規模なデータセットを処理し、地面から始める必要がある場合、外部コンサルタントがあなたの会社のより良いサポートになるかどうかはわかりません。誤解しないでください。しかし、多くの顧客を抱えるプロジェクトを台無しにすると、あなたの会社にPRの影響が出ます。

1つのテーブル内の10Mタプルについては、適切なインデックスが作成されていれば問題ありません。ここでは、1つのテーブルに複数の1億個のタプル（販売アイテム）を格納する必要があります。これは、大きなOracle 11gで正常に動作します

Facebookのデータベースデザインのマップを使用した2010年の投稿を次に示します。Facebookデータベースのデザイン

次のようなパーティションタイプに関するmysqlのドキュメントを読むことをお勧めします。MySQLのドキュメント：パーティショニング

MySQLは次のタイプをサポートします。

RANGEパーティショニング。このタイプのパーティショニングは、指定された範囲内の列値に基づいて行をパーティションに割り当てます。セクション18.2.1「RANGEパーティショニング」を参照してください。

LISTパーティショニング。RANGEによるパーティショニングに似ていますが、一連の離散値のいずれかに一致する列に基づいてパーティションが選択される点が異なります。セクション18.2.2「LISTパーティショニング」を参照してください。

ハッシュ分割。このタイプのパーティション分割では、テーブルに挿入される行の列値を操作するユーザー定義の式によって返される値に基づいてパーティションが選択されます。この関数は、非負の整数値を生成するMySQLで有効な任意の式で構成できます。このタイプの拡張機能であるLINEAR HASHも利用できます。セクション18.2.3「ハッシュパーティション化」を参照してください。

キー分割。このタイプのパーティショニングは、HASHによるパーティショニングと似ていますが、評価される1つ以上の列のみが提供され、MySQLサーバーが独自のハッシュ関数を提供する点が異なります。MySQLが提供するハッシュ関数は列のデータ型に関係なく整数の結果を保証するため、これらの列には整数値以外を含めることができます。このタイプの拡張機能であるLINEAR KEYも使用できます。セクション18.2.4「キーパーティション」を参照してください。

まず、ユーザーを別々のテーブルに分割しないでください。物事が複雑で無意味になります。MySQLなどのデータベースは、同じテーブルの何百万ものレコードのデータベースを問題なく動作できます（適切なプライマリキーが設定されている）。各ユーザー（メインユーザーテーブル内）に対してデータベースのAUTO_INCREMENT AND PRIMARYユニークキーフィールドを使用して、すべてのレコードがユニーク（UID）になるようにします。次に、他のテーブルでは、その一意のIDを使用して参照しています。次に、すべてのテーブルでPRIMARY KEYとして設定していることを確認してください。これにより、データベースサーバー内の情報の処理が高速化されます。Drupal CMSから、ユーザー情報がどのように保存されているかを知ることができます。数百万人のユーザーと非常に大規模な企業（大規模なメディア企業、政府、世界最大の銀行でも使用）によって10年以上にわたってテストされています。www.drupalで。組織では、同じテーブルに1,600万以上のページ（ノード）が保存されており、1か月あたりのユニークビジター数は100万を超えており、ウェブサイトは問題なく機能しています。すべてが適切な最適化と構成に関するものです。

1000万件のレコードの後、パフォーマンスに満足できない場合（適切な最適化とdb構成の変更後）、異なるテーブルでユーザーを本当に分離するかどうかを決定できます。そのため、ユーザーレコードの保存場所に関する情報を持つ新しいテーブルUIDとtable_nameを追加することにより、実際に機能を拡張できます。次に、他のテーブルでこれらの情報を要求すると、このテーブルは正しいテーブルを探します。しかし、1000万から1億を超えるレコードがない限り、ユーザー用に1つの大きなテーブルを用意することを本当にお勧めします。ただし、パフォーマンスはそれほど向上しません（データベースは膨大なデータを処理するように設計されています）。情報をシンプルに保つことをお勧めします。通常、企業は別のデータベースサーバー（マスターとスレーブ）を決定し、別のデータベースサーバーを決定するだけです。負荷分散機能と一緒に再作業します。1,000万人のユーザーがいる場合は、別のdbサーバーに料金を支払うことができますよね？

user.installファイルのuserテーブルスキーマの例を参照してください。

他の回答が示唆するように、ユーザーを複数のテーブルに分割することはお勧めできません。ユーザーIDにインデックスがあるほとんどのデータベースは、100万行を処理できます。ただし、インデックス内のエントリの総数に応じて、クエリごとのレイテンシが増加する場合があります。データセットが小さい限り、通常のデータベースの単一のテーブルで管理できます。

あなたが百万件以上のレコードをはるかに超えて成長する場合、あなたの将来の考慮のためにも、私は異なるアイデアを投げ込もうとします。このような多数の顧客の場合、ダウンタイムなどは必要ありません。したがって、見たいnosqlデータベースがたくさんあります。アプリケーションから自分でシャーディングを管理する代わりに、彼らはあなたのためにシャーディングを行います。また、データの冗長性が得られるため、稼働時間が長くなります。Facebookおよびすべてのユーザーは、キャッシュにmemcacheなどを多用しています。しかし、私は彼らが彼らの常設店に何を使うのか分かりません。

注意すべき重要なことの1つは、nosqlデータベースでは結合などを実行できないことです。したがって、ユースケースを計画して決定してください。結合とマルチレコードトランザクションが必要な場合は、nosqlデータベースは適していません。

アルファベットの範囲に基づいて分割しないのはなぜですか？数百万人のユーザーがいる場合は、文字ごとまたは文字のペアごとに個別のテーブルを作成します（ユーザー名が「a」で始まるユーザーの場合はテーブル「a」）。最初はかなりのオーバーヘッドになりますが、大きなデータベースを想定しており、特定のユーザーに使用するテーブルを区別できるようにしたいので、アルファベット順が明白で最も簡単な選択だと思います。