0. Введение в StarRocks

StarRocks — это высокопроизводительная колонночная аналитическая MPP (масштабно-пар��ллельная обработка) СУБД для широкого круга сценариев. Благодаря колонночному хранению и векторизованному движку (для x86 — инструкции AVX) она достигает предельной производительности на агрегирующих операциях, таких как GROUP BY (на одном узле: сотни миллионов строк — результат за секунды).

1. Чем StarRocks отличается от ClickHouse?

ClickHouse не оптимален для многотабличных JOIN-ов, тогда как StarRocks устраняет это узкое место.

2. Чем StarRocks отличается от Greenplum?

StarRocks — колонночный движок. На колонночном движке StarRocks значительно быстрее Greenplum. При этом сильные стороны Greenplum — строчный формат хранения и полноценная поддержка транзакций, тогда как StarRocks обеспечивает лишь атомарность операций; сложные транзакции не поддерживаются.

1 Описание Tablet

1.1 Что такое Tablet

Tablet — это логический шард таблицы. Одна таблица может иметь несколько Tablet. По умолчанию каждый Tablet имеет 3 реплики (управляется параметром FE default_replication_num, параметр динамический; изменить можно так: ADMIN SET FRONTEND CONFIG ("default_replication_num" = "2"); — применяется немедленно).
StarRocks использует технологию MVCC (многоверсионное управление конкурентным доступом). За счет копирования физических реплик многоверсионных данных обеспечивается эффективное восстановление версий. Управление данными в StarRocks ведется на уровне Tablet.

1.2 Процесс записи данных

Клиент отправляет запрос на импорт данных на узел FE.
Узел FE выбирает один узел BE в качестве узла‑координатора (Coordinator BE) для данной импортной транзакции и генерирует план выполнения.
Узел‑координатор считывает у клиента данные для импорта.
Узел‑координатор распределяет данные по всем репликам соответствующих Tablet.
После загрузки и сохранения данных во все Tablet узел FE делает загруженные данные видимыми.
FE возвращает клиенту успешный результат импорта.

1.3 Управление Tablet

Метаданными Tablet управляет узел FE; при росте числа Tablet требуется соответствующим образом настраивать объём памяти JVM, чтобы обеспечить их управление.
Слишком большое количество Tablet увеличивает затраты ресурсов на управление метаданными и диспетчеризацию как на FE, так и на BE.
Рекомендации по памяти FE в зависимости от количества Tablet:
- До 1 млн: 16 GB
- 1–2 млн: 32 GB (рекомендовано для инициализации; -Xms и -Xmx одинаковые; для всех FE одинаково)
- 2–5 млн: 64 GB
- 5–10 млн: 128 GB

1.4 Обработка проблем, связанных с Tablet

Сбой узла BE или неудачный импорт могут привести к аномалиям реплик. StarRocks автоматически восстанавливает такие реплики.
Если таблица одно‑репликовая (фактор репликации = 1), и часть её Tablet расположена на BE, который планируется удалить, удаление такого BE запрещено.
Каждые tablet_sched_checker_interval_seconds (по умолчанию 20 секунд) узел FE выполняет проверку (Tablet Checker) всех реплик Tablet в кластере StarRocks.
При удалении таблицы команда SHOW PROC '/statistic'; покажет, что количество Tablet уменьшилось сразу, но в SHOW BACKENDS; поле TabletNum не уменьшится, потому что корзина (Recycle Bin) SR по умолчанию хранит удалённые данные сутки (управляется динамическим параметром FE catalog_trash_expire_second, по умолчанию 86400 секунд).
При добавлении или выводе из эксплуатации узлов BE система автоматически выполняет ребалансировку Tablet исходя из нагрузки. В этот момент в SHOW BACKENDS; видно, что TabletNum меняется: при добавлении BE часть Tablet переносится на новый узел, при выводе узла — наоборот.
Чтобы ускорить или снизить влияние балансировки Tablet на текущий кластер, можно настроить следующие параметры FE:
- tablet_sched_slot_num_per_path (по умолчанию: 8): число задач по Tablet, которые может одновременно выполнять один каталог хранения BE (полезно для снижения влияния миграции Tablet при масштабировании).
- tablet_sched_max_scheduling_tablets (по умолчанию: 10000): максимально допустимое количество одновременно планируемых Tablet. Если текущее число планируемых Tablet превышает это значение, шаги балансировки и проверки восстановления пропускаются.
- tablet_sched_max_balancing_tablets (по умолчанию: 500): максимальное число Tablet, одновременно находящихся в балансировке. При превышении этого значения ребалансировка новых Tablet пропускается.

1.5 Запросы, связанные с Tablet

1.5.1 Просмотр статистики базы данных

Просмотр статистики по всем базам текущего кластера:

SHOW PROC '/statistic';

Возвращаемые поля и описания:

DbId — ID базы данных.
DbName — имя базы данных.
TableNum — количество таблиц в базе данных.
PartitionNum — количество партиций в базе данных.
IndexNum — количество индексов в базе данных.
TabletNum — количество Tablet в базе данных.
ReplicaNum — количество реплик в базе данных (TabletNum × число реплик).
UnhealthyTabletNum — количество «нездоровых» Tablet (в т.ч. находящихся в процессе перераспределения/восстановления).
InconsistentTabletNum — количество несогласованных Tablet в базе данных.
CloningTabletNum — количество Tablet, для которых выполняется операция клонирования (Clone).
ErrorStateTabletNum — количество Tablet с ошибочным состоянием в таблицах с первичным ключом.
ErrorStateTablets — ID Tablet с ошибочным состоянием в таблицах с первичным ключом.
Более детальный просмотр статуса Tablet для конкретной БД:

SHOW PROC '/statistic/dbid';

Пример:

mysql> show proc '/statistic/356645';
+------------------+---------------------+----------------+-------------------+
| UnhealthyTablets | InconsistentTablets | CloningTablets | ErrorStateTablets |
+------------------+---------------------+----------------+-------------------+
| []               | []                  | []             | []                |
+------------------+---------------------+----------------+-------------------+
1 row in set (0.01 sec)

1.5.2 Состояние реплик таблицы

1.5.2.1 Запрос всех реплик

Просмотр Tablet в конкретной таблице с возможностью фильтрации по полям:

mysql> show tablet from db2.tbl2 where BackendId=10170\G
*************************** 1. row ***************************
               TabletId: 371281
              ReplicaId: 371282
              BackendId: 10170
             SchemaHash: 0
                Version: 4
            VersionHash: 0
      LstSuccessVersion: 4
  LstSuccessVersionHash: 0
       LstFailedVersion: -1
   LstFailedVersionHash: 0
          LstFailedTime: NULL
               DataSize: 1.7GB
               RowCount: 90000000
                  State: NORMAL
LstConsistencyCheckTime: NULL
           CheckVersion: -1
       CheckVersionHash: 0
           VersionCount: 1
               PathHash: -1
                MetaUrl: http://10.197.165.202:8040/api/meta/header/371281
       CompactionStatus: http://10.197.165.202:8040/api/compaction/show?tablet\_id=371281
           DiskRootPath: Unknown
           IsConsistent: true
               Checksum: -1
1 row in set (0.00 sec)

1.5.2.2 Статус синхронизации реплик

-- Просмотр статуса синхронизации реплик таблицы
ADMIN SHOW REPLICA STATUS FROM db2.tbl2 WHERE STATUS != "OK";

1.5.2.3 Распределение реплик

-- Просмотр распределения всех реплик таблицы с возможностью фильтрации
ADMIN SHOW REPLICA DISTRIBUTION FROM test.t1;

+-----------+------------+-------+---------+
| BackendId | ReplicaNum | Graph | Percent |
+-----------+------------+-------+---------+
| 10002     | 3          | >     | 33.33 % |
| 10170     | 3          | >     | 33.33 % |
| 10171     | 3          | >     | 33.33 % |
+-----------+------------+-------+---------+
3 rows in set (0.01 sec)

1.5.2.4 Запрос конкретного Tablet

-- Сначала узнать, какие Tablet у таблицы
SHOW tablet from db2.tbl2\G

-- Запрос конкретного Tablet
SHOW tablet 371281\G
       DbName: db2
    TableName: tbl2
PartitionName: tbl2
    IndexName: tbl2
         DbId: 356645
      TableId: 371279
  PartitionId: 371278
      IndexId: 371280
       IsSync: true
    DetailCmd: SHOW PROC '/dbs/356645/371279/partitions/371278/371280/371281';
1 row in set (0.00 sec)

-- Запрос детальной информации по Tablet
mysql> SHOW PROC '/dbs/356645/371279/partitions/371278/371280/371281'\G
*************************** 1. row ***************************
            ReplicaId: 371282
            BackendId: 10170
              Version: 4
          VersionHash: 0
    LstSuccessVersion: 4
LstSuccessVersionHash: 0
     LstFailedVersion: -1
 LstFailedVersionHash: 0
        LstFailedTime: NULL
           SchemaHash: -1
             DataSize: 1898090776
             RowCount: 90000000
                State: NORMAL
                IsBad: false
        IsSetBadForce: false
         VersionCount: 1
             PathHash: -1
              MetaUrl: http://10.197.165.202:8040/api/meta/header/371281
     CompactionStatus: http://10.197.165.202:8040/api/compaction/show?tablet\_id=371281&schema\_hash=-1
         IsErrorState: false
1 row in set (0.00 sec)

1.5.2.5 Число реплик

SELECT
    table_schema,
    table_name,
    SUBSTRING_INDEX(SUBSTRING_INDEX(PROPERTIES, '"replication_num":"', -1), '"', 1) AS replication_num
FROM
    information_schema.tables_config
WHERE
    table_schema IN('test','db1','db2')  -- Выбор баз данных
    AND PROPERTIES LIKE '%"replication_num":"3"}%'; -- Выбор количества реплик

+--------------+------------+-----------------+
| table_schema | table_name | replication_num |
+--------------+------------+-----------------+
| db1          | t2         | 3               |
| test         | t1         | 3               |
+--------------+------------+-----------------+
2 rows in set (0.05 sec)

1.5.3 Статус миграции Tablet

cluster_load_stat: состояние текущей загрузки кластера.
working_slots: текущее количество доступных рабочих слотов.
sched_stat: текущее состояние системы планирования.
priority_repair: число задач на восстановление Tablet с повышенным приоритетом.
pending_tablets: количество Tablet в ожидании обработки.
running_tablets: количество Tablet, находящихся в процессе восстановления.
history_tablets: количество Tablet, которые были восстановлены ранее.

1.5.3.1 До добавления узла BE

mysql> SHOW PROC '/cluster_balance';

+-------------------+--------+
| Item              | Number |
+-------------------+--------+
| cluster_load_stat | 1      |
| working_slots     | 3      |
| sched_stat        | 1      |
| priority_repair   | 0      |
| pending_tablets   | 0      |
| running_tablets   | 0      |
| history_tablets   | 0      |
| all_tablets       | 0      |
+-------------------+--------+
8 rows in set (10.19 sec)

1.5.3.2 После добавления узла BE

Видно, что выполняется только 8 задач (соответствует значению по умолчанию параметра tablet_sched_slot_num_per_path):

mysql> SHOW PROC '/cluster_balance';
+-------------------+--------+
| Item              | Number |
+-------------------+--------+
| cluster_load_stat | 1      |
| working_slots     | 4      |
| sched_stat        | 1      |
| priority_repair   | 0      |
| pending_tablets   | 471    |
| running_tablets   | 8      |
| history_tablets   | 1000   |
| all_tablets       | 479    |
+-------------------+--------+
8 rows in set (0.00 sec)

2 Тест по созданию и удалению Tablet

2.1 Тест на создание и удаление таблиц

2.1.1 До создания таблицы

Текущее количество Tablet:

mysql> show backends\G
*************************** 1. row ***************************
            BackendId: 10002
                   IP: 10.197.165.201
        HeartbeatPort: 9050
               BePort: 9060
             HttpPort: 8040
             BrpcPort: 8060
        LastStartTime: 2025-09-01 16:27:49
        LastHeartbeat: 2025-09-01 17:08:36
                Alive: true
 SystemDecommissioned: false
ClusterDecommissioned: false
            TabletNum: 3755
     DataUsedCapacity: 605.218 MB
        AvailCapacity: 13.919 GB
        TotalCapacity: 29.485 GB
              UsedPct: 52.79 %
       MaxDiskUsedPct: 52.79 %
               ErrMsg: 
              Version: 3.3.17-3eac4a9
               Status: {"lastSuccessReportTabletsTime":"2025-09-01 17:07:56"}
    DataTotalCapacity: 14.510 GB
          DataUsedPct: 4.07 %
             CpuCores: 4
             MemLimit: 3.654GB
    NumRunningQueries: 0
           MemUsedPct: 13.55 %
           CpuUsedPct: 20.2 %
     DataCacheMetrics: Status: Normal, DiskUsage: 0B/0B, MemUsage: 0B/0B
             Location:

2.1.2 Генерация большого числа Tablet

-- Генерация большого количества Tablet
CREATE TABLE partitioned_table (
    event_day DATE,
    id BIGINT
) 
PARTITION BY RANGE(event_day) (
    START ("2024-01-01") END ("2025-01-01") EVERY (INTERVAL 1 DAY)
) 
DISTRIBUTED BY HASH(id) BUCKETS 10; -- Будет создано 366*10 Tablet

2.1.3 После создания таблицы

Текущее количество Tablet:

mysql> show backends\G
*************************** 1. row ***************************
            BackendId: 10002
                   IP: 10.197.165.201
        HeartbeatPort: 9050
               BePort: 9060
             HttpPort: 8040
             BrpcPort: 8060
        LastStartTime: 2025-09-01 16:27:49
        LastHeartbeat: 2025-09-01 17:09:56
                Alive: true
 SystemDecommissioned: false
ClusterDecommissioned: false
            TabletNum: 7415
     DataUsedCapacity: 605.218 MB
        AvailCapacity: 13.919 GB
        TotalCapacity: 29.485 GB
              UsedPct: 52.79 %
       MaxDiskUsedPct: 52.79 %
               ErrMsg: 
              Version: 3.3.17-3eac4a9
               Status: {"lastSuccessReportTabletsTime":"2025-09-01 17:09:56"}
    DataTotalCapacity: 14.510 GB
          DataUsedPct: 4.07 %
             CpuCores: 4
             MemLimit: 3.654GB
    NumRunningQueries: 0
           MemUsedPct: 14.07 %
           CpuUsedPct: 0.7 %
     DataCacheMetrics: Status: Normal, DiskUsage: 0B/0B, MemUsage: 0B/0B
             Location:

2.1.4 Удаление таблицы

Здесь видно, что Tablet пока не удалены, так как SR по умолчанию хранит данные в корзине сутки (catalog_trash_expire_second: по умолчанию 86400 секунд):

mysql>  drop table db2.partitioned_table;
Query OK, 0 rows affected (0.06 sec)

mysql> show backends\G
*************************** 1. row ***************************
            BackendId: 10002
                   IP: 10.197.165.201
        HeartbeatPort: 9050
               BePort: 9060
             HttpPort: 8040
             BrpcPort: 8060
        LastStartTime: 2025-09-01 16:27:49
        LastHeartbeat: 2025-09-01 17:10:16
                Alive: true
 SystemDecommissioned: false
ClusterDecommissioned: false
            TabletNum: 7415
     DataUsedCapacity: 605.218 MB
        AvailCapacity: 13.919 GB
        TotalCapacity: 29.485 GB
              UsedPct: 52.79 %
       MaxDiskUsedPct: 52.79 %
               ErrMsg: 
              Version: 3.3.17-3eac4a9
               Status: {"lastSuccessReportTabletsTime":"2025-09-01 17:09:56"}
    DataTotalCapacity: 14.510 GB
          DataUsedPct: 4.07 %
             CpuCores: 4
             MemLimit: 3.654GB
    NumRunningQueries: 0
           MemUsedPct: 14.07 %
           CpuUsedPct: 0.2 %
     DataCacheMetrics: Status: Normal, DiskUsage: 0B/0B, MemUsage: 0B/0B
             Location:

Временно изменим catalog_trash_expire_second:

mysql> ADMIN SHOW FRONTEND CONFIG like 'catalog_trash_expire_second';
+-----------------------------+------------+-------+------+-----------+---------+
| Key                         | AliasNames | Value | Type | IsMutable | Comment |
+-----------------------------+------------+-------+------+-----------+---------+
| catalog_trash_expire_second | []         | 86400 | long | true      |         |
+-----------------------------+------------+-------+------+-----------+---------+
1 row in set (0.00 sec)

mysql> ADMIN SET FRONTEND CONFIG ("catalog_trash_expire_second" = "0");
Query OK, 0 rows affected (0.05 sec)

mysql> ADMIN SHOW FRONTEND CONFIG like 'catalog_trash_expire_second';
+-----------------------------+------------+-------+------+-----------+---------+
| Key                         | AliasNames | Value | Type | IsMutable | Comment |
+-----------------------------+------------+-------+------+-----------+---------+
| catalog_trash_expire_second | []         | 0     | long | true      |         |
+-----------------------------+------------+-------+------+-----------+---------+
1 row in set (0.00 sec)

Видно, что Tablet удалились сразу:

mysql> show backends\G
*************************** 1. row ***************************
            BackendId: 10002
                   IP: 10.197.165.201
        HeartbeatPort: 9050
               BePort: 9060
             HttpPort: 8040
             BrpcPort: 8060
        LastStartTime: 2025-09-01 16:27:49
        LastHeartbeat: 2025-09-01 17:10:51
                Alive: true
 SystemDecommissioned: false
ClusterDecommissioned: false
            TabletNum: 3755
     DataUsedCapacity: 605.218 MB
        AvailCapacity: 13.913 GB
        TotalCapacity: 29.485 GB
              UsedPct: 52.81 %
       MaxDiskUsedPct: 52.81 %
               ErrMsg: 
              Version: 3.3.17-3eac4a9
               Status: {"lastSuccessReportTabletsTime":"2025-09-01 17:09:56"}
    DataTotalCapacity: 14.504 GB
          DataUsedPct: 4.08 %
             CpuCores: 4
             MemLimit: 3.654GB
    NumRunningQueries: 0
           MemUsedPct: 14.06 %
           CpuUsedPct: 0.0 %
     DataCacheMetrics: Status: Normal, DiskUsage: 0B/0B, MemUsage: 0B/0B
             Location:

2.2 Соответствие Tablet физическим файлам

2.2.1 Описание физических файлов

Физическое хранение на узлах BE: путь для Tablet задается в каталоге, указанном в конфигурации be.conf параметром storage_root_path; соответствующие данные Tablet находятся под ${storage_root_path}/data.
Tablet — логическое понятие шарда; на уровне физического хранения данные представлены segment‑файлами. Иерархия каталогов и примеры файлов:

[root@zyf-sr-02 1374885024]# du -sh *
1022M   0200000000003645be4fec146c4c1883227773a343c970af_0.dat (rowset_id + "_" + segment_id + ".dat")
178M    0200000000003645be4fec146c4c1883227773a343c970af_1.dat
[root@zyf-sr-02 1374885024]# pwd
/data/other/starrocks/data/data/374 (shard_id)/371281 (tablet id)/1374885024 (schema_hash)

2.2.2 Тест создания таблицы

2.2.2.1 Генерация данных в БД PG

-- Генерация исходных данных в БД PG
drop table if exists tbl1;  
create table tbl1 (  
  id int primary key,  
  info text,  
  c1 int,  
  c2 float,  
  ts timestamp  
);   
insert into tbl1 selectid,md5(random()::text),random()*1000,random()*100,clock_timestamp() from generate_series(1,60000000) id;  
\dt+ tbl1
                    List of relations
 Schema | Name | Type  |  Owner   |  Size   | Description 
--------+------+-------+----------+---------+-------------
 public | tbl1 | table | postgres | 2664 MB | 
(1 row)
copy tbl1 to '/tmp/tbl1.csv' delimiter ',';

2.2.2.2 Создание таблицы и загрузка в SR (автоматическая бакетизация)

-- Здесь создаем данные с одной репликой, чтобы удобнее наблюдать
create table tbl1 (id int ,info text,c1 int,c2 float,ts datetime) PROPERTIES ("replication_num" = "1");

Загрузка данных (Stream Load):

curl --location-trusted -u root:root -H "column_separator:," \
    -H "Expect:100-continue" \
    -H "columns:id,info,c1,c2,ts" \
    -T /tmp/tbl1.csv -XPUT \
    http://10.197.165.201:8030/api/db2/tbl1/\_stream\_load

2.2.2.3 Наблюдение за файловой структурой

Сначала проверим, какие Tablet у таблицы (видно, что система с автоматической бакетизацией создала 3 Tablet):

SHOW tablet from db2.tbl1\G
*************************** 1. row ***************************
               TabletId: 556040
              ReplicaId: 556041
              BackendId: 10002
             SchemaHash: 0
                Version: 2
            VersionHash: 0
      LstSuccessVersion: 2
  LstSuccessVersionHash: 0
       LstFailedVersion: -1
   LstFailedVersionHash: 0
          LstFailedTime: NULL
               DataSize: 403.5MB
               RowCount: 10000018
                  State: NORMAL
LstConsistencyCheckTime: NULL
           CheckVersion: -1
       CheckVersionHash: 0
           VersionCount: 1
               PathHash: -1
                MetaUrl: http://10.197.165.201:8040/api/meta/header/556040
       CompactionStatus: http://10.197.165.201:8040/api/compaction/show?tablet\_id=556040
           DiskRootPath: Unknown
           IsConsistent: true
               Checksum: -1
*************************** 2. row ***************************
               TabletId: 556042
              ReplicaId: 556043
              BackendId: 10170
             SchemaHash: 0
                Version: 2
            VersionHash: 0
      LstSuccessVersion: 2
  LstSuccessVersionHash: 0
       LstFailedVersion: -1
   LstFailedVersionHash: 0
          LstFailedTime: NULL
               DataSize: 403.4MB
               RowCount: 9999967
                  State: NORMAL
LstConsistencyCheckTime: NULL
           CheckVersion: -1
       CheckVersionHash: 0
           VersionCount: 1
               PathHash: -1
                MetaUrl: http://10.197.165.202:8040/api/meta/header/556042
       CompactionStatus: http://10.197.165.202:8040/api/compaction/show?tablet\_id=556042
           DiskRootPath: Unknown
           IsConsistent: true
               Checksum: -1
*************************** 3. row ***************************
               TabletId: 556044
              ReplicaId: 556045
              BackendId: 10171
             SchemaHash: 0
                Version: 2
            VersionHash: 0
      LstSuccessVersion: 2
  LstSuccessVersionHash: 0
       LstFailedVersion: -1
   LstFailedVersionHash: 0
          LstFailedTime: NULL
               DataSize: 403.4MB
               RowCount: 10000015
                  State: NORMAL
LstConsistencyCheckTime: NULL
           CheckVersion: -1
       CheckVersionHash: 0
           VersionCount: 1
               PathHash: -1
                MetaUrl: http://10.197.165.203:8040/api/meta/header/556044
       CompactionStatus: http://10.197.165.203:8040/api/compaction/show?tablet\_id=556044
           DiskRootPath: Unknown
           IsConsistent: true
               Checksum: -1
3 rows in set (0.00 sec)

Найдём соответствующие файлы данных (искать на BackendId 10002 для Tablet 556040):

[root@zyf-sr-01 ~]# find / -name 556040
/data/other/starrocks/data/data/155/556040

[root@zyf-sr-01 ~]# tree /data/other/starrocks/data/data/155/556040
/data/other/starrocks/data/data/155/556040
└── 1374885024
    ├── 0200000000001cc8e540263d189634598cee6af6d99e56af_0.dat
    ├── 0200000000001cc8e540263d189634598cee6af6d99e56af_1.dat
    ├── 0200000000001cc8e540263d189634598cee6af6d99e56af_2.dat
    ├── 0200000000001cc8e540263d189634598cee6af6d99e56af_3.dat
    ├── 0200000000001cc8e540263d189634598cee6af6d99e56af_4.dat
    ├── 0200000000001cc8e540263d189634598cee6af6d99e56af_5.dat
    └── 0200000000001cc9e540263d189634598cee6af6d99e56af_0.dat

1 directory, 7 files

[root@zyf-sr-01 ~]# cd /data/other/starrocks/data/data/155/556040
[root@zyf-sr-01 556040]# cd 1374885024/
[root@zyf-sr-01 1374885024]# pwd
/data/other/starrocks/data/data/155/556040/1374885024

[root@zyf-sr-01 1374885024]# du -sh *
70M     0200000000001cc8e540263d189634598cee6af6d99e56af_0.dat
70M     0200000000001cc8e540263d189634598cee6af6d99e56af_1.dat
70M     0200000000001cc8e540263d189634598cee6af6d99e56af_2.dat
70M     0200000000001cc8e540263d189634598cee6af6d99e56af_3.dat
70M     0200000000001cc8e540263d189634598cee6af6d99e56af_4.dat
57M     0200000000001cc8e540263d189634598cee6af6d99e56af_5.dat
404M    0200000000001cc9e540263d189634598cee6af6d99e56af_0.dat

2.2.2.4 Слияние версий (компакция)

Выполним вторую загрузку данных — видно, что число файлов увеличилось:

[root@zyf-sr-01 1374885024]# du -sh *
70M     0200000000001cc8e540263d189634598cee6af6d99e56af_0.dat
70M     0200000000001cc8e540263d189634598cee6af6d99e56af_1.dat
70M     0200000000001cc8e540263d189634598cee6af6d99e56af_2.dat
70M     0200000000001cc8e540263d189634598cee6af6d99e56af_3.dat
70M     0200000000001cc8e540263d189634598cee6af6d99e56af_4.dat
57M     0200000000001cc8e540263d189634598cee6af6d99e56af_5.dat
404M    0200000000001cc9e540263d189634598cee6af6d99e56af_0.dat
70M     0200000000001d3ae540263d189634598cee6af6d99e56af_0.dat
70M     0200000000001d3ae540263d189634598cee6af6d99e56af_1.dat
70M     0200000000001d3ae540263d189634598cee6af6d99e56af_2.dat
70M     0200000000001d3ae540263d189634598cee6af6d99e56af_3.dat
70M     0200000000001d3ae540263d189634598cee6af6d99e56af_4.dat
57M     0200000000001d3ae540263d189634598cee6af6d99e56af_5.dat
0       0200000000001d3be540263d189634598cee6af6d99e56af_0.dat

После нескольких запусков Stream Load информация SHOW TABLET FROM db2.tbl1; может обновиться не сразу, а файлы окажутся фрагментированными. Выполним команду компакции (слияние версий) — мелкие файлы объединяются в крупные, но исходные файлы не удаляются:

ALTER TABLE db2.tbl1 COMPACT;

Видно, что файлы объединились, но исходные ещё не удалены:

[root@zyf-sr-01 1374885024]# du -sh *
70M     0200000000001cc8e540263d189634598cee6af6d99e56af_0.dat
70M     0200000000001cc8e540263d189634598cee6af6d99e56af_1.dat
70M     0200000000001cc8e540263d189634598cee6af6d99e56af_2.dat
70M     0200000000001cc8e540263d189634598cee6af6d99e56af_3.dat
70M     0200000000001cc8e540263d189634598cee6af6d99e56af_4.dat
57M     0200000000001cc8e540263d189634598cee6af6d99e56af_5.dat
404M    0200000000001cc9e540263d189634598cee6af6d99e56af_0.dat
70M     0200000000001d3ae540263d189634598cee6af6d99e56af_0.dat
70M     0200000000001d3ae540263d189634598cee6af6d99e56af_1.dat
70M     0200000000001d3ae540263d189634598cee6af6d99e56af_2.dat
70M     0200000000001d3ae540263d189634598cee6af6d99e56af_3.dat
70M     0200000000001d3ae540263d189634598cee6af6d99e56af_4.dat
57M     0200000000001d3ae540263d189634598cee6af6d99e56af_5.dat
723M    0200000000001d3be540263d189634598cee6af6d99e56af_0.dat

2.2.2.5 Создание таблицы в SR (ручная бакетизация)

CREATE TABLE tbl3 (
  id int,
  info text,
  c1 int,
  c2 float,
  ts datetime
) DISTRIBUTED BY RANDOM BUCKETS 1 PROPERTIES ("replication_num" = "1");

Видно, что здесь будет создан только один Tablet:

mysql> show tablet from db2.tbl3\G
*************************** 1. row ***************************
               TabletId: 556065
              ReplicaId: 556066
              BackendId: 10002
             SchemaHash: 0
                Version: 1
            VersionHash: 0
      LstSuccessVersion: 1
  LstSuccessVersionHash: 0
       LstFailedVersion: -1
   LstFailedVersionHash: 0
          LstFailedTime: NULL
               DataSize: 0B
               RowCount: 0
                  State: NORMAL
LstConsistencyCheckTime: NULL
           CheckVersion: -1
       CheckVersionHash: 0
           VersionCount: -1
               PathHash: -1
                MetaUrl: http://10.197.165.201:8040/api/meta/header/556065
       CompactionStatus: http://10.197.165.201:8040/api/compaction/show?tablet\_id=556065
           DiskRootPath: Unknown
           IsConsistent: true
               Checksum: -1
1 row in set (0.00 sec)

3 Бакетизация данных

3.1 Пояснение по бакетизации

При создании таблиц вы можете задать разумные партиции и бакеты, чтобы обеспечить равномерное распределение данных и повысить производительность запросов. Равномерное распределение означает разделение данных на подмножества по правилам и их ��балансированное размещение на разных узлах. Это уменьшает объём сканируемых данных при запросах и максимально использует параллелизм кластера.
Начиная с версии 2.5.7, при создании таблицы и добавлении партиций можно не задавать количество бакетов (BUCKETS). StarRocks автоматически определяет количество бакетов. Если производительность не соответствует ожиданиям и вы хорошо знакомы с механизмом бакетов, можно вручную задать количество бакетов.
Бакет — единица физической организации файлов.
Слишком много Tablet увеличивает затраты FE/BE на управление метаданными и диспетчеризацию.
Партиции и бакеты следует, по возможности, выбирать так, чтобы они покрывали условия запросов — это снижает объём сканирования и повышает параллелизм.
Просмотр количества бакетов: SHOW PARTITIONS.
Ручная настройка количества бакетов:
- Если ожидаемый объём исходных данных в одной партиции таблицы превышает 100 GB, рекомендуется вручную задать количество бакетов в партиции.
- По одному Tablet на каждые 10 GB: DISTRIBUTED BY HASH(site_id,city_code) BUCKETS 30; — если объём данных для одной партиции 300 GB, то по правилу 10 GB на один Tablet число бакетов в партиции — 30.
Для включения внутреннего параллелизма сканирования Tablet убедитесь, что системная переменная enable_tablet_internal_parallel установлена глобально:

SET GLOBAL enable_tablet_internal_parallel = true;

Примеры:

-- При создании таблицы
CREATE TABLE site_access (
    site_id INT DEFAULT '10',
    city_code SMALLINT,
    user_name VARCHAR(32) DEFAULT '',
    event_day DATE,
    pv BIGINT SUM DEFAULT '0'
)
AGGREGATE KEY(site_id, city_code, user_name, event_day)
PARTITION BY date_trunc('day', event_day)
DISTRIBUTED BY HASH(site_id,city_code); -- Нет необходимости вручную задавать число бакетов в партиции

-- После создания таблицы
-- Автоматически задать число бакетов для всех партиций и не включать динамическое увеличение по требованию (число бакетов фиксировано).
ALTER TABLE details DISTRIBUTED BY RANDOM;

-- Автоматически задать число бакетов для всех партиций и включить динамическое увеличение по требованию.
ALTER TABLE details SET("bucket_size"="1073741824");

-- Автоматически задать число бакетов для указанных партиций.
ALTER TABLE details PARTITIONS (p20230103, p20230104)
DISTRIBUTED BY RANDOM;

-- Автоматически задать число бакетов для добавляемой партиции.
ALTER TABLE details ADD PARTITION p20230106 VALUES [('2023-01-06'), ('2023-01-07'))
DISTRIBUTED BY RANDOM;

3.2 Случайная бакетизация

Начиная с версии 3.1, при создании таблицы и добавлении партиций можно не задавать ключ бакетизации (то есть не указывать предложение DISTRIBUTED BY). StarRocks по умолчанию использует случайную бакетизацию и случайно распределяет данные между всеми бакетами в партиции.
Однако если вы часто выполняете запросы по массивам данных, где одни и те же столбцы используются как условия отбора, случайная бакетизация может быть недостаточно эффективна. В таких случаях рекомендуются хеш‑бакеты: тогда при запросе, использующем эти столбцы, необходимо сканировать лишь небольшое число соответствующих бакетов, что существенно повышает производительность.

Ограничения:

Поддерживаются только таблицы модели Detail (detail model).
Нельзя указывать Colocation Group.
Не поддерживается Spark Load.

3.3 Хеш‑бакетизация

Данные распределяются по бакетам по значению ключа бакетизации. Выбор столбцов, часто используемых в условиях запроса, в качестве ключа бакетизации повышает эффективность запросов.
Столбцы, одновременно обладающие высокой кардинальностью (много уникальных значений) и используемые в условиях запросов, подходят для хеш‑бакетизации.

Преимущества:

Повышение производительности запросов: строки с одинаковым значением ключа бакетизации попадают в один бакет, что снижает объём сканируемых данных.
Равномерное распределение данных: выбор столбцов с высокой кардинальностью в качестве ключей бакетизации помогает сбалансировать данные по бакетам.

Как выбирать ключ бакетизации:

Для сложных запросов рекомендуется выбирать столбцы с высокой кардинальностью, чтобы обеспечить равномерное распределение и повысить утилизацию ресурсов кластера.
Для простых запросов рекомендуется выбирать столбцы, часто используемые в условиях запросов, чтобы повысить эффективность.
При серьёзном перекосе данных можно использовать несколько столбцов в качестве ключа бакетизации, но рекомендуется не более трёх.

Замечания:

Ключ бакетизации поддерживает типы: целочисленные, DECIMAL, DATE/DATETIME, CHAR/VARCHAR/STRING.
Начиная с версии 3.2, после создания таблицы можно менять ключ бакетизации через ALTER TABLE.
Если в таблице с первичным ключом новый ключ бакетизации не включает столбцы первичного ключа, SQL выполнится, но в SHOW ALTER TABLE OPTIMIZE\G появится сообщение:
```
create temp partitions failed java.lang.RuntimeException: create partitions failed: Distribution column[id2] is not key column
```

Понимание и практические эксперименты с Tablet в StarRocks