Обновить
3
10
Игорь@IgorBatanov

Пользователь

Отправить сообщение

У меня получалось ~150мб текста, для 1 млн sku. Для 200млн это ~30гб. К сожалению я не знаю куда можно скормить такой объем за раз или как натравить на такой объем, не написав хотя бы примитивные механизмы батчей. Поделитесь опытом какая у вас была задача, какие объемы и как быстро обработали, интересно.

Коллега, спасибо за острую реплику. По делу: в автозапчастях номенклатура исторически живёт по принципу «бренд + артикул» — это и есть уникальный ключ. Название всегда было вторичным полем, которое тянулось из прайсов поставщиков автоматически (кросс-док, сотни поставщиков, сотни тысяч прайсов за годы работы). Ручной контроль каждой позиции убил бы оперативность. Да, получилась свалка, но она не мешала продажам, пока работал поиск по артикулу. А «Честный знак» заставил нас залезть в эту помойку и навести порядок уже постфактум. Так что это не «колхоз», а legacy-последствие отраслевой специфики.

А процесс попадания номенклатуры в БД как бы смешно не звучало, он полуавтоматический, закупки устанавливают только факт того что поставщик надежный и доступные к продаже бренды от этого поставщика. Далее все работает по уникальной связке артикул + бренд, поле наименования является опциональным с точки зрения бизнеса.

Информация

В рейтинге
670-й
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Фулстек разработчик
Ведущий
Rust
Высоконагруженные системы
Kubernetes
Базы данных
Разработка программного обеспечения
Алгоритмы и структуры данных
Управление людьми
Информационные технологии
Управление разработкой
Автоматизация процессов