データベースのI/Oとなる読み込みと更新が多い大規模なWebサイト（トラフィックが多い）の場合、パフォーマンスへの影響を軽減するにはどうすればよいでしょうか？私が考えることができる1つの解決策は、書き込み、キャッシュ、および遅延書き込み（別のジョブを使用）です。読んで、memcachedの概念を使用してください。他のより良いソリューション？大規模なWebサイトのデータベースI/Oボトルネックを軽減する最適な方法は何ですか？
クエリを最適化することを忘れないでください。ほとんどの場合、ディスクI/Oではなく、ボトルネックとなるクエリが記述されていません。
コンテンツがあまり頻繁に変更されない場合は、クエリ結果とWebページ全体をキャッシュすることもできます。
これは、使用パターンとデータタイプに大きく依存します。トランザクションがサポートされるかどうか、完全な一貫性や「最終的な一貫性」、データの大きさ（すべてが大容量のメモリに収まるかどうか）、データの複雑さクエリは、リストが続いていくかもしれません....多くの変数と、すべての制約/要件を列挙した後で、適切な決定を下すことができます。しかし二つの一般的なアドバイス：
（あなたは複雑な関係やトランザクションを使用する必要がない場合のみ）分散型「のNoSQL」（キー/値）アプローチと分散アーキテクチャを使用ここでは、データベースのパフォーマンスに最も一般的な解決策は以下のとおりです。
10年前に、標準答え照会 - 最適化のほかにあなたの特定のデータベースは、2つの方法でMySQLを使用してスケールアウトされました。
読み取りは、2つの方法でスケールアウトできます。第1の方法は、可能性のある矛盾を導入し、別個のキャッシュ層を作成するキャッシュのスルーです。また、読み込みレプリカを作成することで、MySQLでスケールを調整することができます。ここでは、どのデータベースでもクエリを実行できます。すべてのサーバーにすべての書き込みを適用する必要があるため、レプリケーションはスループットの書き込みに役立ちません。
書き込みはシャーディングによってスケーリングされます。たとえば、姓が 'a'のすべてのユーザーが特定のサーバーに割り当てられているとします。特定の行のプライマリIDがハッシュ関数を使用してハッシュされ、サーバープールの1つに配布される、より複雑なシャードアルゴリズムを想像してみましょう。
Facebookは、シャード化されたMySQLアーキテクチャの最も進んだ提案者の1人です。個々のテーブルを「参加」することはできますが、カスタムコードを書く必要があります。サーバーからサーバーに移動する必要があるかもしれないからです。あなたの友人のタイムライン投稿を取得したいと思っているだけで参加できません。アプリケーションコード。
データベースを断片化すると、結合を実行できなくなり、範囲の参照が難しくなります。このサブセットはCRUDオペレーションと呼ばれることもあるため、MySQLは過剰です。多くの中国のソーシャルネットワークはこれを認識して、Redis（これはMySQLよりもはるかに速い）を使用し、独自のシャード層とアプリケーションロジック層を作成しました。
シャーディングの次の問題を想像してください。新しいサーバーを追加し、その新しいサーバーにユーザーの割り当てを開始します。
もう1つのアプローチは、一般的にNoSQLまたはNewSQLという名前の下にあり、さまざまなアプローチを持つ分散データベースを使用することです。 MongoDBのように、このマッピングを管理するシャーディングシステムがありますが、手動でサーバーを追加する必要があります。 Cassandraは、コード化されたアーキテクチャと呼ばれるより柔軟なクラスタリング方式を採用しています。 CouchBaseやAerospikeのようなシステムでは、シャード層の必要性を排除するランダムな配布メカニズムを使用しています。これらのデータベースの中には、サーバー1台あたり1秒あたり10万〜20万件のリクエストを超えるものがあります。このようなクラスタリングのスタイルでは、より高いレベルの冗長性と信頼性を得ることができます。
他の分散型アプローチは、グラフデータベースのように、より効率的な方法でデータを表現します。グラフとして表現したほうが問題がある場合は、クラスタ化されたグラフデータベースが適切かもしれません。