シャーディングとは何ですか、なぜそれが重要なのですか？
シャーディングは、スライスしたデータ（シャード）を、コンテキストで意味のある扱いやすい集計に戻すことを理解していると思います。これは正しいです？
更新：私はここで苦労していると思います。私の意見では、アプリケーション層には、データを保存する場所を決定するビジネスがないはずです。せいぜい何らかの種類のシャードクライアントである必要があります。どちらの回答も、重要な側面である理由ではなく、何に答えました。明らかなパフォーマンスの向上以外にどのような影響がありますか？これらのゲインは、MVC違反を相殺するのに十分ですか？シャーディングは非常に大規模なアプリケーションで最も重要ですか、それとも小規模なアプリケーションに適用されますか？
シャーディングは、データベースの「水平分割」の単なる別名です。より明確にするために、その用語を検索することをお勧めします。
From Wikipedia ：
水平分割は、データベーステーブルの行を列ごとに分割するのではなく、個別に保持する設計原則です（正規化に関して）。各パーティションはシャードの一部を形成し、シャードは個別のデータベースサーバーまたは物理的な場所に配置される場合があります。利点は、各テーブルの行数が減少することです（これにより、インデックスサイズが減少し、検索パフォーマンスが向上します）。シャーディングがデータの実世界の側面に基づいている場合（たとえば、ヨーロッパの顧客とアメリカの顧客）、適切なシャードメンバーシップを簡単かつ自動的に推測し、関連するシャードのみを照会できる場合があります。
シャーディングに関する詳細情報：
まず、各データベースサーバーは同一であり、同じテーブル構造を持っています。第二に、データレコードは分割されたデータベースに論理的に分割されます。パーティションデータベースとは異なり、完全な各データレコードは1つのシャードにのみ存在し（バックアップ/冗長性のミラーリングがない限り）、すべてのCRUD操作はそのデータベースでのみ実行されます。使用されている用語は気に入らないかもしれませんが、これは論理データベースを小さな部分に編成する別の方法を表しています。
更新：MVCを壊すことはありません。データを保存する正しいシャードを決定する作業は、データアクセスレイヤーによって透過的に行われます。そこで、データベースのシャードに使用した基準に基づいて正しいシャードを決定する必要があります。 （アプリケーションの具体的な側面に基づいて、データベースをいくつかの異なるシャードに手動でシャードする必要があるため。）次に、適切なシャードを使用するために、データベースとの間でデータをロードおよび保存する際に注意する必要があります。
多分 この例 with Javaコードはそれをいくらか明確にします（ Hibernate Shards プロジェクトについて）、これが実際のシナリオでどのように機能するか。
「why sharding」に対処するには：lotsof dataの非常に大規模なアプリケーション専用です。まず、データベースクエリの応答時間を最小化するのに役立ちます。次に、1台の大きなサーバーではなく、より安価な「ローエンド」マシンを使用してデータをホストできます。
ローカリティが非常に制限されているDBMSへのクエリがある場合（たとえば、ユーザーが「where username = $ my_username」でのみselectを起動する場合）、AMで始まるすべてのユーザー名を1つのサーバーに配置し、すべてNZから取得することは理にかなっていますもう一方の。これにより、一部のクエリの線形スケーリングに近づきます。
Long story short：シャーディングは、基本的に両方に均等に負荷を分散させるために、異なるサーバーにテーブルを分散するプロセスです。
もちろん、実際にはもっと複雑です。 :)
シャーディングは、vertical（columnwiseとは対照的に、horizontal（rowwise）database partitioningです。 -））パーティション分割正規化。非常に大きなデータベースを、データシャードと呼ばれる、より小さく、より速く、より管理しやすい部分に分割します。分散システムを実現するメカニズムです。
なぜ分散システムが必要なのですか？
- 可用性が向上しました。
- より簡単な拡張。
- 経済性：単一の大型コンピューターの能力を備えた小型コンピューターのネットワークを作成する方が費用がかかりません。
詳細はこちらをご覧ください： Advantages of Distributed database
シャーディングは分散システムの実現にどのように役立ちますか？
検索インデックスをN個のパーティションに分割し、各インデックスを個別のサーバーにロードできます。 1つのサーバーを照会すると、結果の1/Nが得られます。したがって、完全な結果セットを取得するために、典型的な分散検索システムはaggregatorを使用します。これは各サーバーからの結果を蓄積し、それらを結合します。アグリゲーターは、各サーバーにクエリを配布します。このアグリゲータープログラムは、ビッグデータ用語では MapReduce と呼ばれます。言い換えれば、分散システム=シャーディング+ MapReduce（他にもあります）。
以下の視覚的表現。 
シャーディングは非常に大規模なアプリケーションで最も重要ですか、それとも小規模なアプリケーションに適用されますか？
シャーディングは、単一のデータベースサーバーで処理できる範囲を超えてニーズが拡大する場合にのみ懸念されます。シャーディング可能なデータがあり、非常に高いスケーラビリティとパフォーマンスの要件がある場合、これはスウェルツールです。私は12年間ずっとソフトウェアの専門家でしたが、シャーディングの恩恵を受けることができる状況に遭遇したと思います。それは非常に限られた適用性を持つ高度な技術です。
その上、将来はおそらく、パフォーマンスの潜在的な制限をすべて消去する巨大なオブジェクト「クラウド」のように、楽しくてエキサイティングなものになるでしょう。 :)
シャーディングは元々Googleのエンジニアによって作られたもので、Google App Engineでアプリケーションを作成するときにかなり使用されていることがわかります。クエリで使用できるリソースの量には厳しい制限があり、クエリ自体には厳しい制限があるため、シャーディングは推奨されるだけでなく、アーキテクチャによってほぼ強制されます。
シャーディングを使用できる別の場所は、データエンティティの競合を減らすことです。スケーラブルなシステムを構築する場合、それらは常にボトルネックであるため、頻繁に書き込まれるデータに注意することが特に重要です。適切な解決策は、その特定のエンティティを分割して複数のコピーに書き込み、合計を読み取ることです。 「シャードカウンターwrt GAEの例： http://code.google.com/appengine/articles/sharding_counters.html
シャーディングは、水平方向のパーティション分割以上のものを実行します。 wikipediaの記事 によると、
水平分割は、通常、スキーマとデータベースサーバーの単一インスタンス内で、1つ以上のテーブルを行ごとに分割します。最初にインデックスを検索する必要なく、特定の行がどのパーティションで見つかるかを特定するための明確で堅牢で暗黙的な方法があれば、インデックスサイズ（したがって検索の労力）を減らすことで利点があります。 「CustomersEast」テーブルと「CustomersWest」テーブルの例。郵便番号はすでにどこにあるかを示しています。
シャーディングはこれを超えます。問題のあるテーブルを同じ方法でパーティション化しますが、スキーマの複数のインスタンスに分割します。明らかな利点は、同じ論理サーバー上の複数のインデックスだけでなく、大きなパーティションテーブルの検索負荷を複数のサーバー（論理または物理）に分割できることです。
また、
分離された複数のインスタンスにシャードを分割するには、単純な水平分割以上のものが必要です。単純なディメンションテーブルを取得するためだけに、データベースのクエリで両方のインスタンスをクエリする必要がある場合、希望する効率の向上は失われます。分割を超えて、シャーディングは大きなパーティション化可能なテーブルをサーバー間で分割し、小さなテーブルは完全なユニットとして複製されます
私の意見では、アプリケーション層には、データを保存する場所を決定するビジネスはないはずです
これは良いルールですが、ほとんどの場合のように常に正しいとは限りません。
アーキテクチャを作成するときは、責任とコラボレーションから始めます。機能アーキテクチャを決定したら、非機能的な力のバランスを取る必要があります。
これらの非機能的な要因の1つが大規模な拡張性である場合、データストレージの抽象化がアプリケーション層に漏れることを意味する場合でも、アーキテクチャを適応させてこの要因に対応する必要があります。