データパーティション分割に関する推奨事項

[アーティクル]
11/15/2023

この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。

RE:06	アプリケーション、データ、インフラストラクチャの各レベルで、タイムリーで信頼性の高いスケーリング戦略を実装します。

関連ガイド:スケーリング

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

主要な設計戦略

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

注意

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

データをパーティション分割する理由

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

パーティションを設計する

データをパーティション分割する際の一般的な 3 つの戦略を次に示します。

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

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

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

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

最も重要な要素は、選択したシャーディングキーです。システムが運用状態に移行した後にキーを変更することは、非常に困難になる可能性があります。キーは、ワークロードをシャード間でできるだけ均等に分散するようにデータがパーティション分割されるものである必要があります。

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

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

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

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

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

垂直的パーティション分割

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

可用性のためにパーティションを設計する

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

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

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

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

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

1 つのパーティションで障害が発生した場合、他のパーティションのデータにアクセスするアプリケーションに影響を及ぼすことなく、そのパーティションを個別に復旧できます。
地理的領域別にデータをパーティション分割すると、スケジュールされたメンテナンスタスクを各場所のピーク時間外に実行できます。パーティションがそれほど大きくないことを確認して、この期間中に計画メンテナンスが完了しないようにします。

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

アプリケーション設計に関する考慮事項

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

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

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

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

データパーティション分割構成を設計する際には、次の点を考慮する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

パーティションの再調整

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

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

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

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

オフライン移行

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

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

オンライン移行

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

Azure ファシリテーション

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

Azure SQL データベース内のパーティション

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 データ同期を使用して、シャードマップマネージャーデータベースをリージョン間でレプリケートします。この形式のレプリケーションは定期的に実行され、シャードマップの変更頻度が低く、Premium レベルが必要ない場合に適しています。

Elastic Database では、データをシャードレットにマップし、シャードに格納するために、2 つの構成を利用できます。

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

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

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

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

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

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

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

パーティション分割構成は、システムのパフォーマンスに大きく影響します。また、シャードの追加/削除の頻度、またはシャード間でデータを再パーティション分割する必要がある頻度にも影響を及ぼします。次の点を考慮してください。

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

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

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

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

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

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

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

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

考慮事項

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

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

信頼性チェックリスト

推奨事項の完全なセットを参照してください。

信頼性チェックリスト

Share via

データパーティション分割に関する推奨事項