シャーディングの落とし穴は、アプリケーションが照会するシャードを知る必要があることです。一般的に、これはクライアントのようなものでシャーディングすることによって行われます。古いブログ投稿の1つを、回答として使用するように調整します。
多くのクライアント向けのアプリケーションを構築する場合、データベースを設計する2つの一般的な方法があります。
- オプションA：すべてのクライアントを同じデータベースに配置する
- オプション2：クライアントごとに1つのデータベースを構築する
すべてのクライアントを同じデータベースに配置する
簡単です。スキーマの一番上にClientテーブルを追加し、ClientUsersテーブルを追加して、自分のデータのみが表示されるようにします。
このアプローチの利点：
より簡単なスキーマ管理。開発者がアプリケーションの新しいバージョンをデプロイする場合、1つのデータベースでスキーマを変更するだけで済みます。異なる顧客が同期しなくなったり、間違ったバージョンになったりする心配はありません。
簡単なパフォーマンスチューニング。インデックスの使用状況と統計を1か所で確認し、改善を簡単に実装し、すべてのクライアントですぐに効果を確認できます。数百または数千のデータベースでは、わずかな変更でも調整が困難な場合があります。プロシージャキャッシュの内容を確認し、アプリケーション全体でどのクエリまたはストアドプロシージャが最も集中しているのかを特定できますが、クライアントごとに個別のデータベースを使用している場合は、異なる実行プラン間でクエリの使用を集約するのが難しくなります。
外部APIを簡単に構築できます。製品を構築するために部外者にデータベース全体へのアクセスを許可する必要がある場合、すべてのデータが単一のデータベースにあれば簡単にできます。APIが複数のサーバー上の複数のデータベースからのデータのグループ化を処理する必要がある場合、開発およびテスト時間が追加されます。（一方、「複数のサーバー」ということは、1つのデータベースからすべてのルールに至るシナリオの制限を示唆し始めます。1つのデータベースは通常、負荷が1つのデータベースサーバーのみに影響することを意味します。） 、PowerBIを使用すると、全員を1つのデータベースに入れると、接続の管理がはるかに簡単になります。
より簡単な高可用性と災害復旧。心配する必要があるのが1つのデータベースだけであれば、データベースミラーリング、ログ配布、レプリケーション、およびクラスタリングを管理するのは本当に簡単です。インフラストラクチャを迅速に構築できます。
各クライアントを独自のデータベースまたはシャードに入れる
まだクライアントのリストが必要ですが、今ではディレクトリになります-各クライアントについて、それが存在するシャードも追跡します。起動時に、アプリはこのテーブルをクエリし、RAMにキャッシュします。クライアントのデータが必要な場合、そのシャード（データベースとサーバー）に直接接続します。
このアプローチの利点：
簡単な単一クライアントの復元。クライアントは信頼できないミートバッグです。（私のものを除いて、信頼できるミートバッグです。）あらゆる種類の「おっと」瞬間があるので、すべてのデータを特定の時点に戻したいのです。同じテーブル内の他のクライアントデータ。単一クライアントデータベースのシナリオでの復元は非常に簡単です。クライアントのデータベースを復元するだけです。誰も影響を受けません。
より簡単なデータのエクスポート。クライアントは、データを手に入れるのが大好きです。彼らは、恐ろしいベンダーのロックインシナリオを回避し、いつでも自分のデータを取り出すことができることを知り、独自のレポートを作成したいというセキュリティを求めています。各クライアントのデータが独自のデータベースに分離されているため、単純に独自のデータベースバックアップのコピーを提供できます。データエクスポートAPIを作成する必要はありません。
より簡単なマルチサーバースケーラビリティ。アプリケーションが単一のサーバーから得られる以上のパワーを必要とする場合、複数のサーバー間でデータベースを分割できます。また、地理的に負荷を分散し、アジアまたはヨーロッパのサーバーをクライアントに近づけることもできます。
クライアントごとのパフォーマンスチューニングが容易になりました。一部のクライアントが異なる機能またはレポートを使用する場合、全員のデータサイズを増大させることなく、それらのクライアント専用のインデックスまたはインデックス付きビューの特別なセットを構築できます。確かに、ここにはいくつかのリスクがあります。クライアント間でスキーマの違いを許容することにより、コードの展開を少し危険にしただけで、パフォーマンス管理をより難しくしました。
より簡単なセキュリティ管理。データベースごとに1人のユーザーでセキュリティを適切にロックダウンしている限り、クライアントXがクライアントYのデータにアクセスすることを心配する必要はありません。ただし、すべてのユーザーに対して単一のログインを使用する場合は、この懸念に実際には対処していません。
より簡単なメンテナンスウィンドウ。 顧客が世界中に散在しているグローバル環境では、グループまたはゾーンで行うことができれば、保守のために顧客をオフラインにする方が簡単です。
どちらがあなたに合っていますか？
正しい選択は1つではありません。自社の長所と短所を知る必要があります。2つのクライアントを例としてみましょう。
A社は、ハードウェアパフォーマンスの調整に優れています。彼らは本当に、ハードウェアのパフォーマンスの最後のビットを絞り出すのが得意であり、12〜18か月のサイクルでSQL Serverハードウェアを交換することを気にしません。（4〜6か月ごとにWebサーバーを更新します！）彼らのアキレス腱は、極端なコンプライアンスとセキュリティ要件です。監査のニーズは非常に高く、数十台のサーバー上の数千のデータベースでこれらの要件を管理するよりも、単一のサーバー、単一のデータベースに防弾制御を実装する方が簡単です。1つのデータベース、1つのサーバー、多くのクライアントを選択しました。
会社2は開発プラクティスに優れています。数千のデータベースにまたがるスキーマの変更とコードの展開を管理することは、それらの問題ではありません。彼らは世界中にクライアントを持ち、それらのクライアントのクレジットカード取引を24時間処理しています。地理的に負荷を分散する機能が必要であり、世界中のサーバーを12〜18か月ごとに交換したくない。クライアントごとに1つのデータベースを選択し、オフショアクライアント用にSQL Serverをアジアとヨーロッパに導入し始めたため、成果を上げています。