GanosBaseが提供するポリモーフィック階層ストレージ機能のベストプラクティス - PolarDB

GanosBaseとPolarDB for PostgreSQL は、空間データを格納するためのポリモーフィック階層ストレージ機能を提供します。この機能は、Elastic Block Storage (EBS) と一緒に使用できる費用対効果の高いデータベースストレージメディアとしてObject storage Service (OSS) を活用しています。このソリューションを使用すると、CRUD操作の透過性を維持し、階層キャッシュメカニズムによるパフォーマンスの低下を最小限に抑えながら、データベース、テーブル、または特定のフィールドをさまざまなストレージメディアに保存できます。ポリモーフィック階層ストレージ機能は、費用対効果が高く使いやすい包括的な空間データ管理ソリューションを提供します。ビジネス開発を大幅に簡素化し、クラウドリソースコストを削減できます。

ポリモーフィック階層ストレージについて

背景

デジタル化の急速な発展に伴い、あらゆるタイプの大規模、マルチモーダル、およびポリモーフィックなデータを効率的に処理する必要性がさまざまな業界から生まれています。従来のミドルウェアベースのソリューションは、空間計算性能の高い要求に追いつくのに苦労しています。 GanosBaseは、あらゆるタイプの大量データの取得効率を向上させ、空間データ処理をオンラインにするために、空間データおよび多数のコンピューティングオペレーターのさまざまなストレージタイプをネイティブにサポートしています。空間コンピューティングをプッシュダウンすることで、クエリのパフォーマンスが大幅に向上します。コンピューティング効率の向上により、空間データとオブジェクトのサイズが急速に拡大すると、リソースコストが高くなる可能性があります。コストと効率のバランスを取るという課題に直面するために、企業は一部の企業を定期的または完全にオフラインにする必要があります。これにより、事業開発中にストレージメディアが頻繁に切り替えられ、O&MおよびR&Dのコストが増加します。したがって、GanosBaseチームは、費用対効果が高く使いやすいスパティカルなデータ管理ソリューションの開発に2年以上を費やしました。 GanosBaseのチームは、機能の計画と開発に関する以下のコア領域に焦点を当てています。

費用対効果の高いストレージメディア (外部テーブルの形式ではない) を使用して、コストを削減します。
コスト効率の高いストレージメディアを使用しながら、クエリのパフォーマンス低下を最小限に抑えます。
透明性を持つ複数のストレージメディアでデータを管理および利用します。

GanosBaseチームは、PolarDB for PostgreSQL 14 に基づいて、空間データのポリモーフィックな階層ストレージを開発しました。ポリモーフィック階層ストレージは、コスト効率の高い空間データ管理ソリューションであり、BLOB、TEXT、JSON、JSONB、ANYARRAYなどの一般的なデータベースフィールドタイプの管理にも使用できます。

概要

多型階層ストレージは、従来の階層型ホット /コールドストレージよりもはるかに低いストレージコストで優れた読み取りおよび書き込みパフォーマンスを提供します。ホットデータとコールドデータの階層ストレージをサポートし、OSS、MinIO、HDFSなどの複数のオブジェクトストレージメディアと互換性があります。大きなオブジェクト型と空間データ型に柔軟なストレージの組み合わせを提供します。現在、この機能はOSSのみをサポートしています。詳細については、「概要」「」をご参照ください。

多型階層ストレージ機能を使用すると、単純なSQL文を実行して、期限切れデータ、大容量オブジェクトデータ、および空間データをOSSに転送でき、柔軟で費用対効果の高い信頼性の高いデータ管理が可能になります。転送後、SQL文を実行して、書き換えなしでデータにアクセスできます。これにより、CRUD操作やテーブル結合などの複雑な操作を完全な透明性で実行できます。さらに、データアクセス頻度が増加した場合、具体化されたキャッシュは、データベースディスクと同じアクセス性能を提供するように動的に調整され得る。

技術的な利点

多型階層ストレージには、次の技術的利点があります。

コスト: 平均圧縮率50% 、場合によっては最大20% のデータ圧縮をサポートし、元のコストの90% 以上を削減します。
パフォーマンス: マテリアライズドキャッシュ層は、20% 80% のパフォーマンス損失でコールドデータアクセスを加速します。
使いやすさ: ホットデータとコールドデータは階層に保存されます。 SQL文を実行して、書き換えなしでコールドストレージ内のデータに対してCRUD操作を実行できます。
信頼性: OSSを活用して高い信頼性を提供します。追加のストレージを消費することなく、コールドデータのスナップショットを作成できます。スナップショットデータは、迅速な復元に使用できます。
柔軟性: 階層化されたホット /コールドストレージをサポートし、OSSにテーブル、ラージオブジェクト、パーティションを格納します。

コスト

時空間データの量は今や爆発的に増加している。データ量がテラバイトまたはさらにペタバイトに増加すると、履歴データまたは補助データのアクセス頻度が減少します。その結果、ストレージコストの削減がコア顧客要件になります。では、PolarDB for PostgreSQL 階層化されたホット /コールドストレージアーキテクチャにより、コールドデータは小さなブロックに分割され、圧縮されてからOSSに保存されます。これにより、一般的なデータ圧縮率は20% 40% 、時空間データ圧縮率は60% 70% 、平均圧縮率は50% となる。このプロセスは、データがデータベースディスクからOSSに転送されるときに50% でデータ量を効果的に削減し、最終的にストレージコストを90% 以上削減します。次の表は、課金ルール、圧縮率、100 GBのデータの月額ストレージ料金などの点で、PolarDBディスクとOSSを比較しています。

	ディスク	多型階層ストレージ (OSSに保存されたデータ)
課金ルール	PSL4 USD 0.238 /GB-月	ローカル冗長ストレージ (LRS): USD 0.0173 /GB-月ゾーン冗長ストレージ (ZRS): USD 0.0232 /GB-月
圧縮比	0	50%
100 GBのデータのストレージ料金	0.238*100 GB=USD 23.8	LRS: OSS: 0.0173 (100 GB 50%)=USD 0.865 キャッシュ: 0.2381 GB=USD 0.238 合計米ドル1.103。 ZRS: OSS: 0.0232 (100 GB * 50%)=USD 1.16 キャッシュ: 0.238*1 GB=USD 0.238 合計米ドル1.398。

OSSのストレージ料金は、データベースディスクの10% 未満です。

性能

通常、OSSでデータにアクセスする際の待ち時間は、データベースディスクでの待ち時間よりもはるかに長くなります。 OSSに保存されているデータに対する直接読み書き操作のパフォーマンスは低いです。 PolarDB for PostgreSQL ポリモーフィック階層ストレージ機能は、データベースディスクを活用して、OSSに格納されているデータの具体化されたキャッシュレイヤーを提供します。これにより、データブロックのアクセスパターンに基づいた自動階層化ストレージが実現される。読み書き操作は、パフォーマンスを確保するために、まずマテリアライズドキャッシュ内のデータにアクセスできます。更新および挿入操作の全体的なパフォーマンスは、データベースディスクのパフォーマンスの90% です。ポイントクエリのパフォーマンスは、データベースディスクのパフォーマンスとは80% になります。具体化されたキャッシュ内のデータのライフサイクルは、アクセス頻度によって決まります。これにより、ストレージコストを削減しながら高いアクセス性能を確保します。

使いやすさ

PolarDB for PostgreSQL ポリモーフィック階層ストレージ機能は、使いやすい透明な階層型ホット /コールドストレージソリューションを提供します。 CRUD操作、インデックススキャン、結合クエリなどの複雑な操作は、SQL文に変更を加えることなく、OSSに保存されたデータに対してサポートされます。さらに、データを簡単に転送できます。たとえば、パーティション分割されたテーブルをOSSに自動的に転送したり、数回クリックするだけでベーステーブルとインデックスをOSSに転送したりするルールを作成できます。詳細については、「ベストプラクティス」をご参照ください。

信頼性

OSSは、99.9999999999% データの信頼性と99.995% データ可用性を提供します。また、データの信頼性を確保するためにLRSとZRSを備えています。ただし、OSSのデータに対してバックアップと復元を実行する必要があります。更新頻度とアクセス頻度が低くても、ビジネスシナリオでの重要なクエリ分析とデータマイニングタスクには、OSSのデータが必要です。誤って削除または変更した場合は、データをすばやく復元できることが不可欠です。 PolarDB for PostgreSQL ポリモーフィック階層ストレージ機能は、コールドデータのバックアップと復元をサポートします。コピーオンライト (COW) メカニズムに基づいてデータのバージョン管理を実装し、数秒でスナップショットを取得できます。最初のスナップショットが作成された後、更新されたデータブロックに対してのみレプリカが作成されます。これにより、最小限のコストでデータの信頼性が保証されます。

柔軟性

PolarDB for PostgreSQL のポリモーフィック階層ストレージ機能は、さまざまなホットストレージとコールドストレージの組み合わせをサポートします。

テーブル全体のデータをOSSに保存し、ディスクにインデックスを保持して、アクセスパフォーマンスを維持しながらコストを削減します。
大きなフィールドと補助フィールドをOSSに保存し、残りのフィールドをディスクに保持します。
期限切れのパーティションをOSSに保存し、ホットパーティションをディスクに保持します。これは一般的なデータ階層化モードです。このアプローチは、OSSにコールドパーティションとインデックスを保存する、OSSにホットパーティションデータを保存するがインデックスをディスクに保持する、クエリのパフォーマンスを確保するためにホットパーティション全体をディスクに保存するなど、さらにカスタマイズできます。

image (2).png

ベストプラクティス

ケース1: 期限切れのパーティションをコールドストレージに自動的にアーカイブする

背景

軌道データは月で区切られたテーブルに格納されます。時間の経過とともに、3か月前に生成されたデータにアクセスする頻度は大幅に減少します。ストレージコストを削減するには、3か月前に作成されたパーティションをコールドストレージに自動的にアーカイブする必要があります。

手順

テストデータベースを作成します。詳細については、「データベースの作成」「」をご参照ください。次のステートメントを実行して、パーティションテーブルを作成し、テーブルにテストデータを挿入します。

-- Create a partitioned table
CREATE TABLE traj(
  tr_id serial,
  tr_lon float,
  tr_lat float,
  tr_time timestamp(6)
)PARTITION BY RANGE (tr_time);

CREATE TABLE traj_202301 PARTITION OF traj
    FOR VALUES FROM ('2023-01-01') TO ('2023-02-01');
CREATE TABLE traj_202302 PARTITION OF traj
    FOR VALUES FROM ('2023-02-01') TO ('2023-03-01');
CREATE TABLE traj_202303 PARTITION OF traj
    FOR VALUES FROM ('2023-03-01') TO ('2023-04-01');
CREATE TABLE traj_202304 PARTITION OF traj
    FOR VALUES FROM ('2023-04-01') TO ('2023-05-01');

-- Write test data to the partitioned table
INSERT INTO traj(tr_lon,tr_lat,tr_time) values(112.35, 37.12, '2023-01-01');
INSERT INTO traj(tr_lon,tr_lat,tr_time) values(112.35, 37.12, '2023-02-01');
INSERT INTO traj(tr_lon,tr_lat,tr_time) values(112.35, 37.12, '2023-03-01');
INSERT INTO traj(tr_lon,tr_lat,tr_time) values(112.35, 37.12, '2023-04-01');

-- Create an index for the partitioned table
CREATE INDEX traj_idx on traj(tr_id);

テストデータベースにpolar_osfs_toolkit拡張機能を作成して、ユーティリティクラス関数を有効にします。関数を使用して、数回クリックするだけでプライマリテーブルとインデックス、またはパーティションテーブルをOSSにアーカイブできます。
```
CREATE extension polar_osfs_toolkit;
```
特権アカウントを使用してpostgresデータベースに接続し、pg_cron拡張機能を作成します。詳細については、「pg_cron 」をご参照ください。
```
--- Only privileged accounts can execute this statement in the postgres database to create the pg_cron plug-in
CREATE EXTENSION pg_cron;
```
スケジュールされたタスクを設定します。特権アカウントを使用してpostgresデータベースに接続し、テストデータベース用のtask1というタスクを作成します。このタスクは、ストアドプロシージャを呼び出して、3か月前に作成されたパーティションをOSSに自動的に移動します。タスクIDが返されます。
```
-- The statement is executed every minute
SELECT cron.schedule_in_database('task1', '* * * * *', 'select polar_alter_subpartition_to_oss(''traj'', 3);', 'db01');
```
サンプル結果:
```
 schedule_in_database 
----------------------
                    1
```

実行結果と実行履歴を確認してください。

テストデータベースでpsqlを使用して、パーティションテーブルの格納場所を確認します。

\d+ traj_202301

サンプル結果:

                                                                 Table "public.traj_202301"
 Column  |              Type              | Collation | Nullable |               Default               | Storage | Compression | Stats target | Description 
---------+--------------------------------+-----------+----------+-------------------------------------+---------+-------------+--------------+-------------
 tr_id   | integer                        |           | not null | nextval('traj_tr_id_seq'::regclass) | plain   |             |              | 
 tr_lon  | double precision               |           |          |                                     | plain   |             |              | 
 tr_lat  | double precision               |           |          |                                     | plain   |             |              | 
 tr_time | timestamp(6) without time zone |           |          |                                     | plain   |             |              | 
Partition of: traj FOR VALUES FROM ('2023-01-01 00:00:00') TO ('2023-02-01 00:00:00')
Partition constraint: ((tr_time IS NOT NULL) AND (tr_time >= '2023-01-01 00:00:00'::timestamp(6) without time zone) AND (tr_time < '2023-02-01 00:00:00'::timestamp(6) without time zone))
Replica Identity: FULL
Tablespace: "oss" -- Already stored in OSS
Access method: heap

postgresデータベースで、スケジュールされたタスクの実行履歴を確認します。
```
SELECT * FROM cron.job_run_details;
```

この例では、期限切れのパーティションはカスタムルールに基づいて自動的にコールドストレージに移動されます。コールドストレージのパーティションはディスクスペースを占有しなくなり、ストレージコストが大幅に削減されます。 CRUD操作は完全な透明性で実行できます。

ケース2: パーティション分割されていないテーブル内のLOBの階層ストレージ

背景

ラージオブジェクト (LOB) は、BLOB、TEXT、JSON、JSONB、ANYARRAY、spatio-temporal データ型などの一連のデータ型です。この例では、テーブルのLOBはOSSに個別に格納され、完全な透過性でアクセスできます。これにより、フィールドレベルでのホットデータとコールドデータの分離によりコストが削減されます。

手順

LOBを含むテーブルを作成します。この例では、TEXTタイプが使用されています。同じ方法を使用して、他のデータ型を処理できます。
```
CREATE TABLE blob_table(id serial, val text);
```

LOBの保存場所を指定します。

ALTER TABLE blob_table ALTER COLUMN val SET (storage_type='oss');

データを挿入し、保存場所を確認します。

データを挿入します。この時点で、val列のすべての値がOSSに保存されます。

INSERT INTO blob_table(val) VALUES((SELECT string_agg(random()::text, ':') FROM generate_series(1, 100000)));

val列の格納場所を確認してください。

WITH tmp AS (SELECT 'pg_toast_'||b.oid||'_'||c.attnum AS tblname FROM pg_class b, pg_attribute c WHERE b.relname='blob_table' AND c.attrelid=b.oid AND c.attname='val') SELECT t.spcname AS storage_engine FROM pg_tablespace t, pg_class r, tmp m WHERE r.relname = m.tblname AND t.oid=r.reltablespace;

サンプル結果:

 storage_engine 
----------------
 oss
(1 row)

説明

ALTER COLUMNステートメントの実行後に挿入されたデータのみがOSSに保存されます。
既存のテーブルからOSSにLOBを転送するには、まずALTER COLUMN SQL文を実行して、LOBの格納場所を設定します。次に、VACUUM FULL文を実行してデータを書き換えます。 VACUUM FULLステートメントを実行しない場合、履歴データはディスクに残り、新しいデータのみがOSSに保存されます。このステートメントを実行しても、テーブルに対するCRUD操作には影響しません。ただし、データ量が大きい場合、ステートメントの実行に時間がかかる可能性があり、実行中にテーブルを読み取りまたは書き込み操作に使用できません。

ケース3: 時空解析シナリオにおける費用対効果の向上

時空間データ分析は、空間、時空、および時系列データを含むシナリオでのデータマイニングおよび統計分析にデータベース機能を使用します。この例では、リモートセンシング画像の統計分析を使用して、多形階層ストレージが分析パフォーマンスを維持しながらストレージコストを削減できる方法を示します。

説明

この例では、高度な機能を使用します。中間ステップをスキップして、主に最終比較結果に焦点を当てることができます。

背景

空間ビジネスにおけるリモートセンシング画像 (ラスタデータ) の応用が拡大しています。大量のリモートセンシングデータと、画像ブラウジングや統計分析などの複数のビジネス領域でのその使用により、ストレージコストの削減と使いやすさの向上は、非リアルタイムの統計分析を実行する必要があるユーザーにとって特に魅力的です。この例では、OSSを使用してリモートセンシング画像をコスト効率よく保存し、効率的な統計分析機能を提供する方法を示します。

手順

データを準備します。この例では、4つのLandsetリモートセンシング画像が用意される。

リモートセンシング画像をデータベースにインポートします。

rastdbという名前のテストデータベースを作成します。
テストデータベースにganos_raster拡張機能を作成します。詳細については、「ラスターモデル」「」をご参照ください。
```
CREATE EXTENSION ganos_raster CASCADE;
```

画像の読み込み

CREATE TABLE raster_table (id integer, rast raster);
INSERT INTO raster_table VALUES (1, ST_ImportFrom('rbt','/home/postgres/LC08_L1TP_113028_20190912_20190917_01_T1.TIF'));
INSERT INTO raster_table VALUES (2, ST_ImportFrom('rbt','/home/postgres/LC08_L1TP_113029_20191030_20191114_01_T1.TIF'));
INSERT INTO raster_table VALUES (3, ST_ImportFrom('rbt','/home/postgres/LC08_L1TP_114028_20191005_20191018_01_T1.TIF'));
INSERT INTO raster_table VALUES (4, ST_ImportFrom('rbt','/home/postgres/LC08_L1TP_114029_20200905_20200917_01_T1.TIF'));

画像が使用するストレージスペースを計算します。 GanosBaseでは、Rasterデータ型のメタデータとブロックデータは別々に保存されますが、一元管理されます。ベーステーブルはメタデータを格納し、ブロックテーブルはブロックデータを格納する。ブロックテーブルのデータ量を正確に計算するには、次のステートメントを実行してストアドプロシージャを作成する必要があります。

CREATE OR REPLACE FUNCTION raster_data_internal_total_size( rast_table_name text, rast_column_name text)
  RETURNS int8 AS $$
DECLARE
    sql                 text;
    sql2                text;
    rec                 record;
    size                int8;
    totalsize           int8;
    tbloid              Oid;
BEGIN
    size := 0;
    totalsize := 0;

    -- Query the block data table of the raster object
    sql = format('select distinct(st_datalocation(%s)) as tblname from %s where st_rastermode(%s) = ''INTERNAL'';', rast_column_name, rast_table_name, rast_column_name);
    for rec in
        execute sql
    loop
        sql2 = format('select a.oid from pg_class a, pg_tablespace b where a.reltablespace = b.oid and b.spcname=''oss'' and a.relname=''%s'';', rec.tblname);
        execute sql2 into tbloid;

        if (tbloid > 0) then
            size := 0;
        else
            -- Calculate the size of each data table
            sql2 = format('select pg_total_relation_size(''%s'');',rec.tblname);
            execute sql2 into size;
        end if;
        totalsize := (totalsize + size);
    end loop;
    return totalsize;
END;
$$ LANGUAGE plpgsql;

ストアドプロシージャを作成したら、計算を実行できます。この結果は、画像データが約1.2 GBのデータベースストレージを占有することを示しています。

SELECT pg_size_pretty(raster_data_internal_total_size('raster_table','rast'));

サンプル結果:

 pg_size_pretty 
----------------
 1319 MB
(1 row)

正規化された差植生指数 (NDVI) を計算する。データはディスクに保存されます。 NDVIの初期計算中に、モザイク演算が実行され、NDVI分析のために画像を完全な画像にマージする。計算に使用された時間も記録される。詳細については、ST_MosaicFrom を参照してください。

CREATE TABLE rast_mapalgebra_result(id integer, rast raster);

INSERT INTO rast_mapalgebra_result SELECT 1, ST_MapAlgebra(ARRAY(SELECT st_mosaicfrom(ARRAY(SELECT rast FROM raster_table ORDER BY id), 'rbt_mosaic','','{"srid":4326,"cell_size":[0.005,0.005]')),    '[{"expr":"([0,3] - [0,2])/([0,3] + [0,2])","nodata": true, "nodataValue":0}]',    '{"chunktable":"rbt_algebra","celltype":"32bf"}');

サンプル結果:

INSERT 0 1
Time: 39874.189 ms (00:39.874)

ブロックデータをコールドストレージにアーカイブします。リモートセンシング画像のブロックデータをOSSにアーカイブし、メタデータをディスクに保存します。このプロセスを容易にするには、次のステートメントを実行してストアドプロシージャを作成する必要があります。

CREATE OR REPLACE FUNCTION raster_data_alter_to_oss( rast_table_name text, rast_column_name text)
  RETURNS VOID AS $$
DECLARE
    sql                 text;
    sql2                text;
    rec                 record;
BEGIN
    -- Query the data table of the raster object
    sql = format('select distinct(st_datalocation(%s)) as tblname from %s where st_rastermode(%s) = ''INTERNAL'';', rast_column_name, rast_table_name, rast_column_name);
    for rec in
        execute sql
    loop
        sql2 = format('alter table %s set tablespace oss;',rec.tblname);
        execute sql2;
    end loop;
END;
$$ LANGUAGE plpgsql;

ストアドプロシージャが作成されたら、ブロックデータをコールドストレージにアーカイブし、ブロックデータテーブルがディスク上に占有しているストレージスペースを再計算します。

SELECT raster_data_alter_to_oss('raster_table', 'rast');

-- Calculate the storage space occupied by the block data on the disk after cold storage
SELECT pg_size_pretty(raster_data_internal_total_size('raster_table','rast'));

結果は、ブロックデータテーブルがディスク上で占有するストレージスペースが0になり、ブロックデータがOSSに格納されていることを示しています。

 pg_size_pretty 
----------------
 0 bytes
(1 row)

NDVIを再計算する。ブロックデータをOSSにアーカイブした後、NDVIを再度計算します。

INSERT INTO rast_mapalgebra_result select 2, ST_MapAlgebra(ARRAY(select st_mosaicfrom(ARRAY(SELECT rast FROM raster_table ORDER BY id), 'rbt_mosaic','','{"srid":4326,"cell_size":[0.005,0.005]')),    '[{"expr":"([0,3] - [0,2])/([0,3] + [0,2])","nodata": true, "nodataValue":0}]',    '{"chunktable":"rbt_algebra","celltype":"32bf"}');

サンプル結果:

INSERT 0 1
Time: 69414.201 ms (01:09.414)

ストレージコストとパフォーマンスを比較します。

項目	ディスク	OSS	比率
ストレージコスト	1319 MB、GB-月あたりUSD 0.238で、合計USD 0.31	1011.834 MB、GB-月あたりUSD 0.0232で、合計USD 0.023	10:1
NDVIの計算時間	39秒	69秒	1:1.76

比較結果は、OSSをコールドストレージとして使用するコストがディスクの10分の1未満であることを示しています。コンピューティングパフォーマンスの損失は100% 未満です。これは、非リアルタイム統計分析シナリオにおいて費用効果が高い。

結論

GanosBaseは、多数の業界にわたる数千のアプリケーションシナリオで使用されています。 GanosBase の主な利点は、安定性、費用対効果、高性能、および使いやすさです。多型階層ストレージ機能は、PolarDB for PostgreSQL に基づくGanosBaseの主要な競争上の利点です。費用対効果が高く、高性能で使いやすいデータ管理ソリューションを提供します。今すぐ試してみてください。