ビッグデータの時代では、大量のデータを効果的に管理および処理する方法が企業にとって中心的な課題となっています。この目的を達成するために、Tuoshupai は、より効率的で柔軟なデータ処理ソリューションを提供するように設計された新しいクラウドネイティブ仮想データ ウェアハウスとして、初のデータ コンピューティング エンジン PieCloudDB Database を立ち上げました。
PieCloudDB の設計コンセプトは、ユーザー エクスペリエンスとクエリ効率の深い理解から生まれています。PieCloudDB はストレージと計算の分離を実現しながら、新しいストレージ エンジン「Jianmo」およびその他のモジュールを特別に設計、構築しました。クラウド シナリオと分析シナリオ向けに、PieCloudDB は効率的な事前集計 (Pre-Aggregate) 機能も設計しました。この記事では、PieCloudDB が事前集計テクノロジーを使用してデータ処理プロセスを最適化し、ユーザー エクスペリエンスを向上させる方法を詳しく紹介します。
PieCloudDB は、クラウドネイティブの仮想データ ウェアハウスとして、大規模な分散クラスター、仮想マシン、コンテナーなど、クラウド コンピューティングによって提供されるインフラストラクチャ サービスを最大限に活用します。これらの機能により、PieCloudDB は動的で変化するワークロード要件にさらに適応できるようになります。同時に、PieCloudDB は、企業の増大するビジネス ニーズに対応するため、高可用性、容易な拡張、柔軟なスケーリングを実現するために、独自の機能を積極的に拡張しています。
PieCloudDB は、Pre-Aggregate という重要な革新的な機能を実装しています。この機能は、PieCloudDBの新しいストレージエンジン「JANM」を利用し、データ挿入時にデータ列の集計情報を瞬時に計算し、次回利用できるように事前に保存します。この方法では、クエリ時に複雑な計算を実行する従来の方法が廃止され、クエリ速度が大幅に向上します。さらに、集計されたデータはファイルに保存されるため、すぐにアクセスしてクエリに直接適用できます。
PieCloudDB は、ユーザーのクエリに基づいて Pre-Aggregate を使用してプランを自動的に生成し、クエリ プロセスを可能な限り高速かつ正確にします。集計データが必要な場合、システムは事前に保存されている集計値を確認し、条件を満たす集計データを直接読み取ります。これにより、クエリ プロセス中にデータ セット全体をスキャンする必要がなくなり、クエリ速度が大幅に向上します。
条件を部分的に満たすブロックの場合、PieCloudDB は元の処理方法に戻って集計値を計算します。このようにして、事前に集計されたデータを使用でき、欠落部分のみを計算する必要があるため、計算コストが削減され、計算効率が向上します。
1 事前集計の原理
Aggregate のクエリ パフォーマンスを向上させるために、PieCloudDB は「空間」を「時間」に交換する戦略を採用しており、データの書き込み時に、関連する Aggregate が事前に計算されてストレージ層に保存され、迅速にクエリできるようになります。必要な集計データを見つけます。
集計データソースの問題は上記で解決しましたので、次に、事前に計算された集計データを取得する方法を紹介します。プッシュダウンされた集約データを正しく取得するために、PieCloudDB のオプティマイザーとエグゼキューターがさらに変更され、2 つの新しい事前集約コンピューティング ノードが追加されました。変換前後のプラン ツリーの比較を次の図に示します。
改修前と改修後のプランツリーの比較
ストレージエンジン「Jianmo」は、データが挿入されるとリアルタイムで集計情報を更新します。上図では、Pre-Aggregate 計算ノードは AM (アクセス方法) から事前に計算された Aggregate データを取り出しますが、適切な Aggregate データが見つからない場合は、Pre-Aggregate 計算ノードが条件を満たすタプル計算も見つけます。 AM からの条件に対応する集計データが出力され、上位のコンピューティング ノードに返されて使用されます。これにより、プッシュダウンされた集計データを正しく見つける方法の問題が解決されます。
Pre-Aggregate は、OLAP 最適化テクノロジにおけるゾーン マップの特定の実装です。つまり、タプル属性値のバッチの集計が事前に計算されて保存されており、データベースは事前に計算された集計情報をチェックして、ブロックにアクセスするかどうかを決定します。つまり、前述したように、利用可能な集計データが見つかった場合は、それが直接返され、そうでない場合は、ブロックにアクセスして特定のタプルを取得します。
条件付き事前集計の場合、その効果は事前計算に含まれるデータ範囲によって異なります。PieCloudDB は、事前集計の範囲をブロック ファイルに縮小し、各ブロック ファイルを個別に事前計算して保存して、条件付き事前集計クエリの効果を保証します。
2 事前集計の使用のデモンストレーション
以下に、Preagg Block Scan を有効にする方法と、Block Skipping をサポートする Preagg Bitmap Block Scan の使用方法を示します。最後に、対応するパフォーマンス比較表を示します。
2.1 Preagg ブロック スキャンの使用方法
-- 创建 t 表
create table t(a int, b int, c int);
-- 写入三行数据
insert into t values(1,2,3);
insert into t values(3,3,5);
insert into t values(4,4,6);
-- 开启 preagg，默认是开启的
set pdb_enable_preagg = on;
-- 执行如下的 query
explain (costs off) select sum(b), avg(c), count(*) from t;
QUERY PLAN
------------------------------------------------
Finalize Aggregate
-> Gather Motion 3:1 (slice1; segments: 3)
-> Pre-Aggregate Block Scan on t
Optimizer: Postgres query optimizer
(4 rows)
-- 开启后的执行结果
select sum(b), avg(c), count(*) from t;
sum | avg | count
-----+--------------------+-------
9 | 4.6666666666666667 | 3
(1 row)
-- 关闭 preagg
set pdb_enable_preagg = off;
-- 执行同一条 query
explain (costs off) select sum(b), avg(c), count(*) from t;
QUERY PLAN
------------------------------------------------
Aggregate
-> Gather Motion 3:1 (slice1; segments: 3)
-> Seq Scan on t
Optimizer: Postgres query optimizer
(4 rows)
-- 关闭后的执行结果
select sum(b), avg(c), count(*) from t;
sum | avg | count
-----+--------------------+-------
9 | 4.6666666666666667 | 3
(1 row)
2.2 Preagg Bitmap Block Scan の使用方法
create table t(a int, b int);
insert into t values(generate_series(1, 20), generate_series(100, 120));
insert into t values(generate_series(21, 60), generate_series(121, 160));
-- 开启 preagg，默认是开启的
set pdb_enable_preagg = on;
-- 下面是开启 Pre-Aggregate Bitmap Block Scan 的几个 guc
set enable_seqscan = off;
set enable_bitmapscan = on;
set enable_indexscan = on;
-- 执行如下的 query
explain (costs off) select max(a), sum(a) from t where a > 10 and a < 50;
QUERY PLAN
---------------------------------------------------------------
Finalize Aggregate
-> Gather Motion 3:1 (slice1; segments: 3)
-> Partial Aggregate
-> Pre-Aggregate Bitmap Block Scan on t
Recheck Cond: ((a > 10) AND (a < 50))
-> Bitmap Index Scan on t
Index Cond: ((a > 10) AND (a < 50))
Optimizer: Postgres query optimizer
(8 rows)
-- 开启后的执行结果
select max(a), sum(a) from t where a > 10 and a < 50;
max | sum
-----+------
49 | 1170
(1 row)
-- 关闭 preagg
set pdb_enable_preagg = off;
-- 执行同一条 query
explain (costs off) select max(a), sum(a) from t where a > 10 and a < 50;
QUERY PLAN
---------------------------------------------------------------
Finalize Aggregate
-> Gather Motion 3:1 (slice1; segments: 3)
-> Partial Aggregate
-> Bitmap Heap Scan on t
Recheck Cond: ((a > 10) AND (a < 50))
-> Bitmap Index Scan on t
Index Cond: ((a > 10) AND (a < 50))
Optimizer: Postgres query optimizer
(8 rows)
-- 关闭后的执行结果
select max(a), sum(a) from t where a > 10 and a < 50;
max | sum
-----+------
49 | 1170
(1 row)
2.3 性能比較
テストテーブル:
create table preaggdata (a int, b int);
テストステートメント:
explain analyze select sum(a), avg(a), count(*), max(b) from preaggdata;
所要時間の比較表は次のとおりです。
時間のかかる比較表
上記のテストデータと比較表からわかるように、Pre-Agg をオンにしない場合、データ量が増加するにつれて消費時間は増加し続け、増加速度はますます速くなります。をオンにすると、消費時間は着実に増加し、成長率は速くありません。データ量が10000Kに達すると、約28倍の速度向上が実現します。
3 事前集計の将来の進化
現在、Pre-Aggregate はパフォーマンス効率を向上させるために、「空間」を「時間」に交換する戦略を採用しています。当社は、Pre-Aggregateの適用範囲を拡大し、ユーザーエクスペリエンスを最適化するために、今後も技術研究開発を推進し、適用シーンを拡大し、より豊富で多様な機能を提供していきます。
データ処理方法の最適化、サポートされる関数タイプの拡張、または新しいクエリ処理メカニズムの導入によって、私たちはこの目標を達成するためにたゆまぬ努力を続けています。Pre-Aggregate は間もなく、複雑なクエリ シナリオに対してより効率的かつ正確なソリューションを提供できるようになり、それによってデータ分析と処理の分野におけるアプリケーションの影響力が徐々に深まると考えられています。
