これが状況です。数百万人のユーザーのウェブサイト。各ユーザーのページには、メッセージ セクションがあります。誰でもユーザーのページにアクセスして、メッセージを残したり、最新の 100 件のメッセージを表示したりできます。
メッセージは、追加のメタデータを含む短い txt です。すべてのメッセージは永続的に保存する必要があり、リアルタイムで高速でなければならないのは、メッセージの更新と読み取り (人々はチャットとして使用します) だけです。変更を確認するために、多数のメッセージが非常に頻繁に読み取られます。定期的に古いメッセージ (100 件以上) をアーカイブしても問題ありませんが、アクセスできる必要があります。
現在、すべてが 1 つの大きな DB テーブルにまとめられており、メッセージ リストを読んでさらに更新を送信する人々の間の競合が問題になりつつあります。
システムを再設計する必要がある場合、どのストレージ メカニズム/キャッシュを使用しますか? ここではどのようなコンピュータ サイエンス学習を使用できますか? (例: コレクション、リスト アクセスなど)
簡単な解決策の 1 つは、データを非正規化し、事前に計算された集計を別のテーブル (ユーザー ID の列とメッセージ数の列を持つ MESSAGE_COUNTS テーブルなど) に保存することです。メイン メッセージ テーブルが更新されたら、集計を再計算します。
ボトルネックをある場所から別の場所に移動するだけですが、負担の少ない場所に移動する可能性があります。
特定のテクノロジーに限定されない、いくつかの一般的な考え:
ユーザー ID でデータを分割します。アイデアは、ユーザー空間をほぼ同じサイズの個別のパーティションに均一に分割できるということです。適切なハッシュ関数を使用して、パーティション間でユーザーを分割できます。最終的に、各パーティションは別々のマシンに属します。ただし、同じマシン上の異なるテーブル/データベースであっても、これにより競合の一部が解消されます。パーティショニングは競合を制限し、将来の「線形」スケーリングへの扉を開きます。これは、負荷分散とスケールアウトにも役立ちます。
ハッシュ関数を選択してレコードを分割するときは、パーティションが追加/削除された場合に移動する必要があるレコードの数を最小限に抑えるものを探します。
他の多くのアプリケーションと同様に、サービスの使用はべき法則曲線に従うと想定できます。ほとんどのユーザー ページがトラフィックの大部分を引き起こし、その後にロング テールが続きます。キャッシングスキームはそれを利用できます。曲線が急勾配であるほど、キャッシュはより効果的になります。短いメッセージを考えると、各ページに 100 個のメッセージが表示され、各メッセージが平均 100 バイトである場合、1 GB の RAM キャッシュに約 100,000 のトップページを収めることができます。これらのキャッシュされたページは、データベースに遅延して書き込まれる可能性があります。1,000 万人のユーザーのうち、100,000 人が違いを生む球場にいます。
場合によっては同じハッシュ スキームを使用して、Web サーバーを分割します。これにより、競合することなく個別の RAM キャッシュを保持できます。潜在的な利点は、ユーザー数の増加に応じてキャッシュ サイズを増やすことです。
環境に適している場合、新しいメッセージが最終的にデータベースに書き込まれるようにする 1 つの方法は、メッセージを RAM キャッシュに配置した直後に永続メッセージ キューに配置することです。キューは競合せず、マシンの障害時にメッセージが失われないようにします。