このトピックでは、Hologres の仮想ウェアハウスにデータアクセス権限を付与する方法について説明します。
注意事項
-
仮想ウェアハウス A を使用してテーブルグループを作成すると、その仮想ウェアハウスがテーブルグループのデフォルトのリーダー仮想ウェアハウスになります。
-
メモリの状態は、ミリ秒レベルのレイテンシーで仮想ウェアハウス間で同期されます。リーダー仮想ウェアハウスにデータを書き込むと、システムはメモリ内のデータをフォロワー仮想ウェアハウスに同期します。このプロセスでは、フォロワー仮想ウェアハウスで少量の CPU およびメモリリソースが消費されます。仮想ウェアハウス間の仕様差は 4 倍以内に抑えることを推奨します。
-
インスタンスのデフォルトの仮想ウェアハウスのみが外部テーブルに書き込むことができます。
-
Hologres V2.0 では、仮想ウェアハウスは以下のように読み取りタスクと書き込みタスクをサポートします。
-
フォロワー仮想ウェアハウス (テーブルグループをロードしたウェアハウス) は、そのテーブルグループ内のテーブルに対して読み取りタスクのみを実行できます。書き込みタスクはサポートされていません。
-
リーダー仮想ウェアハウス (テーブルグループのリーダーとして指定されたウェアハウス) は、そのテーブルグループ内のテーブルに対して読み取りタスクと書き込みタスクの両方を実行できます。
-
テーブルグループをロードしていない仮想ウェアハウスは、そのテーブルグループからの読み取りも書き込みもできません。
-
-
Hologres V4.0 では、仮想ウェアハウスのインスタンスアーキテクチャがアップグレードされました。読み取りタスクと書き込みタスクのサポートは以下の通りです。
-
hg_warehouse_enable_use_local_resourceGUC パラメーターを有効にする必要があります。詳細については、「GUC パラメーター」をご参照ください。 -
Fixed Plan によって最適化されていない読み取りタスクと書き込みタスクについては、テーブルグループを仮想ウェアハウスにロードせずに実行できます。
-
Fixed Plan によって最適化できる読み取りタスクと書き込みタスクについては、「Fixed Plan を使用した SQL 実行の高速化」をご参照ください。
-
リアルタイム書き込みやバッチ書き込みを含むすべての書き込みタスクは、DML 自動ルーティング機能を使用して、実行のためにリーダー仮想ウェアハウスにルーティングできます。
-
|
タスクタイプ/仮想ウェアハウスタイプ |
リーダー仮想ウェアハウス |
フォロワー仮想ウェアハウス |
その他の仮想ウェアハウス |
|
リアルタイム書き込み |
サポートされています |
サポートされていません |
サポートされていません |
|
バッチ書き込み |
サポートされています |
サポートされています |
サポートされています |
|
Key/Value ポイントクエリおよび Prefixscan |
サポートされています |
サポートされています |
サポートされていません |
|
その他の読み取りタスク |
サポートされています |
サポートされています |
サポートされています |
テーブルグループのアクセス権限の表示
-
構文
現在のインスタンス内のすべての仮想ウェアハウスのテーブルグループ権限情報を表示するには、次の SQL ステートメントを実行します。
SELECT * FROM hologres.hg_warehouse_table_groups; -
パラメーター
次の表に、hg_warehouse_table_groups テーブルの列について説明します。
パラメーター
型
説明
例
warehouse_name
TEXT
仮想ウェアハウスの名前。
init_warehouse
warehouse_id
INTEGER
仮想ウェアハウスの一意の ID。
1
database_name
TEXT
データベースの名前。
wh_demo
tablegroup_name
TEXT
テーブルグループの名前。
wh_demo_tg_default
leader
BOOLEAN
仮想ウェアハウスがテーブルグループのリーダー仮想ウェアハウスであるかどうかを示します。
t
replica_count
INTEGER
レプリカ数。
1
テーブルグループの仮想ウェアハウスへのロード
テーブルグループを仮想ウェアハウスにロードすると、その仮想ウェアハウスはそのテーブルグループのフォロワー仮想ウェアハウスになります。
-
仮想ウェアハウスがテーブルグループをロードした後、その仮想ウェアハウスを使用してテーブルグループ内のテーブルを操作できます。
-
テーブルグループを仮想ウェアハウスにロードするには、インスタンスのスーパーユーザー権限が必要です。
-
構文:
CALL hg_table_group_load_to_warehouse ('<database_name>.<table_group_name>', '<warehouse_name>', <replica_count>); -
パラメーター:
パラメーター
型
説明
database_name
TEXT
データベースの名前。
table_group_name
TEXT
テーブルグループの名前。
warehouse_name
TEXT
テーブルグループをロードする仮想ウェアハウスの名前。
replica_count
INTEGER
レプリカ数。このパラメーターはオプションです。デフォルト値:1。
-
例:
-- db1 データベースの table_group_1 を、1 つのレプリカで warehouse_1 仮想ウェアハウスにロードします。 CALL hg_table_group_load_to_warehouse ('db1.table_group_1', 'warehouse_1'); -- db1 データベースの table_group_1 を、2 つのレプリカで warehouse_1 仮想ウェアハウスにロードします。 CALL hg_table_group_load_to_warehouse ('db1.table_group_1', 'warehouse_1',2);
リーダー仮想ウェアハウスの設定
-
注意事項
-
リーダー仮想ウェアハウスのみが、テーブルグループ内のテーブルに対してデータの書き込みなどの DML 操作を実行できます。
-
1 つのテーブルグループには、1 つのリーダー仮想ウェアハウスしか設定できません。リーダーを変更すると再起動が発生するため、ビジネスへの影響を考慮して計画してください。
-
テーブルグループのリーダー仮想ウェアハウスを設定するには、インスタンスのスーパーユーザー権限が必要です。
-
-
構文
CALL hg_table_group_set_leader_warehouse ('<database_name>.<table_group_name>', '<warehouse_name>'); -
パラメーター
パラメーター
型
説明
database_name
TEXT
データベースの名前。
table_group_name
TEXT
テーブルグループの名前。
warehouse_name
TEXT
リーダーとして設定する仮想ウェアハウスの名前。
テーブルグループのアンロード
-
注意事項
-
仮想ウェアハウスからテーブルグループをアンロードするには、インスタンスのスーパーユーザー権限が必要です。
-
テーブルグループをそのリーダー仮想ウェアハウスからアンロードすることはできません。まずリーダーを変更する必要があります。
-
-
構文
CALL hg_table_group_unload_from_warehouse ('<database_name>.<table_group_name>', '<warehouse_name>'); -
パラメーター
パラメーター
型
説明
database_name
TEXT
データベースの名前。
table_group_name
TEXT
テーブルグループの名前。
warehouse_name
TEXT
テーブルグループをアンロードする仮想ウェアハウスの名前。
レプリカ数の変更
-
注:仮想ウェアハウスにロードされたテーブルグループのレプリカ数を変更するには、インスタンスのスーパーユーザー権限が必要です。
-
構文
CALL hg_table_group_set_warehouse_replica_count ('<database_name>.<table_group_name>', <replica_count>,'<warehouse_name>'); -
パラメーター
パラメーター
型
説明
database_name
TEXT
データベースの名前。
table_group_name
TEXT
テーブルグループの名前。
replica_count
INTEGER
レプリカ数。
warehouse_name
TEXT
レプリカ数を変更する仮想ウェアハウスの名前。
仮想ウェアハウスの DML 自動ルーティング (ベータ版)
-
注意事項
1 つのテーブルグループには 1 つのリーダー仮想ウェアハウスしかなく、それが DML 操作を実行できる唯一のウェアハウスです。Hologres V2.2 以降では、DML 操作をテーブルグループのリーダー仮想ウェアハウスに自動的にルーティングできます。この機能を有効にすると、書き込みタスクは自動的にリーダー仮想ウェアハウスのリソースを使用して実行されますが、QPS などの書き込みタスクのメトリックはフォロワー仮想ウェアハウスに記録されます。
説明複数 DML 混合トランザクション機能を有効にした後、仮想ウェアハウスの DML 自動ルーティング機能は使用できません。複数 DML 混合トランザクション機能の詳細については、「SQL トランザクション機能」をご参照ください。
-
DML 自動ルーティングの有効化または無効化
次の GUC パラメーターを使用して、セッションレベルまたはデータベースレベルで仮想ウェアハウスの DML 自動ルーティングを有効または無効にできます。
説明仮想ウェアハウスの DML 自動ルーティング用の GUC パラメーター
hg_experimental_enable_warehouse_dml_auto_routingは、デフォルトで有効になっています。-
セッションレベル
-- 仮想ウェアハウスの DML 自動ルーティングを有効にします。 SET hg_experimental_enable_warehouse_dml_auto_routing = ON; -- 仮想ウェアハウスの DML 自動ルーティングを無効にします。 SET hg_experimental_enable_warehouse_dml_auto_routing = OFF; -
データベースレベル
-- 仮想ウェアハウスの DML 自動ルーティングを有効にします。 ALTER DATABASE <database_name> SET hg_experimental_enable_warehouse_dml_auto_routing = ON; -- 仮想ウェアハウスの DML 自動ルーティングを無効にします。 ALTER DATABASE <database_name> SET hg_experimental_enable_warehouse_dml_auto_routing = OFF;パラメーター
パラメーター
型
説明
database_name
TEXT
データベースの名前。
-
-
例
-
HoloWeb 開発ページに移動します。詳細については、「HoloWeb への接続とクエリの実行」をご参照ください。
-
HoloWeb ページの上部メニューバーで、Security Center をクリックします。
-
セキュリティセンターページの左側のナビゲーションウィンドウで、計算グループ管理 をクリックします。
-
仮想ウェアハウスリソース管理 タブで、仮想ウェアハウスの新規追加 をクリックして、
read_wh1という名前の仮想ウェアハウスを作成します。説明1 つのインスタンスには最大 10 個の仮想ウェアハウスを設定できます。各仮想ウェアハウスのリソースは最小 32 CU、最大 512 CU である必要があります。割り当てられていないコンピューティングリソースが 32 CU 未満の場合、新しい仮想ウェアハウスを作成することはできません。スケールアップするには、「仮想ウェアハウスのスケールアップ」をご参照ください。
仮想ウェアハウスが作成されると、[仮想ウェアハウスリソース管理] タブに read_wh1 仮想ウェアハウスが 実行中 のステータスで表示されます。[スケール]、[再起動]、[停止] などの操作を実行できます。
-
Management on Permissions of Virtual Warehouses on Table Groups タブで、Grant Permissions to Virtual Warehouse をクリックして、
read_wh1仮想ウェアハウスをターゲットのテーブルグループのフォロワー仮想ウェアハウスとして設定します。説明テーブルグループを作成するには、「テーブルグループの管理」をご参照ください。
権限が付与されると、リストには init_warehouse がリーダー仮想ウェアハウスとして表示されます。read_wh1 の [操作] 列には、[リーダーとして設定] と [権限の取り消し] が表示されます。
-
SQL Editor で、現在の仮想ウェアハウスを
read_wh1に設定し、仮想ウェアハウスの DML 自動ルーティングが有効および無効の状態で DML ステートメントを実行します。-
仮想ウェアハウスの DML 自動ルーティングが有効な場合、DML ステートメントはテーブルグループのリーダー仮想ウェアハウスである init_warehouse に自動的にルーティングされて実行されます。
現在の仮想ウェアハウスを read_wh1 に切り替え、
SET hg_experimental_enable_warehouse_dml_auto_routing = ON;を実行して DML 自動ルーティングを有効にし、INSERT 文を実行してデータを書き込みます。ステートメントは正常に実行され (99 行、約 53 ms)、DML 操作が実行のためにリーダー仮想ウェアハウスに自動的にルーティングされたことが確認されます。 -
DML 自動ルーティングが無効な場合、DML ステートメントはリーダーである init_warehouse にルーティングされません。代わりに、現在の仮想ウェアハウスである read_wh1 が実行を試みます。リーダー仮想ウェアハウスのみがテーブルグループで DML 操作を実行できるため、これはエラーで失敗します。
DML 自動ルーティングを無効にするコマンドは
SET hg_experimental_enable_warehouse_dml_auto_routing = OFF;です。次のエラーメッセージが返されます:ERROR: Dispatch query failed: internal error: Failed to get available shards for query。HINT メッセージは、テーブルグループ (例:demo.demo_tg_default) が現在の仮想ウェアハウスでリーダーであるかどうかを確認することを示唆しています。
-
-