SE の雑記

Datadog のエージェントには、標準で SQL Server のメトリクスを取得するための、Integration が含まれています。

• Collect SQL Server Custom Metrics
• SQL Server
• Key metrics for SQL Server monitoring
• Custom SQL Server metrics for detailed monitoring
• Monitor SQL Server performance with Datadog

軽く触ってみた際の覚書を。
Read the rest of this entry »

de:code 2019 の? DP06 Deep-dive in Azure Cosmos DB: Advanced topics on partitioning, data distribution and indexing で実施されていた Cosmos DB のグローバル分散のデモ で面白いなと思ったものの一つとして、リージョンが違うことによるレイテンシーの違いというものがありました。
この見せ方、面白いなと思って、SQL Database でも簡単なものを試してみました。
DTU モデルの場合は公開されていないのですが、vCore モデルの場合は、デプロイ時に次のような記載があります。

データファイル / ログファイルのような物理ファイルにアクセスする場合の想定待機時間が記載されていますね。
詳細については、仮想コアベースの購入モデルを使用した単一データベースに対するリソース制限 でまとめられているのですが、基本的な考え方としては次のようになります。

• リモートストレージへのアクセス
  • 書き込み時 : 5 ～ 7 ミリ秒程度の I/O 待機時間
  • 読み込み時 : ５～10 ミリ秒程度の I/O 待機時間
• ローカルストレージへのアクセス :
  • 書き込み時 : 1～2 ミリ秒程度の I/O 待機時間
  • 読み込み時 : 1～2 ミリ秒程度の I/O 待機時間

SQL Database はサービスレベルに応じて、使用するストレージ (接続方式) が異なります。
DTU モデルの「Basic」「Standard」と、vCore モデルの「汎用目的」については、「リモートストレージ」が使用されており、データベースは Azure Premium Storage 上に格納されています。

DTU モデルの「Premium」と、vCore モデルの「ビジネスクリティカル」については、「ローカルストレージ」が使用されており、リモートストレージと比較して、高速にアクセスができるようになっています。

データベースの処理時間を考える際には、以下の 2 点を考慮する必要があるか思います。

• アプリケーションからのアクセスを考慮した応答時間
• データベース単体の応答時間

今回はこれらを考慮した情報の取得を行ってみたいと思います。
Read the rest of this entry »