Как правильно хранить атрибуты рассорки для ускорения результата

Дата актуализации: 05 марта 2026 г.

Что такое «рассорка» и почему её атрибуты требуют особого хранения

В контексте складской логистики «рассорка» — это процесс разделения единой партии товара на мелкие группы (короба‚ паллеты‚ ячейки) с последующим адресным размещением на складе. Атрибуты рассорки включают:

• SKU-код товара
• кол-во единиц в группе
• тип упаковки / поддона
• адрес ячейки (зона-стеллаж-полка-ячейка)
• дату/время формирования группы
• срок годности‚ серийный номер‚ температурный режим и др.

Ключевая задача, хранить эти атрибуты так‚ чтобы:

1. поиск нужной группы занимал доли секунды;
2. обновление данных (уложил товар — поменял адрес) не ломало индексы;
3. структура легко масштабировалась при появлении новых типов товара.

Классическая реляционная модель: «одна таблица = один атрибут»

Пример схемы MySQL

CREATE TABLE pallet (
 id INT AUTO_INCREMENT PRIMARY KEY‚
 barcode VARCHAR(32) UNIQUE‚
 sku_id INT NOT NULL‚
 qty INT NOT NULL‚
 created_at DATETIME DEFAULT CURRENT_TIMESTAMP‚
 INDEX idx_sku (sku_id)
);

CREATE TABLE pallet_location (
 pallet_id INT PRIMARY KEY‚
 zone CHAR(2)‚
 rack TINYINT‚
 shelf TINYINT‚
 cell TINYINT‚
 depth DECIMAL(4‚2)‚ -- глубина ячейки‚ м
 updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP‚
 FOREIGN KEY (pallet_id) REFERENCES pallet(id)‚
 INDEX idx_zone (zone‚rack‚shelf‚cell)
);

CREATE TABLE pallet_attr (
 pallet_id INT‚
 attr_key VARCHAR(50)‚
 attr_val VARCHAR(255)‚
 PRIMARY KEY (pallet_id‚ attr_key)‚
 FOREIGN KEY (pallet_id) REFERENCES pallet(id)
) ENGINE=InnoDB;

Ключевые идеи:

• таблица pallet_attr реализует подход EAV (Entity-Attribute-Value)‚ позволяя добавлять произвольные атрибуты без ALTER TABLE;
• индекс составной (zone‚rack‚shelf‚cell) ускоряет поиск «пустых» или «занятых» ячеек;
• поле depth поддерживает адресное хранение в глубоких стеллажах (каналы до 6 м).

Денормализация для сверхбыстрого чтения

Когда скорость важнее нормальной формы‚ создают материализованное представление (MATERIALIZED VIEW) или кэш-таблицу:

CREATE TABLE pallet_full_mv (
 pallet_id INT‚
 sku_code VARCHAR(50)‚
 qty INT‚
 zone CHAR(2)‚
 rack TINYINT‚
 shelf TINYINT‚
 cell TINYINT‚
 temp_min DECIMAL(3‚1)‚
 temp_max DECIMAL(3‚1)‚
 PRIMARY KEY (zone‚rack‚shelf‚cell)‚
 KEY (sku_code)
) ENGINE=InnoDB;

Эта таблица обновляется триггерами или шедулером каждые 5–10 секунд‚ позволяя WMS-терминалам мгновенно выдавать «свободную ячейку» без JOIN-ов.

Горизонтальное партиционирование

Для больших складов (> 1 млн паллет/год) таблицы партицируют по зоне (zone):

ALTER TABLE pallet_location
PARTITION BY LIST (zone) (
 PARTITION pA VALUES IN ('A')‚
 PARTITION pB VALUES IN ('B')‚
 PARTITION pC VALUES IN ('C')‚
 PARTITION pD VALUES IN ('D')
);

Плюсы: каждый стеллажный комплекс физически хранится в отдельном файле‚ сокращая блокировки и время поиска.

Адресное хранение и QR-кодирование

Формат адреса ячейки

Рекомендованный шаблон: AA-NN-LL-DD

• AA — зона (A1‚ A2‚ BZ)
• NN, стеллаж/проход (01..99)
• LL — уровень (01..15)
• DD, глубина ячейки (01..06)

QR-код на поддоне содержит: SKU|QTY|AA-NN-LL-DD|EXPIRY. Сканер терминала распознаёт адрес без обращения к серверу‚ далее лишь фиксирует факт размещения.

Практический чек-лист внедрения в 2026 году

1. Пилот: выберите 1 стеллажный ряд (до 300 ячеек).
2. Обклейка: нанесите QR-стикеры с адресом на каждую ячейку.
3. Скрипт миграции: создайте таблицы pallet‚ pallet_location‚ pallet_attr и заполните их тестовыми данными.
4. Индекс-взрыв: добавьте составной индекс (zone‚rack‚shelf‚cell‚depth).
5. Проверка скорости: замерьте SELECT-запросы на поиск свободной ячейки < 50 мс;
6. Расширение: внедрите мат. представление и партиционирование по мере роста нагрузки.

Апгрейд до 2027: NoSQL-кэш

Для складов robotic-shuttle рассмотрите Redis-схему:

HSET pallet:123456
 sku ABC123
 qty 48
 zone A2
 rack 14
 cell 7
 depth 3
 free false

Команда GEOSEARCH warehouse:A2 FROMLONLAT x y BYRADIUS 5 m мгновенно отдаёт все паллеты в радиусе 5 метров от AGV-робота.

Правильное хранение атрибутов рассорки — это сочетание:

• нормализованной реляционной БД (долговременная точность);
• денормализованных материализованных представлений (скорость чтения);
• адресного QR-кодирования (живой учёт у терминала);
• партиционирования и кэш-слоев (масштаб 2026+).

Внедрите поэтапно‚ контролируйте метрики‚ и рассорка будет работать быстрее‚ чем робот успеет проехать стеллаж.