Table Group设置最佳实践

在实践过程中存在数据量可预估，最适宜的Shard数区间应该设置为多少的问题，由于最适宜Shard数不仅和数据存储量有关，还和实际访问频率、实际数据访问量、计算负载的类型（点查、分析等）、写入吞吐、Table Group上表的个数等因素有关，该问题无法给出准确答案。您可参见下表中根据数据量估算的所需Shard数和实例规格的推荐数，选择适合您的参数配置。

您可以根据以下Table Group规划的最佳实践，来决定是否需要新建以及如何放置Table Group。

• 规划一：使用默认Table Group

  如果您使用Hologres满足下列条件，建议您直接使用默认Table Group即可。Hologres实例升配或降配后，默认Table Group的Shard数不会变，因此可以通过如下命令语句，查看Table Group的Shard数。

  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)

  • 数据量：

    当前默认Table Group的Shard数，符合目前数据量大小的需求。可以使用默认Table Group直接建表。

  • 总体规模：

    全部表的数据量规模总和可控，可预估，使用方式没有大的变化。

  • Local Join：

    需要与已在默认Table Group的表，进行高效的Local Join。

• 规划二：新建Table Group

  如果默认Table Group不能满足您的需求，那么您可能需要多个Table Group。通常在如下条件下，在您的实例中可能需要多个Table Group：

  • 数据量

    已有Table Group的Shard数不适合当前表的预估数据量，例如，数据量小的表一般不适合放在大Table Group中，会造成小文件太多，IO开销变大，数据量大的表一般也不适合放在小Table Group中，造成查询并发度下降。这是最常见的需要划分多个Table Group的原因。

  • 负载分离

    已有的Table Group容纳的表数量很多，且大多数表需要同时写入，导致实例的负载很高，而即将创建的新表又需要较高的查询和写入吞吐，这时多个Table Group可以实现写入和查询一定程度上的独立，不受其他表写入查询影响（更准确的负载分离请参考计算资源隔离章节）。或者经过问题排查，确定是已有Table Group无法满足写入和查询需求时，也需要多个Table Group。

  • 表的相关性

    业务上有一系列具有独特写入或者查询模式的表，且这一系列表之间具有（或未来具有）Local Join的需求（Local Join需要左右表同在一个Table Group才能实现，并且Join Key是各自的分布列），同时这些表和其他Table Group的表具有很浅的联系或根本没有联系。这种情况下可以创建多个独立的Table Group。也就是说，如果您有一组表之间相关性很强的表，而这组表与其他表相关性很低、联合查询的概率很低，可以考虑创建多个Table Group。

  • 实例资源扩缩容

    如果实例进行过扩、缩容超过5倍以上，原来定的Shard数很可能不再满足需求，可以考虑更换默认Table Group。Shard数应大于计算节点数，小于实例总Core数的60%（即计算总Core数）。

• 规划三：多个Table Group放置

  如果需要规划多个Table Group，那么最好是能够在压测和生产之前，提前规划好多个Table Group的作用与意义，以及每个表所属的Table Group。规划时可以考虑如下因素：

  • 数据量

    首先应该考虑的是数据量，也就是大表放更多的Shard，中小表放更少的Shard。

  • 写入性能需求

    Shard数和数据写入性能呈一定的正相关性，单个Shard的写入能力是有上限的。Shard越多，写入的并发越多，写入的吞吐越高。因此，如果表有较高RPS的写入需求，那么可能需要增大shard数。Hologres单Shard将单core打满时，写入RPS为3000-5000条/秒（1KB/条），可以据此估算所需Shard数。考虑到每个shard还需要进行查询等读操作，一般不能使写入打满CPU，因此可以说，使用1/3core的shard，写入RPS为1000条/秒（每条1KB）。因此，举例而言，如果您要求写入RPS 6W/s，每条1KB，则应该选择的Shard数约在60Shard之上，视情况增减。

  • Table Group负载

    在建立一个新的Table Group时，需要考虑当前Table Group需要承载的表数量。例如，如果未来放在此Table Group的表很多，并且多数表都需要经常访问，那么Shard数很小将会存在并发不够的风险。