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