Как разместить 1 млн товаров?

Возникла задача разместить 1 млн товаров в магазине. Вариантов (как я вижу) 3:
1. Писать свою cms
2. Допиливать что-то готовое
3. Использовать сторонние сайты, например webstore.amazon.com

В первом случае, все ясно, можно заточить все под себя, проставить нужные индексы, использовать Sphinx и т.д. Но разработка займет много времени.
Второй вариант — есть опасения, что можно упереться в какой-либо потолок, и возникнет ситуация, что время на допил системы окажется потерянным, и все равно придется писать с нуля.
В третьем варианте — нет возможности более гибкой настройки/написания специфических модулей.

Использовать готовые cms не получается. ибо для таких объемов данных они не предназначены. В openCart и OsCommerce ф-ция поиска по товарам отрабатывает 8 минут. В magento даже не получилось импортировать товары, метод save в модели product отрабатывает 1,5 — 2 секунды. Тестил все на локальном компе, на сервере, конечно, будет быстрее, но все равно, цифры огромные.

Есть ли у кого нить опыт работы с такими данными? Может идеи?
  • Вопрос задан
  • 7083 просмотра
Пригласить эксперта
Ответы на вопрос 9
alekciy
@alekciy
Вёбных дел мастер
Отпишусь пожалуй о своем опыте.

Ситуация схожая, но изначально товаров нужно было 250 кпозицией. Анализ коробочных решений (который не я делал) показал, что либо коробка на таких объемах не может гарантировать быстрой работы, либо производители коробки хотят таких денег на энтерпрайз, что пилить свое дешевле. Собственно чем в настоящее время и занят.

Свое требует времени, но позволяет полностью контролировать движок и быть точно уверенным в нагрузках, которые он потянет. Кроме того гарантирует более выгодную схему модификации движка, т.е. супорт движка становиться проще как технически, так и финансово. А сапорт движка собственно и есть основная статья расхода для ПО. Что удалось получить на данный момент, так это каталог. Т.е. дерево категорий, карточки товара, админка для менеджеров (создать товар, добавить к товару атрибуты). Количество товаров не ограничено, количество и тип характеристик товаров так же не ограничено и ведется через админку (т.е. дополнительно кодить ни чего не нужно). Нагрузочные тесты показали, что при ~200 МБ ОЗУ под PHP движок держит 300 запросов/сек (при попадании в кэш страница генерится за 10-15 мс) долговременно (т.е. где-то до 25 миллионов хитов в сутки) и может держать пик в 1000 запрос, но не дольше 5 сек, потом начинаются валится 50-ые. Это при каталоге в 250 кпозиций по 10 характеристик на товар. В целом вся связка (веб сервер, субд, кэш) кушает 1-1,5 ГБ ОЗУ. При этом полная развязка данных и шаблонов, поэтому можно иметь сколько угодно вариантов верски, т.е. ни какой смеси из php+html нет.

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

Так что есть техническая подготовка, то есть смысл делать свое. В зависимости от опыта, общих требований я бы оценил данную работу месяца в три до года для одного разработчика на фултайме. Это до первого релиза. Ну а дальше стандартный супорт движка.
Ответ написан
int03e
@int03e
В openCart и OsCommerce ф-ция поиска по товарам отрабатывает 8 минут

А в остальном устраивает? Я не в курсе, но подозреваю, что можно туда прикрутить Solr или Sphinx, ситуация должна значительно улучшиться.
Ответ написан
@edogs
1 млн. позиций само по себе не страшно, страшно количество возможных свойств, по которым должен быть доступен поиск. 2-3 свойства — одна ситуация, 20-30 — другая ситуация, 200-300 — третья.

Готовые цмс из коробки такой объем не потянут, однако разумным вариантом будет взять готовую цмс за основу как «обвес», то есть: платежи, статические страницы, статистика, категории, бакэнд, доставка, шаблонный движок и прочее.
А вот конкретно плагин/модуль каталога — написать полностью свой, с прямым доступом к базе (единственная завязка на ИД товара что бы была для остальной цмс-ки), при грамотном проектировании на 100 евровом хетзнеровском сервере даже самый сложный поиск будет укладываться секунд в 10 (если не плэин текст), а набор более или менее стандартных фильтров (стандартный поиск в магазинах) — секунды в 2-3, категории же и тэги просто летать будут.
Ответ написан
DeDraw
@DeDraw
Если у вас нет сил и возможностей писать CMS, хоть это тоже не лучший вариант, то:
Может быть расковырять mysql готового магазина и написать небольшой скрипт для записи в эту базу данные сторонним скриптом?
Ответ написан
DedalX
@DedalX
Web разработчик, IT бизнесмен
«ф-ция поиска по товарам отрабатывает 8 минут» — так может дело не в CMS, а в возможностях и потолке «железа»? В любое случае под такое количество товара вам понадобится серьезный сервер (что самописная CMS, что нет).
Ответ написан
@Chii
ЦМС брать готовую, магазинный модуль писать самостоятельно (в свободном доступе качественных магазинов к сожалению нет).
Кстати, можно организовать модуль свободным проектом и получить себе в штат значительное количество халявных опенсорсников после релиза (они как раз не знают, куда податься — качественных магазинных модулей просто нет) — таким образом вы потратитесь только на первоначальную разработку и сэкономите на поддержке адово много ресурсов.
Ответ написан
Dennion
@Dennion
Разработчик PHPShop CMS.
Случаем, не запчасти для авто? А то там много подводных камней с замещающимися артикулами и номерами у запчастей, и все вместе это с 1 млн. товаров будет крайне тяжелая штука. Поиск по номеру товара будет или как-то сложнее? Свожусь к мысли — взять готовую ЦМС и собрать свой модуль ИМ, данные товаров хранить в удаленном хранилище.
Ответ написан
@Vampiro
imho на 1кк записей тормозит не ЦМС, а БД. И оптимизировать таблички (построить индексы, разнести данные в разные таблички и проч) — это тот минимум, который необходим. Если по полю нет индексов, то поиск будет ползать 8 минут. Если есть — 8 секунд. Мне вообще сложно представить что при 1кк записей может быть запрос дольше 1 сек. Это не те объемы, при которых что-то начинает тормозить. Купите коробку, оптимизируйте запросы и таблички, посмотрите что получится.
Ответ написан
@Neir0
Поддерживаю предыдущего оратора. 8 минут что-то феерическое. У меня столько ищется вхождение подстроки в таблице без индексов на 100кк записей на компе 5 летней давности. Если индексы есть, значит косяк в CMS и стоит попробовать другую или тупо отрубить часть поиска(ну или попробовать оптимизировать :) ). Сам каталог нормально работает?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы