SQL Data Warehouse を使ってみる その 1 に引き続き SQLDW について。
前回の投稿で接続できるようになりましたので、今回は SQLDW の構成を見ていきたいと思います。
SQLDW は膨大な並列処理 (MPP) アーキテクチャにより構成されており、コンピューティングとストレージが分離され、スケーラビリティが確保された環境となっています。
Ignite 2015 の Microsoft Azure SQL Data Warehouse Overview のスライドで構成概要が説明されています。
SQLDW は右側の MPP の構成となっています。
以下の図は、SQL Server to SQL Server PDW Migration Guide (AU3) で開設されているベースとなっている PDW の構成となります。
この構成と同様に、SQLDW も以下の要素で構成がされているようです。
- コントロールノード (制御ノード)
- コンピュートノード (計算ノード)
- ディストリビューション
Introducing Azure SQL Data Warehouse のスライドの内容ですと以下の図のような構成ですね。
上記の図ですと、Balanced storage が ドキュメントに出てくるディストリビューション になるかと思います。
■制御ノード
制御ノードはクエリ実行の中心となる制御ノードで、こちらについては SQLDW では意識することはないかと思います。制御ノードは 1 ノードが担当することになります。(内部的には Active / Passive になっていると思いますが)
■計算ノード
計算ノードについては、クエリ実行の性能にかかわってきます。
ノード数については、スケールの DWU に応じて変化し、100DWU につき、1 ノード追加される、スケールしていくようです。
■ディストリビューション
ディストリビューションは実際にデータを格納する分散ストレージ部分となります。
ドキュメントで Azure ストレージのページ BLOB が使用されていると記載されている箇所ですね。
現状の Preview では、SQLDW を使用すると 60 のディストリビューションが作成され、各ディストリビューションにデータが分散されて配置されるようです。
現状、DWU を変更してもディストリビューションの数は 60 から変化がないようです。
# 変化するとリバランシングが発生するのでそれはそれで大変だと思いますが。
データベースは複数のディストリビューションで構成され、それが仮想的に一つのデータベースとして見える形になっています。
ディストリビューション自体もデータベースのようですので、Azure ストレージ上に配置されたデータベースがディストリビューションとなるかと。
100 DWU の環境だと以下のような構成となるかと。
SQL Server と書いていますが、SQL Server ベースのデータベースエンジンが搭載されている形になるかと思います。
# SQL Database のコンピューティング用のノードがそのままついているのかもしれませんが。
ディストリビューションは計算ノードからアクセスされるため、計算ノードが一つの場合はすべてのディストリビューションが、単一のノードからアクセスされる状態となります。
DWU を変更し、計算ノードが複数になった場合はディストリビューションが各ノードに分散されてアクセスがされるようになります。
SQLDW では、環境の状態を確認できる各種 DMV が提供されていますので、実際にデータから確認してみたいと思います。
まずは 100 DWU の状態について。
ノードの構成については以下のようなクエリで確認することができます。
-- SQLDW ノード情報 select * from sys.dm_pdw_nodes node LEFT JOIN sys.dm_pdw_nodes_os_sys_info sysinfo ON node.pdw_node_id = sysinfo.pdw_node_id
結果は以下のようになります。
100 DWU ですので、制御ノード 1 / 計算ノード 1 で構成されていることが確認できますね。
次にディストリビューションの情報を確認してみます。
-- ディストリビューションの確認 select * from sys.pdw_distributions select pdw_node_id, count(*) from sys.pdw_distributions group by pdw_node_id
ディストリビューションの全レコードについては省略してしまいますが、ノード 18 (計算ノード) に60 のディストリビューションが関連付けられていることがここから確認ができるかと。
冒頭でディストリビューションはデータベースと記載しましたが、この情報については以下のクエリで確認ができます。
-- データベース情報 select node.*, pdw_database.* from sys.pdw_nodes_pdw_physical_databases pdw_database left join sys.dm_pdw_nodes node on pdw_database.pdw_node_id = node.pdw_node_id order by pdw_database.pdw_node_id,database_id select node.pdw_node_id,type,count(*) from sys.pdw_nodes_pdw_physical_databases pdw_database left join sys.dm_pdw_nodes node on pdw_database.pdw_node_id = node.pdw_node_id group by node.pdw_node_id,type
今回は「SQLDW」というデータベースを作成したのですが、そのような名称のデータベースは PDW 向けの DMV からは確認することはできません。
計算ノードにはシステムデータベース (master/tempdb/model_userdb/model_masterdb) のほかには、「Distribution_xx」というデータベースが 60 個関連づいており、合計で 64 このデータベースが設定されている状態となっています。
「Distribution_1」~「Distribution_60」までの全 60 データベースで、「SQLDW」というユーザーデータベースが仮想的に構成されている形になるかと。
それでは、200 DWU に変更して、再度同一の情報を取得してみます。
計算ノードが追加されたことで、ディストリビューションが分散されて関連付けられていることが確認できますね。
計算ノードとディストリビューションは疎結合となっているようで、DWU を変更し、計算ノードが追加されるのに時間はさほどかからず、関連付けの変更が実施されています。
現状、最大で 2,000 DWU ですので、2,000 DWU で計算ノードが 20 ノードとなった場合には、各計算ノードに 3 個のディストリビューションが関連付けられた形になるかと。
サーバー全体のざっくりとした構成はこのようになっているようですね。