はじめに

DP-420を取得したので、復習がてら記事作成。
DP-420はCosmos DB特化試験。NoSQLデータベースの知識は前提として必要。
変更フィードなどはAZ-204と範囲が一部被っているので割愛。

論理パーティション

データベース内のコンテナ内の項目を分割したサブセット=論理パーティション

論理パーティションに関連付けられているキー=パーティションキー
論理パーティション内で一意のキー=項目ID

論理パーティション数に制限は無いが、各論理パーティション内に格納できるデータは最大20GB。論理パーティションがトランザクションのスコープになるので、パーティションキー戦略はクエリパフォーマンス向上に重要。

物理パーティション

1つ以上の論理パーティションが物理パーティションにマップされる。
内部的には物理パーティション間でデータとスループットを分散する。物理パーティションはCosmos DB側で管理されるので、パーティション設計の際は論理パーティション間でクエリが偏らないようにパーティションキーを設計する。(それが物理パーティション間での分散にも繋がる)

インパーティションクエリ・クロスパーティションクエリ

クエリ実行の際、WHERE句にパーティションキーを含んだ等値フィルターを指定すると、クエリを対応する物理パーティションにルーティングする(インパーティションクエリ)ことができる。

例えばStudentIDがパーティションキーだとしたら、以下のようにするとインパーティションクエリになる。

SELECT * FROM c WHERE c.StudentID = '123456'

逆に範囲フィルター(例えばc.StudentID > '123456')を使ったりパーティションキー以外のキーでフィルターをすると、全ての物理パーティションのインデックスに対してクエリが実行される(クロスパーティションクエリ)。
物理パーティションが複数あるような大きなコンテナであれば、クロスパーティションクエリが少なくなるようなパーティション設計にするとパフォーマンス向上が見込める。

Cosmos DBの操作にかかるコストは要求ユニット(RU)で表される(後述)が、RUの消費量を論理パーティション間で均等になるようなパーティション設計が重要。
ワークロードのほとんどがクエリであれば、クエリの等値フィルタで使われるプロパティをパーティションキーに設定するとクロスパーティションクエリの数を抑えることができる。

スループット

スループットは、サーバレス、手動、自動スケーリングから選択できる。
ざっくりとした選び方の目安として、サーバレスは予測不可能・平均は低いが時折バーストするようなトラフィック、手動は安定・予測できるトラフィック、自動スケーリングは安定していない・予測不可能なトラフィックに適している。

サーバレスと自動スケーリングが似ているけど、サーバレスは従量課金で、手動・自動スケーリングはプロビジョニングされたスループットに対して課金。

要求ユニット(RU)

RUはデータベース操作に必要なシステムリソースを抽象化したもので、コストもRUに基づいて計算される。1RU=1KBのポイント読み取り。
(ポイント読み取り=パーティションキー+項目IDでのキー/値参照。コストを抑えるには、なるべくクエリでなくポイント読み取りで値を取得するようにする。)

10KBのポイント読み取りなら100RUなのかというとそうではなく、以下を見ると100KBのポイント読み取りは10RUになっている。(読み取り容量と使用システムリソースは完全に比例するわけではないからかな？)

Azure Synapse Link for Azure Cosmos DB

Cosmos DB内のデータの準リアルタイム分析に利用される。Synapse Link自体はCosmos DBとSynapse Analyticsを統合する、クラウドネイティブのHTAP。

Cosmos DBの分析ストアは分析用に完全に分離された列ストアであるが、デフォルトではパーティション分割されない。
カスタムパーティション分割機能で分析ストアのデータをパーティション分割することで、クエリパフォーマンスを向上させることができる。

おわりに(学習しての所感)

Azure Cosmos DB分析ワークロードを有効にする(Synapse Linkまわり)は試験ガイドにはバッチリ書いてあるけど、DP-420のトレーニングだけだと手薄になりがちかなと思った。DP-203でAzure Synapse Analytics出てくるので重点的にやりたい。