Apache Doris リソース分離の詳細な説明
1. 簡単な紹介
主に BE ノード用
Doris のマルチテナントおよびリソース分離スキームの主な目的は、複数のユーザーが同じ Doris クラスター内でデータ操作を実行する場合の相互干渉を軽減し、クラスター リソースを各ユーザーにより合理的に割り当てることです。
2. テスト体験
2.1 BEノード設定ラベル
注: 1 つの BE は 1 つのタグの設定のみをサポートします。
Doris クラスター内の BE ノードにはタグ (タグ) を付けることができ、同じタグが付いた BE ノードはリソース グループ (リソース グループ) を形成します。リソース グループは、データ ストレージとコンピューティングの管理単位とみなすことができます。
2.1.1 グループ化前
2.1.2 グループ化の開始
-- 3个节点划分成2个资源组
alter system modify backend "be01:9050" set ("tag.location" = "group_a");
alter system modify backend "be02:9050" set ("tag.location" = "group_b");
alter system modify backend "be03:9050" set ("tag.location" = "group_c");
2.1.3 グループ化後
2.2 リソースグループに応じたデータの分散
リソース グループを分割した後、ユーザー データの異なるコピーを異なるリソース グループに分散できます。
2.2.1 テストテーブルの作成
-- 以SQL99其中一张维表为例，每个资源组放一个副本
create table tpcds.catalog_returns_duplicate
(
cr_item_sk integer not null,
cr_order_number integer not null,
cr_returned_date_sk integer ,
cr_returned_time_sk integer ,
cr_ship_date_sk integer ,
cr_refunded_customer_sk integer ,
cr_refunded_cdemo_sk integer ,
cr_refunded_hdemo_sk integer ,
cr_refunded_addr_sk integer ,
cr_returning_customer_sk integer ,
cr_returning_cdemo_sk integer ,
cr_returning_hdemo_sk integer ,
cr_returning_addr_sk integer ,
cr_call_center_sk integer ,
cr_catalog_page_sk integer ,
cr_ship_mode_sk integer ,
cr_warehouse_sk integer ,-- cr_reason_sk integer ,
cr_return_quantity integer ,
cr_return_amount decimal(7,2) ,
cr_return_tax decimal(7,2) ,
cr_return_amt_inc_tax decimal(7,2) ,
cr_fee decimal(7,2) ,
cr_return_ship_cost decimal(7,2) ,
cr_refunded_cash decimal(7,2) ,
cr_reversed_charge decimal(7,2) ,
cr_store_credit decimal(7,2) ,
cr_net_loss decimal(7,2)
)ENGINE=olap
DUPLICATE KEY(`cr_item_sk`,`cr_order_number`)
DISTRIBUTED BY HASH(`cr_item_sk`,`cr_order_number`) BUCKETS 10
PROPERTIES("replication_allocation"
= "tag.location.group_a:1, tag.location.group_b:1, tag.location.group_c:1");
2.2.2 テストデータのインポート
-- 随机测试写入几条数据验证
insert into tpcds.catalog_returns_duplicate values
(.....)
2.3 ユーザリソースの使用権限制御
ユーザーのリソース使用権限を設定することで、特定のユーザーのクエリは、指定したリソースグループ内のノードを使用してのみ実行できます。
2.3.1 テストユーザーの作成
-- 用户名@用户端连接所在的主机地址（测试不设置密码）
-- 默认为 '%'，即表示该用户可以从任意host连接到 DorisDB
CREATE USER 't_rg_user01'@'%';
CREATE USER 't_rg_user02'@'%';
CREATE USER 't_rg_user03'@'%';
2.3.2 許可されたユーザー
-- GRANT授权（授予所有库和表的权限给用户）
GRANT SELECT_PRIV ON *.* TO 't_rg_user01'@'%';
GRANT SELECT_PRIV ON *.* TO 't_rg_user02'@'%';
GRANT SELECT_PRIV ON *.* TO 't_rg_user03'@'%';
2.3.3 ユーザーリソースの使用権限の設定
set property for 't_rg_user01' 'resource_tags.location' = 'group_a';
set property for 't_rg_user02' 'resource_tags.location' = 'group_b';
set property for 't_rg_user03' 'resource_tags.location' = 'group_a, group_b, group_c';
2.3.4 認証局
- テストクエリSQLの準備
select * from (
select * from catalog_returns_duplicate crd0402
) t1
JOIN
(
select * from catalog_returns_duplicate crd0402
) t2 on t1.cr_item_sk = t2.cr_item_sk
JOIN
(
select * from catalog_returns_duplicate crd0402
) t3 on t2.cr_item_sk = t3.cr_item_sk
JOIN
(
select distinct cr_item_sk from catalog_returns_duplicate crd0402
) t4 on t3.cr_item_sk = t4.cr_item_sk
- クエリを開始
grafana の [be scan rows] アイコンから、各ユーザーが使用するリソースが設定に基づいて対応するメモリ分離を持っていることがはっきりとわかります。
2.4 読み取りおよび書き込み権限の検証
書き込みなしの読み取り専用、または読み取り権限の検証なしの書き込みのみ
-- 用户创建
CREATE USER 't_only_read_user'@'%';
CREATE USER 't_only_write_user'@'%';
-- 对指定的库或表的读取权限
GRANT SELECT_PRIV ON *.* TO 't_only_read_user'@'%';
-- 对指定的库或表的导入权限
GRANT LOAD_PRIV ON *.* TO 't_only_write_user'@'%';
3. 構成の最適化
リソース グループのアプローチは、ノード レベルでリソースを分離して制限することです。
リソース グループでは、リソースのプリエンプションが引き続き発生する可能性があります。リソース制限機能は 1 つのクエリに対して使用できます。
3.1 メモリ制限
-- 设置会话变量 exec_mem_limit。则之后该会话内（连接内）的所有查询都使用这个内存限制。
set exec_mem_limit=1G;
-- 设置全局变量 exec_mem_limit。则之后所有新会话（新连接）的所有查询都使用这个内存限制。
set global exec_mem_limit=1G;
-- 在 SQL 中设置变量 exec_mem_limit。则该变量仅影响这个 SQL。
select /*+ SET_VAR(exec_mem_limit=1G) */ id, name from tbl where xxx;
3.2 CPU制限
-- 设置会话变量 cpu_resource_limit。则之后该会话内（连接内）的所有查询都使用这个CPU限制。
set cpu_resource_limit = 2
-- 设置用户的属性 cpu_resource_limit，则所有该用户的查询情况都使用这个CPU限制。该属性的优先级高于会话变量 cpu_resource_limit
set property for 'user1' 'cpu_resource_limit' = '3';
4. まとめ
- ユーザーはクエリ リソースの物理的な分離を実現でき、書き込みにはリソースの分離は必要ありません。
- ユーザーに対するデータベースの権限とテーブルの粒度を制御できます。「ユーザー アカウント管理」を参照してください。