データパーティション分割戦略を設計する

2025-06-21

このガイドでは、デプロイするデータベースとデータストレージテクノロジのデータパーティション分割戦略を設計するための推奨事項について説明します。この戦略は、データ資産の信頼性の向上に役立ちます。

多くの大規模なソリューションでは、 パーティション を使用してデータを分割し、個別に管理およびアクセスできるようにします。データをパーティション分割すると、スケーラビリティが向上し、競合が減少し、パフォーマンスが最適化されます。データのパーティション分割を実装して、使用パターンでデータを分割します。たとえば、古いデータを安価なデータストレージにアーカイブできます。パーティション分割戦略を慎重に選択して、利点を最大化し、悪影響を最小限に抑えます。

注

この記事では、 パーティション分割 という用語は、データを個別のデータストアに物理的に分割するプロセスを意味します。 SQL Server テーブルのパーティション分割とは異なります。

データは次のパーティションに分割できます。

拡張性の向上。 1 つのデータベースシステムをスケールアップすると、最終的にデータベースは物理ハードウェアの制限に達します。データを複数のパーティションに分割し、各パーティションを個別のサーバーでホストする場合は、ほぼ無期限にシステムをスケールアウトできます。
パフォーマンスを向上させます。 各パーティションでは、パーティション分割されていないデータと比較して、データアクセス操作が少量のデータに対して実行されます。システムの効率を高めるためにデータをパーティション分割します。複数のパーティションに影響を与える操作は、並列で実行できます。
セキュリティを強化します。 場合によっては、機密データと非センシティブデータを異なるパーティションに分割し、機密データに異なるセキュリティ制御を適用できます。
運用上の柔軟性を提供します。 データをパーティション分割して操作を微調整し、管理効率を最大化し、コストを最小限に抑えることができます。たとえば、各パーティション内のデータの重要性に基づいて、管理、監視、バックアップと復元、およびその他の管理タスクの戦略を定義できます。
データストアを使用パターンと一致させます。 各パーティションは、データストアが提供するコストと組み込み機能に基づいて、異なる種類のデータストアにデプロイできます。たとえば、大きなバイナリデータを BLOB ストレージに格納したり、構造化データをドキュメントデータベースに格納したりできます。詳細については、「データストアモデルについて」を参照してください。
可用性を向上させます。 単一障害点を回避するために、複数のサーバー間でデータを分離できます。 1 つのインスタンスが失敗した場合、そのパーティション内のデータのみが使用できなくなります。操作は他のパーティションでも続行されます。この考慮事項は、マネージドサービスとしてのプラットフォーム (PaaS) データストアには冗長性が組み込まれているため、関連性が低くなります。

適切なパーティション分割戦略を選択する

データのパーティション分割には、次の 3 つの一般的な方法があります。

水平パーティション分割 (シャー ディングと呼ばれることがよくあります)。この方法では、各パーティションは個別のデータストアですが、すべてのパーティションに同じスキーマがあります。各パーティションは シャード と呼ばれ、顧客注文のセットなど、データのサブセットを保持します。
垂直パーティション分割。 この戦略では、各パーティションは、データストア内の項目のフィールドのサブセットを保持します。フィールドは、使用パターンに応じて分割されます。たとえば、頻繁にアクセスされるフィールドは、1 つの垂直パーティションに配置され、アクセス頻度の低いフィールドが別のパーティションに配置される場合があります。
機能パーティション分割。 この戦略では、システム内の各境界コンテキストでデータがどのように使用されるかに従ってデータが集計されます。たとえば、eコマースシステムでは請求書データが 1 つのパーティションに格納され、製品在庫データが別のパーティションに格納される場合があります。

パーティション分割スキームを設計するときは、これらの戦略を組み合わせることを検討してください。たとえば、データをシャードに分割し、垂直パーティション分割を使用して、各シャード内のデータをさらに分割することができます。

水平パーティション分割 (シャーディング)

次の図は、水平方向のパーティション分割またはシャーディングの例を示しています。次の使用例は、プロダクトキーに基づくシャードに製品在庫データを分割します。各シャードは、アルファベット順に編成された連続したシャードキーの範囲 (A から G、H- Z) のデータを保持します。シャーディングを実行すると、負荷がより多くのコンピューターに分散され、競合が減り、パフォーマンスが向上します。

最も重要な要素は、選択したシャーディングキーです。システムの稼働後にキーを変更することは困難な場合があります。キーは、ワークロードをシャード全体にできるだけ均等に分散させるために、データがパーティション分割されていることを確認する必要があります。

シャードが同じサイズである必要はありません。要求の数のバランスを取る方が重要です。一部のシャードは大きくなる可能性がありますが、シャード内の各項目のアクセス操作の数は少なくなっています。他のシャードは小さい場合がありますが、シャード内の各項目にアクセスする頻度が高くなります。また、1 つのシャードがデータストアの容量と処理リソースのスケール制限を超えないようにすることも重要です。

パフォーマンスと可用性に影響する 可能性があるホット パーティションの作成は避けてください。たとえば、顧客の名前の最初の文字を使用すると、一部の文字が他の文字よりも一般的であるため、不均衡な分布が作成される可能性があります。代わりに、顧客識別子ハッシュを使用して、パーティション間でデータを均等に分散します。

大きなシャードを分割したり、小さなシャードを大きなパーティションに結合したり、スキーマを変更したりする必要が将来のニーズを最小限に抑えるシャーディングキーを選択します。これらの操作には時間がかかり、1 つ以上のシャードをオフラインにする必要がある場合があります。

シャードがレプリケートされる場合は、一部のレプリカをオンラインにしておき、他のレプリカは分割、マージ、再構成することができます。ただし、再構成中に実行できる操作がシステムによって制限される場合があります。たとえば、レプリカ内のデータは、データの不整合を防ぐために読み取り専用としてマークされる場合があります。

詳細については、「シャーディングパターン」を参照してください。

垂直パーティション分割

垂直パーティション分割の最も一般的な用途は、頻繁にアクセスされる項目のフェッチに関連する I/O とパフォーマンスのコストを削減することです。次の図は、垂直パーティション分割の例を示しています。この例では、項目のさまざまなプロパティが異なるパーティションに格納されます。 1 つのパーティションには、製品名、説明、価格など、より頻繁にアクセスされるデータが保持されます。別のパーティションには、在庫数や最後の注文日など、在庫データが保持されます。

この例では、アプリケーションは、製品の詳細を顧客に表示するときに、製品名、説明、および価格を定期的に照会します。これらの 2 つの項目は一般的に一緒に使用されるため、在庫数と最終注文日は個別のパーティション内にあります。

垂直パーティション分割の次の利点を参照してください。

比較的動きの遅いデータ (製品名、説明、価格) を、より動的なデータ (在庫レベルと最後の注文日) から分離できます。データの移動速度が遅い場合は、アプリケーションをメモリにキャッシュすることをお勧めします。
セキュリティコントロールを追加して、機密データを別のパーティションに格納できます。
垂直方向のパーティション分割により、必要な同時アクセスの量を減らすことができます。

垂直パーティション分割は、データストア内のエンティティレベルで動作し、エンティティを部分的に正規化して 、幅の広い 項目から狭い項目のセットに分割します。これは、HBase や Cassandra などの列指向データストアに最適です。列のコレクション内のデータが変更される可能性が低い場合は、SQL Server で列ストアを使用することを検討してください。

機能的パーティション分割

アプリケーション内の個別のビジネス領域ごとに境界付きコンテキストを識別できる場合、機能パーティション分割によって分離とデータアクセスのパフォーマンスが向上する可能性があります。機能パーティション分割のもう 1 つの一般的な用途は、読み取り/書き込みデータと読み取り専用データを分離することです。次の図は、在庫データが顧客データから分離された機能パーティション分割の概要を示しています。

このパーティション分割戦略は、システムのさまざまな部分でデータアクセスの競合を減らすのに役立ちます。

スケーラビリティのためのパーティションの設計

各パーティションのサイズとワークロードを考慮することが重要です。データが分散されるようにバランスを取り、最大限のスケーラビリティを実現します。ただし、1 つのパーティションストアのスケーリング制限を超えないように、データをパーティション分割する必要もあります。

スケーラビリティのためにパーティションを設計する場合は、次の手順に従います。

アプリケーションを分析して、各クエリが返す結果セットのサイズ、アクセスの頻度、固有の待機時間、サーバー側のコンピューティング処理要件など、データアクセスパターンを理解します。多くの場合、いくつかの主要なエンティティは、ほとんどの処理リソースを必要とします。
この分析を使用して、現在および将来のスケーラビリティターゲット (データサイズやワークロードなど) を決定します。次に、スケーラビリティターゲットを満たすために、パーティション間でデータを分散します。水平パーティション分割の場合は、適切なシャードキーを選択して均等な分散を確保します。詳細については、「シャーディングパターン」を参照してください。
各パーティションに、データサイズとスループットの観点からスケーラビリティ要件を処理するための十分なリソースがあることを確認します。データストアによっては、ストレージ領域、処理能力、またはネットワーク帯域幅の量に関して、パーティションごとに制限が存在する場合があります。要件がこれらの制限を超える可能性がある場合は、パーティション分割戦略を調整するか、データをさらに分割する必要があります。 2 つ以上の戦略を組み合わせる必要がある場合があります。
システムを監視して、データが想定どおりに分散されていること、およびパーティションが負荷を処理できることを確認します。実際の使用状況は、分析の予測と常に一致するとは限りません。必要な残高を得るために、パーティションの再調整やシステムの一部の再設計が必要になる場合があります。

一部のクラウド環境では、インフラストラクチャの境界に基づいてリソースが割り当てられます。選択した境界の制限によって、データボリューム、データストレージ、処理能力、帯域幅の予想される増加に十分な余裕があることを確認します。

たとえば、Azure Table Storage を使用する場合、1 つのパーティションが特定の期間に処理できる要求の量に制限があります。詳細については、「 Standard ストレージアカウントのスケーラビリティとパフォーマンスのターゲット」を参照してください。ビジー状態のシャードでは、1 つのパーティションで処理できるリソースよりも多くのリソースが必要になる場合があります。負荷を分散するには、シャードを再パーティション分割する必要がある場合があります。これらのテーブルの合計サイズまたはスループットがストレージアカウントの容量を超える場合は、より多くのストレージアカウントを作成し、これらのアカウントにテーブルを分散することが必要になる場合があります。

クエリパフォーマンスのためのパーティションの設計

小さなデータセットを使用し、並列クエリを実行することで、クエリのパフォーマンスを向上させることができます。各パーティションには、データセット全体のごく一部を含める必要があります。この量の減少により、クエリのパフォーマンスが向上する可能性があります。ただし、パーティション分割は、適切なデータベースの設計と構成の代わりではありません。必要なインデックスを実装していることを確認します。

クエリパフォーマンス用にパーティションを設計する場合は、次の手順に従います。

アプリケーションの要件とパフォーマンスを確認します。
- ビジネス要件を使用して、常に迅速に実行する必要がある重要なクエリを決定します。
- システムを監視して、実行速度が遅いクエリを特定します。
- 最も頻繁に実行されるクエリを決定します。 1 つのクエリに最小限のコストがある場合でも、累積リソース消費量は大きくなる可能性があります。
パフォーマンスの低下の原因となっているデータをパーティション分割します。
- クエリの応答時間がターゲット内になるように、各パーティションのサイズを制限します。
- 水平パーティション分割を使用する場合は、アプリケーションが適切なパーティションを簡単に選択できるようにシャードキーを設計します。この仕様により、クエリですべてのパーティションがスキャンされなくなります。
- パーティションの場所を考えてみましょう。アプリケーションとアクセスするユーザーに地理的に近いパーティションにデータを保持してみてください。
エンティティにスループットとクエリのパフォーマンス要件がある場合は、そのエンティティに基づく機能パーティション分割を使用します。この割り当てがまだ要件を満たしていない場合は、水平パーティション分割を追加できます。通常、1 つのパーティション分割戦略で十分ですが、場合によっては、両方の戦略を組み合わせる方が効率的です。
パフォーマンスを向上させるために、パーティション間でクエリを並列で実行します。

可用性のためのパーティションの設計

データをパーティション分割して、アプリケーションの可用性を向上させます。パーティション分割により、データセット全体に単一障害点がないようにし、データセットの個々のサブセットを個別に管理できます。

可用性に影響を与える次の要因を考慮してください。

データの重要度を判断します。 トランザクションなどの重要なビジネスデータと、ログファイルなどの重要度の低い運用データを特定します。

高可用性パーティションに重要なデータを格納し、適切なバックアップ計画を作成します。
データセットごとに個別の管理手順と監視手順を確立します。
同じパーティションに同じレベルの重要度を持つデータを配置して、同じ頻度でバックアップできるようにします。たとえば、ログ情報やトレース情報を保持するパーティションよりも、トランザクションデータを保持するパーティションのバックアップが必要になる場合があります。

個々のパーティションを管理します。 独立した管理とメンテナンスをサポートするようにパーティションを設計します。この方法には、次のようないくつかの利点があります。

パーティションが失敗した場合は、他のパーティションのデータにアクセスするアプリケーションを使用せずに、パーティションを個別に復旧できます。
地理的領域でデータをパーティション分割すると、各場所のピーク時以外にスケジュールされたメンテナンスタスクを実行できます。パーティションが大きくないので、この期間中に計画メンテナンスが完了しないようにします。

パーティション間で重要なデータをレプリケートします。 この戦略により、可用性とパフォーマンスが向上しますが、整合性の問題が発生する可能性もあります。変更をすべてのレプリカと同期するには時間がかかります。同期中、パーティションごとに異なるデータ値が含まれます。

パーティションを使用するようにアプリケーションコードを最適化する

パーティション分割により、システムの設計と開発が複雑になります。システムに最初に 1 つのパーティションのみが含まれている場合でも、システム設計の基本的な部分としてデータをパーティション分割します。パーティション分割に後から対処する場合は、保守するライブシステムが既に存在するため、困難です。あなたは次のことを考慮するかもしれません。

データアクセスロジックを変更する必要があります。
パーティション間で分散するには、大量の既存のデータを移行する必要があります。
ユーザーは移行中もシステムを引き続き使用することを期待しているため、問題が発生します。

場合によっては、初期データセットが小さく、1 台のサーバーで簡単に処理できるため、パーティション分割は重要ではありません。一部のワークロードはパーティションなしで実行できますが、多くの商用システムでは、ユーザーの数が増えるにつれて拡張する必要があります。

一部の小さなデータストアでは、パーティション分割の利点もあります。たとえば、数百の同時実行クライアントが小さなデータストアにアクセスする場合があります。このような状況でデータをパーティション分割すると、競合を減らし、スループットを向上させることができます。

データパーティション分割スキームを設計するときは、次の点を考慮してください。

パーティション間のデータアクセス操作を最小限に抑えます。 パーティション間のデータアクセス操作を最小限に抑えるために、最も一般的なデータベース操作のデータをパーティション内に保持します。 1 つのパーティション内でクエリを実行するのではなく、パーティション間でクエリを実行する方が時間がかかる場合があります。ただし、1 つのクエリセットのパーティションを最適化すると、他のクエリセットに悪影響を及ぼす可能性があります。パーティション間でクエリを実行する必要がある場合は、並列クエリを実行し、アプリケーション内で結果を集計することで、クエリ時間を最小限に抑えます。あるクエリの結果が次のクエリで使用されている場合など、この方法を使用できない場合があります。

静的参照データをレプリケートします。 郵便番号テーブルや製品リストなどの比較的静的な参照データをクエリで使用する場合は、すべてのパーティションでこのデータをレプリケートして、異なるパーティションでの個別の参照操作を減らすことを検討してください。この方法では、システム全体からのトラフィックが多い ホット データセットになる参照データの可能性を減らすこともできます。参照データへの変更の同期には、追加のコストがかかります。

パーティション間の結合を最小限に抑えます。 可能であれば、垂直パーティションと機能パーティション全体の参照整合性の要件を最小限に抑えます。これらのスキームでは、アプリケーションはパーティション間で参照整合性を維持する役割を担います。複数のパーティション間でデータを結合するクエリは、通常、キーと外部キーに基づく連続するクエリを実行するため、非効率的です。代わりに、関連するデータのレプリケートまたは正規化解除を検討してください。パーティション間結合が必要な場合は、パーティションに対して並列クエリを実行し、アプリケーション内でデータを結合します。

最終的な整合性の受容。 厳密な整合性が要件であるかどうかを評価します。分散システムの一般的なアプローチは、最終的な整合性を実装することです。各パーティション内のデータは個別に更新され、アプリケーションロジックによって更新が正常に完了します。アプリケーションロジックでは、最終的に一貫性のある操作が実行されている間に、データのクエリによって発生する不整合も処理されます。

クエリが正しいパーティションを見つける方法を検討します。 クエリですべてのパーティションをスキャンして必要なデータを見つける必要がある場合、複数の並列クエリが実行された場合でも、パフォーマンスに大きな影響を与えます。垂直パーティション分割と機能パーティション分割では、クエリでパーティションを指定できます。一方、水平方向のパーティション分割では、すべてのシャードに同じスキーマがあるため、項目の検索が困難になる可能性があります。一般的な解決策は、項目のシャードの場所を検索するために使用されるマップを維持することです。このマップをアプリケーションのシャーディングロジックに実装します。また、データストアが透過的なシャーディングをサポートしている場合は、データストアによって管理することもできます。

シャードを定期的に再調整します。 水平方向のパーティション分割を使用すると、シャードの再調整は、サイズとワークロードによってデータを均等に分散するのに役立ちます。シャードを再調整してホットスポットを最小限に抑え、クエリのパフォーマンスを最大化し、物理ストレージの制限を回避します。このタスクは複雑であり、多くの場合、カスタムツールまたはプロセスが必要です。

パーティションをレプリケートします。 各パーティションをレプリケートして、障害に対する保護を強化します。 1 つのレプリカが失敗した場合、クエリは作業コピーに送られます。

スケーラビリティを別のレベルに拡張します。 パーティション分割戦略の物理的な制限に達した場合は、スケーラビリティを別のレベルに拡張することが必要になる場合があります。たとえば、パーティション分割がデータベースレベルの場合は、複数のデータベースでパーティションを検索またはレプリケートすることが必要になる場合があります。パーティション分割が既にデータベースレベルであり、物理的な制限がある場合は、複数のホスティングアカウントでパーティションを検索またはレプリケートすることが必要になる場合があります。

複数のパーティション内のデータにアクセスするトランザクションは避けてください。 一部のデータストアでは、データを変更する操作に対してトランザクションの整合性と整合性が実装されますが、データが 1 つのパーティションに配置されている場合にのみ実装されます。複数のパーティションにまたがるトランザクションサポートが必要な場合は、ほとんどのパーティション分割システムでネイティブサポートが提供されないため、アプリケーションロジックの一部として実装します。

すべてのデータストアには、運用管理と監視アクティビティが必要です。これらのタスクには、データの読み込み、データのバックアップと復元、データの再構成、およびシステムが正しく効率的に実行されるようにすることが含まれます。

運用管理に影響を与える次の要因を考慮してください。

データがパーティション分割されるときに、適切な管理タスクと運用タスクを実装します。 これらのタスクには、バックアップと復元、データのアーカイブ、システムの監視、その他の管理タスクが含まれる場合があります。たとえば、バックアップ操作と復元操作中に論理的な一貫性を維持することは困難な場合があります。
複数のパーティションにデータを読み込み、他のソースから取得した新しいデータを追加します。 一部のツールとユーティリティでは、適切なパーティションへのデータの読み込みなど、シャード化されたデータ操作がサポートされない場合があります。
データを定期的にアーカイブおよび削除します。 パーティションの過剰な増加を防ぐために、毎月データをアーカイブおよび削除します。別のアーカイブスキーマに一致するようにデータを変換する必要がある場合があります。
データ整合性の問題を特定します。 データ整合性の問題 (あるパーティション内のデータなど、不足している情報を別のパーティションで参照するデータなど) を特定するには、定期的なプロセスを実行することを検討してください。このプロセスでは、これらの問題を自動的に修正するか、手動レビュー用のレポートを生成することができます。

パーティションの再調整

システムが成熟するにつれて、パーティション分割スキームを調整する必要がある場合があります。たとえば、個々のパーティションでトラフィックの量が不均衡になり、ホットになり、過剰な競合が発生する可能性があります。または、一部のパーティション内のデータ量を過小評価している可能性があり、これによりパーティションが容量制限に近づきます。

Azure Cosmos DB などの一部のデータストアでは、パーティションを自動的に再調整できます。それ以外の場合は、次の 2 つのステージでパーティションを再調整できます。

新しいパーティション分割戦略を決定します。
- 分割または結合する必要があるパーティションはどれですか?
- 新しいパーティションキーとは
古いパーティション分割スキームから新しいパーティションセットにデータを移行します。

データの再配置中にパーティションを使用できないようにすることが必要になる場合があります。これは オフライン移行と呼ばれます。データストアによっては、使用中にパーティション間でデータを移行する場合があります。この手法は 、オンライン移行と呼ばれます。

オフライン移行

オフライン移行により、競合が発生する可能性が低くなります。オフライン移行を実行するには:

パーティションをオフラインとしてマークします。パーティションを読み取り専用としてマークすると、移動中もアプリケーションでデータを読み取ることができます。
分割マージし、新しいパーティションにデータを移動します。
データを検証します。
新しいパーティションをオンラインにします。
古いパーティションを削除します。

オンライン移行

オンライン移行は、オフライン移行よりも複雑ですが、中断が少なくなります。このプロセスはオフライン移行に似ていますが、元のパーティションをオフラインとしてマークすることはありません。移行プロセスの粒度 (アイテム別の項目とシャード別のシャードなど) によっては、クライアントアプリケーションのデータアクセスコードで、元のパーティションと新しいパーティションの 2 つの場所にあるデータの読み取りと書き込みが必要になる場合があります。

Azure ファシリテーション

次のセクションでは、Azure サービスに格納されているデータをパーティション分割するための推奨事項について説明します。

Azure SQL Database でのパーティション

1 つの SQL データベースには、格納できるデータの量に制限があります。スループットは、アーキテクチャの要因と、それがサポートする同時接続の数によって制限されます。

エラスティックプール、SQL データベースの水平方向のスケーリングをサポートします。エラスティックプールを使用して、複数の SQL データベースに分散されたシャードにデータをパーティション分割します。また、データの量が増減するにつれてシャードを追加または削除することもできます。エラスティックプールは、データベース間で負荷を分散することで競合を減らすのにも役立ちます。

各シャードは SQL データベースとして実装されます。シャードは複数のデータセットを保持できます。各データセットは シャードレットと呼ばれます。各データベースには、含まれているシャードレットを記述するメタデータがあります。シャードレットには、1 つのデータ項目、または同じシャードレットキーを共有する項目のグループを指定できます。たとえば、マルチテナントアプリケーションでは、シャードレットキーをテナント ID にすることができ、テナントのすべてのデータを同じシャードレットに格納できます。

アプリケーションは、データセットとシャードレットキーの関連付けを担当します。別の SQL データベースは、グローバルシャードマップマネージャーとして機能します。このデータベースには、システム内のすべてのシャードとシャードレットの一覧があります。アプリケーションはシャードマップマネージャーデータベースに接続して、シャードマップのコピーを取得します。シャードマップをローカルにキャッシュし、マップを使用してデータ要求を適切なシャードにルーティングします。この機能は、Java および .NET で使用できる SQL Database の Elastic Database 機能のクライアントライブラリに含まれる一連の API の背後に隠されています。

エラスティックプールの詳細については、「 SQL Database を使用したスケールアウト」を参照してください。

待機時間を短縮し、可用性を向上させるために、グローバルシャードマップマネージャーデータベースをレプリケートできます。 Premium 価格レベルでは、アクティブ geo レプリケーションを構成して、異なるリージョンのデータベースにデータを継続的にコピーできます。

または、SQL Database または Azure Data Factory の SQL Data Sync を使用して、リージョン間でシャードマップマネージャーデータベースをレプリケートします。この形式のレプリケーションは定期的に実行され、シャードマップの変更頻度が低く、Premium レベルを必要としない場合に適しています。

Elastic Database には、シャードレットにデータをマッピングし、シャードに格納するための 2 つのスキームが用意されています。

リストシャードマップは、1 つのキーをシャードレットに関連付けます。たとえば、マルチテナントシステムでは、各テナントのデータを一意のキーに関連付け、独自のシャードレットに格納できます。分離を保証するために、各シャードレットを独自のシャード内に保持できます。

この図の Visio ファイルをダウンロードします。
範囲シャードマップは、連続する一連のキー値をシャードレットに関連付けます。たとえば、一連のテナントのデータを、それぞれ独自のキーで同じシャードレット内にグループ化できます。このスキームは、テナントがデータストレージを共有するため、リストシャードマップよりもコストは低くなりますが、分離性は低くなります。

この図の Visio ファイルをダウンロード

1 つのシャードに複数のシャードレットのデータを含めることができます。たとえば、リストシャードレットを使用して、連続していない異なるテナントのデータを同じシャードに格納できます。同じシャードに範囲シャードレットとリストシャードレットを混在させることもできますが、異なるマップを介してアドレス指定されます。次の図は、この方法を示しています。

この図の Visio ファイルをダウンロードします。

エラスティックプールを使用すると、データの量が増減するにつれてシャードを追加および削除できます。クライアントアプリケーションは、シャードを動的に作成および削除し、シャードマップマネージャーを透過的に更新できます。ただし、シャードの削除は破壊的操作であり、そのシャード内のすべてのデータも削除する必要があります。

アプリケーションで 1 つのシャードを 2 つの個別のシャードに分割するか、シャードを結合する必要がある場合は、分割/マージツールを使用。このツールは Azure Web サービスとして実行され、シャード間で安全にデータを移行します。

パーティション分割スキームは、システムのパフォーマンスに大きな影響を与える可能性があります。また、シャードを追加または削除する必要がある速度や、シャード間でデータを再パーティション分割する必要がある速度にも影響を与える可能性があります。次の点を考慮してください。

同じシャード内で一緒に使用されるデータをグループ化し、複数のシャードのデータにアクセスする操作を回避します。シャードはそれ自体が SQL データベースであり、操作が複数のシャードにアクセスする場合は、クライアント側でデータベース間結合を実行する必要があります。

SQL Database ではデータベース間結合はサポートされていませんが、Elastic Database ツールを使用してマルチシャードクエリを実行できます。マルチシャードクエリは、個々のクエリを各データベースに送信し、結果をマージします。
シャード間の依存関係を持たないシステムを設計します。あるデータベースの参照整合性制約、トリガー、およびストアドプロシージャは、別のデータベース内のオブジェクトを参照できません。
クエリで頻繁に使用される参照データがある場合は、シャード間でデータをレプリケートすることを検討してください。この方法では、データベース間でデータを結合する必要がなくなります。レプリケーションの労力を最小限に抑え、古くなる可能性を減らすには、このようなデータを静的または低速にすることが理想的です。
同じシャードマップに属するシャードレットには、同じスキーマを使用します。このガイダンスは SQL Database では適用されませんが、各シャードレットに異なるスキーマがある場合、データの管理とクエリは複雑です。代わりに、スキーマごとに個別のシャードマップを作成します。異なるシャードレットに属するデータを同じシャードに格納できます。
ビジネスロジックでトランザクションを実行する必要がある場合は、データを同じシャードに格納するか、最終的な整合性を実装します。トランザクション操作は、シャード内のデータに対してのみサポートされ、シャード間ではサポートされません。トランザクションは、同じシャードの一部である場合、シャードレットにまたがることができます。
シャードを、それらのシャード内のデータにアクセスするユーザーの近くに配置します。この戦略は、待機時間の短縮に役立ちます。
非常にアクティブなシャードと比較的非アクティブなシャードを組み合わせないようにします。負荷をシャード間で均等に分散してみてください。シャーディングキーをハッシュする必要がある場合があります。シャードを地理的に検索する場合は、ハッシュされたキーが、そのデータにアクセスするユーザーの近くに格納されているシャードに保持されているシャードレットにマップされていることを確認します。

Azure Blob Storage でのパーティション

Blob Storage では、大きなバイナリオブジェクトを格納できます。大量のデータをすばやくアップロードまたはダウンロードする必要があるシナリオでは、ブロック BLOB を使用します。データの一部へのシリアルアクセスではなくランダムなアクセスを必要とするアプリケーションには、ページ BLOB を使用します。

各ブロック BLOB またはページ BLOB は、Azure ストレージアカウント内のコンテナーに保持されます。コンテナーを使用して、同じセキュリティ要件を持つ関連する BLOB をグループ化します。このグループ化は、物理的ではなく論理的です。コンテナー内では、各 BLOB に一意の名前が付けられます。

BLOB のパーティションキーは、アカウント名、コンテナー名、BLOB 名です。パーティションキーは、データを範囲にパーティション分割するために使用されます。これらの範囲は、システム全体で負荷分散されます。 BLOB を多数のサーバーに分散して、BLOB へのアクセスをスケールアウトできます。 1 つの BLOB は、1 つのサーバーでのみ提供できます。

名前付けスキームでタイムスタンプまたは数値識別子を使用すると、1 つのパーティションへのトラフィックが過剰に発生する可能性があります。これにより、システムが効果的に負荷分散を行うのを防ぐことができます。たとえば、 タイムスタンプが y-mm-ddなどの BLOB オブジェクトを使用する毎日の操作がある場合、その操作のすべてのトラフィックは 1 つのパーティションサーバーに送信されます。代わりに、名前の先頭に 3 桁のハッシュを付けます。詳細については、「パーティションの名前付け規則」を参照してください。

1 つのブロックまたはページを書き込む操作はアトミックですが、ブロック、ページ、または BLOB にまたがる操作はアトミックではありません。ブロック、ページ、BLOB 間で書き込み操作を実行するときに一貫性を確保する必要がある場合は、BLOB リースを使用して書き込みロックを解除します。

考慮事項

データのパーティション分割では、考慮する必要があるいくつかの課題と複雑さが生まれます。

パーティション間のデータ同期が困難になる可能性があります。 1 つのパーティションに対する更新または変更が、タイムリーかつ一貫性のある方法で他のパーティションに反映されるようにします。
複数のパーティションのバックアップと復元を調整する必要がある場合、フェールオーバーとディザスターリカバリーのプロセスは複雑になります。データ整合性の問題は、一部のパーティションまたはそのバックアップが破損しているか使用できない場合に発生する可能性があります。
パーティション間でクエリを実行する必要がある場合や、データが不均等に増加した場合にパーティションを再調整する場合は、データのパーティション分割がパフォーマンスと信頼性に影響する可能性があります。