@Rocky Shared-data clusters now support range-based data distribution and automatic splitting and merging of tablets. Tablets can be automatically split when they become oversized or hotspots, without requiring schema changes, SQL modifications, or data re-ingestion. This feature can significantly improve usability, directly addressing data skew. 1) Does nothing-shared support range distribution? 2) Does range distrubtion possible with partition? In fact table both with partitioning but range buketing? Or does it always has 1 partition?

Based on the latest StarRocks features (introduced in version 4.1), here are the answers to your questions regarding range-based data distribution and automatic tablet management: 1) Does shared-nothing (nothing-shared) support range distribution? Currently, range-based data distribution and automatic tablet splitting/merging are only supported in Shared-data (Cloud-native) clusters. This feature is designed specifically for the disaggregated storage-compute architecture. In a Shared-data cluster, data is stored in centralized remote storage (like S3 or HDFS). This allows the system to split or merge tablets by simply updating metadata and logically re-dividing the data files without the need to physically move or replicate data across local disks—a process that would be significantly more complex and resource-intensive in a Shared-nothing architecture. * Shared-data: Supports range-based distribution, automatic splitting of oversized tablets, and merging of small tablets. * Shared-nothing: Continues to use Hash and Random bucketing. Tablet counts are generally fixed at the time of partition creation, though they can be adjusted manually via

ALTER TABLE

. 2) Does range distribution work with partitioning? Yes, range distribution works seamlessly with partitioning. It is not restricted to a single partition. StarRocks maintains its two-level data distribution strategy: 1. First Level (Partitioning): You can use Expression, Range, or List partitioning (e.g., partitioning by

event_date

). This splits the table into high-level management units. 2. Second Level (Bucketing/Distribution): Within each partition, data is distributed into tablets. While traditional tables use Hash or Random bucketing at this level, range-based distribution allows the data within that specific partition to be distributed based on the range of the key columns (typically the

ORDER BY

or

DUPLICATE KEY

columns). Key details of this behavior: * Multi-partition support: You can have a table partitioned by day, and within each day's partition, the tablets will be automatically managed via range distribution. * Automatic Management: If a specific day's partition receives a massive influx of data (a hotspot), StarRocks will automatically split the tablets in that specific partition to maintain optimal performance and balance. * Syntax: If

enable_range_distribution

is enabled (in v4.1+), you can create such a table by specifying an

ORDER BY

clause (for Duplicate Key tables) without a

DISTRIBUTED BY

clause. Summary Comparison: Feature | Hash/Random Bucketing | Range-based Distribution Cluster Type | Shared-nothing & Shared-data | Shared-data Only Tablet Count | Fixed (or manual change) | Automatic (Dynamic) Partitioning | Supported | Supported Data Skew | Handled via good key selection | Automatically mitigated Automatically mitigated via splitting** | References • table_design/data_distribution/Data_distribution.md • table_design/data_distribution/feature-support-data-distribution.md • deployment/shared_data/feature-support-shared-data.md • table_design/data_distribution/dynamic_partitioning.md

@Rocky is it any plan for support this in shared-nothing?

As of the latest product roadmap and the release of version 4.1, there is no official plan or timeline to support automatic range-based tablet splitting and merging in Shared-nothing (BE-based) clusters. While the StarRocks team is always evaluating feature parity, this specific functionality is architecturally tied to the Shared-data (Cloud-native) mode for several technical reasons: 1. Metadata vs. Physical Movement * Shared-data: Since data is stored in centralized object storage (like S3), "splitting" a tablet is primarily a metadata operation. The system creates new metadata entries pointing to existing data files and re-divides the ranges. No physical data needs to be copied between physical nodes. * Shared-nothing: In this architecture, tablets are physically stored on the local disks of specific Backend (BE) nodes. Splitting or merging would require significant physical I/O to move data across disks or nodes, making it a heavy and resource-intensive operation that could impact cluster stability and performance. 2. Roadmap Focus (2026) The StarRocks 2026 Roadmap explicitly categorizes "Range-based data distribution" and "Auto tablet split" under the Native Storage (shared-data) section. The focus for Shared-nothing remains on: * Sub-second data freshness. * Large-scale workload optimizations (lock optimizations, concurrent transaction commits). * Enhanced Batch processing (ETL mode, disk spill). 3. Current Workarounds for Shared-nothing If you are using a Shared-nothing cluster and facing data skew or hotspot issues, the recommended approaches remain: * Random Bucketing (v3.1+): Use

DISTRIBUTED BY RANDOM

for Duplicate Key tables to ensure data is evenly spread regardless of key distribution. * Automatic Bucket Number (v2.5.7+): Let StarRocks automatically determine the initial bucket count based on your cluster size and disk count. * Manual Adjustment: Use

ALTER TABLE ... MODIFY SET ("bucket_num" = "XX")

if you find that a table's distribution is no longer optimal. Summary: While the "Virtual Buckets" infrastructure (#59134) is being built to make data distribution more flexible across the board, the automatic, range-based dynamic management remains a flagship feature of the Shared-data architecture to leverage the benefits of storage-compute separation. References • table_design/data_distribution/Data_distribution.md • deployment/shared_data/feature-support-shared-data.md • table_design/data_distribution/feature-support-data-distribution.md • quick_start/shared-data.md

@Rocky show me specific internal code that split a table is only a metadata change. I think segments in s3 or anything else will be splitted.

In StarRocks Shared-data (Cloud-native) architecture (v4.1+), splitting a table is indeed a metadata-only operation. The underlying data files (segments) in S3 are not physically split or rewritten during the process. Instead, the system leverages a "Metadata Reference" and "Range Filtering" approach. Here is the technical breakdown of the internal mechanism: 1. The Core Concept: Virtual Buckets & Range Metadata The foundation of this feature is the Virtual Bucket layer introduced in PRs like #59134. * Logical Layer: A Tablet represents a specific range of the sort key (e.g.,

user_id

from

1000

to

2000

). * Physical Layer: Data is stored in immutable Segments (S3 objects). A single segment might contain keys ranging from

1000

to

2000

. 2. How the "Split" Occurs (Metadata Change) When a tablet becomes a hotspot or oversized and needs to split: 1. FE Metadata Update: The Frontend (FE) identifies the split point (e.g.,

1500

). 2. Creation of New Tablets: Two new tablets are registered in the metadata. * Tablet A: Range

[1000, 1500)

* Tablet B: Range

[1500, 2000]

3. Referencing Existing Rowsets: Both Tablet A and Tablet B are updated to point to the exact same Rowset and Segment IDs that the parent tablet used. No data is copied. 3. Internal Code Logic: "Skipping Deletion" and "Shared Files" To prevent S3 objects from being deleted while they are still referenced by the new "split" tablets, StarRocks introduced logic to mark files as shared. * PR #71135 (and related #70685) explicitly implements a fix to skip data file deletion for range distribution tablets. * In the

lake

(Shared-data) storage engine, the

TabletMetadata

structure (defined in

protos/lake_metadata.proto

) tracks which data files belong to a tablet. When a split happens, the versioning mechanism ensures that the new metadata entries "inherit" the file references from the parent. 4. How Queries Work (The "Read-Time Split") If the segments aren't split, how does a query on Tablet A avoid reading Tablet B's data? * Segment Range Pruning: Each segment file in StarRocks contains internal metadata (min/max values for columns). * Scan-Time Filtering: When a Compute Node (CN) scans Tablet A, the Scan operator is aware of the tablet's range boundaries (

[1000, 1500)

). As it reads the shared segment file, it applies these range predicates at the storage engine level to skip data blocks that fall outside the current tablet's boundaries. 5. When does physical splitting actually happen? The data is eventually "physically" reorganized during Compaction. * When the background compaction process runs for Tablet A, it will read the shared segments, filter out the data that no longer belongs to its range (

>1500

), and write a new, smaller segment containing only the relevant data. * The old, large shared segment remains in S3 until all tablets referencing it (A and B) have undergone compaction and no longer need it. At that point, the StarRocks Vacuum process (Garbage Collector) deletes the original file from S3. Summary for your curiosity: * Shared-nothing: Splitting = Physical data movement + rewriting (High cost). * Shared-data: Splitting = Metadata pointer creation + Scan-time filtering (Near-zero cost). * The "Secret Sauce": The

lake

engine's ability to have multiple tablets reference the same physical S3 objects via versioned metadata. Relevant Code Areas in GitHub: * `fe/fe-core/src/main/java/com/starrocks/clone/TabletScheduler.java`: Logic for deciding when to split. * `be/src/storage/lake/`: The implementation of the Shared-data storage engine. * `protos/lake_metadata.proto`: Definition of how tablets map to files and ranges to files are tracked. References • faq/shared_data_faq.md