【DWH】 PostgreSQLとSnowFlake_設計思想とデータ管理の違い

Transcript

1. 【DWH】 PostgreSQLとSnowFlake 設計思想と データ管理の違い
2. 目次 1. 両者の立ち位置 2. データの基本単位と管理方法 3. データの配置と管理責任 4. アクセスモデルと最適化の考え方 5. パーティション・インデックスの位置付け 6. まとめ ※ 本資料は、 PostgreSQL（RDB）と Snowflake（DWH）を それぞれの主用途を前提に比較しています。
3. 1.両者の立ち位置 観点 PostgreSQL SnowFlake 分類 RDB → 行単位で正確に管理。 クラウド型DWH → 大量のデータを蓄積し収集分析。 主用途 OLTP(Online Transaction Processing) → 1件ずつの登録・更新・削除を高速に処理。 OLAP(Online Analytical Processing) → 大量データをまとめて集計・分析。 想定データ量 少〜中 中〜超大規模 利用形態 単体DB / クラスタ → サーバやDBの構成・運用を 利用者が管理する RDB。 SaaS → インフラやDB運用を意識せず 利用できるクラウド DWH。 ⭐PostgreSQL と Snowflake は、 　扱うデータ量と用途（ OLTP / OLAP）が根本的に異なる。
4. 2.データの基本単位と管理方法 観点 PostgreSQL SnowFlake 基本単位 行 → タプル(行)を最小単位として扱う。 ※1 マイクロパーティション → 複数行を含むデータの塊を 　最小単位として扱う。 データ指向 ※2 行指向 → 1行分のデータをまとめて保存・処理する方式。 列指向 → 列ごとにデータをまとめて 　保存・処理する方式。 データ取得 行を1件ずつ → 必要な行を1件ずつ取得する方式。 マイクロパーティションをまとめて → パーティション単位で読み込む。 ※3 ※1 PostgreSQLでは、タプル（行）はテーブルに対応するヒープ領域（データページ）に格納されている ※2 データをどの単位・構造で保存・処理するかという考え方 ※3 Snowflakeでは行ごとのメタデータは保持せず、 　 マイクロパーティション単位で「各列の範囲情報（ min/max など）」を管理する。 　 クエリ実行時は、この列メタデータを使って不要なパーティションを読み飛ばすことで、 　 スキャン量を削減し、結果として高速化を図る。 ⭐両者は用途・データ規模・利用形態が異なるため、 　設計思想や最適化の考え方も大きく異なる。
5. 3.データの配置と管理責任 観点 PostgreSQL SnowFlake 配置の制御 → データをどこに、どのように 　配置するかを誰が決めるか。 人が設計 → 利用者がパーティションや 　インデックスを設計し、配置を制御する。 システムが自動 → システムが自動的にデータを分割・配置し、 　利用者は意識しない。 パーティション → テーブルのデータを分割して 　管理する仕組み。 明示的に定義 → 利用者が分割ルール（範囲・条件など） 　を指定して作成する。 自動生成 → システムが自動的に分割し、 　利用者は定義しない。 再配置 → データの配置を見直し、 　並びや分布を整え直すこと。 手動（DDL） → 利用者がDDLを実行して、 　意図的に再配置を行う。 自動（再クラスタリング） → システムが自動的に配置を調整し、 　利用者は操作しない。 運用の主 → 誰がDBを管理するか。 DBA / 開発者 → 利用者側（DBAや開発者）が 　運用・管理を行う。 Snowflake側 → サービス提供側が運用・管理を担い、 　利用者は意識しない。 ⭐PostgreSQLではデータ配置や運用を人が設計・管理するのに対し、 　Snowflakeではシステムが自動で管理し、利用者は意識しない。
6. 4.アクセスモデルと最適化の考え方 観点 PostgreSQL Snowflake 最適化対象 行への到達 → 必要な行に、 　できるだけ早く辿り着くことを最適化する。 読まないデータの除外 → 不要なデータを事前に除外し、 　読み込まないことを最適化する。※ 1 代表要素 インデックス / TID → 行の位置（TID）を使って、 　目的の行に直接到達する仕組み。 プルーニング → 条件に合わないマイクロパーティションを 　事前に除外する仕組み。 統計の役割 行数推定 → 条件に一致する行数を見積もり、 　最適な実行計画を選択する。 ブロック除外判断 → マイクロパーティションのメタデータを使い、 　読み込む必要のないデータを除外する。 実行計画 → クエリの実行手順 行中心 → 行の取得方法や結合順序など、 　行単位の処理を中心に示す。 スキャン量中心 → 読み込むデータ量や除外された 　パーティション数など、スキャン量を中心に示す。 ※1 PostgreSQLは行を特定して処理する RDBであるのに対し、 Snowflakeは統計・分析を目的とした DWHであるため、最適化の単位や考え方が異なる。 ⭐PostgreSQLは行にどう辿り着くかを最適化し、 　Snowflakeはどのデータを読まないかを最適化する。
7. 5.パーティション・インデックスの位置付け 観点 PostgreSQL Snowflake パーティション → データを分割して管理・最適化 　するための仕組み。 設計要素 → 利用者が用途に応じて設計・定義する 　チューニング要素。 内部実装 → システム内部で自動的に管理され、 　利用者は設計しない仕組み。 パーティションの種別 RANGE / LIST / HASH → 値の範囲・指定値・ハッシュ値 　に基づいて分割する方式。 なし → 利用者が分割ルールを指定する 　仕組みは存在しない。 インデックス 主役 → 行に素早く到達するための 　主要な最適化手段。 原則使わない → 行検索を前提としないため、 　基本的に利用しない。 インデックス設計の焦点 分割ルール → どの列・どの条件でデータを分割するか 　を設計する。 データ配置 → データがどのように配置・並ぶか 　を意識する。 ⭐PostgreSQLではパーティションやインデックスが設計・チューニングの主役だが、 　Snowflakeではそれらは内部実装として扱われ、設計対象ではない。
8. 6.まとめ 1. 立ち位置の違い PostgreSQL は RDB → 行を正確・高速に扱うためのDB Snowflake は DWH → 大量データを集計・分析するためのDB 2. 最適化の考え方の違い PostgreSQL → 行にどう辿り着くかを最適化する Snowflake → どれを読まないかを最適化する 3. 設計・運用責任の違い PostgreSQL → 人が設計し、人が運用する（インデックス・パーティション・統計） Snowflake → システムが自動で管理する（マイクロパーティション・プルーニング） 4. 最後に 同じSQLが速いかどうかではなく、 どんな用途に向いているDBかを理解して使い分けることが重要。