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

Basic concepts

The resources that are used to run a Hologres instance include the resources consumed by metadata management processes, the computing resources consumed by query services, and the resources consumed by importing and caching services for optimized data writing. Hologres offers features based on 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 using functions. When a Hologres instance is scaled up or down, the maximum number of connections is automatically adjusted. For a database 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 a database 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, which improves 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 easier for data to be read.

Recommended instance types

When you use a Hologres instance, you can estimate the volume of data to store and may want to determine the most appropriate instance type to use and the shard count to configure. However, the instance type and shard count are related to a variety of factors, including the volume of data to store, the frequency of access, the actual volume of data accessed, the type of computing loads (such as point query or analysis), the 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 appropriate settings based on the 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 0.4 billion rows More than 64 cores 20 to 40 This configuration is suitable for scenarios where no hybrid loads exist.
0.4 billion 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
  • To improve user experience, the maximum number of connections for each instance type in Hologres V0.10.25 or later is twice that of the same instance type in Hologres V0.10.24 or earlier. For Hologres V0.10.31 or later, the shard count for each instance type is decreased. The following table provides detailed information.
  • 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 a maximum computing memory of 20 GB. For Hologres V1.1.24 or later, the computing memory can be elastically scaled.
  • 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, whereas the number that follows the multiplication operator indicates the number of frontend nodes.
Instance type Default number of 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 the superuser (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)
400Core 25 240 160 1,600 (160 × 10) 3,200 (128 × 25) 30 125 (5 × 25)
512Core 32 320 160 2,052 (171 × 12) 4,096 (128 × 32) 36 160 (5 × 32)

Query the maximum number of connections and manage the 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 it to 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. 
    show max_connections;
  • Manage connections

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

Query and change the shard count for a Hologres instance

After a Hologres instance is scaled up, more CPU cores are available, which improves 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 easier for data to be read. For more information about how to query and change the shard count for a Hologres instance, see Resharding.