読み取りレートだけでなく、挿入レートと更新レートが非常に高いテーブルがあります。平均して、1秒あたり約100行が挿入および更新されます。そして、1秒あたり約1000の選択があります。
テーブルには約1億のタプルがあります。リレーションシップテーブルなので、フィールドは5つ程度です。3つのフィールドにはキーが含まれているため、インデックスが作成されます。すべてのフィールドは整数です。
データをシャーディングすることを考えていますが、複雑さが増しますが、速度は向上します。もう1つの方法は、innodbを使用することです。
データベースは、256GBssdのRAID1で実行され、32GB 1600mhzのRAMと、4Ghzにクロックオーバーされたi73770kが搭載されています。
データベースはピーク時に絶えずフリーズします。この場合、クエリは200行が挿入または更新され、1秒あたり2500行が選択されます。
私がすべきことを指摘していただけませんか。
シャーディングは通常、テーブル サイズを分散するのに適しています。負荷の問題は、通常、複製されたデータ環境で対処する必要があります。あなたの問題は、a) 巨大なテーブル、b) テーブル レベルのロック、c) 安っぽいハードウェアです。
テーブルのキーの 1 つを主キーとして使用できる場合は、InnoDB が適している可能性があります。行レベルのロックを実行できるため、クエリが相互に待機するのを減らすことができるからです。テーブルをテスト サーバーにレプリケートし、テーブルに対してすべてのクエリを試して、パフォーマンスの利点を確認することをお勧めします。InnoDB は MyISAM よりもリソース消費率が高いため、その点に注意してください。
申し訳ありませんが、あなたのハードウェアはあなたが必要とするパフォーマンスに対してくだらないものです。Twitter は 2.6k QPS で 1 秒あたり 34 回の書き込みを行います。Twitter のボリュームを上げて、強化されたゲーム用デスクトップがそれを削減すると考えることはできません。いくつかの SSD ドライブを備えた 15,000 ドルの Dell を購入すると、100,000 QPS をバーストすることができます。あなたは今、大きな時代にいます。スタートアップ ギアを捨てて、素敵なサーバーを手に入れる時が来ました。シャードしたくありません。ハードウェアをアップグレードする方が安くなりますし、率直に言って、アップグレードする必要があります。
シャーディングは、大きなテーブルを分割するのに最適です。以上です。
悪いことをはっきりさせてください。シャード アーキテクチャの開発は最悪です。シャードしないようにできる限りのことをしたい。ハードウェアをアップグレードし、複数のサーバーを購入してレプリケーションをセットアップし、コードを最適化しますが、念のためシャードは行わないでください。シャーディングのパフォーマンス ラインをはるかに下回っています。プッシュが 30k+ QPS を維持した場合、シャーディングについて話します。その日まで、NO.
16 コアで 5 TB の Fusion IO と 256 GB の RAM を備えた中規模サーバー ($30,000 の Dell PowerEdge) を購入すると、彼は 200,000 QPS まであなたを連れて行ってくれます。
しかし、あなたが私の言うことを聞くことを拒否し、とにかくシャードするつもりなら、あなたがしなければならないことはここにあります.
シャード化したら、複数のシャードからデータにアクセスする必要はありません。クエリをできるだけ同じシャードに保持するパーティション ルールを選択する必要があります。クエリの分散 (ルール 4) は、分散データ環境では非常に苦痛です。
コードはすべてのシャードにアクセスできる必要があります。パーティション ルールに基づいてシャード マップを作成し、必要なデータを取得するためにどこに行けばよいかをコードに知らせます。
どのシャードに移動するかを手動で決定する必要はありません。あなたのためにそれを行うラッパーを書いてください。コードを書いているときは、将来自分自身に感謝するでしょう。
最終的には、パフォーマンスを最適に保つためにシャードのバランスを取る必要があります。事前にこれを計画し、シャードのバランスを取る kron ジョブを意図してコードを記述します。
必然的に、ルール 1 を破る必要があります。その場合、複数のシャードからデータを取得して 1 か所に集約 (持ち込み) できるクエリ ラッパーが必要になります。シャードが多いほど、マルチスレッド化が必要になる可能性が高くなります。私のショップでは、これを分散クエリ (つまり、複数のシャードで実行されるクエリ) と呼んでいます。
悪いニュース: 分散クエリを実行して結果を集計するためのコードはありません。Apache Hadoop は試みますが、ひどいものです。HiveDB も同様です。優れたクエリ ディストリビューターは、設計、作成、最適化が困難です。これは、年間数十億ドル規模の企業が直面している問題です。たわごとはありませんが、並べ替え + 制限句と適切なスケーリングをサポートするシャード全体にクエリを分散するための優れたラッパーを思いついたら、一晩で億万長者になることができます. 300万で売ってんの？ドアの外に1マイルの長さの列ができます。
ここで私が言いたいのは、シャーディングは難しく、コストがかかるということです。それには多くの作業が必要であり、シャードしないように人間が可能な限りのことをしたいと考えています。やむを得ない場合は、ルールに従ってください。