The numbers of CPU cores, shards, and connections allocated to Hologres instances vary based on the instance type. In Hologres, storage resources are independent from computing resources and do not depend on the instance type. This topic describes the instance types that are available for use in Hologres. You can change the configurations of a Hologres instance to meet your business requirements. For example, you can upgrade or downgrade the configurations of the Hologres instance and separately manage its computing and storage resources.

Basics

The resources that are used to run a Hologres instance include resources consumed by metadata management processes, computing resources consumed by query services, and resources consumed by importing and caching services for optimized data writing. Hologres offers features based on cloud-native container technologies and provides high-performance parallel computing capabilities by using multiple parallel container-based compute nodes.

Hologres determines the maximum number of connections and the shard count for a Hologres instance based on the instance type. The default settings are tuned and optimized to meet the requirements of most scenarios. The maximum number of connections cannot be changed, but the shard count can be changed by creating table groups. When a Hologres instance is scaled up or down, the maximum number of connections is automatically adjusted. For databases created before the instance is scaled up or down, the shard count remains unchanged. You must manually change the shard count for the database. For databases created after the instance is scaled up or down, the shard count is determined based on the new instance type.

After a Hologres instance is scaled up, more CPU cores are available to improve the performance of concurrent queries. In most cases, you do not need to change the shard count. If you want to write more data to Hologres, you can increase the shard count to improve the write throughput. For row-oriented tables, a larger shard count makes it faster to read data from the tables.

Recommended instance types

When you use a Hologres instance, you may want to estimate the volume of data to store and determine which instance type is most appropriate and how many shards to configure. However, the instance type and shard count are related to a variety of factors, including the volume of data stored, access frequency, volume of data accessed, compute load type (such as point query or analysis), write throughput, and the number of tables in a table group. Therefore, it may be difficult for you to determine the appropriate instance type and the shard count. The following table describes the recommended instance types and shard counts for specific data volume ranges. You can select the appropriate settings based on your estimated data volume and recommended configurations.
Note The recommended instance types and shard counts for specific data volume ranges described in the following table are for reference only. Tables that contain a small volume of data can be added to a table group that has a large shard count, and tables that contain a large volume of data can also be added to a table group that has a single shard. You must select an appropriate shard count based on your business scenario to implement high concurrency, high computing efficiency, and high data concentration, and prevent unnecessary shuffle overheads.
Data volume Recommended instance type Recommended shard count Description
Less than 40 million rows More than 32 cores 10 to 20 This configuration is suitable for development environments rather than stress testing.
40 million to 400 million rows More than 64 cores 20 to 40 This configuration is suitable for scenarios in which no hybrid loads exist.
400 million to 4 billion rows More than 128 cores 40 to 80 This configuration offers balanced write and query capabilities. We recommend that you use starting settings for production systems.
4 billion to 40 billion rows More than 256 cores 80 to 240 We recommend that you configure two table groups for large and small tables, and configure different shard counts for these tables.
40 billion to 400 billion rows More than 512 cores 160 to 400 We recommend that you configure multiple table groups and configure a large shard count only for large tables. We recommend that you do not configure a large shard count for standard tables.

Default resource configurations

Hologres determines the maximum number of connections and the shard count for a Hologres instance based on the instance type. The following table describes the default resource configurations for each instance type.
Note
  • Each instance type specifies the numbers of compute nodes and frontend nodes. In instances that have 512 or fewer cores, the number of compute nodes is the same as the number of frontend nodes. In instances that have more than 512 cores, the number of frontend nodes is less than the number of compute nodes.
  • If you want to increase the number of CPU cores allocated to your instance to a number that is less than five times the default number, we recommend that you keep the shard count unchanged for the instance. This is because the default number is determined based on both write and query operations and is applicable to most scenarios.
  • Each node can have a memory size of up to 64 GB. The memory is used for computing, caching, and metadata storage. For Hologres versions earlier than V1.1.24, each node can have up to 20 GB of computing memory. For Hologres V1.1.24 or later, the computing memory can be elastically scaled. Remaining memory that is not used can be allocated for computing to improve the overall memory usage.
  • The maximum number of connections for an instance is calculated by using the following formula: Maximum number of connections for a Hologres instance = Maximum number of connections for a single frontend node × Number of frontend nodes. In each cell that is related to the maximum number of connections in the following table, the number that precedes the multiplication operator in the parentheses indicates the maximum number of connections for a single frontend node, and the number that follows the multiplication operator indicates the number of frontend nodes.
Instance type Default number of compute nodes Default shard count (for Hologres V0.10.30 or earlier) Default shard count (for Hologres V0.10.31 or later) Maximum number of connections (for Hologres V0.10.24 or earlier) Maximum number of connections (for Hologres V0.10.25 or later) Number of connections reserved for superusers (for Hologres V0.10 or earlier) Number of connections reserved for the superuser (for Hologres V1.1 or later)
32Core 2 20 20 128 (64 × 2) 256 (128 × 2) 6 10 (5 × 2)
64Core 4 40 40 256 (128 × 2) 512 (128 × 4) 6 20 (5 × 4)
96Core 6 60 60 384 (192 × 2) 768 (128 × 6) 6 30 (5 × 6)
128Core 8 80 80 513 (171 × 3) 1,024 (128 × 8) 9 40 (5 × 8)
160Core 10 100 80 640 (160 × 4) 1,280 (128 × 10) 12 50 (5 × 10)
192Core 12 120 80 770 (154 × 5) 1,536 (128 × 12) 15 60 (5 × 12)
256Core 16 160 120 1,026 (171 × 6) 2,048 (128 × 16) 18 80 (5 × 16)
384Core 24 N/A 160 N/A 3,072 (128 × 24) N/A 120 (5 × 24)
512Core 32 320 160 2,052 (171 × 12) 4,096 (128 × 32) 36 160 (5 × 32)

Newly supported instance types

From April 25, 2022, you can directly create a Hologres instance that has 640, 768, 896, or 1,024 CPU cores. If you need to create a Hologres instance that has more than 1,024 CPU cores, submit a ticket. Before you scale up your instance, make sure that the version of your instance is Hologres V1.1.58 or later. The following table describes the default resource configurations for each new instance type.
Instance type Default number of compute nodes Default shard count (for Hologres V1.1.58 or later) Maximum number of connections (for Hologres V1.1.58 or later) Number of connections reserved for superusers (for Hologres V1.1.58 or later)
640Core 40 160 5,120 (128 × 40) 200 (5 × 40)
768Core 48 160 6,144 (128 × 48) 240 (5 × 48)
896Core 56 160 7,168 (128 × 56) 280 (5 × 56)
1024Core 64 200 8,192 (128 × 64) 320 (5 × 64)
1280Core 80 200 10,240 (128 × 80) 400 (5 × 80)
1536Core 96 200 12,288 (128 × 96) 480 (5 × 96)
1792Core 112 200 14,336 (128 × 112) 560 (5 × 112)
2048Core 128 200 16,384 (128 × 128) 640 (5 × 128)
2304Core 144 240 18,432 (128 × 144) 720 (5 × 144)
2560Core 160 240 20,480 (128 × 160) 800 (5 × 160)
3072Core 192 240 24,576 (128 × 192) 960 (5 × 192)
3584Core 224 240 28,672 (128 × 224) 1,120 (5 × 224)
4096Core 256 320 32,768 (128 × 256) 1,280 (5 × 256)
4608Core 288 320 36,864 (128 × 288) 1,440 (5 × 288)
5120Core 320 320 40,960 (128 × 320) 1,600 (5 × 320)
5632Core 352 320 45,056 (128 × 352) 1,760 (5 × 352)
6144Core 384 320 49,152 (128 × 384) 1,920 (5 × 384)
6656Core 416 320 53,248 (128 × 416) 2,080 (5 × 416)
7168Core 448 320 57,344 (128 × 448) 2,240 (5 × 448)
7680Core 480 320 61,440 (128 × 480) 2,400 (5 × 480)
8192Core 512 400 65,536 (128 × 512) 2,560 (5 × 512)

Query the maximum number of connections and manage connections

Hologres allows you to query the maximum number of connections for a Hologres instance and manage the connections to the Hologres instance.
  • Query the maximum number of connections for a Hologres instance
    After you create a Hologres instance and connect to it by using a development tool, you can execute the following statement to query the maximum number of connections for a single frontend node.
    Note Maximum number of connections for a Hologres instance = Maximum number of connections for a single frontend node × Number of frontend nodes. 
    -- Query the maximum number of connections for a single frontend node. The connections are distributed among multiple frontend nodes. 
show max_connections;
  • Manage connections

    Hologres reserves connections for superusers of an instance. When the number of connections to the instance reaches the upper limit specified for the instance type, the superusers can connect to Hologres and execute SQL statements to query idle connections and release them. The superusers can also upgrade the configurations of the instance based on the business requirements. For more information about how to query and release idle connections, see the "Connections" section in Metrics of Hologres.

Query and change the shard count for a Hologres instance

After a Hologres instance is scaled up, more CPU cores are available to improve the performance of concurrent queries. In most cases, you do not need to change the shard count. If you want to write more data to Hologres, you can increase the shard count to improve the write throughput.

For row-oriented tables, a larger shard count makes it faster to read data from these tables. For more information about how to query and change the shard count for a Hologres instance, see User guide of table groups and shard counts.