cosmic

Cosmos DB の論理パーティションは、コンテナーのパーティションキーに基づいてデータをグルーピングします。

Cosmos DBは、水平スケールさせるために、物理サーバー/パーティション間で、論理パーティションをシームレスに組み合わせます。
ユーザーが制御できるのは論理パーティションまでで、論理パーティションと物理パーティションのマッピングはシステム側で自動的に行います。

image

パーティショニングの設計により性能に大きく影響がでます。
良いパーティションキーとは、容量とスループットの観点からバランスが取れて分散するものです。

容量が偏ったり、スループットが偏ったりする場合には、パーティションキーを見直ししたほうがいいです。

image

cosmic

Cosmos DB の性能は、RSuで定義されています。
指定したRUsに従って、性能が提供されます。

RUsは、メモリやCPU、IOPSが抽象化して表現されたものです。
1KBのItemを1Readすると1RUs。
1KBのItemを1Write1すると5RUs。

RUsが課金に関係してくるので、各クエリのRUsをいかに低くするのかが重要な性能チューニングポイントになります。
RUsを抑えるデータモデリングについては、こちらの「Cosmos DBのデータモデリングの勘所」を参照してください。

image

SDK

PR #561: GetItemLinqQueryable now works with null query
Azure Cosmos DB .NET SDK Version 3.0 のバグ情報。

GetItemLinqQueryableを使っているときに、結果がNULLになると例外が発生するバグ修正がマージされました。
次ようなコードがあったときに、ItemがNullになると例外が発生します。

var allObjects = this.container.GetItemLinqQueryable<ExampleObject>(true).ToList();

SDK

元ネタ:ISSUE:#550 serializerSettings with v3 client

Version 2までは、Clientにシリアライザの設定をすることができました。

var serializerSettings = new JsonSerializerSettings { NullValueHandling = NullValueHandling.Ignore };

this.client = new DocumentClient(new Uri(this.options.CosmosDbEndPoint), this.options.CosmosDbKey, serializerSettings: serializerSettings);

しかし、2019/07/16段階では、Version 3ではカスタム設定が削除され、カスタムのシリアライザを設定できるようになりました。

参考:シリアライザの設定

参考:既定のシリアライザの実装

既定のシリアライザの設定を変更する方法を提供しない理由はないので、ISSUEとしてあがりました。

ISSUE:#551 Add support for JsonSerializerSettings on default serializer

カスタムシリアライザの使用方法

サンプル:https://github.com/Azure/azure-cosmos-dotnet-v3/pull/560/files

  1. CosmosSerializerを継承してカスタムシリアライザクラスを作成する。
  2. CosmosClientOptionsで、Serializerに作成したカスタムシリアライザクラスのインスタンスを渡す
  3. CosmosClientのインスタンス作成時にOptionを渡す

class JsonSerializerIgnoreNull : CosmosSerializer
{
    ……..
}

CosmosClientOptions options = new CosmosClientOptions()
{
     Serializer = new JsonSerializerIgnoreNull(),
};

CosmosClient client = new CosmosClient(endpoint, key, options)

SQL Azure

今後、改善が入るとおもうので、あくまでも本日時点の考慮ポイントとなります。

1.新規にHyperscale環境を作成し利用する

現在、128GB以上を使用しているDTUモデルのAzure SQL Database からHyperscale環境に移行をしようとしていて、かつ少しでも性能をよくしたい場合の話になります。

128GB以上を使用しているデータベースから移行する場合は、新規にHyperscale環境を作成し、データをMigration Wizardなどクライアントツールを使用してデータを移行させて、アプリケーションの向き先を切り替える対応が最もHyperscale環境の性能が良くなります。

Azure Portal の設定から、モデルを切り替えた場合は少し性能的に不利になります。

Azure SQL Database ではデータファイルのサイズが1TBと128GBの2種類が提供されています。
そして、128GBのデータファイルを使用したほうが、性能的にちょびっと有利になります。

128GB以上を使用しているデータベースから移行すると、データベースファイルは1TBが使用されてしまいます。

新規環境にデータを流し込むことで、128GBのデータファイルが選択され、追加されていくので性能的に有利になります。
現在のところ、データファイルサイズを明示的に選択はできないので、マイグレーションは新規にするのがよさそうです。

※性能影響なんであるの?どれぐらいあるの?は、きっとムッシュ案件。

2.CPUコア数の選択

P15 4000DTUのCPUコア数は通常32コアになっています。
その環境からHyperscaleに移行するなら、40コアでいいのかなと思うのですが、ちょっと事情が違うかもしれません。

ハイパースレッディングがらみで、DTUの32コアは、Hyperscaleの64コア相当になるかもしれません。
(これは、まだ検証中)

なので、4000DTUから移行するときには、80コアがよさそう。
なんとなく80コアを選ぶと、CPU使用率が2/3になったので、間違ってはなさそう?

3. DTUからHyperscaleへの移行時間

3TBぐらいあって、時々書き込みが発生するDTU P11からHyperscale 第4世代6コアに、Azure Portalから移行させました。

設定変更ボタンを押してから5時間程度かかって、最終処理、環境の切り替えで約8分ほどオフラインになった後、Hyperscaleに変更されました。
設定で対応する場合には、8分オフラインになることを見越して計画をしましょう。