LAMPを実行しているWebアプリがあります。最近、負荷が増加しており、現在、スケーリングするソリューションを検討しています。apacheのスケーリングは非常に簡単です。複数の複数のマシンでapacheをホストし、着信トラフィックをラウンドロビンします。
ただし、Apacheの各インスタンスはMySQLと通信し、最終的にMySQLはオーバーロードされます。このセットアップで複数のマシン間でMySQLをスケーリングするにはどうすればよいですか？これについてはすでに見てきましたが、具体的にはDBからの更新をすぐに利用できるようにする必要があるため、ここではレプリケーションが適切な戦略ではないと思いますか？また、これは最小限のコード変更で実行できることを願っています。
PS。読み取りと書き込みの比率は約1：1です。
レプリケーションとシャーディングの 2 つの戦略しかありません。レプリケーションは、書き込みトラフィックが少なく読み取りトラフィックが多い場合に頻繁に行われるため、読み取りを多くのスレーブにリダイレクトできますが、時間と不一致の可能性を伴う多くのレプリケーション トラフィックの落とし穴があります。
シャーディングを使用すると、データベース テーブルを複数のマシンにまたがってシャーディングし (ファンクショナル シャーディングと呼ばれます)、特に結合がはるかに難しくなります。これがうまくいかない場合は、複数のマシンで行を分割する必要もありますが、これは面白くなく、アプリケーションとデータベースの間に実装された分割レイヤーに依存します。
ドキュメント指向データベースまたは列ストアがこの作業を行いますが、現在のところ、OLTP ではなく OLAP 向けに最適化されています。
MySQL Performance Blogをご覧ください。何か便利なものが見つかるかもしれません。
ええと...これらすべての書き込みを実際の大規模にスケーリングしてください。データベース エンジンがボトルネックになり、ロックやバッファの管理などが多すぎます...
実際に機能することがわかった唯一の方法は、スケールアウト、シャーディングです。残念ながら、シャーディングはMySQLの「すぐに使える」ものではありません（Mongoなどの一部のNoSQLのように）。ScaleBase (免責事項: 私はそこで働いています) は、完全なスケールアウト ソリューション、つまり「自動シャーディング マシン」のメーカーです。ScaleBae は、データと SQL ストリームを分析し、DB ノード間でデータを分割し、コマンドをルーティングして実行時に結果を集計します。