今回はAzure Cosmos DB NoSQL(以降Cosmos DB)を使ってみました。
そして良かった点をご紹介します。
Cosmos DB とは?
- NoSQL
- 分散型
- SALに基づく10ミリ秒未満の読み込み・書き込みを10ミリ秒
といった特徴があり、今までSQLデータベースを使っていた私からしたら違うことばかりでした。
変更フィード(Change Feed)が便利
もうこれだけのためにCosmos DBを使って良いのではないか?と言って良いくらい素晴らしい機能です。
Webのバックエンド開発をしていて、「このデータが変わったらこんな処理をしたい。」といった事はよくあると思います。データの整合性の保持だったり後続処理だったり色々あります。
例えば、「Aテーブルのレコードを削除したらBテーブル、Cテーブル・・・のレコードを削除したい。」といった場合、削除のAPIを呼んだらそれに続くすべてのレコードが削除し終わるまでクライアントは待たされることになります。データが多すぎてタイムアウトなんてことも・・・
Cosmos DBの変更フィードはその問題を解決してくれます。
流れ
1. APIではAテーブルのレコードの削除だけを行います。
2. Azure FunctionがAテーブルのレコードの変更を検知します。
3. Azure FunctionはAテーブルのレコードが削除されたのでBテーブルとCテーブルのレコードを削除します。
この様にAPIの仕事は単純になり、BテーブルやCテーブルのレコードがAPIの処理速度に影響を与えることがありません。
水平スケーリングなので将来も安心
通常のデータベースサーバーは1台のマシンで管理します。そのためデータやアクセスが増えたらスペックの良いマシンに載せ替える必要があります。この載せ替えることを「垂直スケーリング」と言います。
しかしCosmos DBは違います。スペックの良いマシンに載せ替えるのではなくマシンを増やすのです。これを「水平スケーリング」と言います。データやアクセスが増えたらマシンを増やして同時に処理できるようになるのでパフォーマンス低下に強いです。
消費コスト(RU)が取得しやすいので改善しやすい
Cosmos DBは1秒間に使用できるRU値によって料金が変わります。そのため価格レベルを決める時にシステムが使用するRU値は重要になってきます。
C#のソースコードでRU値を取得する簡単な例を書きます。
var client = new CosmosClient("connectionString"); var response = await client .GetContainer("db", "container") .ReadItemAsync<Item>("id", new PartitionKey("partitionKey")); Console.WriteLine($"{response.RequestCharge}RU 消費しました。"); class Item { }
これで自身が書いた処理がどのくらいのRUを消費しているのかがわかります。
更にApplication Insightsに送信してリクエストごとに集計されるようにしたりと柔軟に出力することができます。そうしてRU消費量の多い処理を見直すことで価格レベルを下げてお得に利用することにもつながります。
おわりに
今回はCosmos DBの良かった点をご紹介しました。みなさんもぜひ1度使ってみてください。
KENTEMでは、様々な拠点でエンジニアを大募集しています!
建設×ITにご興味頂いた方は、是非下記のリンクからご応募ください。
https://hrmos.co/pages/kentem2211/jobs/A0008hrmos.co
hrmos.co