データベースシャーディング戦略

Question

構築中のオンラインマーケットプレイス製品では、データベースシャーディングソリューションを実装する必要があります。私はシャーディングが初めてで、このフォーラムの記事を読んだ後に、ビジネスエンティティを使ったディレクトリベースのシャーディング戦略が適していると感じています。しかし、私は、このような断片化されたソリューションで採用する非正規化とデータ同期のベストプラクティスについてはまだ明確ではありません。 3つのコアエンティティ、サプライヤ、顧客、および注文があります。私は、注文データの処理の大部分がサプライヤの管理者によって実行されるため、サプライヤIDに基づいてデータベースを破棄することを計画しています。これにより、サプライヤの注文が1つのdbインスタンスからフェッチされ、クロスdbフェッチが排除されます。しかし、この場合、顧客が注文情報を見ると、そのデータは複数のDBインスタンスに存在し、複数のデータベースフェッチが必要になります。そのようなシナリオが分割されたソリューションに現れたときに通常行われる処理。

Answer 1

シャーディングを必要としない可能性が99.9％あると思います。

場合は、シャーディングを必要とする：あなたのデータベースの挿入/更新速度が近くにある、または超えている、あなたはコスト効率ができますが、すでに耕作されている購入し、

最高スペックのサーバーの容量

• など、あなたの読取り問合せ、レポート作成、バックアップの最も上の読み取り専用で複製する奴隷
• からあなたのマスターサーバーから任意の非必須または無関係更新重いワークロードを移動するための機能分割を行っている

上記の3つすべてに「はい」と明言できない場合は、断片化する必要はありません。

読む

http://www.mysqlperformanceblog.com/2009/08/06/why-you-dont-want-to-shard/

Answer 2

データベースシャーディングは、データベースのサイズが複数のTBようになる前であっても、非常に有効であることができます。私たちの主な理由は、メモリ/ CPUとディスクの比率が著しく変化し、MySQLなどのDBMS製品が最近使用されたインデックスとデータをメモリに格納する上で非常に優れているためです。

データシャーディングの問題については、この手法が役立ちます。

パラレルクエリ（「Go Fish」クエリと呼ぶ）。このアイデアを使用すると、複数のシャードから顧客注文を同時に照会し、結果を統合することができます。それが正しく行われれば、これは非常に効率的になります。

一般的なルックアップテーブルに対してグローバルテーブルレプリケーションを頻繁にお勧めしますが、カスタマーオーダーと同じようにアクティブなものはあまり役に立ちません。

いずれの場合でも、シャーディングは非常に費用対効果の高い方法で実装することができ、書き込みのために線形にスケーリングすることができます。

Answer 3

また、あなたはまた、あなたはまた、複数のスレーブとマスタースレーブレプリケーションに見ることができ、高速アクセス

のためにデータをキャッシュするようにmemcacheを使用することができ、そのようなMongoDBのかカサンドラ

としてのNoSQLのDBを試してみたいことがあります。