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
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
- 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
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
- 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.