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

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

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

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

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

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

主要な設計戦略

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

Note

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

データをパーティション分割すると次のことが可能になります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

垂直的パーティション分割の利点は次のとおりです。

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

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

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

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

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

スケーラビリティを考慮したパーティション分割の設計

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

スケーラビリティの観点でパーティション分割を設計する際には、次の手順に従います。

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

クラウド環境によっては、インフラストラクチャ境界に基づいてリソースが割り当てられます。選択した境界の制限が、データ量、データストレージ、処理能力、および帯域幅の想定される増加分に十分対応できるようにを確認する必要があります。

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

クエリパフォーマンスの観点でのパーティション分割の設計

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

クエリパフォーマンスの観点でパーティション分割を設計する際には、次の手順に従います。

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

可用性の観点でのパーティションの設計

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

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

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

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

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

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

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

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

パーティション分割を使用すると、システムの設計と開発の複雑さが増大します。初期においてシステムが単一のパーティションのみを含んでいる場合でも、システム設計の基盤としてデータをパーティション分割してください。パーティション分割を後回しにした場合、すでに稼働中のシステムを維持しなければならないため、対応が難しくなります。次の方法があります。

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

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

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

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

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

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

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

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

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

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

パーティションをレプリケートする: 各パーティションをレプリケートして、障害に対する保護を強化します。単一のレプリカで障害が発生しても、動作しているコピーにクエリを振り向けることができます。

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

トランザクションでは、複数のパーティションのデータにアクセスしないようにします。 一部のデータストアには、データを変更する操作に対してトランザクションレベルの一貫性と整合性を保つ機能を実装していますが、これが有効になるのは、データが単一のパーティションに配置されている場合だけです。複数のパーティションにまたがってトランザクションレベルのサポートを必要とする場合、ほとんどのパーティション分割システムでこの機能はネイティブにサポートされていないため、アプリケーションロジックの一部として実装してください。

すべてのデータストアで運用の管理および監視のアクティビティが必要です。これらのタスクには、データの読み込み、バックアップおよび復元、データの再編成、システムが正確かつ効率よく動作していることの確認などがあります。

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

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

パーティションの再調整

システムが成熟するにつれて、パーティション分割構成を調整することが必要になる場合があります。たとえば、パーティション間でトラフィック量に不均衡が生じ始め、特定のパーティションがホットスポットになり、過度の競合が発生することがあります。あるいは、一部のパーティションのデータ量を過小評価したために、これらのパーティションが容量の上限に近づいていることもあります。

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

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

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

オフライン移行

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

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

オンライン移行

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

Azure ファシリテーション

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

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

1 つの SQL データベースには保持できるデータ量に制限があります。スループットにはアーキテクチャ上の要因とアーキテクチャがサポートするコンカレント接続数による制約があります。

エラスティックプールは、SQL データベースの水平スケーリングをサポートします。エラスティックプールを使用することで、データを複数の SQL データベースにまたがるシャードにパーティション分割できます。また、データ量の増減に合わせてシャードを追加または削除することもできます。さらに、エラスティックプールを使用して負荷をデータベース全体に分散することにより、競合を少なくすることもできます。

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

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

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

遅延を小さくし、可用性を高めるには、グローバルシャードマップマネージャーデータベースをレプリケートします。 Premium 価格レベルを使用すると、アクティブ geo レプリケーションを構成して、データを異なるリージョン内のデータベースに連続してコピーできます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

単一のブロックまたはページを書き込む操作はアトミックですが、複数のブロック、ページ、または BLOB にまたがる操作はアトミックではありません。複数のブロック、ページ、または BLOB にまたがる書き込み操作の実行中に一貫性を確保するには、BLOB リースを使用して書き込みロックを取得する必要があります。

考慮事項

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

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

信頼性チェックリスト

レコメンデーションの完全なセットを参照してください。

信頼性チェックリスト

次の方法で共有

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