Hologres は、さまざまなコア数およびメモリリソースを備えた複数のインスタンスタイプを提供しています。コンピュートとストレージが分離されたアーキテクチャを採用しているため、ストレージリソースはインスタンスタイプとは独立しています。本トピックでは、各インスタンスタイプのリソース仕様について説明します。必要に応じて、スペックアップ、スペックダウン、またはコンピュートおよびストレージリソースを個別にスケーリングすることで、インスタンスの仕様を動的に調整できます。
用語
Hologres のランタイムリソースには、データ管理のためのプロセスリソース、クエリサービスのための計算リソース、データ書き込みパスを最適化するためのリソース、およびキャッシュサービスが含まれます。すべてのサービスはクラウドネイティブなコンテナー技術に基づいており、複数の並列コンテナ計算ノードを使用して高性能な並列計算を実現しています。
Hologres は、インスタンスのリソース仕様に基づき、デフォルトの最大接続数および Shard Count を設定します。これらのデフォルト構成は、ほとんどのシナリオ向けにチューニングおよび最適化されています。最大接続数は変更できません。Shard Count は新しいテーブルグループを作成することで調整可能です。インスタンスをスケールアウトまたはスケールインした場合、最大接続数も自動的に調整されます。ただし、既存のデータベースのデフォルト Shard Count はスケーリング操作中には変更されず、手動で修正する必要があります。新規データベースは、新しい仕様に対応したデフォルト Shard Count を使用します。
スケールアウト後、より多くのコアリソースによりクエリの同時実行性が向上します。ほとんどのシナリオでは、Shard Count を調整する必要はありません。書き込みスループットをさらに高める必要がある場合は、Shard Count を増やすことで同時書き込みスループットを改善できます。ただし、オンライン分析処理(OLAP)クエリの場合、Shard Count を増やしてもクエリパフォーマンスが大幅に向上することはなく、システムの同時スループットが低下する可能性さえあります。調整を行う前に、その基本原理を理解することが重要です。また、行指向テーブルでは、自然な分散特性により、Shard 数が多いほど読み取り性能が向上します。
推奨インスタンスタイプ
各シャードはデータの一部に対する読み取りおよび書き込みサービスリクエストを処理します。同一のテーブルグループ内では、各テーブルのデータの一部が同じシャードに分散されます。これらのテーブルがシャード内で結合できる場合、これは「ローカルジョイン」と呼ばれ、より効率的な結合方法です。データが同じシャードにない場合、データを再配置するためにリダイストリビューションオペレーターが必要となり、ネットワーク転送およびスケジューリングのオーバーヘッドが増加します。そのため、シャード設計時には、計算処理がシャード間で並列化可能か、あるいはシャード間でのデータ交換が必要かどうかを慎重に検討する必要があります。データの書き込みおよび更新シナリオでは、書き込みおよび更新はシャード間で並列化可能なため、シャード数が多いほどスループットが高くなります。ポイントクエリシナリオでは、各クエリが特定のシャードを正確にヒットできる場合(このプロセスは「シャードプルーニング」と呼ばれます)、シャード数が多いほど同時実行性が高くなります。一方、OLAP クエリでは複数のシャードが計算に参加する必要があり、必然的にデータ交換が発生します。シャード数が多すぎるとノード間のスケジューリングオーバーヘッドが増え、最終的にクエリの同時実行性が低下します。
Hologres インスタンスをご利用の際は、想定されるデータ量に最も適したインスタンスタイプおよび Shard Count を決定する必要があります。最適なインスタンスタイプおよび Shard Count は、データストレージ量だけでなく、アクセス頻度、実際のデータアクセス量、計算ペイロードの種類(ポイントクエリまたは分析など)、書き込みスループット、テーブルグループ内のテーブル数などの要因にも依存します。したがって、唯一の正解はありません。以下の表は、推定データ量に基づいた推奨 Shard Count およびインスタンスタイプを示しています。ご自身のニーズに合ったパラメーター設定をお選びください。
以下の表に記載されている推奨 Shard Count およびインスタンスタイプは、あくまで参考情報です。たとえば、小規模データのテーブルは Shard Count が高いインスタンスに配置でき、大規模データのテーブルは単一シャードのインスタンスに配置することも可能です。ビジネスシナリオに応じて適切な Shard Count を選択してください。目標は、計算効率を高めるための高い同時実行性を実現しつつ、不要なシャッフルオーバーヘッドを回避するためにデータを集中させることです。
|
合計データサイズ |
推奨仕様 |
推奨 Shard Count |
注意事項 |
|
4,000 万行未満 |
32 コア以上 |
10 ~ 20 |
ストレステストには不向きです。開発環境向けに推奨されます。 |
|
4,000 万行 ~ 4 億行 |
64 コア以上 |
20 ~ 40 |
混合ペイロードのないシンプルなビジネスシナリオに適しています。 |
|
4 億行 ~ 40 億行 |
128 コア以上 |
40 ~ 80 |
書き込みとクエリの能力がバランスよく調整されています。本番システムのデフォルト開始構成として推奨されます。 |
|
40億~400億行 |
256 コア以上 |
80 ~ 240 |
複数のテーブルグループの使用を検討してください。異なるビジネス属性の凝集性またはデータ量に基づいてテーブルグループを分割し、それぞれのテーブルグループに対して異なるシャードを設計し、テーブル作成時に明示的にテーブルグループを指定してください。 |
|
400 億行 ~ 4,000 億行 |
512 コア以上 |
160 ~ 400 |
複数のテーブルグループの使用を検討してください。異なるビジネス属性の凝集性またはデータ量に基づいてテーブルグループを分割し、それぞれのテーブルグループに対して異なるシャードを設計し、テーブル作成時に明示的にテーブルグループを指定してください。非常に大規模なテーブルに対してのみ、より多くのシャード数を割り当ててください。標準的なテーブルには、高い Shard Count は推奨されません。 |
デフォルトインスタンスリソース
Hologres は、インスタンスのリソース仕様に基づき、デフォルトの最大接続数および事前割り当て済みの Shard Count を提供します。デフォルト構成は以下の表のとおりです。
2022 年 4 月 25 日以降、汎用インスタンスは 512 CUs ~ 1,024 CUs の計算リソース仕様をサポートしています。それ以上の仕様をご希望の場合は、チケットを送信してください。より大きなリソース仕様にスペックアップする前に、インスタンスを V1.1.58 以降にアップグレードする必要があります。
計算グループインスタンスの場合、チケットを送信せずに 32 CUs ~ 8,192 CUs の任意の仕様を柔軟に購入できます。
-
各インスタンスタイプには計算ノードおよびフロントノードが含まれます。16 CUs ごとに 1 つの計算ノードが対応します。512 CUs 以下の仕様では、デフォルトの計算ノード数はフロントノード数と同じです。1,600 CUs 以上の仕様では、フロントノード数は 100 のまま固定されます。
-
インスタンスを元のサイズの 5 倍未満でスケールアウトする場合、Shard Count を調整しないでください。このデフォルト仕様はほとんどのシナリオに適しており、書き込みおよびクエリのバランスの取れた構成を提供します。
-
合計最大接続数 = フロントノードあたりの最大接続数 × フロントノード数。括弧内の値は各ノードの仕様を示しています。乗算記号の前の数値はアクセスノードあたりの最大接続数、後の数値はフロントノードの総数です。
|
インスタンスタイプ |
計算ノード数 |
デフォルトの Shard Count |
合計最大接続数(V2.1 以前) |
合計最大接続数(V2.2 以降) |
Superuser 用予約接続数合計(V1.1 以降) |
|
32 CUs |
2 |
20 |
256(128 × 2) |
512(256 × 2) |
10 (5 × 2) |
|
48 ~ 80 CUs |
3 ~ 5 |
40 |
128 × 計算ノード数 |
256 × 計算ノード数 |
5 × 計算ノード数 |
|
96 ~ 112 CUs |
6 ~ 7 |
60 |
128 × 計算ノード数 |
256 × 計算ノード数 |
5 × 計算ノード数 |
|
128 ~ 192 CUs |
8 ~ 12 |
80 |
128 × 計算ノード数 |
256 × 計算ノード数 |
5 × 計算ノード数 |
|
208 ~ 352 CUs |
13 ~ 22 |
120 |
128 × 計算ノード数 |
256 × 計算ノード数 |
5 × 計算ノード数 |
|
368 ~ 992 CUs |
23 ~ 62 |
160 |
128 × 計算ノード数 |
256 × 計算ノード数 |
5 × 計算ノード数 |
|
1,008 ~ 1,584 CUs |
63 ~ 99 |
200 |
128 × 計算ノード数 |
256 × 計算ノード数 |
5 × 計算ノード数 |
|
1,600 ~ 2,272 CUs |
100 ~ 142 |
200 |
12,800 (128 × 100) |
25,600 (256 × 100) |
500 (5 × 100) |
|
2,288 ~ 4,000 CUs |
143 ~ 250 |
240 |
12,800 (128 × 100) |
25,600 (256 × 100) |
500 (5 × 100) |
|
4,016 ~ 8,000 CUs |
251 ~ 500 |
320 |
12,800 (128 × 100) |
25,600 (256 × 100) |
500 (5 × 100) |
|
8,016 ~ 8,192 CUs |
501 ~ 512 |
400 |
12,800 (128 × 100) |
25,600 (256 × 100) |
500 (5 × 100) |
デフォルトインスタンス接続数の確認と管理
Hologres では、インスタンスのデフォルト接続数を確認および管理できます。
-
接続数の確認
インスタンスを作成し、開発者ツールに接続した後、次の文を実行して、単一のフロントノードあたりの最大接続数を確認できます。戻り値は、単一のフロントノードあたりの最大接続数です。
説明Hologres インスタンスの合計最大接続数 = フロントノードあたりの最大接続数 × フロントノード数
-- 単一アクセスノードあたりの最大接続数を確認します。接続は複数のアクセスノードに均等に分散されます。 show max_connections; -
接続の管理
インスタンスには Superuser 用の予約接続が提供されています。接続数がデフォルト制限に達した場合、Superuser は Hologres に接続し、SQL コマンドを使用してアイドル接続を確認・解放したり、必要に応じてインスタンスをスペックアップしたりできます。アイドル接続の確認および解放方法の詳細については、「接続数」をご参照ください。
インスタンス Shard Count の確認と変更
インスタンスをスケールアウトした後、通常は Shard Count を調整する必要はありません。なぜなら、より多くのコアリソースによりクエリの同時実行性が向上するためです。書き込みスループットをさらに高める必要がある場合は、Shard Count を増やすことで同時書き込みスループットを改善できます。
また、行指向テーブルでは、自然な分散特性により、シャード数が多いほど読み取り性能が向上します。インスタンス Shard Count の確認および変更方法については、「テーブルグループおよび Shard Count ユーザーガイド」をご参照ください。