この方法では、シャードキーに対して数式（ハッシュ関数）を使用してデータを割り当てます。たとえば、システムはユーザー ID を 4 で割った余り（mod 4）を計算し、4 台のサーバーのうちどれに割り当てるかを決定します。

ハッシュ関数はデータを一貫して分散させるのに役立ちますが、シャードキーのカーディナリティが高く、頻度の偏りが少ない場合にのみ、均等な分散が保証されます。たとえば、「姓」など、共通の値を持つキーを選び、「Smith」が「Pyne」より 1,000 倍多く存在する場合、ハッシュ関数はすべての「Smith」レコードを同じシャードに送ります。これにより、数式を使っても「ホットシャード」が発生することになります。

また、この方法では、数式が変更されるため、新しいサーバーを追加することも困難です。多くの場合、「再シャーディング」または新しいサーバー クラスタへのデータの移動が必要になります。

データは値の範囲に基づいて割り当てられます。たとえば、ユーザー ID 1 ～ 1,000 をサーバー A に、1,001 ～ 2,000 をサーバー B に配置するといった方法です。この方法は非常に直感的で、連続したデータを読み取る必要があるクエリ（範囲クエリ）に適しています。ただし、欠点として「ホットスポット」が発生する可能性があります。たとえば、新規ユーザーがすべてサーバー B に割り当てられると、そのサーバーがすべての処理を担当し、サーバー A はアイドル状態になってしまいます。

この手法では、どのシャードにどのデータが保持されているかを正確に追跡するルックアップ テーブル（ディレクトリ）を使用します。数式を変更せずにシャード間でデータを移動できるため、最も高い柔軟性を実現できます。しかし、このルックアップ テーブルがボトルネックになります。すべてのクエリで最初にディレクトリを参照する必要があるため、レイテンシが発生します。また、ディレクトリに障害が発生すると、データベース全体にアクセスできなくなります。

ジオ シャーディングとは、ユーザーの所在地に基づいて、データを特定のサーバーに割り当てる手法です。たとえば、フランスのユーザーのデータは EU のサーバーに保存され、米国のユーザーのデータは北米のサーバーに保存されます。これにより、ユーザーのレイテンシ（待ち時間）が大幅に短縮されるとともに、企業が GDPR などのデータ所在地に関する法律の遵守にも役立ちます。

機能的パーティショニングとも呼ばれるこの方法では、行単位ではなく機能単位でデータを分割します。たとえば、「ユーザー プロフィール」関連のすべてのテーブルをサーバー A に配置し、「写真アップロード」関連のすべてのテーブルをサーバー B に配置するといった方法です。この方法ではデータを論理的に整理できますが、実質的にはマイクロサービス型のデータ アーキテクチャと同様の構成になります。そのため、特定の機能（写真など）が単一サーバーでは処理しきれないほど大規模に成長した場合には、問題の解決にはなりません。

シャーディングは、データの断片を完全に異なるサーバー間に分散する、水平パーティショニングの一種です。これにより、異なるサーバーが同時に書き込みを処理できるため、ハードウェアの容量制限（ストレージ）と書き込みスループットのボトルネックの両方を解消できます。

• 手動シャーディング: 手動シャーディング環境では、デベロッパーまたはデータベース管理者が、シャードキーの定義、各シャードのインフラストラクチャの作成、クエリをルーティングするロジックの記述を担当します。これにより、データの保存場所をきめ細かく制御できます。しかし、その分、メンテナンスの負担は大きくなります。特定のシャードが大きくなりすぎた場合は、手動でデータを「再シャーディング」する必要があります。これには、アプリケーションのダウンタイムを最小限に抑えながら、数百万行のデータを新しいサーバーへ移動させる作業が伴います。
• 自動シャーディング: 自動シャーディングは、Bigtable などの NoSQL データベースや Spanner などの分散 SQL データベースで一般的に採用され、データとトラフィックの分散を自動的に処理します。システムは、各サーバーのデータサイズと負荷をモニタリングします。特定のシャードが「ホットスポット」になったり、大きくなりすぎたりすると、データベース エンジンが自動的にシャードを分割し、より負荷の少ないサーバーにデータを移動します。これにより、チームの運用負担が軽減され、アプリケーションのスケーリングに伴って一貫したパフォーマンスを維持しやすくなります。

パーティショニングとは、大きなテーブルをより管理しやすい小さな単位に分割すること（ログテーブルを月ごとに分割するなど）ですが、分割したものは同じサーバー インスタンス上に保持されます。これにより、テーブルの他の部分に影響を与えることなく、古いデータをアーカイブまたは削除しやすくなるため、ストレージの問題を解決できます。ただし、サーバー自体の問題を解決するものではありません。すべてのパーティションが依然として単一のマシン上に存在するため、同じ CPU と RAM を共有し続けます。そのため、サーバーがパフォーマンスの上限に達した場合、パーティショニングでは対処できません。

レプリケーションとは、データベース全体を複数のサーバーにコピーするプロセスです。これは読み取りの可用性を高めるには有効な手法で、あるサーバーが故障しても、別のサーバーが処理を引き継ぐことができます。ただし、書き込まれたすべてのデータがすべてのレプリカにコピーされる必要があり、書き込み速度は単一のマシンの容量に制限されるため、書き込みスケーリングには効果が見込めません。

さらに重要な点として、ほとんどのレプリケーション モデルでは、一度に許可される「ライター」（プライマリ ノード）は 1 つだけです。複数のサーバーが同時に書き込みを許可しようとすると、2 つのサーバーが同じレコードを異なる情報で更新しようとする書き込み競合が発生するリスクがあります。これらの競合を解決することは技術的に難しく、高度な分散システムで処理されない場合、データ損失や不整合につながる可能性があります。

Spanner などの分散データベースを利用すると、手作業による負荷を伴わずにシャーディングのメリットが得られます。これらのシステムは、最初から複数のマシンで構成されるクラスター上で動作するように設計されています。データ分散、リバランス、レプリケーションを透過的に自動処理します。これらの中には、複数のライター（書き込みノード）を持ち、書き込みの競合を自動的に処理するシステムもあります。これにより、従来のリレーショナル データベースの一貫性を維持しながら、水平スケーリングを実現できます。