могут быть представлены на 10-ти складах.
Для каждого товара нужно вывести количество товара на складе в зависимости от местоположения и роли пользователя. Соответственно приходится перебирать все склады. Кешировать, кажется, бессмысленно, так как вариантов будет столько же, сколько товаров, местоположений и ролей, ведь для каждой роли и для каждого местоположения количество товара разное.
Посоветуйте какие-нибудь кейсы, чтобы это оптимизировать? Иначе прод упадет
В сторону Elasticsearch стоит смотреть или это не про то?
Склады должны по шине инфу передавать в одно хранилище
А если это чужие склады и раьотают по апи?
можно более подробно или ссылку, пожалуйста?
В этом и проблема, что в виду структуры проекта вычисление остатка товара для местоположения для каждого пользователя индивидуально ресурсозатратно. То есть нужно как-то хранить все возможные комбинации. Таблица с полями: id товара, id склада, id местоположения и количество? Соотв. добавить индекс по id товара. — такая реализация подойдет? Или сразу, например, Elastic Search использовать?
Помню, пришли мы на одно неназываемое ювелирное предприятие. Там тоже "архитекторы" в РСУБД не осилили и решили использовать Эластик для хранения штрих-кодов. Для скорости, исключительно. Для производительности! Кодировались артикулы и модели изделий. Разумеется, уникальностью кодов "архитекторы" не озаботились. Пришлось парочку рекомендовать уволить, после того как вскрылось, что под одним штрих-кодом могли скрываться однотипные изделия. Но одно из золота, второе, более дешевое, серебряное. Разумеется, кто-то активно скупал в рознице золотые по цене серебряных...
Прикинул, что в моем случае будет 1.5 млрд вариантов
уверен, что у вас какая-то системная архитектурная ошибка вы - не яндекс и не баду вам точно не нужно хранить полтора миллиарда записей
Обсуждают сегодня