@Rocky In StarRocks shared-nothing mode, what topology options are available for distributing tablet replicas?

In StarRocks shared-nothing mode, you can control the distribution and topology of tablet replicas using several mechanisms to ensure high availability and resource isolation: 1. Rack Awareness (Location-based Topology) You can configure a location-aware topology to ensure that tablet replicas are distributed across different physical racks or availability zones. This prevents data loss if an entire rack or zone fails. * BE Labels: Assign a location label to each Backend (BE) node using the

labels.location

property.

sql
    ALTER SYSTEM MODIFY BACKEND "be_host:be_port" SET ("labels.location" = "rack:rack1");

* Table/MV Properties: When creating a table or materialized view, specify which locations should host the replicas. StarRocks will distribute replicas across the specified labels in a Round-Robin fashion.

sql
    CREATE TABLE example_table (...)
    PROPERTIES ("labels.location" = "rack:rack1,rack:rack2,rack:rack3");

2. Default High Availability Topology By default, StarRocks ensures that: * Node Diversity: Replicas of the same tablet are never placed on the same BE node. * Automatic Balancing: The

Tablet Scheduler

automatically balances replicas across BEs based on disk utilization and replica count. 3. Storage Medium Topology If your BE nodes have different types of drives (e.g., SSD and HDD), StarRocks can distribute replicas based on the storage medium: * Medium Categorization: StarRocks categorizes BE nodes by storage type and attempts to move tablets only between nodes of the same medium during balancing. * Property Control: You can specify the preferred storage medium for a table or partition using the

storage_medium

property (e.g.,

SSD

for hot data,

HDD

for cold data). 4. Colocation Topology (Colocate Join) For performance optimization, you can group related tables into a Colocation Group. This ensures that the corresponding tablets of different tables are stored on the same set of BE nodes, allowing for "local" joins that avoid data shuffling across the network. * Usage: Set the

colocate_with

property during table creation.

sql
    PROPERTIES ("colocate_with" = "group_name");

Summary of Topology Options Feature | Level | Purpose Rack Awareness | Table/BE | Fault tolerance against rack/zone failure. Storage Medium | Table/Partition | Tiered storage (hot/cold data separation). Colocation | Group of Tables | Performance optimization for joins. Default Balancing | Cluster | Uniform resource utilization across all nodes. References • administration/management/resource_management/be_label.md • administration/stargo.md • deployment/plan_cluster.md • faq/Deploy_faq.md

@Rocky The recommendation is to keep tablet size around 1 GiB — if a table keeps growing, is it possible to dynamically increase the number of tablets or something similar?

Yes, it is possible to increase the number of tablets (buckets) after a table has been created. StarRocks provides several mechanisms to handle data growth, depending on your version and bucketing strategy. 1. Dynamic Increase during Loading (Random Bucketing) Since v3.2.0, if you use Random Bucketing, StarRocks can dynamically increase the number of buckets in a partition as data is being loaded. * How it works: You must set the

bucket_size

property to specify the target size for a single bucket (e.g., 1 GiB). * Usage:

sql
    -- Enable dynamic growth by setting a target bucket size
    ALTER TABLE my_table SET ("bucket_size" = "1073741824"); -- 1 GiB

As data volume grows, StarRocks will automatically split or add buckets to maintain the target size. 2. Manual Re-bucketing (v3.2+) For tables using Hash Bucketing (or if you want to manually override), you can use

ALTER TABLE

to change the bucket count for existing partitions. * Change all partitions:

sql
    ALTER TABLE my_table DISTRIBUTED BY HASH(user_id) BUCKETS 20;

* Change specific partitions:

sql
    ALTER TABLE my_table PARTITIONS (p202312, p202401)
    DISTRIBUTED BY HASH(user_id) BUCKETS 30;

Note: This operation triggers a background data redistribution (re-sharding). 3. Automatic Bucketing (v2.5.7+) If you don't specify

BUCKETS

during table creation, StarRocks uses Automatic Bucketing. It determines the initial number of buckets based on the number of BE nodes and historical data volume in existing partitions. * When a new partition is created (e.g., in a time-series table), StarRocks looks at the data size of the last 5 partitions to decide the bucket count for the new one. 4. Changing Default Buckets for New Partitions If you want to keep existing data as-is but ensure all future partitions have more tablets, you can modify the default bucket count (supported from v3.5.8 and v4.0.1):

sql
ALTER TABLE my_table DISTRIBUTED BY HASH(user_id) DEFAULT BUCKETS 40;

Summary of Recommendations * Tablet Size: While 1 GiB was the historical recommendation, since v2.4.0 (with

enable_tablet_internal_parallel

set to

true

), StarRocks can efficiently handle tablets up to 10 GiB by scanning them with multiple threads. * Growth Strategy: For most users, Automatic Bucketing is recommended. If you have extremely unpredictable growth, Random Bucketing with

bucket_size

provides the most "elastic" behavior. References • table_design/data_distribution/Data_distribution.md • sql-reference/sql-statements/table_bucket_part_index/ALTER_TABLE.md • administration/management/FE_configuration.md References • sql-reference/sql-statements/table_bucket_part_index/ALTER_TABLE.md • table_design/data_distribution/Data_distribution.md • knowledge/usage/best-practice.md