JAZUG12周年俺の Azure Cosmos DB

俺の Azure Cosmos DB
- 本番アプリを作る上で知っておきたいコト -
畠山大有 | Daiyu Hatakeyama
Architect && Software Engineer && Applied Data Scientist
Microsoft Japan
/dahatake
@dahatake
/in/dahatake
/dahatake
/dahatake
/dahatake
時間の関係で
一部分だけ😊

https://channel9.msdn.com/Events/PDC/PDC08/KYN01

グローバル分散マルチモデル/API ミリ秒
レイテンシの保証
伸縮性のある
スケールアウト明確に定義された
整合性
包括的な SLA
Azure Cosmos DB

1 桁ミリ秒
Read < 2 ms
Writes < 6 ms
Read < 10 ms
Writes < 15 ms
99%
50%

ストレージとスループットを
水平スケールアウトし
あらゆるニーズに対応
数百万トラン
ザクション/秒
PB 級のデータ
数百トラン
ザクション/秒
GB 級のデータ
Cosmos
DB

Cosmos 君の
良さを活かしたい
ミリ秒
レイテンシの保証
伸縮性のある
スケールアウト

Cosmos 君との付き合い
方

何でもできる Giant Database じゃない
伸縮性のある
スケールアウト

Software Engineering
の Know-How を振り返る

ボトルネック
巨大なDB
複数データソース
別アーキテクチャ
小さい
App Operational
Store
Analytical
Store

ID 姓名性別 ID 姓名性別
Row Colum
• 行単位
• 少数の行多数の列
• 結合処理
• 複数テーブルの結合が可能
• 少数の列多数の行分析
• 結合処理
• RDBMS 由来のデータベースは、複数テーブルの結合が一般的に可
能
• NoSQL 型のデータベースは、複数テーブルの結合が一般的に苦手

仮想マシンの中
で
約 275万 IOPS
 不揮発性メモリの利用で、ストレージIO 性能は異次
元に
 ランダム IO に強烈なパフォーマンスを発揮

• 大量
• 複数データストア
• 機能
Web /
Mobile
Operational
Store
Search

Column Store
Row Store
App
Container
本日の範囲
Write
Read
Read
Read
本日の範囲

Data Modeling
インフラのチューニングよりもよっぽど
効果的

エンティティ間の参照は保持: address と password は特定の顧客に reference して
いる

1つのJSONドキュメントに、address の配列とpasswordのサブオブジェクトを
embed できる

1:1 もしくは 1:少数の relationship
通常、customer に関する全てのデータを
一緒に取得・更新する
全てのデータを1つの JSONドキュメント
に
embed することは理にかなう

productCategories
PK: ?
SELECT * FROM c
このクエリのデータを単一 partition にするには、
すべての category を同じ論理 partition に配置する必要がある

productCategories
PK: type
これを達成するために適用できるトリックは、実際にはドキュメント内の定数にな
る
フィールドを partition key として使用する。例えば、‘type’ というプロパティで
partition 分割し、各ドキュメントでこのプロパティを ‘category’ に設定する。
これはおそらく少し奇妙に見えるが、その設計を繰り返して最適化する。

1:少数の relationship なので、embed する

products
PK: ?
CategoryA CategoryC
CategoryB
SELECT * FROM c WHERE c.categoryId = 'CategoryA'
このクエリのデータを単一 partition にするには、
すべての product を同じ論理 partition に配置する

products
PK: categoryId
category name?
tag names?
‘categoryId’は、カテゴリのすべての製品を非常に効率的に取得できるため、ここで
は適切な partition key といえる
しかし、今の問題は product をクエリするたびに、category ID と tag ID の塊が取
得される。

products
SELECT * FROM c WHERE c.categoryId = 'CategoryA'
productCategories
SELECT c.name FROM c WHERE c.id = 'CategoryA'
productTags
SELECT * FROM c
WHERE c.id IN ('<tagId1>', '<tagId2>', '<tagId3>')

products
PK: categoryId
明らかに、新しい product を作成するときはいつでも、これらの追加プロパティを
設定する。
しかし、それぞれのコンテナ内の category または tag の名前を変更するとどうなる

productCategories
productTags
products

salesOrders
PK: ?
CustomerA CustomerC
CustomerB
SELECT * FROM c WHERE c.customerId = 'CustomerA'
このクエリのデータを単一 partition にするために、
すべての sales order を同じ論理 partition に配置する

salesOrders
PK: customerId
customers
PK: id
同じ container に保存するべきか

同じコンテナ内に複数のエンティティを混在さ
せる

salesOrders
PK: customerId
customers
PK: id

CustomerA
CustomerC
CustomerB
customer sales orders
customers
PK: customerId

customers
PK: customerId
SELECT * FROM c WHERE c.customerId = 'CustomerA'
AND c.type = 'salesOrder'

CustomerA
CustomerC
CustomerB
update the customer add a sales order
customers
PK: customerId
Sales order を追加するたびに、対応
する customer も更新して、sales
order の数を増やす

CustomerA
CustomerC
CustomerB
update the customer add a sales order

customers
PK: customerId
SELECT * FROM c WHERE c.type = 'customer'
ORDER BY c.salesOrderCount DESC

customers
PK: customerId
productCategories
PK: type
productTags
PK: type
products
PK: categoryId

最適化
customers
PK: customerId
productMeta
PK: type
products
PK: categoryId

Cosmos 君は
Application のための database

Performance について
Application 側で
考慮したい点

“パラメーター“ 一つで
パフォーマンスはがらりと変わる

Direct Gateway
パフォーマンス高速普通
サポートされているSDK .NET, Java 全て
通信プロトコル TCP (TLSで暗号化) HTTPS
同時接続セッション数少ない
(よいパフォーマンスのために8-
16/Connection毎)
多い
サーバーメンテナンスの
影響
受ける (SDK で Retry実装はされている) 受けない
https://learn.microsoft.com/ja-jp/azure/cosmos-db/sql/sql-sdk-connection-modes

最新の SDK を使用する
パフォーマンスのヒントを確認し、提案されたプラクティスに従う
• .NET SDK v3 用の Azure Cosmos DB のパフォーマンスに関するヒント | Microsoft Learn
• Azure Cosmos DB Java SDK v4 のパフォーマンスに関するヒント | Microsoft Learn
Azure ポータルを使用したメトリックのログ記録
SDK ログを有効にして、問題のトラブルシューティングに役立てる
• ログを有効にするとパフォーマンスに影響する可能性があるため、問題のトラブルシューティングを行う場合にのみ有効にすることをお勧め
• ポイント操作応答からの診断文字列をログに記録
• すべてのクエリ応答から SQL クエリメトリックをログに記録
• SDK ログのセットアップに従う
一般的な問題と回避策を見る
• Azure Cosmos DB .NET SDK の使用時の問題を診断しトラブルシューティングする | Microsoft Learn
• Azure Cosmos DB Java SDK v4 の診断およびトラブルシューティング | Microsoft Learn
「GitHub の Issues」を確認

• Direct Mode は、ネットワークホップが少ないため、パフォー
マンスが向上する
接続ポリシー: Direct Mode (.NET)
を使用する
• 最初の要求は、アドレスルーティングを取得する必要がある
ため、待機時間が長くなる
OpenAsync を呼び出して、最初の
要求 (.NET) での起動待機時間を回避
• 同じリージョン内の呼び出しは 1 ~ 2 ミリ秒以内に完了するが、
リージョン間の待機時間は >50 ミリ秒かかる
同じ Azure リージョンに
クライアントを併置する
• 並列処理の程度をチェックして、クライアントアプリケーショ
ンが要求間の待機時間をほとんど費やさないようにする
スレッド/タスクの数を増やす
• レイテンシとCPUジッタを低減する
VMでの高速ネットワークを有効に
する

• SDKは、最高のパフォーマンスを提供するために絶
えず改善されている
最新の SDK をインストールする
• シリアル化せずにデータを送受信できる
ストリーム API の使用
• 効率的な接続管理とパフォーマンスの向上を可能に
する
シングルトンの Azure Cosmos
DB クライアントをアプリケー
ションの有効期間中使用する
• ゲートウェイモードの使用時にHTTPS/REST経由で要求が行われ、
ホスト名
またはIPアドレスごとのデフォルトの接続制限が適用される
ゲートウェイ・モードの使用時
にホストあたり System.Net
MaxConnections を増やす

• 並列クエリは、クエリの待機時間とスループットを
向上させるように設計される
パーティション分割された
コレクションの並列クエリ
• ガベージコレクションの頻度を減らすと、場合によっては役立つこと
がある
サーバー側 GC を有効にす
る
• コンピューターが CPU またはネットワーク使用率
(>50,000 RU/s) で制限されているため、クライアント
アプリケーションがボトルネックになることがある
クライアントのワークロー
ドを
スケールアウトする

• 可能な限りドキュメント URI をキャッシュして、
読み取りパフォーマンスを最高にする
ドキュメントの URI をキャッ
シュして読み取り待機時間を
短縮
• 該当するすべての結果を取得するために必要な
ネットワークラウンドトリップの数を減らす
パフォーマンスを向上させる
ために、クエリ/読み取り
フィードのページサイズを調
整する
• アプリケーションは64 ビットのホストで使用す
る
64 ビット・ホスト処理の使用

WHERE 句/フィルタ
の活用
• 最初に検索対象を絞
る
クエリメトリックの
有効化
• クエリのトラブル
シューティングが可
能になる
• 実行のどの部分に
どれ程の時間が費や
されているかを
知るのに役立つ
インデックス作成パ
ス/設定
• 除外/包含パスが
適切に設定されて
いることを確認する
Feed Option クラスに
よるチューニング
• パラメータを調整し
て、ネットワークの
処理を調整

IDocumentQuery<dynamic> query = client.CreateDocumentQuery(
UriFactory.CreateDocumentCollectionUri(DatabaseName, CollectionName),
"SELECT * FROM c WHERE c.city = 'Seattle'",
new FeedOptions
{
PopulateQueryMetrics = true,
}).AsDocumentQuery();
• .NET クエリ関数の
PopulateQueryMetrics パラメー
ターを true に設定
クエリメト
リックの
有効化

メトリックは、パフォーマンスの問題を特定するのに役に立つ
返されるいくつかの一般的なメトリック
• Index Utilization percentage
• Query Execution Times
• Runtime Execution Time
• Request Units used
• Individual Partition metrics

返される最も重要なクエリメトリックの 1 つ
以下より算出:
• クエリのフィルターによって一致したドキュメント/クエリ
によって読み込まれた
ドキュメントの合計
• この割合をできるだけ 100% に近づけたい
• 100% に近づかない場合は、クエリを最適化して改善させる

• Lazy なインデックスを持ちたくない
インデックス作成モードを
コンシステントに設定
• 一意でまばらな値のみを含める
• Where 句の一部となる値を含める
パスを /* に設定しない
• 数値と文字列に有益
• Where 句のクエリ > < に役立つ
インデックスは種類の範囲
でなければならない
• パスを除外し、使用しない場合、不要な書き込みが増えます
• ホットまたは定期的に使用される「パスを含める」によってパフォーマン
スが向上
包含パスと除外パス

• Partition 横断のクエリにWHERE/IN +キーを使用する
• 以下の条件の場合は、Partition 横断のクエリを割ける
• 30,000 より多くの RU をプロビジョニングする予定
• 100 GB を超えるデータを格納する予定
データが物理 Partition に分割されている場合
//Query using Partition key DeviceId
Iqueryable<DeviceReading> query =
Client.CreateDocumentQuery<DeviceReading>(
UriFactory.CreateDocumentCollectionUri(“database1”, “collection1”))
.Where (m=> m.MetricType == “Temperature” && m.DeviceId = “010101-ABD”);

MaxItemCount
• サーバーへのラウンドトリップごとに返されるアイテムの最大数
• -1 に設定すると、サーバがアイテム数を管理しない (最も最適な値)
• 値を小さくして、トリップあたりのアイテム数を減らす (返されるアイテムの数が多い場合に関係する場合)
MaxBufferedItemCount
• ドキュメントバッファリングに割り当てられるメモリ消費量を制限
• 値を大きくすると、パーティション間の並べ替え/ORDER BY クエリの待機時間が短縮されます
• 疑わしい場合は -1 に設定されているが、最適でない場合は、メモリ使用量/平均ドキュメントサイズで決定
• それ以外の場合は、値2、4、8、16を試すことができます...コレクションに最適な値が見つかるまで
MaxDegreeOfParallelism
• 並列に実行するバックエンド要求の数
• 0 に設定すると、実行が順番に実行
• 正の値を指定すると、同時操作の数が制限される
• パーティション数に設定すると、パーティションごとに 1 回の実行が実行され、通常は最も最適
• < 0 に設定すると、システムは実行する同時操作の数を自動的に決定する

• WITH 句を使用して、入れ子になった配列を列として公開し、データ型を最適化
Query Azure Cosmos DB data using a serverless SQL pool in Azure Synapse Link Preview -
Azure Synapse Analytics | Microsoft Docs

スケールアウトのため
分散処理の Know-How は、殆ど同じ
特にどう分散させるか?

Partition key 範囲
論理 partition 論理 partition
hash(pkValue)
⚡

Physical partition 1
Physical partition n
物理 partition
hash(pkValue)
⚡

5EB91C 7CEAA1 4E4899
18CE64 BE8A87 11E67F
B7D527 0AA119 842A83
BE8A87
hash(pkValue)
⚡

5806BA 8849CF 7A420E
18CE64 BE8A87 11E67F
B7D527 0AA119 842A83

Request Units
Storage Space
Request Units
Storage Space

Point reads
RU
B7D527
0AA119
7A420E
BXC890

Single-partition queries
RU
B7D527
0AA119
7A420E
BXC890
単一
Partition

Fan-out queries
RU
B7D527
0AA119
7A420E
BXC890
RU
• ファンアウトクエリ
• 関連する結果のない Partition を走査しても、

30,000
RU/s
hash(pkValue)
⚡
18CE64 BE8A87 11E67F
B7D527 0AA119 842A83

30,000
RU/s
hash(pkValue)
⚡
6,000 RU/s
6,000 RU/s
6,000 RU/s
18CE64 BE8A87 11E67F
B7D527 0AA119 842A83

300,000
RU/s
hash(pkValue)
⚡
6,000 RU/s
6,000 RU/s
6,000 RU/s
18CE64 BE8A87 11E67F
B7D527 0AA119 842A83

300,000
RU/s
hash(pkValue)
⚡
10,000 RU/s
10,000 RU/s
18CE64 BE8A87 11E67F
5806BA 8849CF 7A420E
10,000 RU/s
10,000 RU/s
B7D527 0AA119 842A83

hash(pkValue)
⚡
18CE64 BE8A87 11E67F
B7D527 0AA119 842A83
30,000
RU/s
1,000 RU/s
1,000 RU/s
1,000 RU/s

hash(pkValue)
⚡
18CE64 BE8A87 11E67F
B7D527 0AA119 842A83
72%
83%
99%

hash(pkValue)
⚡
18CE64 BE8A87 11E67F
B7D527 0AA119 842A83
72%
83%
58%
5806BA 8849CF 7A420E
41%

hash(pkValue)
⚡
5EB91C
18CE64
72%
0%
58%
0%

hash(pkValue)
⚡
5EB91C
18CE64
72%
0%
58%
0%
32,000
RU/s
8,000 RU/s
8,000 RU/s
8,000 RU/s
8,000
RU/s

hash(pkValue)
⚡
72%
83%
58%
41%
正規化された
RU
x RU/s
x RU/s
x RU/s
x RU/s

• 最小値は現在1,000 RU/秒(約7,000/月)
• しかし、さらに重要なのは、各物理パーティションには
100 RU/秒しかない

• 代わりに
• 最小値は今ちょうど400 RU/s(〜3,000円
/月)
• ...まだ2つの物理 Partition
(それぞれ200 RU/秒)

パフォーマンスなどの制限が来た場合
– 最初に根本原因の調査を試みる
根本問題が不適切なパーティション分割
である場合
– 最初にそれに対処してみる
スケールアップするだけでは必ずしも問
題が解決するとは限らず、コストのかか
るソリューションになる可能性がありま
す
• 代わりに
• 最小値は今ちょうど400 RU/s(〜3,000円
/月)
• ...まだ2つの物理 Partition
(それぞれ200 RU/秒)

1) 全体のリクエストとストレージのボリュームを分散
• カーディナリティが高い Partition Key を指定して
ホットパーティションを避ける
2) 効率的なクエリとトランザクションのスコープ
• クエリが Partition Key で適切にルートされる
• ファンアウトクエリが出来るだけ発生しないようにす
る

分散されている
偏りがある

Cosmos 君は
Application の一部として扱いたい。
データベースは「別」ではなく。

Step-by-Step Achievements スムーズな学習環境
 無料
 日本語対応
 ブラウザーのみでOK
ハンズオン環境も含めて
 ダウンロード可能なサンプ
ルコード
 Product/Service, 技術レベル,
job role, などに応じたガイダ
ンス
 Video, チュートリアル, ハンズ
オン
 スキルアップを促す
 ユーザープロファイ
ル毎に
カスタマイズ
www.microsoft.com/learn

www.microsoft.com/ja-jp/events

Resource
Manager
Language
Runtime(s)
Hosts
Query
Processor
RSM
Index Manager
Bw-tree++/LLAMA++
Log Manager
IO Manager
Resource Governor
Transport
Database engine
Admission control
…
…
地球 Azureリージョンデータセンタースタンプ障害ドメイン
クラスターマシンレプリカデータベースエンジン
Container
Various agents

コンテナー
リソースパーティション
コレクション
テーブルグラフ
テナント

Account
Database
Database
Database
Database
Database
Container
Database
Database
Item Conflict
Sproc Trigger UDF

Admin
Ops
AAD
Dashboard
Portal
Control
ARM
Clusters
Meta
Servers
Gateway
SDK Data
Attachments Backups Logs

Tenant Administration
(via Portal)
Operator
Azure AD
(Authentication)
Azure RM
Azure Cosmos DB
Portal
Azure Cosmos DB
Control Plane
Management
Front-end
Resource Provider
Management Workers
Azure Cosmos DB
Dashboard

Azure Cosmos DB
Database Server Cluster
Infrastructure Servers
Gateway Servers Metadata
Store
Database Servers
(Customer Content)
Compute Gateway
Azure Compute
(Customer
Workloads)
SDK
End-User
Data
Procedures

Azure Blob Storage
(Attachments)
Azure Blob Storage
(Customer Backups)
Azure Blob Storage
(Application Logs)

Geo-replication
West US2
Japan East
Admin
Ops
AAD
Dashboar
d
Portal
Control
ARM
Clusters
Meta
Servers
Gateway
SDK Data
Clusters
Meta
Servers
Gateway
SDK
Data
Attachments
Backups
Logs
Attachments
Backups
Logs

Process
Admission Control & Resource Governance
Admission Control & Resource Governance
Query engine (QVM/QIL)
Tx Management & Replication
Content Store Latch-free, Log structured index
B-tree Cache
Storage
Engine
Bw-tree Cache LSS

RU はパフォーマンスとコストの単位

Account
Database
Database
Database
Database
Database
Container
Item Conflict
Sproc Trigger UDF
=
Collection Graph Table
SQL, MongoDB Gremlin Azure Table
keyspace
Cassandra

最小 RU/秒
最大 RU/秒
入力リクエス
ト
レプリカが
休止状態
レート制
限
レート制限な
し
Serverless

Account
Database
Database
Database
Database
Database
Container
Database
Database
Item
Serverless

Account
Database
Database
Database
Container Container Container

手動モードで構成されたコンテナーオートスケール
プロビジョニングさ
れた
スループット
手動でプロビジョニングワークロードの使用パターンに基づいて
自動的かつ瞬時にスケーリング
要求/操作のレート制
限 (429)
消費量がプロビジョニングされた容量を超え
た場合に発生する可能性がある
消費されるスループットがオートスケールモードで選択
した
最大スループットの範囲内にある場合は発生しない
キャパシティ・プラ
ンニング
初期キャパシティプランニングと、必要なス
ループットの提供を行う必要がある
容量計画について心配する必要はありません。能力計画
と能力管理は自動的に処理される
料金 1 時間あたりに手動でプロビジョニングされ
た RU/秒
単一書き込みリージョンアカウントの場合、1 時間あた
りのオートスケール RU/s レートを使用して、1 時間ご
とに使用されるスループットに対して課金
複数の書き込みリージョンを持つアカウントの場合、
オートスケールに追加料金は発生しない。時間単位で使
用されるスループットに対して、同じマルチマスター
RU/s /時間レートが課金対象
最適なワークロー
ド・タイプ
予測可能で安定したワークロード予測不能で変動するワークロード

各最大 RU/秒のストレージ制限 (GB 単位) は、(最大 RU/秒) / 100
ストレージの制限を超えた場合、Azure Cosmos DB はスループットをスケーリング
より高い最大RU/秒への変更は非同期であり、時間がかかる場合がある (通常は4-6時間)
低い最大RU/秒への変更は、ストレージ制限に依存します
最大 RU/秒を超える要求は調整され、429 状態コードが返されます

サーバーレス容量モード

• Getting started with Azure Cosmos DB
• Running applications with
• bursty, intermittent traffic that is hard to forecast, or
• low (<10%) average-to-peak traffic ratio
• Developing, testing, prototyping and running in production new applications where the traffic pattern is
unknown
• Integrating with serverless compute services like Azure Functions

ワークロードのサイズ
運用要件
パフォーマンスのニー
ズ
パフォーマンスと可用
性
データ・パターン
ワークロード使用量の
予測可能性と一貫性
1
2
3
課金の詳細
標準のプロビジョニング
小規模から無制限
あらゆる規模で高スループッ
トのワークロードをサポート
とても高い
すべての Azure リージョンで、
あらゆる規模で <10 ミリ秒の待
機時間と 99.999% の可用性を保
証
高度に予測可能
予測可能で一貫性のあるワーク
ロード、または直接スループット
管理が必要な
場所に適する
ワークロードの容量を予約し、時
間単位で課金。プロビジョニング
するものに
対して、1 秒あたり 400 要求ユ
ニット (RU/s) から
オートスケールでプロビ
ジョニング
小規模から無制限
あらゆる規模で高スループッ
トのワークロードをサポート
とても高い
すべての Azure リージョンで、
あらゆる規模で <10 ミリ秒の待
機時間と 99.999% の可用性を保
証
予測可能性が低い
予測可能性の低いワークロードや、
直接的なスループット管理の
オーバーヘッドが望ましくない場合
に適する
カスタムスループットの最大値
を設定し、時間単位で課金される。
400 RU/秒または最大値の10%か
ら、使用されるものに対して課金
される
サーバーレス
非常に小さいから中程度
現在、中程度のバーストをサ
ポート
適度
現在、単一の Azure リージョン
の
デプロイに制限
予測できない
長いアイドル期間と散発的な要求
を伴うスパイキーなワークロード
に最適
要求単位 (RU) によって課金され、
操作ごとに消費された合計に対
して、ゼロから始まる
ニーズに合ったモデルを選択

Item size Reads/s Writes/s Calculation Request Units
1 KB 500 100 (500 * 1) + (100 * 5) 1,000 RU/s
1 KB 500 500 (500 * 1) + (500 * 5) 3,000 RU/s
4 KB 500 100 (500 * 1.3) + (100 * 7) 1,350 RU/s
4 KB 500 500 (500 * 1.3) + (500 * 7) 4,150 RU/s
64 KB 500 100 (500 * 10) + (100 * 48) 9,800 RU/s
64 KB 500 500 (500 * 10) + (500 * 48) 29,000 RU/s

1.監視対象コンテナ: 変更フィードの生成元のデータ
を含む
コンテナー
2.リースコンテナ: リースコンテナは状態ストレージ
として機能し、複数のワーカー間で変更フィードの
処理を調整する
3.ホスト: ホストは、Change Feed Processor を使用
して変更をリッスンするアプリケーション・インス
タンス。
各インスタンスは異なるインスタンス名を持つ必要
がある
4.デリゲート: デリゲートは、Change Feed
Processor が
読み取る変更の各バッチで何が行われるかを定義す
るコード

Change Feed Processor Instance Code

Change Feed Processor Delegate Code

Change Feed Processor Estimator Code

自動的に再試行さ
れない

Document
Document TTL
Default TTL

約 10,000 クエリ/秒を見積もってみましょう
SELECT TOP 1 * FROM c WHERE c.vin = “Z3YM…" ORDER BY c.timestamp DESC
このクエリを 1 秒あたり何回実行する必要があるか??

Operation Request Charge Operations/sec Total
Write to container 5 RU’s 200/sec 1,000 RU / sec
SELECT TOP 1 * FROM
c WHERE c.vin =
“Z3YM…" ORDER BY
c.timestamp DESC
35 RU’s 10,000/sec 350,000 RU / sec
Operation Request Charge Operations/sec Total
Write to container 5 RU’s 200/sec 1,000 RU / sec
Update to container
with current status
9 RU’s 200/sec 1,800 RU / sec
Read current status
from container
1 RU’s 10,000/ sec 10,000 RU / sec
351,000 RU’s
12,800 RU’s

Microservice #1
Microservice #N
Microservice #2
…

Subscription User Create Date …
123abc Ben6 6/17/17
456efg Ben6 3/14/17
789hij Jen4 8/1/16
012klm Joe3 3/4/17
Application
User Total Subscriptions
Ben6 2
Jen4 1
Joe3 1

DASHBOARDS & REPORTS
EVENT HUBS
Triggered by Cosmos
Change Feed
IoT Devices: Streaming
Events
(from the data
generator)
AZURE FUNCTION COSMOS DB
AZURE FUNCTION
STREAM
ANALYTICS
EVENT HUBS
Azure SQL Database
(database that users
migrated from – data
generator pulls order
info from here)
Velocity
Concurrency

Event/stream
processing app tier
Consumer 1
Consumer 2
Consumer 3

Change Feed – RETRIEVING Key Ranges

Change Feed - Consuming Change Feed

Change Feed Primitives - Consume Change Feed

https://www.nuget.org/package
s/Microsoft.Azure.DocumentDB.
ChangeFeedProcessor/

Change Feed PROCESSOR – Interface
Implementation

Change Feed PROCESSOR - Registration

 大量のデータがある場合、
分析クエリの実行には時間が
かかり、リソース集中型にな
る
 OLTP ワークロードの
パフォーマンスへの大きな影
響
リアルタイム
アプリ/サー
ビス
Azure
Cosmos DB
レポート /
ダッシュボー
ド

ユーザー
アプリ
Azure
Cosmos DB
Azure Data Lake Storage
抽出
(パイプライン)
変換 /
強化
オーケストレーション
Power BI
提供
Azure Cosmos DB から Azure Data Lake Storage に定期的にデータをイン
ジェスト
分析に最適化するために、データ形式とストレージレイヤーを管理
Apache Spark
for Synapse
Synapse
SQL

 準リアルタイムのデータ
分析
 トランザクションワーク
ロード
へのパフォーマンスの影

分析ストア
分析クエリに最適化された「列ストア」
トランザクションストア
トランザクション操作に最適化された「行ストア」
Azure Cosmos DB Azure Synapse Analytics
コンテ
ナークラウドネイ
ティブHTAP
Azure
Synapse
Link
SQL
自動同期
機械学習
ビッグデータ
分析
BI ダッシュ
ボード
オペレー
ショナル
データ
オペレーショナルデータに対する準リアルタイムの洞察を生成

• “Auto-Sync”: トランザクションデータは 2 分以
内に
分析ストアに自動的に同期
• ダウンタイムなしの自己管理コンピューティング、
スループット、ストレージ
• パフォーマンスやコストがトランザクションワー
クロードに影響しない
• 自動スキーマ推論
• Synapseとのネイティブ統合により、SQLとSpark
ランタイムでデータを直接分析
• Cosmos DB データは、Cosmos DB アカウントが
レプリケートされているすべてのグローバルリー
ジョンで分析に
使用できる

サプライチェーン分析、予測、レポート
IoT 予測メンテナンス
リアルタイムの個人用設定

Value 分析データの保持いつ使用するか?
0 or null
トランザクションストアからレプリケートさ
れたデータは無い
コンテナーはトランザクション・ワークロー
ドにのみ使用
既定値 (分析ストアがオフの場合)
-1 コンテナ内の分析データの無限の保持
分析のためにすべての履歴データを保持した
い
‘n’
アイテムは、トランザクションストアでの最
終変更時刻から "n" 秒後に分析ストアから期
限切れに
トランザクションデータとは無関係に分析ス
トア内の
アイテムを期限切れにしたい
ストレージのコスト・パフォーマンスを考慮
したい

Big data analytics
Data Preparation/Curation
Ad-hoc data
exploration
Find answer to unknown
questions
Azure Machine
Learning
Machine learning
Build and deploy models

Item Analytical Store Transactional Store
1 GB of Data $0.02/month $0.25/month
Read / Write
• Writes: $0.05 / 10K operations
• Reads: $0.005/10K operations
RUs
Synapse Analytics
Runtime
• Serverless Pool = $5.00/TB
• Spark Pool = $0.167 / vCore-hour RUs

Cosmos 君の
Performance
Monitoring

Azure Cosmos DB には、スループット、ストレージ、一貫性、可用性、待機時間のメトリック
が用意されている。Azure ポータルでは、これらのメトリックの集計ビューが提供されている
メトリックは 5 分ごとに収集され、7 日間保持されます
これらのメトリックは、データベース、コンテナー、またはリージョンごとにフィルター処理
できる
また、特定の時間粒度でメトリックをフィルター処理することも

•コンテナーにプロビジョニングされたスループットまたはストレージ容量を超えたために消費または失敗した要求の数
(429 応答コード)
Throughput metrics
•このメトリックは、データのサイズとインデックスの使用状況
Storage metrics
•このメトリックは、1 時間あたりの合計要求数に対する成功した要求の割合を示す。
成功率は、Azure Cosmos DB SLA によって定義
Availability metrics
•アカウントが動作しているリージョンで Azure Cosmos DB によって監視された読み取りと書き込みの待機時間を示す。
geo レプリケートされたアカウントのリージョン間の待機時間を視覚化できる。エンドツーエンドの要求待機時間は表示
しない
Latency metrics
•選択した整合性モデルの整合性がどの程度最終的なものになるかを示す。複数リージョンアカウントの場合、このメト
リックには、選択したリージョン間のレプリケーションの待機時間も表示される
Consistency metrics
•マスターパーティションによって処理されるメタデータ要求の数を示す。また、調整された要求を識別するのにも役立つ
System metrics

ホットパーティション

IDocumentQuery<dynamic> query = client.CreateDocumentQuery(
UriFactory.CreateDocumentCollectionUri(DatabaseName, CollectionName),
"SELECT * FROM c WHERE c.city = 'Seattle’”,
new FeedOptions
{
PopulateQueryMetrics = true,
MaxItemCount = -1,
MaxDegreeOfParallelism = -1,
EnableCrossPartitionQuery = true
}).AsDocumentQuery();
FeedResponse<dynamic> result = await query.ExecuteNextAsync();
// Returns metrics by partition key range Id
IReadOnlyDictionary<string, QueryMetrics> metrics = result.QueryMetrics;

Response Status Codes
• 要求が失敗すると、Azure Cosmos DB は明確に定義された HTTP 状態コードを使用
して応答し、特定の要求が失敗した正確な理由をより詳細に提供できます。.
Response Headers
• Azure Cosmos DB では、さまざまな HTTP ヘッダーを使用して、要求の結果、エ
ラー条件、および次のようなアクションを実行するための有用なメタデータに関す
る洞察を提供します。:
• Resume request
• Measure RU/s charge associated with request
• Access newly created resource directly.
HTTP response codes
2xx Success
4xx Client Errors
5xx Server Errors

JAZUG12周年俺の Azure Cosmos DB

JAZUG12周年俺の Azure Cosmos DB

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à JAZUG12周年俺の Azure Cosmos DB

Similaire à JAZUG12周年俺の Azure Cosmos DB (20)

Plus de Daiyu Hatakeyama

Plus de Daiyu Hatakeyama (20)

Dernier

Dernier (11)