Cosmos DB の整合性レベルは、個人的にはいつもはあまり意識せずに Session を使ってます (意識する必要のない使い方や設計をしているって言った方が妥当か..)。
ただ、Document DB が出た時からもう4-5年使ってるのに、整合性レベルの日本語表記の英語の表記は頭のなかで一ミリのピンとこない (むしろ日本語表記の名称知らん) ので、それを整理したくてメモしてみました。
英語と日本語の表記
英語と日本語はドキュメントと Azure ポータルの表記を書いてみました。
| 英語 | 日本語 (ドキュメント) | 日本語 (Azure ポータル) |
|---|---|---|
| Strong | 厳密 | 強固 |
| Bounded staleness | 有界整合性制約 | (←同じ) |
| Session | セッション | (←同じ) |
| Consistent prefix | 整合性のあるプレフィックス | 一貫性のあるプレフィックス |
| Eventual | 最終的 | (←同じ) |
なんとゆーことでしょう...本日時点では表記違うし (私にとっては) その日本語の固有名詞では意味がピンとこないです。
(ポータルは基本的に英語にしてるので、ドキュメントとの表記の揺れがあるのに今気づいた...）
料金・コストの違い
直接的な価格体系に違いはないです。ただし、Strong および Bounded Staleness の Read の RU が 2倍になると、以下のドキュメントに書かれているので見ておきましょう。
ローカル マイノリティの読み取りに対する RU/秒の読み取りコストは、強度の低い一貫性レベルの場合の 2 倍です。これは、2 つのレプリカから読み取りが行われ、強固および有界整合性制約の整合性が保証されるためです。
整合性のセマンティクス
細かい仕様は公式のドキュメントを読んだ方が2億%よいので、ここではさらーっとざっくりとひとことで説明できる程度に整理しておきます。
Strong (厳密 / 強固)
全てのレプリカで最終的なコミットされたデータのみが Read できる。その分処理も遅くなるのは仕方ない。
個人的には、これを求めた時点で No SQL の DB 使わなくてよくね？とか厳密なトランザクションを必要とするならそれに強い DB 使うべきじゃね？とかアーキテクチャーに疑問を感じそう。(もし理由を聞いたら聞いてみたら妥当な場合もあるとは思いますがね)
Bounded staleness (有界整合性制約)
"K" 回の Write、またはレイテンシーの時間 "T" だけ Read が遅延する可能性があります。で、 "K" と "T" を設定可能です。レプリカの有無で設定できる値が変わります。Write できるリージョン数が単一だと同じリージョンのクライアントの整合性は Strong になるってのがある。
Write できるリージョン数と、レプリカが同一リージョンか別リージョンかによってちょっと制約はあるので詳しくは公式のドキュメントをチェック。
Session (セッション)
Cosmos DB 作成時のデフォルトの設定値。
Monotonic Read (同一のセッションでは Read においてデータの先祖がえりはしない), Monotonic Write (同一のセッションではデータの Write 順序は保証される) , Read Your own Write(RYW: 同一セッションでは Write したデータは即データが Read できる)を保証するってものです。
Write できるリージョン数と、レプリカが同一リージョンか別リージョンかによってちょっと制約はあるので詳しくは公式のドキュメントをチェック。
Consistent prefix (整合性のあるプレフィックス / 一貫性のあるプレフィックス)
Write が複数発生した場合の順序保証はあるけど、更新された最新のデータが即時 Read できる保証はない (もちろん最終的には Read できる)ってものです。
(毎回のように書いてるけど) Write できるリージョン数と、レプリカが同一リージョンか別リージョンかによってちょっと制約はあるので詳しくは公式のドキュメントをチェック。
Eventual (最終的)
Write が複数発生した場合の順序保証なし、レプリカはそのうち最終的に同期さます。ゆーてもよっぽど激しい Write じゃない限り数秒で収束すると思いますが。
参考
さっとひとことで説明できる程度にまとめただけ (全然ひとことになってないけど...)なので、詳細は公式ドキュメントで理解しましょう。
