Snowflake - Hybrid Table / Unistoreのパフォーマンスを検証してみた！
この記事は何
Snowflake Summit 2022にて発表された Hybrid Tableをデモ環境にて検証することが出来たので、検証内容とその結果をまとめました。
なお、Hybrid TableについてはPrivate Previewの機能となっており、今回の検証は記事公開時点（2022年8月30日）での検証内容であることにご留意ください。
Hybrid Tableとは
Hybrid Tableは、Snowflake上で作成できるOLTP向けテーブルのことで、これまでのOLAP向けテーブルとのシームレスな統合を実現することができます。
Snowflakeが提唱するUnistoreと呼ばれるOLTP/OLAPの統合ワークロードの核となる機能として提供されています。
手前味噌にはなりますが、より詳しい内容はこちらをご確認いただければと思います。
検証環境
検証に使うデータ
今回は、以下のようなデモデータを用いて検証を行います。
各テーブルのSQL定義は以下のようになります。Hybrid Tableの場合は、Primary Keyの設定が必須です。
create or replace hybrid table region_hybrid (
r_regionkey number not null primary key,
r_name string not null,
r_comment string
);
create or replace hybrid table nation_hybrid (
n_nationkey number not null primary key,
n_name string not null,
n_regionkey number not null,
n_comment string not null,
constraint fK_regionkey foreign key (n_regionkey) references region_hybrid(r_regionkey)
);
create or replace hybrid table customer_hybrid (
c_custkey number not null primary key,
c_name string not null,
c_address string not null,
c_nationkey number not null,
c_phone string not null,
c_acctbal number not null,
c_mktsegment string,
c_comment string,
constraint fk_nationkey foreign key (c_nationkey) references nation_hybrid(n_nationkey)
);
create or replace hybrid table orders_hybrid (
o_orderkey number not null primary key,
o_custkey number not null,
o_orderstatus string not null,
o_totalprice number not null,
o_orderdate date not null,
o_orderpriority string not null,
o_clerk string not null,
o_shippriority string not null,
o_comment string not null,
constraint fk_custkey foreign key (o_custkey) references customer_hybrid(c_custkey)
);
各テーブルのレコード数は以下の通りです。
| Region | Nation | Customer | Orders |
|---|---|---|---|
| 5行 | 25行 | 15万行 | 150万行 |
今回は比較のため、同じカラム定義で通常のテーブルも用意します。
検証に使ったウェアハウス
今回は、Snowflakeでの最小のウェアハウスサイズである「XS」を利用して検証します。今回のデモ環境では、ウェアハウスのサイズを変更することができなかったため、他のサイズでのパフォーマンスについては別の機会に検証したいと思います。
検証その1: トランザクション処理
Hybrid Tableが得意とするトランザクション処理について、通常のTableと比較して、どれくらいのパフォーマンス差異があるのかを検証してみます。
一般的な以下のユースケースについて検証してみます。
- ある特定の1レコードを取得する (SELECT)
- ある特定のレコードを追加する (INSERT)
- ある特定のレコードを更新する (UPDATE)
- ある特定のレコードを削除する (DELETE)
今回は、連続して5回クエリを発行してみて、クエリパフォーマンスを調べます。
SELECT
Primary Keyをwhere句で指定した形のよくあるクエリを発行してみます。
-- 通常のTable
select * from customer
where c_custkey = 50000
;
-- Hybrid Table
select * from customer_hybrid
where c_custkey = 50000
;
結果は以下のようになりました。今回はウェアハウスを立ち上げたまま連続で5回クエリしたため、各種キャッシュが効いています。通常のTableの場合、2回目以降はQuery Result Cacheが効いているので30ms程度でレスポンスしています。一方、Hybrid Tableの場合、Query Result Cacheが効かないため、徐々に改善するものの、100ms前後に留まる形となっています。
| 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | |
|---|---|---|---|---|---|
| Table | 338ms | 56ms | 42ms | 38ms | 34ms |
| Hybrid Table | 341ms | 167ms | 139ms | 92ms | 98ms |
では、より行数の多いテーブルでどうなるかも見てみます。
-- Table
select * from orders
where o_orderkey = 5000000
;
-- Hybrid Table
select * from orders_hybrid
where o_orderkey = 5000000
;
| 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | |
|---|---|---|---|---|---|
| Table | 1.6s | 68ms | 44ms | 45ms | 34ms |
| Hybrid Table | 353ms | 256ms | 104ms | 96ms | 92ms |
より行数が多いと、通常のテーブルでは初回のクエリにかなり時間がかかるようになった一方、Hybrid Tableではパフォーマンスがあまり低下していません。
INSERT
次に、5回に分けて1レコードずつ追加してインサート処理のパフォーマンスを検証してみたいと思います。
-- 通常のTable
insert into customer
values (0, 'Created', 'xxxxx', 23, '00-000-000-0000', 0.0, 'created', 'created')
;
-- 以下、PKの値を変えてレコードを追加
-- Hybrid Table
insert into customer_hybrid
values (0, 'Created', 'xxxxx', 23, '00-000-000-0000', 0.0, 'created', 'created')
;
| 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | |
|---|---|---|---|---|---|
| Table | 520ms | 407ms | 530ms | 466ms | 835ms |
| Hybrid Table | 223ms | 167ms | 136ms | 183ms | 170ms |
インサート処理に関しては、明確にHybrid Tableの方が3倍程度早くなっています。
よりデータ量が多いテーブルではどうなるかも見てみます。
-- 通常のTable
insert into orders
values (0, 1, 'O', 100, '2022-08-01', 'xxx', 'xxx', 0, 'created')
;
-- Hybrid Table
insert into orders_hybrid
values (0, 1, 'O', 100, '2022-08-01', 'xxx', 'xxx', 0, 'created')
;
| 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | |
|---|---|---|---|---|---|
| Table | 629ms | 459ms | 365ms | 482ms | 373ms |
| Hybrid Table | 179ms | 399ms | 160ms | 139ms | 119ms |
どちらのケースでもパフォーマンスはあまり変わりませんでした。
UPDATE
更新処理についても、同じレコードを5回連続で更新してみて、処理速度を確かめてみます。
-- 通常のTable
update customer set c_comment = 'updated'
where c_custkey = 50000
;
-- Hybrid Table
update customer_hybrid set c_comment = 'updated'
where c_custkey = 50000
;
| 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | |
|---|---|---|---|---|---|
| Table | 3.5s | 827ms | 997ms | 933ms | 902ms |
| Hybrid Table | 206ms | 211ms | 193ms | 446ms | 189ms |
インサート処理に比べると、より差が明確になりました。4-5倍の速度差が生じています。
より大きいテーブルに対しても検証してみます。
-- Table
update orders set o_comment = 'updated'
where o_orderkey = 5000000
;
-- Hybrid Table
update orders_hybrid set o_comment = 'updated'
where o_orderkey = 5000000
;
| 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | |
|---|---|---|---|---|---|
| Table | 3.0s | 1.5s | 1.4s | 1.4s | 1.2s |
| Hybrid Table | 351ms | 332ms | 172ms | 164ms | 178ms |
通常のTableでは速度低下が見られる一方、Hybrid Tableはほとんど性能劣化していません。
レコードを削除する
最後に、レコードを1つずつ、5回削除してみます。追加処理の検証で作成したレコードを削除していきます。
-- 通常のTable
delete from customer
where c_custkey = 0
;
-- Hybrid Table
delete from customer_hybrid
where c_custkey = 0
;
| 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | |
|---|---|---|---|---|---|
| Table | 1.2s | 602ms | 460ms | 473ms | 307ms |
| Hybrid Table | 337ms | 194ms | 165ms | 160ms | 167ms |
更新処理ほどではありませんでしたが、こちらも、Hybrid Tableの方が早い結果となりました。
より大きいテーブルでも試してみましたが、どちらの場合でも大きな変化は見られませんでした。
-- 通常のTable
delete from orders
where o_orderkey = 0
;
-- Hybrid Table
delete from customer_hybrid
where c_custkey = 0
;
| 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | |
|---|---|---|---|---|---|
| Table | 539ms | 497ms | 529ms | 463ms | 289ms |
| Hybrid Table | 168ms | 207ms | 142ms | 136ms | 143ms |
まとめ
トランザクション処理の基本的な操作について、通常のTableとHybrid Tableで比較してみました。
当然ではありますが、Hybrid Tableの方が優位という結果になりました。特に更新処理では大きい差が出ています。
通常のトランザクション処理として考えた場合には、パフォーマンスにやや物足りなさを感じてしまいますが、Hybrid Tableは開発中の機能ですし、今回の検証ではウェアハウスサイズも最小のものしか利用できなかったこともあり、改善の余地は非常にあると考えられます。引き続き今後も検証していきたいと思います。
検証その2: アナリティクス処理
Summitでは、Hybrid TableとTableを組み合わせてデータ分析することができると紹介されていました。実際のユースケースとしても、RDBとDWHのデータを組み合わせて分析したい場合があると思います。そこで、以下の3パターンで、パフォーマンスがどのように変わるかを検証してみます。
- Tableのみから分析
- Hybrid Tableのみから分析
- TableとHybrid Tableを組み合わせて分析
今回は、アジアRegionの顧客の全注文の合計金額を集計するクエリを発行してみます。
Tableのみ / Hybrid Tableのみ から分析
まずは、組み合わせない場合のパフォーマンスについて見てみます。
-- 通常のTableのみで集計
select sum(o_totalprice) from orders o
join customer c on o.o_custkey = c.c_custkey
join nation n on n.n_nationkey = c.c_nationkey
join region r on r.r_regionkey = n.n_regionkey
where r.r_name = 'ASIA'
;
-- Hybrid Tableのみで集計
select sum(o_totalprice) from orders_hybrid o
join customer_hybrid c on o.o_custkey = c.c_custkey
join nation_hybrid n on n.n_nationkey = c.c_nationkey
join region_hybrid r on r.r_regionkey = n.n_regionkey
where r.r_name = 'ASIA'
;
| 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | |
|---|---|---|---|---|---|
| Table | 3.8s | 39ms | 33ms | 46ms | 39ms |
| Hybrid Table | 1m18s | 7.4s | 7.7s | 7.5s | 7.3s |
通常のTableのみから構成される集計クエリの場合、2回目以降はQuery Result Cacheが効くようになります。一方、Hybrid Tableを含むクエリの場合にはQuery Result Cacheは効かず、毎回処理が行われているようです。
TableとHybrid Tableを組み合わせて分析
-- ordersのみ、hybrid tableを利用する
select sum(o_totalprice) from orders_hybrid o
join customer c on o.o_custkey = c.c_custkey
join nation n on n.n_nationkey = c.c_nationkey
join region r on r.r_regionkey = n.n_regionkey
where r.r_name = 'ASIA'
;
-- customerのみ、hybrid tableを利用する
select sum(o_totalprice) from orders o
join customer_hybrid c on o.o_custkey = c.c_custkey
join nation n on n.n_nationkey = c.c_nationkey
join region r on r.r_regionkey = n.n_regionkey
where r.r_name = 'ASIA'
;
-- order, customerをhybrid tableにする
select sum(o_totalprice) from orders_hybrid o
join customer_hybrid c on o.o_custkey = c.c_custkey
join nation n on n.n_nationkey = c.c_nationkey
join region r on r.r_regionkey = n.n_regionkey
where r.r_name = 'ASIA'
;
| 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | |
|---|---|---|---|---|---|
| order, customerがhybrid | 7.2s | 5.5s | 7.1s | 6.5s | 6.5s |
| orderのみhybrid | 6.7s | 6.3s | 6.0s | 6.3s | 8.7s |
| customerのみhybrid | 1.7s | 669ms | 773ms | 236ms | 846ms |
このjoinの中で最も大きいordersテーブル(150万行)がhybridの場合は、クエリはかなり重たいものになってしまいました。一方で、customer(15万行)のみがhybridになっている場合は、クエリのパフォーマンスは大幅に改善されています。
また、Hybrid Tableのデータを分析に使いたい場合のユースケースの多くは、最新データのみHybrid Tableから取得し、主なデータはTableに既に入っている、という状態だと想像されます。そこで、デモデータ内で最新の日付（1998-08-02)のデータを含まないorders_2テーブルを用意し、最新日のデータのみはHybrid Tableから取得して集計するような以下のクエリも試してみます。
with o as (
select * from orders_2
union all
select * from orders_hybrid where o_orderdate = '1998-08-02'
)
select sum(o_totalprice) from o
join customer_hybrid c on o.o_custkey = c.c_custkey
join nation n on n.n_nationkey = c.c_nationkey
join region r on r.r_regionkey = n.n_regionkey
where r.r_name = 'ASIA'
| 1回目 | 2回目 | 3回目 | 4回目 | 5回目 |
|---|---|---|---|---|
| 9.5s | 8.8s | 8.4s | 7.5s | 7.9s |
hybridテーブルからは一部のデータしか利用しないため、高速に処理されることを期待していたのですが、残念ながらselect * from orders_hybrid where o_orderdate = '1998-08-02'の部分の処理が重いため、クエリは高速にはなりませんでした。
まとめ
分析ワークロードでは、通常のテーブルのみのクエリの方が当然高いパフォーマンスを発揮しますが、Hybrid Tableを組み合わせた場合でも、巨大なテーブルでなければ非常に高速に処理できることがわかりました。
アドホックにHybrid TableのデータをDWHのデータと掛け合わせて分析したい、といった用途であれば現段階でも十分実用可能ではないでしょうか。
検証その3: データ同期
では、最後に、Hybrid Tableと通常のTableの間でのデータ同期について検証します。
データ同期の具体的なユースケースとしては、
- RDBのデータをDWHに同期して分析したい
- DWHでデータ集計し、集計結果をRDBに保管したい(ReverseETL, Data Activation)
といったことが想定されます。このようなユースケースにどれくらい対応できるのかを調べるため、以下のような検証を実施しました。
- Hybrid TableからTableへのデータ同期
- TableからHybrid Tableへのデータ同期
Hybrid TableからTableへのデータインサート
3つのテーブルサイズで、パフォーマンスを比較してみます。
-- 25行
insert into nation
select * from nation_hybrid
;
-- 15万行
insert into customer
select * from customer_hybrid
;
-- 150万行
insert into orders
select * from orders_hybrid
;
結果は以下のようになりました。150万行のテーブルでも20秒以内に取り込めます。最小のウェアハウスでこのパフォーマンスなので、非常に高速だと考えて良いのではないでしょうか。また、ETLツールなどを用いずに、クエリ1行でDWHにRDBデータが取り込めるのは革新的ですね...!
| nation (25行) | customer (15万行) | order (150万行) |
|---|---|---|
| 460ms | 2.4s | 17s |
なお、CDC(Change Data Capture)で、変更をリアルタイムにDWHに取り込みたいと思うことも多いと思います。Snowflakeには、テーブルの変更を追跡するストリームという機能があり、これを用いるとCDCを実現できます。しかし、残念なことに、現時点ではHybrid Tableに対してストリームを設定することはできませんでした。今後対応してくれることに期待です...!
TableからHybrid Tableへのデータインサート
こちらも、3つのテーブルサイズで、パフォーマンスを比較してみます。
-- 25行
insert into nation_hybrid
select * from nation
;
-- 15万行
insert into customer_hybrid
select * from customer
;
-- 150万行
insert into orders_hybrid
select * from orders
;
結果は以下のようになりました。制約のチェックが入る分、HybridTable->Tableより時間がかかるようになります。また、データ量に対しておおよそ線形にロード時間が伸びているようです。
15万行のbulk insert処理が30秒程度で終わるのであれば、かなり多くのユースケースで実用に耐えるのではないでしょうか。
| nation (25行) | customer (15万行) | order (150万行) |
|---|---|---|
| 500ms | 28s | 5m15s |
なお、外部キー制約を外すことで、より高速にロードすることが可能です。
終わりに
今回は、Hybrid Tableの各種パフォーマンスについて、現段階での検証を一通り実施してみました。
TableとHybrid Tableを跨いだ分析クエリやデータ同期については現段階でも実用レベルの完成度になっていると感じました。
一方で純粋なOLTP処理についてはまだ改善の余地があると思われますが、トランザクション負荷の小さいアプリケーションやキャッシュを効かせやすいアプリケーションであれば、問題なく使えそうでした。
総じて、今後の開発の期待がより高まる結果となりました！ （※記事公開時点では一部のリージョンでPrivate Previewとして提供）
なお、今回の検証の一部は、以下のYoutube Liveにて紹介しておりますので、こちらの動画も是非ご確認いただければと思います。
Twitterも始めました。Snowflakeに興味のある皆様と繋がれれば嬉しいです！
Discussion