多数回の反復と更新の後、elastic storageモードとServerlessモードは、AnalyticDB for PostgreSQLインスタンスの主要なリソースタイプになりました。 このトピックでは、インスタンス購入時のサービスエクスペリエンスを向上させるために、仕様とストレージ容量を選択する方法について説明します。
インスタンス仕様を選択するプロセスを簡素化するには、次のパラメーターのみを設定して、エラスティックストレージモードまたはサーバーレスモードでAnalyticDB for PostgreSQLインスタンスを作成する必要があります。
インスタンスリソース
エンジンバージョン
エラスティックストレージモードでは、次のエンジンバージョンを使用できます。
6.0 Standard Editionは、オープンソースのGreenplum Databaseに基づいて開発され、一般的なビジネスシナリオに適した標準エンジンを提供します。
7.0 Standard Edition: PostgreSQL 12に基づいて構築された標準エンジンを提供し、機能、パフォーマンス、エンタープライズクラスの機能、およびセキュリティの点で競争力があります。
ノード仕様
AnalyticDB for PostgreSQLは、大規模並列処理 (MPP) アーキテクチャを使用します。 各AnalyticDB for PostgreSQLインスタンスは、1つ以上のコーディネーターノードと複数のコンピュートノードで構成されています。 コーディネータノードは、SQL要求を受信し、ルートを配布し、結果セットを処理する。 計算ノードはSQLクエリを実行し、データを保存します。 各計算ノードは、データを処理し、テーブルパーティションに格納する。 各テーブルパーティションは、MPPアーキテクチャにおけるデータパーティションである。
インスタンスを作成またはアップグレードする場合は、[コーディネーターノードリソース] 、[コンピュートノード仕様] 、[コンピュートノード] 、および [ディスクストレージタイプ] パラメーターを設定する必要があります。
コーディネーターノードリソース: コンピュートユニット (CU) の数がコンピュートノードあたりのCPUコアの数に等しいコーディネーターノードリソースを選択することを推奨します。
より多くのコーディネーターノードリソースが必要な場合は、インスタンスの作成後にリソースを追加できます。 詳細については、「コーディネーターノードリソースの管理」をご参照ください。
計算ノード仕様:
ノードあたり2コアと16 GBのメモリ。これは、低並行性のシナリオに適しています。
ノードあたり4コアと32 GBのメモリ。中程度の同時実行シナリオに適しています。 このオプションを選択することを推奨します。
ノードあたり8コア、64 GBのメモリ。同時実行性の高いシナリオに適しています。
ノードあたり16コアと128 GBのメモリ。非常に高い同時実行性のシナリオに適しています。
コンピュートノード: MPPアーキテクチャを使用すると、インスタンスのデータ処理能力がコンピュートノードの数に比例して増加します。 ただし、クエリ応答時間は、データ量が増加するかどうかに関係なく同じままです。 ビジネスシナリオと生データの量に基づいて、計算ノードの数を決定できます。
ディスクストレージタイプ:
ESSD (Enhanced SSD): パフォーマンス優先のシナリオで、より優れたI/O機能とより高い分析パフォーマンスを実現します。
ストレージタイプ
ノードあたりのコア数
メモリ
Storage
推奨シナリオ
ESSD
2
16 GB
50 GBから1テラバイト
低並行性のシナリオ。インスタンスには4〜128の計算ノードがあります。
ESSD
4
32 GB
50 GBから2テラバイト
同時実行性の高いシナリオ。インスタンスには4〜128の計算ノードがあります。
メモリ容量とディスク容量の推奨比率は、CPUコアあたり8:80です。 高いキャッシュヒット率を実現し、インスタンスの全体的なパフォーマンスを確保するために、各計算ノードのメモリに対するデータ量の比率を20以下に維持することを推奨します。
暗号化タイプ:
データセキュリティ準拠が必要なシナリオでは、暗号化タイプを選択する必要があります。 デフォルトでは、ディスクは暗号化されません。 ディスク暗号化は、インスタンスが作成されている場合にのみ有効にできます。 インスタンスの作成後、ディスク暗号化を有効または無効にすることはできません。 ディスク暗号化機能を有効にするには、インスタンスの作成時に特定のパフォーマンスレベルでストレージタイプをESSDに設定します。 インスタンスでディスク暗号化を有効にすると、インスタンスで作成されたスナップショットと、これらのスナップショットから作成されたインスタンスがディスク暗号化機能を継承します。
ディスク暗号化機能により、ストレージディスクのI/Oパフォーマンスが低下し、インスタンスの応答時間と処理能力に影響を与える可能性があります。
インスタンス仕様の選択
高性能分析シナリオでは、5テラバイトの生データに対して100を超える同時クエリが実行される場合、ストレージタイプをSSDに設定し、コンピューティングノードの仕様を4コアと32 GBメモリに設定することを推奨します。 ストレージ使用量を80% 未満に維持するには、32個のコンピューティングノードと1ノードあたり200 GBのストレージを持つインスタンスを作成します。 AnalyticDB for PostgreSQLは、プライマリ /セカンダリの高可用性アーキテクチャを使用して、デュアルレプリカを提供します。
行指向ストレージおよび列指向ストレージ
AnalyticDB for PostgreSQLは、行指向ストレージと列指向ストレージの2つのストレージモデルをサポートしています。 これらのストレージモデルには、さまざまなシナリオでのパフォーマンスとストレージの点で利点と欠点があります。 テーブルを作成するときに、いずれかのストレージモデルを指定できます。
多数のINSERT、UPDATE、またはDELETE操作を実行する必要があるオンライントランザクション処理 (OLTP) シナリオでは、行指向ストレージを使用できます。 OLTP操作とオンライン分析処理 (OLAP) 操作の両方を実行する必要がある場合は、パーティションテーブルを使用できます。 たとえば、時間ごとにテーブルを分割し、最大200個のパーティションを維持して、SQLパフォーマンスの最適化を実現できます。 大量のデータの詳細をクエリする場合は、行指向のストレージを使用することもできます。 行指向ストレージを選択した場合、1テラバイトの生データには約1テラバイトのストレージが必要です。 ただし、コンピューティング中に生成されたインデックス、ログ、および一時ファイルもストレージを占有します。 この場合、生データ1テラバイトごとに1テラバイトの追加ストレージを予約することをお勧めします。 クエリのパフォーマンスを向上させるために、ノードを追加して使用可能なCPUおよびメモリリソースを増やすことができます。
データ統計を頻繁に収集する必要があるOLAPシナリオでは、列指向ストレージを使用できます。 たとえば、データがバッチ保存され、少量のデータが更新または削除されるバッチ処理のETL (extract-transform-load) シナリオでは、複数の列でテーブルデータの集計クエリを実行する必要があります。 より高い圧縮率が必要な場合は、列指向ストレージを使用することもできます。 カラム指向ストレージは、1:5〜1:2の範囲の圧縮比を提供する。 たとえば、列指向ストレージモードでの圧縮後に1テラバイトの生データが0.5テラバイト以下に削減された場合、インスタンスを作成するときに1テラバイトのストレージのみを選択する必要があります。
AnalyticDB for PostgreSQLは、OSS (Object storage Service) 外部テーブルへのデータストレージをサポートしています。 gzipユーティリティを使用して、リアルタイムコンピューティングに不要なデータを圧縮し、そのデータをOSSバケットにアップロードしてストレージコストを削減できます。