はじめてのCosmos DB

こんな人に向けた記事

Azure Cosmos DBを使ってみたいと思ったけど、所謂普通のDBと何が違うのか必要最低限だけまともにまとめてある記事あったら楽なのになぁと思っていた人向け。

RUって何？

Request Unitの略で、この数値が性能であり課金単位となります。
後述するデプロイ方法により、最低に指定できる値が400 RUか1,000 RUかの２パターンあります。
400 RU＝約2,943円/月が最低金額になります。開発環境用に100 RUで作れればいいのにね、というのが本音。また、課金かかる単位は「コレクション」単位でかかります。

コレクションて何？

SQL Databaseでいうところのテーブルだと考えてください。はい、これわりと大問題です。前述で「400 RU＝約2,943円/月が最低金額」「課金かかる単位は「コレクション」単位」と説明しています。ということは、10コレクション作成した場合は約3万円が最低でも月々かかってしまうわけです。
そういったわけで、月額費用を抑えるためにはコレクション数を減らす形で設計しなければいけない、という制約条件がつくわけです。
お金さえ気にしなければ、今までのDB設計と同じノリでコレクションを使えますが、こういった理由があり設計で工夫しないと「Azure Cosmos DBは高い」と、わけがわからん事を言う人が出てくるので、しっかり工夫しましょう。

具体的にRUっていくつあれば足りるの？

CRUDのどの処理を行うか、実データの大きさがどのくらいか、等で必要なコストは変わります。
参考としてですがIoT系でほぼ登録なシステムの場合、400 RUで20 count/sec程度でした。
利用条件で変化しますので、まずは実測しましょう。

データ量と最低RUの関係

MSのBLOGに書いてあるものしか正確な情報ないのですが、DocumentCollectionを作成する際のオプションOfferThroughputで400 RUと2,500 RUで作成した場合で、それぞれデータ容量と指定できるサイズのレンジが異なります。
（これは現在の仕様なので変更される可能性あるなぁと個人的には思っています。なにせわかりにくい！）

400 RU指定の場合

Storage capacity : Fixed (10GB)
Throughput (400 - 10,000 RU/s)

2,500 RU指定の場合

Storage capacity : Unlimited
Throughput (1,000 - 50,000 RU/s)

コレクション作成コードサンプル（C#)

private static async Task CreateCollectionIfNotExistsAsync(
    Action<DocumentCollection> indexPolicyAction, bool highperformance)
{
    var offerThroughput = highperformance ? 2500 : 400;

    var result = await _client.CreateDocumentCollectionIfNotExistsAsync(
        UriFactory.CreateDatabaseUri(_setting.DatabaseId),
        new DocumentCollection
        {
            Id = _setting.CollectionId,
            PartitionKey = new PartitionKeyDefinition()
            {
                Paths = new Collection<string>() { _setting.PartitionKeyName }
            }
        },
        new RequestOptions { OfferThroughput = offerThroughput }
        ).ConfigureAwait(false);
    if (result.StatusCode == HttpStatusCode.Created
        && indexPolicyAction != null)
    {
        indexPolicyAction(result);
    }
}

TIPS

2,500RU指定でコレクションを作成した場合、テスト環境であればAzureポータルでRUを2,500→1,000に下げておきましょう。
Cosmos DB→コレクション→スケール　から変更できます。

SQL Databaseとの使い分け

用途が異なるので使い分け・併用することも検討してください。
ざっくりいうと「マスタ」「トラン」はCosmosDB、「複合検索インデックス」はSQL Databaseにすると良いのではないか、というのが私の今のところの考え。

Cosmos DBの得意なこと

• 応答時間にSLAがある（＝読み取りがほとんどなマスタ系に向いている）
• 容量制限のないコレクションを作成可能（＝IoTのような大量なデータ蓄積にも向いている。SQL Databaseはせいぜい数TBが上限）
• スキーマレスなので不定なデータを扱いやすい

Cosmos DBの苦手なこと

• 突発的に負荷が上昇するシステム。確保しているRUを使い切ると瞬間的にエラーとなるので、何等かの方法で稼働状況を監視していないとシステム止まってたなんてことになります。まあこれはSQL DatabaseでもDTU 100%張り付きで動かなっていう状態と同じなのですが、それにしてもSQL Databaseよりもスパイクに弱い気はします。個人の感想です。

SQL Databaseの得意なこと

• JOINして複雑な検索が可能（＝検索インデックスをSQL Database側に作成し、実体をCosmos DBに配置といった構成はおすすめ）
• ASP.NET Identityのデータストア（Cosmos DBでむりくり使うようなGithubライブラリはありますが、更新されていないので私は採用せず）
• バックアップがフルオートで35日保持。

SQL Databaseの苦手なこと

• データ容量がある
• JSONのような不定なデータを扱いにくい

具体的な設計例

次回書きます。