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