Azure Cosmos DB (NoSQL) の機能を整理 - 2024年5月編

Azure Portal で Cosmos DB のリソースを開いたときに表示される Features (機能) の一覧をみたら、いつのまに結構増えてるし 2024年5月時点だと1年くらい preview のままのも多い気がするので改めて整理しようと思いました。

※ ブログのタイトルにある "機能" は、Azure portal 内の Cosmos DB の中のメニューのことです。

Vector Search for NoSQL API (preview)

2024年5月に発表の NoSQL API でも Vector sotre として利用できる機能。

これは別途まとめてる途中なのでドキュメントのリンクだけ。

2023年11月ごろ発表の機能。2023年11月15日以降で作成した Cosmos DB アカウントでのみ利用可能だが、既存のアカウントに対しても段階的に利用可能になる予定。

概要:

以前までは、たとえばマルチリージョンアカウントの Cosmos DB では、最も利用頻度の高いリージョンに基づいてすべてのリージョンでスケールされていたためコストが割高になっていた。
この機能の導入で、リージョンごと、パーティションごとにスケールできるようになり、コストが効率的になった。
具体的なユースケースによるコスト (RUの計算) がどうなるかは、以下のドキュメントで例が示されてるのでみるとわかりやすいです。

ドキュメント:

2023年5月ごろ発表の機能。

概要:

RU の上限を超えるリクエストが発生したときに、優先度の高いリクエストの実行を優先的に実行できる仕組み。
優先度が高いリクエストが保証されるわけではなく、ベストエフォートでの実行になる。
実装は、.NET の SDK (v3.33.0-preview 以降)だと ItemRequestOptions のプロパティPriorityLevel = PriorityLevel.High や PriorityLevel.Low を設定する感じ。
- PriorityLevel のデフォルト値が PriorityLevel.High なので既存のコードに Htigh だけのコードを追加しても意味ないのは注意。

ドキュメント:

概要:

各物理パーティションごとで最大5分のアイドルされてると RU を貯めることができ、Max 3000RU/秒で消費できる。基本的に有効化しておいて損がない機能。
機能を有効化したときの具体的なイメージはこんな感じ。
- 1000 RU の DB で、5分 (=300秒) 間完全にアイドル状態だったら、1000 RU x 300 秒で 300000 RU 蓄積の状態になる。
- その直後に大量のトラフィックが来た場合以前なら MAX 1000RU/秒の性能しか出せないが、Burst Capacity により 3000 RU x 100秒間リクエストをさばくことができる。
3,000 RU/秒未満の物理パーティションを持つ Cosmos DB account が対象という条件はあり。

ドキュメント:

2024年1月の機能。

概要:

SQL Server だと運用してる間にインデックスが断片化してきて再構築や再編成をすることでパフォーマンス改善をしますが、Cosmos DB の Partition merge 機能は似たような位置づけで container に使われいる物理パーティションを再調整して減らすことで RU の効率化に繋げる機能。
ドキュメントには、patition merge すべき container を識別するためのメトリクスの見方も書いてるので、長く運用してる Cosmos があるなら見てみるとよいかもですね。

ドキュメント:

この機能と全然関係ないけど、今年 Partition Key を変更できるようになったのも地味にあついですね。

一年前の2023年5月の Build で出た機能だっけ...

概要:

以前は、1つの container のデータをもとに Materialized View として別の container にデータを入れたい場合、Change Feed とか使って自分で処理を実装していた。
この機能の登場で、設定だけで Materialized View を構成できる。自身で実装してた時に既存の RU の削減とか cross partition query の軽減などの恩恵が得れる。
まだ結構制限も多いので、細かいことしたいなら自分で実装するしかないケースも少なくない印象。

ドキュメント: