1717879569
2024-05-30 04:54:50
導入
まず、このシナリオでCosmos DBがどのように使用されているかの概要を説明しましょう。以下に示すアーキテクチャの概要によると、データを出力する顧客システムのエコシステムがあり、これらはパイプラインにヒットし、次に挿入されます。 コスモスDB バッチプロセスを介して。
2019 年の元の設計では、Cosmos DB に取り込まれたすべてのドキュメントを含むコンテナーはデータのみでした。データ コンテナーが大きくなり、クエリ パフォーマンスと RU/秒が法外なレベルに達したため、データ コンテナーの「インデックス」として機能するインデックス コンテナーが導入されました。この設計変更により、次のデータ アクセス パターンが必須になりました。
- インデックスコンテナでドキュメントIDを照会する
- ドキュメントIDを使用したクエリを介してデータコンテナからドキュメントを取得します。
- ドキュメントのサイズが2MBを超える場合、ドキュメントペイロードにはBlobストレージポインターが含まれます。
- GET 操作を介して Blob ストレージからドキュメントを取得する
ドキュメント サイズが 2 MB を超える場合は、GET Blob 操作が必要になり、ドキュメントを取得するには常に最低でも 2 つの Cosmos DB 操作が必要になります。
その後、インデックス コンテナーは、データ コンテナーとの相関でサイズが大きくなるにつれて、クエリを実行する RU/秒のコストを最適化するために複合インデックスを導入することで、さらに変更されました。このアーキテクチャを確認すると、いくつかの課題が明らかになります。
- 1 つのドキュメントを読み取るには 2 つまたは 3 つの操作が必要です。
- インデックス コンテナーには、データ コンテナー内のデータが必ず重複して存在します。
- データ コンテナーのサイズとインデックス コンテナーのサイズは密接に関連しており、データ コンテナーが大きくなると、インデックス コンテナーも大きくなる必要があります。
- ドキュメントは見つかるまでは存在しないため、データの一貫性が実現されるにはインデックス コンテナーの書き込みが成功する必要があることが前提となります。
- このアーキテクチャの全体的な進化可能性は限られています。
このアーキテクチャの進化能力が不足していることは明らかです。この設計では、あと何回変更できるでしょうか。それほど多くはありません。複合インデックスの導入は、このアーキテクチャ内で妥当なパフォーマンスと RU/秒のメリットを得るために実行できる最後の変更でした。このアーキテクチャをベースラインの位置に戻し、さらなる進化を可能にするには、一連のアーキテクチャ変更が必要です。
推奨事項
何を変更するかを評価する際に、Cosmos DB の機能と顧客の現在および将来のニーズを新たに検討できるという利点がありました。Cosmos DB は 2019 年以降大幅に進化しており、提示された課題を解決する機能と付随サービスを備えています。
推奨された変更は次のとおりです。
- 動的自動スケーリングを有効にする
- この機能を有効にした後、顧客は開発/テスト/プレプロダクションおよび運用 Cosmos DB アカウント全体で即座に大幅なコスト削減を実現しました。
- 動的自動スケーリングにより、パーティションを個別にスケーリングできます。複数のパーティションを持つ非均一な大規模ワークロードのコスト効率が向上します。
- バッチ挿入/更新/削除データ処理をスムーズに
- Cosmos DB は時間単位で課金されます。Cosmos DB の使用方法がコストに影響することを覚えておくことが重要です。このシナリオでは、両方のコンテナーでバッチ プロセスが実行され、データが更新されました。
- ただし、これにより、RU コストが一般的なデータ アクセス パターンよりも 45% ～ 55% 高くなります。
- 更新速度を犠牲にしてバッチをスムーズにすると、このコストの増加を軽減するのに役立ちます。
- Cosmos DB 統合キャッシュを有効にする
- Cosmos DB 統合キャッシュを使用すると、繰り返しクエリに対して RU コストは発生しません。
- Cosmos DB 統合キャッシュには管理や運用は必要ありません。
- 各ノードは最大 64 GB の独立キャッシュを保存できます。
- RU が高く、クエリが複雑で、ポイント読み取りが 16 KB を超える場合は、Cosmos DB 統合キャッシュを使用することでメリットが得られると考えられます。
- 階層パーティションキーを有効にする
- 階層パーティション キーを使用すると、データを最大 3 レベルの深さまでサブパーティション化できるため、読み取り負荷の高い大規模なドキュメントに役立ちます。
- 完全なサブパーティション キー パスまたは部分的なサブパーティション キー パスを指定すると、クエリは、関連するデータを含む物理パーティションのサブセットのみに効率的にルーティングされます。
- ドキュメントタイプごとにコンテナを導入する
- これにより、ドキュメント タイプごとに適用できる複合インデックスがより明確になります。これは、ドキュメントにさまざまなプロパティの組み合わせがある場合に特に便利です。
- これにより、階層パーティション キーから十分なメリットを得られない可能性のある高スループットのドキュメント タイプも分離されます。
- 動的自動スケーリングと組み合わせることで、これらの高スループットのドキュメント タイプ コンテナーを独立してスケーリングできます。
- インデックスコンテナの廃止
- 適切なコンテナ戦略を採用することで、インデックス コンテナを廃止し、単一書き込みの一貫性、追加コストの軽減、38 TB の重複データの削除が可能になります。
- Cosmos DB 分析ストアを実装する
- Cosmos DB 分析ストアは、トランザクション ストアでこのタイプのクエリを実行して RU/秒のコストが発生するのとは対照的に、分析クエリ用に最適化された、完全に分離された列ストアです。
- 分析ストアのクエリは 0 RU/秒で処理されます。
- Synapse Link は、トランザクション ストアから分析ストアに 2 分以内にデータをシームレスに複製します。
- カスタム パーティションがサポートされているため、より効率的なデータ検出戦略の基盤となります。
- Cosmos DB 変更フィードを使用してデータを複製する
- Cosmos DB から別のデータベース (Azure SQL など) にデータを複製する必要がある場合は、Azure Functions で Cosmos DB 変更フィードを使用します。
- このパターンは、1 秒あたり 100,000 件以上のリクエストに対応できます。
- プレミアムBLOBストレージを使用する
- 2 MB を超えるドキュメントを Azure Blob Storage に保存することは、Cosmos DB に推奨される設計パターンです。
- Premium Blob Storage を使用すると、ドキュメントのサイズに応じて、より速くアクセスできます。
結論
ここまで多くのことを説明してきましたが、大規模な困難な要件を解決するために有効にできる Cosmos DB の機能について理解していただけたと思います。
アーキテクチャを設計する際には、それが進化し続けることを保証することが重要です。これを実現するには、アーキテクチャを「現在の」ベスト プラクティス、製品の機能、ビジネスのニーズに照らして定期的にレビューし、必要に応じてリファクタリング/再設計します。
マイクロソフトは、 適切に設計されたフレームワークこれらのレビューは、お客様と提携して実施することも、お客様が独自に実施することもできます。これらのレビューは、少なくとも 6 か月ごと、多くても 1 年に 1 回実施してください。
要件を解決するために製品の機能を採用できるほど、アーキテクチャは長期的に進化しやすくなります。このシナリオでは、重要な目的の 1 つは、顧客を「ベースライン」の位置に移動させることでした。
Cosmos DBアーキテクチャをリセットし、 もっと Cosmos DB は、既存のアーキテクチャ内でのカスタム実装や回避策ではなく、要件を解決する機能を備えています。
#大規模なドキュメント #サイズで #Cosmos #を大規模に使用する方法