在實踐過程中存在數據量可預估，最適宜的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數很小將會存在并發不夠的風險。