私たちは Facebook アプリケーションを作成し、多くのバイラル性を獲得しました。問題は、データベースが完全にいっぱいになり始めたことです (一部のテーブルには現在 2,500 万行以上あります)。何千もの書き込みのキューがあったため、アプリが機能しなくなったところまで来ました。
このアプリを迅速にスケーリングするためのソリューションを実装する必要がありますが、それぞれの長所と短所がわからないため、シャーディングまたはクラスタリングを追求する必要があるかどうかわかりません。また、パーティション/レプリケーションを行うことを考えていました。アプローチですが、書き込みに負荷がかかっている場合、それは役に立たないと思いますか?
2,500 万行は、適切に構築されたリレーショナル データベースにとって完全に妥当なサイズです。ただし、覚えておくべきことは、インデックスが多いほど (そしてそれらがより包括的であるほど)、書き込みが遅くなるということです。インデックスは、書き込み速度を犠牲にしてクエリのパフォーマンスを向上させるように設計されています。インデックスが過剰に作成されていないことを確認してください。
このデータベースを動かしているハードウェアの種類は何ですか? RAM は足りていますか？これらの属性を変更する方が、複雑な RDBMS ロード バランシング手法を実装しようとするよりもはるかに簡単です。特に、時間に追われている場合はそうです。
それを理解するには、MySQL がクラスタリングを処理する方法を理解する必要があります。それには主に2つの方法があります。マスター マスター レプリケーション、または NDB (ネットワーク データベース) クラスタリングのいずれかを実行できます。
両方のマスターが発行されたすべての書き込みを再生する必要があるため、マスター間のレプリケーションは書き込み負荷には役立ちません (そのため、何も得られません)。
NDB クラスタリングは、主にプライマリ キー ルックアップを実行している場合にのみ、非常にうまく機能します (PK ルックアップを使用する場合のみ、NDB は通常のマスター マスター セットアップよりも効率的に動作するため)。すべてのデータは、多数のサーバー間で自動的に分割されます。私が言ったように、クエリの大部分が PK ルックアップにすぎない場合にのみ、これを検討します。
つまり、あと 2 つのオプションが残ります。シャーディングと MySQL からの移行。
シャーディングは、このような状況を処理するための適切なオプションです。ただし、シャーディングを最大限に活用するには、アプリケーションがシャーディングを完全に認識している必要があります。そのため、データベースにアクセスするコードをすべて書き直して、クエリごとに通信する適切なサーバーを選択する必要があります。また、システムの現在のセットアップ方法によっては、効果的にシャーディングできない場合があります...
しかし、あなたのニーズに最も適していると思われる別のオプションは、MySQL から切り替えることです。とにかく DB アクセス コードを書き直す必要があるため、NoSQL データベースに切り替えるのはそれほど難しくありません (これも、現在の設定によって異なります)。世の中にはたくさんの NoSQL サーバーがありますが、私はMongoDBが好きです。書き込み負荷に心配なく耐えられるはずです。それを適切に使用するには（データ量で）64ビットサーバーが本当に必要であることに注意してください。
レプリケーションは、パフォーマンスのためではなく、データのバックアップのためのものであるため、問題外です。
まあ、8GB の RAM はまだそれほど多くはありませんが、非常に大きなハードディスク容量を備えた数百 GB の RAM を持つことができ、MySQL は引き続き機能します。
クラスタリング/シャーディング/パーティショニングは、単一ノードがそのハードウェアが負荷に耐えられないポイントに達したときに発生します。しかし、ハードウェアにはまだ拡張する余地があります。
ハードウェアをアップグレードしたくない場合は、上記のオプションを深く検討できるように、データベースの設計と結合が多いかどうかについての詳細情報を提供する必要があります。