ADBPG&Greenplum cost-optimized disk water level management

1: 背景説明

現在、企業の重要データは一般的に二次元テーブルの形でデータベースに保存されています。
コア技術が独立して制御可能な環境において、政府・企業業界のお客様は、特にデータウェアハウス OLAP の分野で、国産データベースやオープンソースデータベースを使用するようになってきており、Greenplum の利用がますます広がっています。
また、Alibaba Cloud ADB PG の市場機会も増えています。
さらに、データセンタープラットフォームの価値が近年広く認識されるようになったことで、企業がデータセンタープラットフォームを構築する需要も非常に切実です。
データセンタープラットフォームの多くのシーンで Greenplum または ADB PG が使用されます。
そのため、今年 Alibaba Cloud は ADB PG を使用して、多くのお客様のコアデータウェアハウスのアップグレードを支援しました。
お客様はクラウドネイティブデータウェアハウスの使用コストにより注目する傾向があることがわかり、お客様のコストを節約する方法を探求し、実施することは価値があります。


ADB PG は AnalyticDB PostgreSQL のクラウドネイティブデータウェアハウス版を表します。
これは超並列処理（MPP）アーキテクチャを持つデータベースであり、Greenplum オープンソース版をベースとしています。
図 1 は ADB PG（Greenplum も同様）のアーキテクチャの概念図です。
Master は接続要求の受け入れ、SQL 解析、最適化、トランザクション処理などを担当し、タスクを Segment にディスパッチして実行します。
そして各 Segment が返す結果を統合し、最終結果をクライアントプログラムに提示します。
Segment は独立した PostgreSQL データベースであり、ビジネスデータの保存と計算を担当します。
各 Segment は異なる独立した物理マシン上に配置され、ビジネスデータの異なる部分を保存します。
複数の Segment がコンピューティングクラスターを形成し、クラスターは水平方向に拡張可能です。
アーキテクチャから明確なように、Greenplum のコストを節約するために最も重要なのは、可能な限り Segment サーバーの数を節約することですが、MPP 全体のコンピューティング能力を確保すると同時に、データストレージ領域の要件も満たす必要があります。
通常、データウェアハウスのデータは企業の各部門の上流プロダクションシステムから同期されます。
これらのデータは分析分野でのライフサイクルを持ち、多くのデータは歴史的変化を反映する必要があります。
したがって、データウェアハウスのデータは複数のソースと履歴データを持ち、データ量も比較的大きいという特徴があります。
大量のデータは必然的にストレージ領域を消費し、MPP アーキテクチャの下ではサーバーコストを消費します。
お客様のコストを最適化し、ストレージ領域を節約することが最優先課題です。


次に、実際のディスク領域最適化ケースを使用して、お客様のコストを最適化する方法を説明します。


2: ADB PG & Greenplum のディスク管理の概要

1. ADB PG ディスク管理の重要技術ポイント

ADB PG は Greenplum（略称「GP」）カーネルをベースに改変された MPP データベースです。
ディスク領域管理について、Greenplum と共通するいくつかの技術ポイントがあります。


(1) ビジネスデータは主に Segment ノードに分散されています。


(2) Segment には Primary と Mirror ノードがあり、利用可能なビジネス領域は総サーバー領域の 1/2 です。


(3) Greenplum の MVCC 機構により、テーブルデータで DML が発生した後にゴミデータのデッドタプルが生成されます。


(4) コピーテーブル（全分散テーブル）は各 Segment に同じデータコピーを保存します。
分散テーブルは分散キーに従ってデータを各 Segment に分散保存します。


(5) Greenplum には Append-Only テーブルがあり、圧縮保存をサポートし、領域を節約できます。
ただし、ユーザーアクセス時に解凍に時間がかかるため、パフォーマンスと領域のバランスを取る必要があります。


クラウドネイティブデータベースの特徴は、データベースのストレージと計算だけでなく、運用管理プラットフォーム（略称「データベース管理コントロール」）もサポートすることです。
ADB PG ディスク管理の原理を理解した後、ディスク水位管理におけるデータベース管理コントロールの設計を理解する必要があります。


2. データベースコントロールのディスク予約メカニズム

データウェアハウス実験環境の各 Segment ノードのディスク使用状況図を見てみましょう。


上の図の最初のパーセンテージは Segment が配置されている物理マシンのディスク使用率です。
2 番目のパーセンテージはデータベースコントロールによるディスク使用率です。
なぜコントロールのデータとサーバーの実際の使用量が異なるのでしょうか。
実は、これは水位管理における非常に重要な予防策であるスペース予約です。
つまり、ADB コントロールが Segment インスタンスを作成する際、サーバー領域に応じて約 12% を予約します。
つまり 20T のサーバーの場合、コントロールがビジネスに使用可能と考える最大値は 17.6T です。
このロジックはモニタリングシステムに通知されます。
したがって、ディスク比率を計算する際、モニタリングシステムの分母は 20T ではなく 17.6T です。
これが最初の保護レベルです。


スペースを予約するもう一つの重要な理由は、データベース自体に WAL トランザクションログやエラーログなども領域を占有することです。
したがって、ディスク領域の一部をログに使用する必要があり、お客様のビジネスデータはサーバー領域の 100% を使用することはできません。
これが図 2 に 2 つの領域パーセンテージが表示されている理由です。


3. データベースコントロールの「書き込みロック」保護メカニズム

2 番目の保護レベルは「ディスクフル書き込みロック」です。
17.6T を基に、コントロールはビジネスが完全にディスクを満たすことを許可しません。
これはデータファイルの破損を引き起こしやすく、データベースのダウンタイムと回復不能な災害をもたらします。
したがって、2 番目の閾値があり、ディスクが 90% まで書き込まれると、データベースコントロールの自動検査タスクが「書き込みロック」操作を開始します。
この時、ADB に要求するすべての DML が失敗します。
これは重要な保護メカニズムです。
下の図 3 に示すように、閾値に達すると「ロックが必要」と表示されます。
閾値は設定可能で、ディスク領域が逼迫している場合は実際の状況に応じて適切に調整できます。


データベース管理コントロールの上記 2 つのメカニズムにより、ディスクが安全な水位の下で実行されることを効果的に確保できます。
これらの設計はコスト最適化の基礎です。
ディスクコスト最適化とは、サーバーのディスクをできるだけ使用することを意味します。
ディスク領域を節約するには、比較的高いディスク水位で実行する必要があります（これはデータ量が本当に大きい場合を指します）。
したがって、効果的なディスク管理とタイムリーな問題モニタリング・発見メカニズムが非常に重要です。


3. ディスク領域最適化スキーム

お客様のケースを例にして、ディスク領域最適化の方法を説明します。
お客様のデータウェアハウスのデータ（インデックスを含む）は 1.5PB を超えていますが、お客様は第 1 期の ADB データベース用に 40 台のマシンを購入し、総容量は約 800T です。
お客様は明確に、Alibaba Cloud がデータウェアハウスの設計でビジネスサイドと協力してコストを節約するよう支援することを要求しました。
お客様は既にコスト最適化の KPI を設定しており、Alibaba Cloud に技術を通じて実施することを要求しています。
ビジネスサイドと協力して設計段階でいくつかのスキームを作成しました。
技術的には、主にテーブル圧縮とホットデータ・コールドデータの分離の観点から検討しました。
ビジネス的には、開発者に設計の観点から ADB のストックデータをできるだけ減らすよう要求しました。
最終的に、開発者は約 360T のホットデータを古いデータウェアハウスから ADB に移行すると見積もりました。
オンライン化する前に、開発者は必要な基本ビジネスデータ（ソースレイヤー、ミドルレイヤーなど）を DB2 から ADB PG に移行する必要があります。
移行が完了し、ビジネスが試行実行期間に入った後、領域がほぼいっぱいであることがわかりました（図 2 に示すように）。
領域最適化が差し迫っているため、ディスク領域最適化ガバナンスを開始しました。
図 4 はディスク領域管理最適化のフレームワークです。


次に、詳しく説明します。


1. テーブルストレージ形式と圧縮

テーブルの圧縮保存は、お客様のストレージ領域節約を効果的に保証します。
Greenplum は行ストレージ、Append-Only 行ストレージ、Append-Only カラムストレージなどのストレージ形式をサポートしています。
ストレージ領域を節約したい場合、Append-Only カラムストレージテーブルがより良い選択です。
データ圧縮をよりよくサポートし、テーブル作成時に圧縮アルゴリズムと圧縮レベルを指定できます。
適切な圧縮アルゴリズムとレベルはストレージ領域を数倍節約できます。
テーブル作成の例文は以下の通りです。


カラムストレージテーブルは Append-Only 型である必要があります。
カラムストレージテーブルを作成する際、ユーザーは COMPRESSTYPE フィールドを指定することで圧縮タイプを指定できます。
指定しない場合、データは圧縮されません。
現在 3 つの圧縮タイプをサポートしています。


zstd、zlib、lz4 があり、zstd アルゴリズムは圧縮速度、解凍速度、圧縮率の 3 つの次元で比較的バランスが取れています。
実際には、zstd アルゴリズムを優先することをお勧めします。
zlib アルゴリズムは主に既存のデータとの互換性のためのもので、通常新しいテーブルでは zlib アルゴリズムを使用しません。
lz4 アルゴリズムの圧縮速度と圧縮率は zstd ほど良くありませんが、解凍速度は zstd アルゴリズムより明らかに優れています。
したがって、クエリパフォーマンス要件が厳しいシーンでは lz4 アルゴリズムをお勧めします。


ユーザーは COMPRESSLEVEL フィールドを指定することで圧縮レベルを決定できます。
値が大きいほど圧縮率が高くなり、値の範囲は 1 〜 19 です。
具体的な圧縮レベルは数値が大きいほど良いというものではありません。
前述の通り、解凍にも時間がかかり、圧縮率が高いほど解凍が比較的遅くなります。
したがって、実際のビジネステストに従って選択する必要があります。
通常、5 〜 9 が実際のプロダクション実践での圧縮レベルです。


2. ホットデータ・コールドデータの階層ストレージ

大企業のデータウェアハウス設計では、MPP データベース（ADB は MPP に属する）はデータストレージの 1 つに過ぎず、主に部分的なバッチ処理、オンラインクエリ、adHoc クエリで使用されます。
多くのコールドデータやアーカイブデータもあります。
通常、Hadoop、MaxCompute、さらには OSS がストレージ用に計画されます。
さらに、近年登場したストリームデータの計算とストレージには非常に強い需要があり、Kafka、Blink、Storm で解決できます。
したがって、MPP データベースの領域が逼迫している場合、ホットデータ・コールドデータの階層ストレージスキームを実施することもできます。
ADB PG の階層ストレージソリューションは大きく分けて 2 つあります。
1. ビジネスサイドがコールドデータとホットデータを自分で管理する。
2. ADB PG のホットデータ・コールドデータの階層ストレージ変換機能を使用する。


ビジネスサイドは PXF 外部テーブルを通じて HDFS コールドデータにアクセスします

ビジネスサイドは一部のコールドデータを HDFS または Hive にファイルとして保存し、ADB で PXF 外部テーブルを作成してアクセスできます。
外部テーブルは ADB PG のディスク領域を占有しません。
PXF は Greenplum と Hadoop クラスター間のデータインタラクションのための並列チャネルフレームワークです。
Greenplum では、PXF を使用して Hadoop プラットフォームデータのロードとアンロードを並列に実行できます。
具体的な使用方法は以下の通りです。


(1) コンソールで PXF サービスを有効化

ADB コンソールにログインし、ADB PG インスタンスの外部テーブルページにアクセスし、新しいサービスを有効化するをクリックします。


詳細な Hadoop サービス情報（Kerberos 認証に関わるが、本記事の焦点ではありません）を入力した後、PXF サービスが開始されます。
上の図は正常に開始された後の様子です。


(2) PXF 拡張機能を作成

-- 管理者実行

(3) PXF 外部テーブルを作成

説明：Location は HDFS ソースファイル情報で、/data/pxf_examples/pxf_hdfs_simple.txt はビジネスがアクセスする外部コールドデータファイルです。
SERVER=23 は Hadoop 外部のアドレス情報を示し、23 はクラスターアドレス情報のストレージディレクトリです。
図 8 の PXF サービスに従って確認できます。


(4) 外部テーブルへのアクセス

外部テーブルへのアクセスは通常のテーブルと変わりありません。


ADB PG コールドデータ・ホットデータ階層ストレージスキーム

上記の PXF 外部テーブルアクセスには欠点があります。
コールドデータ（外部テーブル）をホットデータと結合する必要がある場合、効率が悪いのです。
理由は、HDFS から ADB にデータをロードしてから ADB テーブルと結合する必要があり、大量の IO が増加するためです。
したがって、ADB PG は Greenplum の PXF 外部テーブルを基にホットデータ・コールドデータ変換機能を提供します。
ビジネスサイドは外部テーブルと通常テーブルの分析を結合する必要がある場合、外部テーブルを ADB の通常テーブルデータに変換してからビジネスを実行できます。
クエリ全体をホットデータ・コールドデータ階層ストレージと呼びます。
どちらも PXF 外部テーブルサービスを使用するため、3.4.1 の最初と 2 番目のステップを再利用できます。
追加の設定方法は以下の通りです。


(1) 階層ストレージがデフォルトで先ほどの Foreign Server を使用するように設定

スーパー管理者で実行

ALTER DATABASE postgres SET RDS_DEF_OPT_COLD_STORAGE TO 'server "23",resource "/cold_data", format "text",delimiter ","';
ここでは postgres を実際のデータベース名に置き換え、/cold_data を実際に HDFS にコールドデータを保存するために使用するパスに置き換える必要があることに注意してください。


(2) データベースインスタンスの再起動後に確認を実行

SHOW RDS_DEF_OPT_COLD_STORAGE;
設定が成功したことを確認します。


(3) テストテーブルを作成し、少量のテストデータを挿入

この時、t1 テーブルのデータは ADB のローカルストレージに保存され、ホットデータに属します。


(4) テーブルデータをコールドストレージ HDFS に移行

現在のバージョンではこの NOTICE は正常です。
コールドストレージにはいわゆる分散情報が存在しないか、または分散情報が外部ストレージ（HDFS）によって決定されるためです。


(5) コールドデータテーブルの使用を確認

まず、テーブル定義を確認してテーブルがコールドストレージに移行されたことを検証します。


その後、通常通りテーブルデータをクエリします。


(6) データをホットストレージに戻す

alter table t1 set (storagepolicy=hot);

注意：ホットストレージに戻した後、分散情報は失われます。
これは現在のバージョンの制限です。
テーブルにインデックスがある場合、移行後にインデックスは失われ、インデックスの再構築が必要です。
上記の 2 つのソリューションにより、コールドデータを ADB PG から外部ストレージに一定程度移行し、ADB PG の領域を節約できます。


ソリューション 1 は結合効率が低く、ホットデータ・コールドデータ変換をサポートしませんが、ADB の領域を占有しません。


ソリューション 2 は結合効率が高く、ホットデータ・コールドデータ変換をサポートしますが、一定時間 ADB の領域を占有します。


2 つのソリューションにはそれぞれ長短があります。
実際、プロジェクトではビジネスアプリケーションに依存します。
このお客様のケースでは、ホットデータ・コールドデータ階層ストレージスキームにより、全体の ADB に対して数百トンの領域を節約しました。
この数百トンの領域の大部分は設計段階で解決され、一部は試行実行中にさらに最適化されました。


3. ゴミデータの VACUUM

GP カーネルの MVCC 管理メカニズムにより、テーブルの DML（時刻 t2）コミット後のデータタプルは即座に削除されず、常にテーブルの通常タプルと一緒に保存され、デッドタプルとしてマークされます。
これによりテーブルが肥大化し、余分な領域を占有します。
ゴミデータ回収には 2 つの方法があります。
カーネル自動クリーンアップと SQL 手動クリーンアップです。
自動クリーンアップのメカニズムは次の通りです。
テーブルのデッドタプルが一定の割合に蓄積し、そのテーブルをクエリするすべてのトランザクション（時刻 t1 < 時刻 t2）が終了すると、カーネルが自動的にゴミデータを auto vacuum します。
このメカニズム自体に問題はありませんが、大規模データベースと大規模テーブルのシーンでは一定の問題があります。
大きなテーブル T で、データ変更が 10G の 1% であっても、複数の大きなテーブルが同時に変更されると、全体の領域に問題をもたらします。
したがって、手動回収で補完する必要があります。


手動回収方法

(1) システムのトップテーブルを統計します。


(2) 大きなテーブルのデッドタプルの割合と領域をクエリします。


-- 統計情報に基づいて膨張率が 20% を超えるテーブルをクエリ

(3) pg_cron タイミングタスクを使用して、ビジネスのゴミデータ回収を支援します。


ここでは、ビジネスとコミュニケーションして実行時間を明確にする必要があります。
具体的な VACUUM は読み書きに影響を与えませんが、追加の IO 消費があります。
VACUUM FULL tablename は注意して使用する必要があり、2 つの違いを説明する必要があります。
単純な VACUUM（FULL なし）はテーブルの領域を回収し、元のテーブルを再利用可能にするだけです。
この形式のコマンドは排他ロックを要求しないため、テーブルの通常の読み書きと並行して実行できます。
ただし、余分な領域はオペレーティングシステムに返されず、同じテーブル内で利用可能なまま残ります。
VACUUM FULL はテーブルの内容全体を新しいファイルに書き換え、ゴミデータなしにします（新しいディスク領域を占有し、次に古いテーブルのファイルを削除して領域を解放します）。
これは未使用の領域をオペレーティングシステムに返すことに相当します。
この形式ははるかに遅く、処理中にテーブルの排他ロックが必要です。
したがって、ビジネスのテーブル使用に影響を与えます。


(4) ビジネスコードの適切なリンクに VACUUM を追加して回収します。


一部のテーブルが頻繁に更新され毎日肥大化する場合、ビジネスコードに VACUUM を追加し、頻繁な DML 変更の直後にゴミデータを回収できます。


システムテーブルも回収が必要

これは非常に見過ごされやすいポイントです。
特に一部のデータウェアハウスで頻繁にテーブルの作成と変更が必要なシーン（一時テーブルもカウントされます）では、メタデータを保存する多くのシステムテーブルも膨張を経験し、膨張率は DDL の頻度と正の相関があります。
あるお客様で pg_attribute が数百ギガバイトに膨張し、pg_class が 20 倍に膨張する状況を経験しました。
以下の表は実際のまとめに基づいて比較的膨張しやすい pg システムテーブルです。


手動 VACUUM の制限

手動 VACUUM には一定の制限があり、注意が必要です。


(1) IO 使用率が高い期間には VACUUM を実行しないでください。


(2) VACUUM FULL には完了するために追加のディスク領域が必要です。


ディスク水位が高く、残りの領域が小さい場合、大きなテーブルの VACUUM FULL に十分な領域がない可能性があります。
まず一部の履歴テーブルを削除してディスク領域を解放し、その後対象テーブルの VACUUM FULL を実行できます。


(3) 対象テーブルの大規模トランザクションが先に終了している必要があります

大きなテーブルの定期メンテナンス中に、テーブルの VACUUM を 1 回実行しましたが、膨張した領域が回収されませんでした。
pg_stat_activity を詳しく確認したところ、このテーブルに対する大規模トランザクション（手動 VACUUM 開始より前に開始された）がまだ終了していないことがわかりました。
この時、カーネルは古いデータがまだ使用されている可能性があると考え、回収できません。
手動でも回収できません。


4. 冗長インデックスのクリーンアップ

インデックス自体も領域を占有し、特に大きなテーブルではそうです。
インデックスはデータベースがクエリ効率を向上させるための一般的かつ基本的な方法です。
インデックスをうまく使うことは、可能な限り多くのインデックスを作成することではなく、特に大規模データベースの大きなテーブルではそうです。
領域が逼迫している場合、クリーンアップ可能な冗長インデックスがないか確認してみてください。


トラブルシューティングの考え方

(1) 「異常に多くの」フィールドを含む複合インデックスがあるかどうか。


(2) 同じプレフィックスフィールドを持つ複数の複合インデックスがあるかどうか。


(3) オプティマイザが決して使用しないインデックスがあるかどうか。


トラブルシューティング方法と例

まず、最初の考え方から始めます。
4 列以上のフィールドを含むインデックスを持つテーブルをクエリします。


あるお客様は、以下の図に示すように、10 個以上のフィールドを持つ多くの複合インデックスを作成していました。



通常、6 個以上のフィールドを持つ複合インデックスはプロダクションではほとんど見られないため、最初の判断はテーブル構築時にビジネスサイドが冗長なインデックスを作成したというものです。
次に、インデックスのサイズに従って並べ替えた後、冗長インデックスリストを出力できます。


ここで、一部のインデックスのサイズが 500G を超え、10 個以上のインデックスのサイズが 1TB を超えていることが明確にわかりました。
この情報を見た時、私たちは驚くと同時に喜びました。
喜ばしいことは、多くの領域を回収できるはずだということです。
次に、ビジネスサイドとコミュニケーションを取り、ビジネスサイドが不要であることを確認した後に削除します。


このお客様のケースでは、サイズが 24T の 200 以上の冗長インデックスを削除し、ビジネス領域の 7% を直接解放しました。
非常に印象的な領域最適化効果です。
この最適化は非常にタイムリーでした。
最適化が 11 月末に完了したことを覚えています。
その後 12 月初旬にピークが到来し、ビジネスサイドがさらに 20TB の新しいデータを書き込みました。
このインデックス最適化がなければ、誇張ではなく、12 月初旬のお客様の ADB クラスターはもはや耐えられなかったでしょう。


考え方 (2)（同じプレフィックスフィールドを持つ複数の複合インデックスがあるかどうか）の場合、確認 SQL は以下の通りです。
インデックスと含まれるフィールドのメタデータを他の GP ライブラリにエクスポートして分析することをお勧めします。
インデックスデータの分析比較（ベクトルから文字配列への変換、および部分集合とスーパーセットの計算に関わる）はより多くのパフォーマンスを消費するためです。


以下は、トラブルシューティング例の user_t に対する 2 番目の複合問題のインデックスです。


上記の例の結果の説明：multi_index1 は multi_index2 の部分集合であり、前者のインデックス列は後者で既にインデックスが作成されています。
したがって、multi_index1 は冗長インデックスです。


考え方 (3)：オプティマイザが決して使用しないインデックスがあるかどうか。


さらに、非常に重要な知識ポイントがあります。
Append-Only カラムストレージテーブルのインデックススキャンはビットマップスキャンモードのみをサポートします。
Greenplum がビットマップスキャンインデックススキャンモードを無効化した場合、AO カラムストレージテーブルへのすべてのアクセスはテーブル全体をスキャンします。
つまり、理論上は AO カラムストレージテーブル上の非ユニークインデックスはすべて使用できず、すべて削除できます。
もちろん、この操作は非常にリスクが高く、データベース全体で AO カラムストレージテーブルを使用するビジネスがバッチ処理のみで、ポイントチェックや範囲検索のビジネスがない場合にほぼ限られます。
要約すると、冗長インデックスを削除することでお客様のディスク領域を節約できます。


5. コピーテーブルを分散テーブルに変更

ご存知の通り、ADB PG のテーブル分散戦略には DISTRIBUTED BY（ハッシュ分散）、DISTRIBUTED RANDOMLY（ランダム分散）、DISTRIBUTED REPLICATED（全分散またはコピーテーブル）があります。
最初の 2 つのテーブルは指定された分散キーに従ってハッシュアルゴリズムでデータを各 Segment に分散します。
コピーテーブルは各 Segment にデータの完全なコピーを保存します。
レプリケートテーブル分散戦略（DISTRIBUTED REPLICATED）は小さなテーブルで使用する必要があります。
大きなテーブルデータを各ノードに複製することは、ストレージとメンテナンスの両方の観点からコストがかかります。
全分散テーブルをクエリする SQL は以下の通りです。


クエリ結果は下の図に示すように、約 10TB の全分散テーブルが見つかりました。
最初の 3 つのテーブルがより大きいため、ハッシュ分散テーブルに変更でき、約 7T の領域を節約できます。


6. 一時テーブル領域の独立保存

Greenplum には 2 つのデフォルトテーブルスペースがあることはご存知の通りです。


テーブル作成時にテーブルスペースを指定しない場合、デフォルトで pg_default テーブルスペースに配置されます。
ヒープテーブル、AO テーブル、カラムストレージテーブル、一時テーブルなどです。
Segment ファイルディレクトリでは、各 Segment サーバーの ~/data/Segment/${Segment_id}/base/${database_oid} ディレクトリの下にあります。
同時に、Greenplum はさまざまなシーンで一時テーブルを生成します。
例えば：

(1) SQL での order by や group by などの操作。


(2) データ読み取りやシャッフルの必要性により GP エンジンが作成する一時テーブル。


(3) ビジネスサイドが ETL タスクで作成する一時テーブル。


これには問題があります。
ビジネス操作によって生成された一時テーブルも領域を占有しますが、これはビジネステーブルのデータが占有するものではなく、大規模データベースのディスク領域を正確に管理するのが不便です。
したがって、一時テーブルのテーブルスペースを分離し、サーバーのファイルレベルでも独立させ、ビジネスデータの個別できめ細かな管理を容易にします。
利点もあります。
一時テーブル領域、データテーブル領域、WAL ログ、エラーログを個別にモニタリングし、各部分の占有状況を確認できます。
ディスク領域がアラートを出した場合、対象的な措置を取ることができます。
Greenplum の一時テーブルスペース作成方法は比較的標準的で、以下の通りです。


7. その他の最適化スキーム

上記で詳しく説明した最適化スキームに加えて、一般的に Greenplum にはいくつかの一般的な処理方法があります。
Segment コンピューティングノードの拡張、ビジネスデータのクリッピング、バックアップファイルのクリーンアップです。
コンピューティングノードの拡張が最も効果的です。
通常、Alibaba 自身のビジネスでも外部お客様のビジネスでも、データベースのディスク使用率が 60% に達すると、ビジネスの増加を考慮した後に拡張が計画されます。
これらの「基本プラクティス」についてお客様に伝える必要があります。


ビジネスデータのクリッピングは、コールドデータに加えて、一部の中間テーブルや履歴テーブルもあり、ビジネスサイドにデータのライフサイクル管理を適切に行い、タイムリーに削除またはアーカイブを転送するよう推進できます。
さらに、一時的な運用保守操作について、操作完了後に残ったバックアップファイルをタイムリーにクリーンアップする必要があります。
このシンプルな習慣は非常に無視されやすく、注意が必要です。
大規模ライブラリのディスク管理では、どんな小さな問題も拡大されます。


4: 最適化の成果

1. お客様のサーバーコストを節約

このケースでは、お客様元の DB2 データ量は 1PB を超えており、上記の方法を総合的に最適化し、ADB で 300T 以上のデータを保存するだけで、全体のビジネスを完全に実行できるようにしました。
お客様のために約 100 台のサーバーと関連するソフトウェアライセンスフィーを節約し、数千万円相当になります。


2. 高いディスク水位による二次災害を回避

高いディスク水位は多くの問題を引き起こします。
ディスク領域最適化スキームにより、これらの問題を回避できます。
以下が含まれます。


1. ビジネスのわずかな増加によりディスクがフルになり、「書き込みロック」が発生し、データベースが一時的にストライキに入る可能性があります。


2. ディスク領域が不十分な場合、運用保守担当者が問題を特定するための一時テーブルを作成できません。

3. ADB の大きなテーブルメンテナンス（VACUUM FULL など）で、使用可能な空きディスク領域がありません。

上記のディスク領域最適化方法は非常に包括的ではない可能性があり、読者のご参考になれば幸いです。記事に遺漏がある場合や読者の方で補足がある場合は、クラウド移行のコスト最適化についてコミュニケーションや議論を歓迎します。

用語集

ビジネスサイド：ビジネス開発またはデータ分析に Greenplum を使用するユーザーを指し、通常はお客様またはお客様の開発者です。

OLAP：オンライン分析処理システムを指し、データウェアハウスシステムの最も重要なアプリケーションです。複雑で大量のデータの分析とクエリ処理をサポートするために特別に設計されており、直感的で理解しやすい結果を迅速に返します。

DML：テーブルデータの追加、削除、変更、結合のための SQL を指し、データベース分野で DML 型 SQL と呼ばれます。