0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Snowflakeのゼロコピーの仕組みをマイクロパーティションの状態とともに想像してみる

Last updated at Posted at 2025-12-05

はじめに

Snowflake アドベントカレンダー2025の6日目として投稿します。
今年はAI SQLとかのすごい記事がたくさん出るのかなとわくわくしつつ、自分はAIとは無縁の基本的なところ=マイクロパーティションについてを想像してみたのでまとめます。

基本は大事。「左手は添えるだけ」by花道

ゼロコピーのざっくりイメージ

Snowflakeのいいところとしてゼロコピークローンがあります。
クローンした際に、データ自体はコピーせずに、同じマイクロパーティションを参照しに行くことで実現するのがゼロコピークローンです。
イメージを描いてみました。
(スマホで見ていて字がちっちゃいよという方はクリックして拡大)
image.png
図1

TableAをクローンしてTableBを作ったら、TableB用のデータができるわけではなくてTableAのマイクロパーティションを参照しに行くということで、データをコピーしない=ゼロコピーが実現できています。
その後のそれぞれのテーブルに対する変更は、それぞれ専用のマイクロパーティションで管理されます。

疑問:ゼロコピーってコピー元が消えたらどうなるの?

でもそういう仕組みであればコピー元が消えたら見えなくなっちゃわない?という疑問があります。
image.png
図2

懸念しているのはこんなイメージです。
TableAのドロップによってTableAのマイクロパーティションもお亡くなりになると、TableBから見えなくなってしまいます。

「いや、さすがにそうならないようにSnowflakeさんやってくれてるでしょ。」
と思うんですよね。

実験

手順1:図1.ざっくりイメージの左

--TableAを作成
CREATE TABLE TableA(id number, name string);
--TimeTravel用の保持期限を0日にセット
ALTER TABLE TableA SET DATA_RETENTION_TIME_IN_DAYS = 0;
SHOW TABLES;

image.png
TimeTravel用の保持期限を0日にセットしています。
retention_timeが0になってることを確認。

--サンプルデータ追加
INSERT INTO TableA (id, name) VALUES 
(1,'あああ'),
(2,'いいい'),
(3,'ううう'),
(4,'えええ'),
(5,'おおお'),
(6,'かかか'),
(7,'ききき');

SELECT * FROM TableA;

image.png

まずは元になるTableAを作りました。適当に7レコード作成。

手順2:図1.ざっくりイメージの真ん中

--クローン
CREATE TABLE TableB CLONE TableA;
SELECT * FROM TableB;

TableAをクローンしてTableBを作成しました。
image.png
当然ですが、TableAとTableBでSELECT結果は同じです。
同じマイクロパーティションを参照しているかどうかは確認できません。
裏側ではそうなっているハズ。

手順3:図1.ざっくりイメージの右

DELETE FROM TableA WHERE id = 1;
UPDATE TableB SET name = 'んんん' WHERE id = 2;

TableAに対してデータを1つ削除します。
TableBに対してデータを1つ更新します。

SELECT * FROM TableA;

image.png
TableAのID=1のデータ削除は反映されていて
TableBに対するID=2のデータ更新は当然ですがTableAには反映されていません。
図1のA2,A3,A4のマイクロパーティションを見ているイメージ。

SELECT * FROM TableB;

image.png
TableBに対するID=2のデータ更新は反映されていて
TableAのID=1のデータ削除はTableBには反映されていません。
図1のA2,A3,B1のマイクロパーティションを見ているイメージ。

※実際のマイクロパーティションとは違いますがイメージとしてはこんな感じです。
 そもそも7行のデータではマイクロパーティションは3つにならないです。1つのはず。

手順4:図2.TableAをDrop

DROP TABLE TableA;

image.png

SELECT * FROM TableA;

image.png
もちろんSELECTできないです。

UNDROP TABLE TableA;

image.png
最初にDATA_RETENTION_TIME_IN_DAYS = 0をSETしているので、TimeTravel機能で戻すこともできません。

これでTableAがなくなりました。
TableBのデータ(Aのマイクロパーティションを参照している)は見えるのでしょうか?

SELECT * FROM TableB;

image.png

見えますね。さっきと全く同じ結果で取れました。

図2で黄緑の×を付けたところも実際は×ではないということになります。

結果:正しくはこんなイメージ(想像)

図2の訂正版イメージです。
image.png
図3

マイクロパーティション:A1とA4に黒い×を付けてますが、ここがホントに×なのかは不明です。

DropしたTableAのマイクロパーティションでも、他から参照されているマイクロパーティションは生きている。

というのがやってみた結果得られた結論です。
A2とA3のマイクロパーティションはTableBの持ち物になったのではないかと想像して、色を黄緑に変更しています。

感想

懸念事項が解消しました。
ゼロコピー、よくできてるねー(小並感)

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?