私の実稼働環境では、1時間に最大20,000のクエリを処理する16ギガのメモリで実行されているMySQLサーバーの単一のインスタンスがあります。私のテーブルの1つのサイズは、月に200万の割合で増加しています。これらの数値はどちらも時間の経過とともに増加すると予想されますが、アーキテクチャをいつ改善する必要があるかはわかりません。
どうすれば状況に積極的に取り組み、将来にわたってシステムを保証できるでしょうか。
ハードウェアをアップグレードすることは、時間と資本効率の点で多くを購入しますか？
この場合、トラフィックを3か月ごとに2倍にすると、シャーディングは自然な進行になるので、一般的な方法は何でしょうか。または他の選択肢はありますか？
システムがピークに達しているかどうかを確認するにはどうすればよいですか？データベースのプロファイリングに使用できるツールにはどのようなものがありますか？そして、それを測定するために使用するメトリックは何ですか？
スケーラビリティに関するこのような膨大な質問に答えるのは非常に困難です。
まず、指数関数的成長を計画しているように見えるため、単一のマシンでのハードウェアのアップグレードは長期的ではなく、短期的でもありません（3か月ごとのx2は大きく、1か月あたり200万行から始まります）。したがって、分散型のスケーラブルなハードウェアアーキテクチャを見つける必要があります。
次に、2つの基本的なオプションが思い浮かびます。
増え続けるテーブルのSQLストレージに固執する場合は、クラスタリングとレプリケーションのどちらかを選択する必要があります。後者は、私の観点からは前者よりも費用効果が高く、高速であることがよくありますが、解決するのは少し難しいです。
ここでは、高度なMySQLレプリケーション手法に関する非常に興味深い論文を見つけることができます。
次に、前述のように、パーティショニングまたはそれ以上のシャーディングから始めることができます。
一部のMySQL製品は自動シャーディングクラスターを提供しているように見えることに注意してください。
もう1つのオプションは、明らかに、モンスターテーブルでNoSQLテクノロジーを使用することを想定することです。分散型Key-Valueストレージシステムは、スケーラビリティの点でほとんどコストがかからず、せいぜい線形であることを意味します。
もう1つのポイントは、キー値がよく知られているMemcachedなどの分散キャッシュで適切に機能するため、ほとんどの言語でAPIを使用してセットアップし、非常に低コストで非常に優れたパフォーマンスを実現できることです。