Managed Postgres のクイックスタート

NVMe による Postgres のパフォーマンスを体験し、ネイティブな ClickHouse 連携でリアルタイム分析を実現

ClickHouse Managed Postgres は、NVMe ストレージを基盤とするエンタープライズグレードの Postgres サービスです。EBS のようなネットワーク接続型ストレージと比較して、ディスクバウンドなワークロードに対して最大 10 倍高速なパフォーマンスを実現します。このクイックスタートは 2 つのパートに分かれています：

• 第1部: NVMe Postgres を使い始め、そのパフォーマンスを体感する
• 第2部: ClickHouse と統合してリアルタイム分析を実現する

Managed Postgres は現在、AWS の複数のリージョンで利用可能であり、パブリックベータ版として提供されています。

このクイックスタートでは、以下を行います：

• NVMe による高性能を備えた Managed Postgres インスタンスを作成
• 100万件のサンプルイベントを読み込み、NVMe の速度を実際に確認
• クエリを実行し、低レイテンシのパフォーマンスを体感
• リアルタイム分析のためにデータを ClickHouse にレプリケート
• pg_clickhouse を使用して、Postgres から ClickHouse に直接クエリ

​

第1部: NVMe Postgres を使い始める

​

データベースを作成する

新しい Managed Postgres サービスを作成するには、Cloud Console のサービス一覧にある New service ボタンをクリックします。その後、データベースタイプとして Postgres を選択できます。

データベースインスタンスの名前を入力し、Create service をクリックします。概要ページに移動します。

Managed Postgres インスタンスは 3～5 分で準備が完了し、使用できるようになります。

​

データベースに接続する

左側のサイドバーに Connect ボタン が表示されます。クリックすると、接続の詳細と複数のフォーマットの接続文字列を確認できます。

psql の接続文字列をコピーして、データベースに接続します。DBeaver などの Postgres 互換クライアントや、任意のアプリケーションライブラリを使用することもできます。

​

NVMe のパフォーマンスを体感する

NVMe によるパフォーマンスを実際に確認してみましょう。まず、クエリの実行時間を測定できるよう、psql でタイミング計測を有効にします。

\timing

イベント用とユーザー用のサンプルテーブルを2つ作成します。

CREATE TABLE events (
   event_id SERIAL PRIMARY KEY,
   event_name VARCHAR(255) NOT NULL,
   event_type VARCHAR(100),
   event_timestamp TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
   event_data JSONB,
   user_id INT,
   user_ip INET,
   is_active BOOLEAN DEFAULT TRUE,
   created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
   updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE users (
   user_id SERIAL PRIMARY KEY,
   name VARCHAR(100),
   country VARCHAR(50),
   platform VARCHAR(50)
);

それでは、100万件のイベントを挿入して、NVMeの速度を見てみましょう：

INSERT INTO events (event_name, event_type, event_timestamp, event_data, user_id, user_ip)
SELECT
   'Event ' || gs::text AS event_name,
   CASE
       WHEN random() < 0.5 THEN 'click'
       WHEN random() < 0.75 THEN 'view'
       WHEN random() < 0.9 THEN 'purchase'
       WHEN random() < 0.98 THEN 'signup'
       ELSE 'logout'
   END AS event_type,
   NOW() - INTERVAL '1 day' * (gs % 365) AS event_timestamp,
   jsonb_build_object('key', 'value' || gs::text, 'additional_info', 'info_' || (gs % 100)::text) AS event_data,
   GREATEST(1, LEAST(1000, FLOOR(POWER(random(), 2) * 1000) + 1)) AS user_id,
   ('192.168.1.' || ((gs % 254) + 1))::inet AS user_ip
FROM
   generate_series(1, 1000000) gs;

INSERT 0 1000000
Time: 3596.542 ms (00:03.597)

NVMe パフォーマンス

JSONB データを含む 100 万行を 4 秒未満で挿入。EBS のようなネットワーク接続型ストレージを使用する従来のクラウドデータベースでは、ネットワーク往復遅延と IOPS のスロットリングにより、同じ操作に通常 2〜3 倍の時間がかかります。NVMeストレージは、ストレージをコンピュートに物理的に直結することで、こうしたボトルネックを解消します。

パフォーマンスは、インスタンスサイズ、現在の負荷、データ特性によって異なります。

1,000 人のユーザーを挿入します:

INSERT INTO users (name, country, platform)
SELECT
    first_names[first_idx] || ' ' || last_names[last_idx] AS name,
    CASE
        WHEN random() < 0.25 THEN 'India'
        WHEN random() < 0.5 THEN 'USA'
        WHEN random() < 0.7 THEN 'Germany'
        WHEN random() < 0.85 THEN 'China'
        ELSE 'Other'
    END AS country,
    CASE
        WHEN random() < 0.2 THEN 'iOS'
        WHEN random() < 0.4 THEN 'Android'
        WHEN random() < 0.6 THEN 'Web'
        WHEN random() < 0.75 THEN 'Windows'
        WHEN random() < 0.9 THEN 'MacOS'
        ELSE 'Linux'
    END AS platform
FROM
    generate_series(1, 1000) AS seq
    CROSS JOIN LATERAL (
        SELECT
            array['Alice', 'Bob', 'Charlie', 'Diana', 'Eve', 'Frank', 'Grace', 'Hank', 'Ivy', 'Jack', 'Liam', 'Olivia', 'Noah', 'Emma', 'Sophia', 'Benjamin', 'Isabella', 'Lucas', 'Mia', 'Amelia', 'Aarav', 'Riya', 'Arjun', 'Ananya', 'Wei', 'Li', 'Huan', 'Mei', 'Hans', 'Klaus', 'Greta', 'Sofia'] AS first_names,
            array['Smith', 'Johnson', 'Williams', 'Brown', 'Jones', 'Garcia', 'Miller', 'Davis', 'Martinez', 'Taylor', 'Anderson', 'Thomas', 'Jackson', 'White', 'Harris', 'Martin', 'Thompson', 'Moore', 'Lee', 'Perez', 'Sharma', 'Patel', 'Gupta', 'Reddy', 'Zhang', 'Wang', 'Chen', 'Liu', 'Schmidt', 'Müller', 'Weber', 'Fischer'] AS last_names,
            1 + (seq % 32) AS first_idx,
            1 + ((seq / 32)::int % 32) AS last_idx
    ) AS names;

​

データに対してクエリを実行する

それでは、NVMe ストレージを使用した場合に Postgres がどれほど高速に応答するか、いくつかのクエリを実行して確認してみましょう。

100万件のイベントをタイプ別に集計する：

SELECT event_type, COUNT(*) as count 
FROM events 
GROUP BY event_type 
ORDER BY count DESC;

 event_type | count  
------------+--------
 click      | 499523
 view       | 375644
 purchase   | 112473
 signup     |  12117
 logout     |    243
(5 rows)

Time: 114.883 ms

JSONB フィルタリングと日付範囲を使用したクエリ：

SELECT COUNT(*) 
FROM events 
WHERE event_timestamp > NOW() - INTERVAL '30 days'
  AND event_data->>'additional_info' LIKE 'info_5%';

 count 
-------
  9042
(1 row)

Time: 109.294 ms

イベントとユーザーを結合する:

SELECT u.country, COUNT(*) as events, AVG(LENGTH(e.event_data::text))::int as avg_json_size
FROM events e
JOIN users u ON e.user_id = u.user_id
GROUP BY u.country
ORDER BY events DESC;

 country | events | avg_json_size 
---------+--------+---------------
 USA     | 383748 |            52
 India   | 255990 |            52
 Germany | 223781 |            52
 China   | 127754 |            52
 Other   |   8727 |            52
(5 rows)

Time: 224.670 ms

Postgres の準備が整いました

この時点で、トランザクションワークロードに対応できる、高性能で完全に機能する Postgres データベースが利用可能になっています。

第2部に進み、ネイティブな ClickHouse 連携が分析性能をどのように大幅に高めるかをご覧ください。

---

​

第2部: ClickHouse でリアルタイム分析を追加する

Postgres はトランザクション系ワークロード (OLTP) に優れている一方、ClickHouse は大規模データセットに対する分析クエリ (OLAP) に特化して設計されています。両者を統合することで、それぞれの長所を最大限に活かすことができます：

• アプリケーションのトランザクションデータ (挿入、更新、ポイントルックアップ) には Postgres
• 数十億行規模のデータに対するサブ秒の分析には ClickHouse

このセクションでは、Postgres のデータを ClickHouse にレプリケートし、シームレスにクエリを実行する方法を説明します。

​

ClickHouse 連携のセットアップ

Postgres にテーブルとデータが揃ったので、分析のためにテーブルを ClickHouse にレプリケートしましょう。まず、サイドバーの ClickHouse 連携 をクリックします。次に、Replicate data in ClickHouse をクリックします。

次のフォームでは、インテグレーションの名前を入力し、レプリケート先となる既存の ClickHouse インスタンスを選択できます。ClickHouse インスタンスをまだお持ちでない場合は、このフォームから直接作成することもできます。

重要

次に進む前に、選択した ClickHouse service が Running 状態であることを確認してください。

次へをクリックすると、テーブルピッカーに移動します。ここで必要な操作は以下のとおりです：

• レプリケート先の ClickHouse データベースを選択します。
• public スキーマを展開し、先ほど作成した users テーブルと events テーブルを選択します。
• Replicate data to ClickHouse をクリックします。

レプリケーションプロセスが開始され、インテグレーションの概要ページに移動します。初回のインテグレーションでは、初期インフラストラクチャのセットアップに 2〜3 分かかる場合があります。その間に、新しい pg_clickhouse 拡張機能を確認してみましょう。

​

Postgres から ClickHouse をクエリする

pg_clickhouse 拡張機能を使用すると、Standard SQL を使って Postgres から直接 ClickHouse のデータをクエリできます。これにより、アプリケーションはトランザクションデータと分析データの両方に対して、Postgres を統合クエリレイヤーとして利用できます。詳細については、完全なドキュメントを参照してください。

拡張機能を有効にします:

CREATE EXTENSION pg_clickhouse;

次に、ClickHouse への foreign server 接続を作成します。セキュアな接続には、ポート 8443 を使用する http ドライバーを指定します：

CREATE SERVER ch FOREIGN DATA WRAPPER clickhouse_fdw
       OPTIONS(driver 'http', host '<clickhouse_cloud_host>', dbname '<database_name>', port '8443');

<clickhouse_cloud_host> をご使用の ClickHouse のホスト名に、<database_name> をレプリケーション設定時に選択したデータベース名に置き換えてください。ホスト名は、サイドバーの Connect をクリックすることで ClickHouse サービス上で確認できます。

次に、Postgres ユーザーを ClickHouse サービスの認証情報にマップします：

CREATE USER MAPPING FOR CURRENT_USER SERVER ch 
OPTIONS (user 'default', password '<clickhouse_password>');

次に、ClickHouse のテーブルを Postgres のスキーマにインポートします。

CREATE SCHEMA organization;
IMPORT FOREIGN SCHEMA "<database_name>" FROM SERVER ch INTO organization;

<database_name> には、サーバーの作成時に使用したデータベース名と同じ名前を指定してください。

これで、Postgres クライアントですべての ClickHouse テーブルを確認できます：

\det+ organization.*

​

分析機能を実際に確認する

インテグレーションページに戻って確認してみましょう。初期レプリケーションが完了していることが確認できるはずです。詳細を表示するには、インテグレーション名をクリックしてください。

サービス名をクリックして ClickHouse コンソールを開き、レプリケートテーブルを確認します。

​

Postgres と ClickHouse のパフォーマンスを比較する

次に、いくつかの分析クエリを実行して、Postgres と ClickHouse のパフォーマンスを比較してみましょう。なお、レプリケートテーブルは public_<table_name> という命名規則を使用します。

クエリ 1: アクティビティ別上位ユーザー

このクエリは、複数の集計を用いて最もアクティブなユーザーを見つけます。

-- Via ClickHouse
SELECT 
    user_id,
    COUNT(*) as total_events,
    COUNT(DISTINCT event_type) as unique_event_types,
    SUM(CASE WHEN event_type = 'purchase' THEN 1 ELSE 0 END) as purchases,
    MIN(event_timestamp) as first_event,
    MAX(event_timestamp) as last_event
FROM organization.public_events
GROUP BY user_id
ORDER BY total_events DESC
LIMIT 10;

 user_id | total_events | unique_event_types | purchases |        first_event         |         last_event         
---------+--------------+--------------------+-----------+----------------------------+----------------------------
       1 |        31439 |                  5 |      3551 | 2025-01-22 22:40:45.612281 | 2026-01-21 22:40:45.612281
       2 |        13235 |                  4 |      1492 | 2025-01-22 22:40:45.612281 | 2026-01-21 22:40:45.612281
...
(10 rows)

Time: 163.898 ms   -- ClickHouse
Time: 554.621 ms   -- Same query on Postgres

クエリ 2: 国別・プラットフォーム別のユーザーエンゲージメント

このクエリはイベントとユーザーを結合し、エンゲージメントメトリクスを計算します：

-- Via ClickHouse
SELECT 
    u.country,
    u.platform,
    COUNT(DISTINCT e.user_id) as users,
    COUNT(*) as total_events,
    ROUND(COUNT(*)::numeric / COUNT(DISTINCT e.user_id), 2) as events_per_user,
    SUM(CASE WHEN e.event_type = 'purchase' THEN 1 ELSE 0 END) as purchases
FROM organization.public_events e
JOIN organization.public_users u ON e.user_id = u.user_id
GROUP BY u.country, u.platform
ORDER BY total_events DESC
LIMIT 10;

 country | platform | users | total_events | events_per_user | purchases 
---------+----------+-------+--------------+-----------------+-----------
 USA     | Android  |   115 |       109977 |             956 |     12388
 USA     | Web      |   108 |       105057 |             972 |     11847
 USA     | iOS      |    83 |        84594 |            1019 |      9565
 Germany | Android  |    85 |        77966 |             917 |      8852
 India   | Android  |    80 |        68095 |             851 |      7724
...
(10 rows)

Time: 170.353 ms   -- ClickHouse
Time: 1245.560 ms  -- Same query on Postgres

パフォーマンス比較：

クエリ	Postgres (NVMe)	ClickHouse (via pg_clickhouse)	高速化倍率
上位ユーザー (5つの集計)	555 ms	164 ms	3.4x
ユーザーエンゲージメント (JOIN + 集計)	1,246 ms	170 ms	7.3x

ClickHouse を使うべきケース

この 100 万行のデータセットでも、ClickHouse は JOIN を含む複雑な分析クエリや複数の集計で 3〜7 倍高速なパフォーマンスを発揮します。さらに大規模 (1 億行以上) になるとその差はいっそう顕著になり、ClickHouse の列指向ストレージとベクトル化実行によって 10〜100 倍の高速化が得られることがあります。

クエリ時間は、インスタンスサイズ、サービス間のネットワーク遅延、データ特性、現在の負荷によって異なります。

​

クリーンアップ

このクイックスタートで作成したリソースを削除するには：

1. まず、ClickHouse サービスから ClickPipe インテグレーションを削除します
2. 次に、Cloud Console から Managed Postgres インスタンスを削除します