All Products
Search

This Product

    Hologres:Apply trial instances to production environments

    Document Center

    Hologres:Apply trial instances to production environments

    Last Updated:Apr 25, 2025

    If you have used a trial instance of Hologres and are ready to conduct more in-depth performance testing or use it in a production environment, you need to upgrade the instance specification to meet higher performance requirements. Without upgrading the instance, resource insufficiency may cause increased latency, slower processing speed, or service interruption when you conduct performance testing or run production tasks. This topic uses a trial instance with an 8-core specification as an example to describe how to apply a trial instance to a production environment.

    Step 1: Upgrade the instance specification

    The 8-core instance specification of Hologres is only recommended for experience use and functional testing, not for performance testing and business production scenarios.

    When you need to conduct further performance testing or connect to production tasks, you must first upgrade the instance to a higher specification, such as the 64-core specification. For more information about how to upgrade instance specifications, see Upgrade or downgrade instance specifications.

    Step 2: Modify the shard count

    Hologres is a distributed real-time data warehouse engine, and data is stored in data shards of the underlying storage system. A reasonable shard count enables better utilization of distributed computing resources, allowing parallel data processing and improving query performance.

    The default shard count for a Hologres 8-core instance is 2. After upgrading the instance specification, the default shard count remains unchanged, but the number of compute nodes (workers) increases, which cannot leverage the query performance advantages of a distributed system. Therefore, after you complete the instance specification upgrade, follow these steps to modify the shard count. For more information, see User guide of table groups and shard counts.

    Note

    The following steps can be performed in a visualized manner in HoloWeb. For more information, see Manage table groups.

    1. Create a table group and set an appropriate shard count.

      The recommended shard count for a Hologres 64-core instance is 40. Run the following command to create a table group and set the shard count:

      CALL HG_CREATE_TABLE_GROUP ('<new_tg_name>', <shard_count>);

      new_tg_name indicates the name of the new table group, and shard_count indicates the shard count.

    2. Configure the new table group as the default table group.

      Run the following command to configure the new table group as the default table group. Subsequently created tables will belong to the new table group by default.

      CALL HG_UPDATE_DATABASE_PROPERTY ('default_table_group', '<new_tg_name>');

    3. Migrate existing tables to the new table group.

      Existing tables in the instance still belong to the original table group. Run the following command to migrate existing tables to the new table group.

      -- Syntax for Hologres V1.1 and later
CALL HG_MOVE_TABLE_TO_TABLE_GROUP('<table_name>','<new_tg_name>');

-- Syntax for Hologres V0.10
CALL HG_UPDATE_TABLE_SHARD_COUNT('<table_name>','<new_tg_name>');

    (Optional) Resource isolation and high availability

    If your business requires read/write splitting or read/read splitting, you can use the shared-storage multi-instance high availability solution supported by Hologres. For more information, see Configure read/write splitting for primary and secondary instances (shared storage).

    Using 64 cores as an example, you can adjust the specification of the primary instance to 32 cores for handling data write tasks, and create a 32-core read-only secondary instance for handling business query requirements, achieving read/write splitting. If multiple businesses have query requirements, you can handle them through more read-only secondary instances, achieving read/read splitting.

    Next steps

    After your job is deployed to the production environment and becomes stable:

    • For computing resources, it is recommended to switch your billing method from pay-as-you-go to subscription to save costs. For the cost differences between the two billing methods, see Billing overview. For more information about how to switch the billing method, see Change billing methods.

    • For storage resources, it is recommended to purchase standard storage in subscription mode (upgrade the instance specification after switching to subscription billing) to reduce storage costs.

    References