来週から PASS Summit 2020 が開催されますが、その前に、先月の更新情報を確認しておかないとなと思いチェックしてみましたとさ。
更新情報のまとめは、毎週は無理なので月次でやろうと思いました(遠い目)
Synapse Analytics の SQL on-demand の DB を跨いだクエリの実行について
Synapse Analytics (Workspace) の SQL on-demand (Serverless SQL Pool) では、次の形態の DB を利用することができます。
- SQL on-demand 用のデータベース
- OPENROWSET により、Data Lake / Synapse Link のデータを検索
- SQL on-demand のメタデータオブジェクトを格納するためのデータベース
- 共有データベース
- Spark Pool と SQL on-demand でテーブルを共有するためのデータベース
従来の、Azure SQL Database では「論理サーバー」を使用した環境の場合、サーバーはエンドポイントとなっていました。
エンドポイント内に複数のデータベースを作成することはできるのですが、各データベースは独立したリソースで動作しているため、データベースを跨いだクエリの実行にはかなり制限がありました。
SQL on-demand の場合、Azure SQL Database の論理サーバーモデルとは異なり、データベースを跨いだクエリの実行ができるようです。
Azure Synapse SQL でサポートされる Transact-SQL 機能 で、サポートされる T-SQL の機能が記載されているのですが、SQL on-demand では、データベース間のクエリはサポートとなっています。
Synapse Analytics の SQL on-demand の共有メタデータ テーブルの照合順序について
SQL on-demand (Serverless SQL Pool) では、共有メタデータテーブル という形で Spark Pool で作製した Parquet フォーマットを使用したテーブルを、SQL on-demand で参照することができます。
先日投稿した、Synapse Analytics の Serverless SQL Pool (SQL on-demand) でテキストを参照する際の文字コードの設定 (おまけで Synapse Link for Cosmos DB) でも Synapse Analytics の照合順序に触れましたが、共有メタデータテーブルでも照合順序はポイントとなる点がありますので、触れておきたいと思います。
ドキュメントについては、SQL オンデマンド (プレビュー) で Apache Spark for Azure Synapse の外部テーブル定義を同期する を参照すると良いかと。
Synapse Analytics の SQL on-demand と Query Acceleration にはどのような違いがあるのか
Synapse Analytics の SQL on-demand(Serverless SQL Pool) と、Azure Storage の Query Acceleration では、Azure Storage 上のファイルに対して、SQL を実行することが可能です。
どちらもファイル対して、SQL を実行する機能ではありますが、これらの機能ではどのような違いがあるのか気になったので簡単にではありますが比較してみました。
ツールによりデータを取得するか、SDK からクエリを実行してデータを取得するかという、そもそものユースケースに違いがありますので、あまり比較しても意味はないかもしれませんが、ざっとした比較では次のようになるかと。
| SQL on-demand | Query Acceleration | |
| 検索対象として利用可能な Azure ストレージ | Azure BLOB ストレージ Azure Data Lake Storage Gen2 |
Azure BLOB ストレージ Azure Data Lake Storage Gen2 (Synapse Link で Cosmos DB に接続可) |
| クエリの実行方法 | TDS データは TDS で取得 |
SDK データは Stream オブジェクトで取得 |
| サポートする SQL | 一般的な検索の SQL をサポート データソース間の JOIN が可能 |
限定的 な SQL をサポート 単一データソースによる検索 |
| データのエクスポート | TDS を利用可能なツール CETAS |
Stream オブジェクトをコードで操作 |
| 検索対象のファイル | CSV JSON Parquet |
CSV JSON |
| 一つのクエリで検索可能なファイル | ディレクトリ ワイルドカード |
単一ファイル |
| メタデータによる検索するファイルのフィルター | filename() 関数 filepath() 関数 |
メタデータ BLOB インデックスタグ |
Ignite 2020 の What’s New in Azure Storage では、Query Acceleration に関しては、次のような解説が行われていました。
「Deeply integrated into Azure Synapse Analytics for improved performance and cost」と説明がされています。
具体的にどのように Synaspe Anaytics と統合されているのかまでは解説されていないのですが、Synapse Analytics で使用されている Polaris という分散 SQL エンジンが内部的には使用されているのかもしれませんね。
SQL Server Management Studio 18.7 から Azure Data Studio が同時にインストールされるようになりました
SQL Server Management Studio 18.7 now generally available でアナウンスされていますが、本日 SSMS 18.7 がリリースされました。
18.7 から、SSMS のインストール時に Azure Data Studio (ADS) が同時にインストールされるようになりました。
これについては リリースノート にも記載されています。
Azure Data Studio がリリースされてから、2 年以上経過しますが、Azure Data ファミリーを使用する際には、SSMS だけでなく、Azure Data Studio を組み合わせて利用する機会が多くなってきており、SSMS を利用しているユーザーが Azure Data Studio の機能の恩恵を受けられるようにするということで、同時にインストールされるようになったようです。
SQL Server on Azure VM の AlwaysOn 可用性グループで DNN がサポートされました
DNN については、以前、Lift and Shift Always On SQL Server Failover Cluster Instance (SQL FCI) to Azure VMs で、SQL Server 2019 CU2 を適用することで、Failover Cluster Instance のサポートが行われていました。
今回、Released: Support for Dynamic Network Names (DNN) Listeners for Always On Availability Groups でアナウンスがあり、SQL Server 2019 CU8 を適用することで、SQL Server on Azure VM で AlwaysOn 可用性グループを構築する際に、可用性グループのリスナーで DNN (Dynamic Network Names) Listeners がサポートされるようになりました。
これにより、AlwaysOn 可用性グループにアクセスする際にロードバランサーを使用することなくアクセスができるようになります。
関連情報は次のドキュメントとなります。(投稿を書いている時点では、英語版にのみ情報が公開されています)
Synapse Link for Cosmos DB を SQL Ondemand で操作する場合のメモ
Synapse Link for Cosmos DB を SQL Ondemand (Serverless SQL Pool) で操作する場合のメモを。
SQL Ondemand なのか、Serverless SQL Pool なのかがよくわからないので、どちらでもヒットするようにしています (遠い目)
ドキュメントとしては次の内容をベースとしています。
Synapse Analytics の Serverless SQL Pool (SQL on-demand) でテキストを参照する際の文字コードの設定 (おまけで Synapse Link for Cosmos DB)
Synapse Analytics の Serverless SQL Pool (SQL on-demand) では、BLOB / ADL Gen2 上のファイルに対してクエリを実行することができます。
- Synapse SQL 内で SQL オンデマンド (プレビュー) リソースを使用してストレージ ファイルに対してクエリを実行する
- SQL オンデマンド (プレビュー) のストレージ アカウント アクセスを制御する
同様の内容を実現する機能としては、Azure Data Lake Storage のクエリ アクセラレーション があります。
こちらについては、しばやん先生が Azure Data Lake Storage の Query Acceleration が GA になったので試したら最高だった で機能の解説をされています。
この機能の比較をするために検証していたときに「そういえば、Serverless SQL Pool で、テキストを読むとき文字コードって何にする必要があったっけ？」と思い、軽く検証してみました。
今回は Shift-JIS / UTF8? / UTF16 LE の 3 パターンで検証しています。
使用しているデータは、本ブログのアクセスログを CSV に出力したものです。
シンプルな構成にするのであれば、次のような構成をしておけばいいのではないでしょうか。
- ファイルは UTF8 のエンコードを使用する
- データベースの照合順序は _UTF8 を使用する
- 日本語環境の SQL Server の照合順序と同様にするのであれば、次の照合順序のいずれかを使用しておけば、最新のUnicode を考慮した文字コード体系になる
- Japanese_XJIS_100_CI_AS_SC_UTF8
- Japanese_XJIS_140_CI_AS_UTF8
- Synapse SQL でのデータベースの照合順序のサポート では、140 系はサポートされていないということになっていますが、本投稿を書いているタイミングでは、設定はできます。(サポート対象なのかは要確認ですが)
- 基本的な検索であれば、任意の照合順序に「_UTF8」を設定したものであれば、ある程度カバーできるはず
- 日本語環境の SQL Server の照合順序と同様にするのであれば、次の照合順序のいずれかを使用しておけば、最新のUnicode を考慮した文字コード体系になる
- 検索条件で、文字列リテラルを使用する場合、「N’xxxxx’」の Unicde 変数で検索を行う。
Windows Server 2019 でパフォーマンスモニターのログの世代管理を実施
インサイトテクノロジーさんの db tech showcase ONLINE 2020 で、次のセッションを担当させていただきます。
本セッションでは、パフォーマンスモニターや、動的管理ビュー (DMV) の情報を使用したベースライン取得の基本的なアプローチについてお話をさせていただく予定です。
セッション資料を作成していて「そういえば Windows Server 2019 でデータコレクションの自動起動が動かない件があったな」ということを思い出したので情報をまとめておこうかと。
基本的には、次の記事を把握しておけば問題ないはずです。
- データ コレクター セットの停止に時間がかかる事象について
- Windows Server 2019: working with Performance Monitor data collector sets
今回は、スクリプトは作成せずに、GUI からの操作でできる範囲で対応していますが、本来は、logman 等を使用したタイマー起動 / 終了と、スクリプトによるファイルの削除を実施したほうが良いかと思います。
Windows Server 2008 の検証環境作成時についてのメモ
2020/10 時点で Windows Server 2008 の検証環境を構築(サポートが切れていても検証で環境を構築しないといけないときがあるのです)していた際に気づいた内容のメモを。
久しぶりに古い OS を Windows Server 2019 から触ろうとしたら、いろいろと設定忘れていました。
本投稿では、Windows Server 2008 SP2 インストール直後の環境にたいして、最新の Windows Update を適用している Windows Server 2019 で接続を行っています。