Ecom, БД MySQL с 10+ млн. товаров, рекомендации по проектированию БД
Есть ecommerce проект прайс агрегатор (аналоги regmarkets.ru, satom.ru, yavitrina.ru и др.). Сейчас есть порядка 10 млн. товаров, планируется рост до десятков - сотен млн. товаров.
Входные данные из партнерок Admitad, Яндекс дистрибуция - фиды XML (вариация Yml - Yandex Market Language). Фиды скачиваются через API.
Каждый yml фид содержит название магазина и компании, например:
<shop><name>Yandex Market</name><company>Yandex</company>
(в самой партнерке Admitad каждый shop также имеет свой числовой ID).
ID категорий:
<category id="8269840" parentId="8264460">Купальники и плавки</category>
ID офферов (товаров):
<offer available="true" id="1779862800">
В фидах некоторых магазинов одинаковые товары <offer>, но например разных цветов имеют параметр <group_id>, например <group_id>1779862800</group_id>. Группирующие одинаковые товары.
У крупных шопов вроде Яндекс Маркет сами фиды также делятся на несколько частей (как правило по крупной родительской категории, например "Одежда и обувь") и каждая такая часть имеет свой feed ID (возможно их тоже стоит использовать).
Изначально использовали только данные Яндекс маркет, сейчас планируем подключить множество других магазинов.
Возникает проблема с идентификаторами товаров. В каждом магазине своя нумерация <offer>. В некоторых магазинах <offer> имеет даже буквенные значения (хотя чаще всего это цифры).
Также возникает проблема с нагрузкой на MySQL при таком количестве товаров. С техниками шардирования, партицирования знакомы поверхностно и пока к ним не прибегали.
В настоящий момент в качестве бэкенда используем Pimcore (PHP, Symphony, подробнее о технологическом стеке Pimcore), БД MySQL.
Рассматриваем вариант переделки бэкенда на ensi (PHP) + PostgreSQL (если поймем, что на Pimcore не сможем работать нормально с шардированной MySQL).
Очень не хотелось бы писать полностью свой бэкенд самопис. Хотим использовать готовую платформу.
Важный момент! Не хотелось бы связываться с Kubernetes на первых этапах. Хотим работать с сервисной архитектурой, вынося сервисы по разным ВМ (или железным серверам).
Примеры XML (yml) файлов фидов (файлы много весят):
https://mega.nz/file/lwciRKaL#j94tfcQlJsNbCbuVJYeL...
Как нам построить свой уникальный ID товара для БД?
Как учесть, что в будущем одинаковые товарных из разных магазинов мы будем объединять в одну карточку (после product matching) с разными предложениями внутри? Имеется ввиду как учесть ID.
Как правильно обновлять такую БД (в каждом магазине и в каждом фиде могут появляться новые товары каждый день)? Товар может менять цену каждый день.
Вообще как лучше проектировать БД для такого большого числа товаров (у нас MySQL)? Шарды, партиции и др.
По железу - имеем множество своих серверов в стойке.
Требования к исполнителю:
Исполнитель должен иметь опыт работы с крупными ecommerce, с миллионами товаров.
Опыт работы с MySQL или PostgreSQL с миллионами товаров. Будет большим плюсом, если работали конкретно с фидами Admitad.
Желателен опыт программирования на PHP, Python.
В отклике на проект ОБЯЗАТЕЛЬНО укажите проекты над которыми работали и коротко подтвердите выполнение подобных работ (чтобы после отклика хоть как-то было понятно, что с Вами можно обсуждать подобную задачу и приступать к сотрудничеству).
Со студиями не работаем! Рассматриваем только опытных разработчиков, непосредственных исполнителей!
Порядок работы и оплаты:
Сперва нужна консультация или серия консультаций. Цена указана за час консультации. В дальнейшем возможно договоримся о работах с БД.
Согласовываем с исполнителем цену (строго в рублях) и сроки. Если условия устраивают и меня и вас - работаем!
Работаю строго без предоплат! Возможны поэтапные постоплаты.