Hologres:テーブルグループ設定のベストプラクティス

実際には、データ量が予測可能な場合に、最適な Shard Count の範囲を決定する必要があります。最適な Shard Count は、保存するデータ量だけでなく、実際のアクセス頻度、実際にアクセスされるデータ量、ポイントクエリやデータ分析などのコンピューティング負荷の種類、書き込みスループット、テーブルグループ内のテーブル数にも関連します。したがって、最適な Shard Count の正確な値を得ることはできません。次の表に、特定のデータ量範囲に対応する推奨 Shard Count とインスタンス仕様を示します。推定データ量に基づいて適切な設定を選択できます。

以下のプランのベストプラクティスに基づいて、テーブルグループを作成するかどうか、およびテーブルに適したテーブルグループを選択する方法を決定できます。

• プラン 1：デフォルトのテーブルグループの使用

  ご利用の Hologres インスタンスが以下の条件を満たす場合、デフォルトのテーブルグループを使用することを推奨します。Hologres インスタンスの仕様をアップグレードまたはダウングレードした後も、デフォルトのテーブルグループの Shard Count は変更されません。次のステートメントを実行して Shard Count をクエリできます。

  SELECT * FROM hologres.hg_table_group_properties;
  
  -- 結果の例
   tablegroup_name | property_key  | property_value
  -----------------+---------------+----------------
   test_tg_default | is_default_tg | 1
   test_tg_default | shard_count   | 40
   test_tg_default | tg_version    | 1
   test_tg_default | table_num     | 1
  (4 rows)

  • データ量

    デフォルトのテーブルグループの Shard Count がデータ量の要件を満たしている場合。この場合、デフォルトのテーブルグループにテーブルを作成できます。

  • 全体のサイズ

    すべてのテーブルの総データ量は制御可能で予測可能です。使用モードは大きく変化しません。

  • ローカル結合

    デフォルトのテーブルグループ内のテーブルに対して効率的なローカル結合操作を実行する必要がある場合。

• プラン 2：テーブルグループの作成

  デフォルトのテーブルグループが要件を満たせず、複数のテーブルグループが必要になる場合があります。ほとんどの場合、以下の条件下でインスタンスに複数のテーブルグループが必要になることがあります。

  • データ量

    既存のテーブルグループの Shard Count が、現在のテーブルで推定されるデータ量に対して不適切な場合。Shard Count が大きくデータ量が少ないと、過剰な小規模ファイルが生成され、I/O オーバーヘッドが高くなります。Shard Count が小さくデータ量が多いと、クエリの同時実行性が低下します。この場合、複数のテーブルグループが必要です。

  • ペイロード分離

    既存のテーブルグループに多数のテーブルが含まれており、ほとんどのテーブルに同時にデータを書き込む必要があるため、インスタンスの負荷が高くなっている場合。さらに、作成するテーブルが高いクエリおよび書き込みスループットを必要とする場合。この場合、データの書き込みとクエリをある程度独立させるために、複数のテーブルグループが必要です。詳細については、コンピューティングリソースを分離する方法に関するトピックをご参照ください。既存のテーブルグループが書き込みとクエリの要件を満たせないと判断した場合も、複数のテーブルグループが必要です。

  • テーブルの相関関係

    ビジネス上の一連のテーブルが独自のデータ書き込みまたはクエリパターンを持ち、ローカル結合の要件があるか将来的に発生する可能性があり、既存のテーブルグループ内のテーブルとの相関がほとんどまたはまったくない場合、その一連のテーブルに対して複数の独立したテーブルグループを作成できます。ローカル結合操作は、結合キーを分散キーとし、同じテーブルグループに属するテーブルでのみ実行できます。互いに強い相関関係があるが、既存のテーブルグループ内のテーブルとの相関がほとんどなく、ローカル結合の可能性が低い一連のテーブルに対して、テーブルグループを作成できます。

  • インスタンスリソースのスケーリング

    ご利用のインスタンスが 5 倍以上のスケールインまたはスケールアウトを行った場合、元の Shard Count が要件を満たさなくなる可能性があります。この場合、デフォルトのテーブルグループを変更できます。シャード数は計算ノード数より多く、かつ総 CPU コア数の 60% 未満である必要があります。

• プラン 3：複数のテーブルグループの配置

  複数のテーブルグループを計画するには、ストレステストと本番環境への適用前に、テーブルグループの役割と重要性、および各テーブルが属するテーブルグループを計画することを推奨します。計画時には以下の要素を考慮できます。

  • データ量

    Shard Count は、テーブルに保存されるデータ量によって決まります。Shard Count が大きいテーブルグループは大規模なテーブルに適しており、Shard Count が小さいテーブルグループは中小規模のテーブルに適しています。

  • 必要な書き込みパフォーマンス

    Shard Count は、データの書き込みパフォーマンスと正の相関関係にあります。単一シャードの書き込み能力には上限があります。シャードが多いほど、書き込みの同時実行性とスループットが高くなります。高い 1 秒あたりのレコード数 (RPS) でテーブルにデータを書き込むには、より大きな Shard Count が必要になる場合があります。単一コアの CPU 使用率が 100% の場合、Hologres の単一シャードは 3,000 から 5,000 RPS (1 レコードあたり 1 KB) でデータを書き込みます。必要な RPS に基づいて、必要な Shard Count を見積もることができます。各シャードはデータクエリなどの読み取り操作も実行する必要があるため、データ書き込みの CPU 使用率が 100% に達することはありません。CPU コアの 1/3 を使用するシャードは、1,000 RPS (1 レコードあたり 1 KB) でデータを書き込みます。たとえば、60,000 RPS でデータを書き込み、各レコードのサイズが 1 KB の場合、Shard Count は 60 より大きくする必要があります。Shard Count は微調整が可能です。

  • 各テーブルグループの負荷

    テーブルグループを作成する際には、このテーブルグループに追加されるテーブルの数を考慮する必要があります。将来的に多くのテーブルがこのテーブルグループに追加され、そのほとんどが頻繁にアクセスされる場合、Shard Count が小さいと高い同時実行性のクエリをサポートできない可能性があります。