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

Question

[Владимир Болиев]

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

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

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

Есть ли у кого нить опыт работы с такими данными? Может идеи?

Comments

[edogs]

Во всех cms которые я видел, продукты — это обычные элементы с определенным набором полей, а магазинный модуль — это корзина+оплата. Узкое место — именно организация бд товаров.

Опишите подробнее структуру и тип Вашей базы товаров. От нее все сильно зависит.

Answer 1

[Алексей Сундуков]

Отпишусь пожалуй о своем опыте.

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

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

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

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

Answer 2

[int03e]

В openCart и OsCommerce ф-ция поиска по товарам отрабатывает 8 минут

А в остальном устраивает? Я не в курсе, но подозреваю, что можно туда прикрутить Solr или Sphinx, ситуация должна значительно улучшиться.

Comments

[Владимир Болиев]

Пока этот вариант лидирует, но непонятно можно ли это сделать

Answer 3

[edogs]

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

Готовые цмс из коробки такой объем не потянут, однако разумным вариантом будет взять готовую цмс за основу как «обвес», то есть: платежи, статические страницы, статистика, категории, бакэнд, доставка, шаблонный движок и прочее.
А вот конкретно плагин/модуль каталога — написать полностью свой, с прямым доступом к базе (единственная завязка на ИД товара что бы была для остальной цмс-ки), при грамотном проектировании на 100 евровом хетзнеровском сервере даже самый сложный поиск будет укладываться секунд в 10 (если не плэин текст), а набор более или менее стандартных фильтров (стандартный поиск в магазинах) — секунды в 2-3, категории же и тэги просто летать будут.

Answer 4

[Артемий Аверин]

Если у вас нет сил и возможностей писать CMS, хоть это тоже не лучший вариант, то:
Может быть расковырять mysql готового магазина и написать небольшой скрипт для записи в эту базу данные сторонним скриптом?

Comments

[Владимир Болиев]

Как это поможет?

Answer 5

[Дмитрий]

«ф-ция поиска по товарам отрабатывает 8 минут» — так может дело не в CMS, а в возможностях и потолке «железа»? В любое случае под такое количество товара вам понадобится серьезный сервер (что самописная CMS, что нет).

Comments

[Владимир Болиев]

Это ясно, но в своей cms структуру БД и средства поиска можно организовать так, что в ущерб гибкости и простоте установки, система будет работать гораздо быстрее.

Answer 6

[Chii]

ЦМС брать готовую, магазинный модуль писать самостоятельно (в свободном доступе качественных магазинов к сожалению нет).
Кстати, можно организовать модуль свободным проектом и получить себе в штат значительное количество халявных опенсорсников после релиза (они как раз не знают, куда податься — качественных магазинных модулей просто нет) — таким образом вы потратитесь только на первоначальную разработку и сэкономите на поддержке адово много ресурсов.

Comments

[Владимир Болиев]

Во всех cms которые я видел, продукты — это обычные элементы с определенным набором полей, а магазинный модуль — это корзина+оплата. Узкое место — именно организация бд товаров.

Answer 7

[Денис Туренко]

Случаем, не запчасти для авто? А то там много подводных камней с замещающимися артикулами и номерами у запчастей, и все вместе это с 1 млн. товаров будет крайне тяжелая штука. Поиск по номеру товара будет или как-то сложнее? Свожусь к мысли — взять готовую ЦМС и собрать свой модуль ИМ, данные товаров хранить в удаленном хранилище.

Comments

[Алексей Сундуков]

Коробочный версии CMS под такие объемы обычно не работают. Маджента даже под 250кпозиций говорит, юзайте интерпрейз версию. А тут в 4 раза больше. Да и стоит этот интерперайз под 400круб.

Можно конечно сказать, что коробку можно отмаштабировать по железу. Но… Кто-то может похвалится, что смог разнести коробочный продукт по нескольких нодам и получился юзабельный вариант? Я такого что-то пока не встречал. Если архитектурно авторы коробки не подумали о мастабировании, то завести этого поверх задача становиться уже очень непростой.

Answer 8

[Vampiro]

imho на 1кк записей тормозит не ЦМС, а БД. И оптимизировать таблички (построить индексы, разнести данные в разные таблички и проч) — это тот минимум, который необходим. Если по полю нет индексов, то поиск будет ползать 8 минут. Если есть — 8 секунд. Мне вообще сложно представить что при 1кк записей может быть запрос дольше 1 сек. Это не те объемы, при которых что-то начинает тормозить. Купите коробку, оптимизируйте запросы и таблички, посмотрите что получится.

Comments

[Владимир Болиев]

Это 1кк продуктов раскиданы по 2к разделов. Та же рекурсия, при сборе дерева — не хило грузит все, что можно загрузить. Ну это как пример.

[Vampiro]

Как бы не проблема собрать это дерево один раз, и пересобирать при обновлении категорий. Мне казалось все нормальные деревья работают по этому принципу. Могу ошибаться, мир не так совершенен как я =)

[Владимир Болиев]

Не проблема, но в тех cms которые я тестировал, кроме magento, сделано именно рекурсией. Таких моментов на самом деле много, просто проставлением индексов не обойтись(

[Vampiro]

Вероятно, это повод задуматься о качестве продукта. Это их способ втюхать вам более дорогие Интерпрайз версии. Они же тоже кушать хотят.
Кстати, вам нет нужды делать свою cms для продажи 1млн. товаров. Интернет магазины замечательно делаются на основе готовых фреймворков а-ля симфони, зенд, yii. И при этом создание с нуля будет быстрее и качественнее допила существующих. Только надо найти хорошего спеца. Где-то тут парень искал работу со свободным графиком относительно. К Июлю бета, в августе продакшн можно уже запуститься.

[Владимир Болиев]

Само собой предполагается использовать фрэймворк :-) Специалистов у нас хватает, просто вопрос стоял: Стоит ли писать, или можно найти подходящее готовое решение)

Answer 9

[Dmitry]

Поддерживаю предыдущего оратора. 8 минут что-то феерическое. У меня столько ищется вхождение подстроки в таблице без индексов на 100кк записей на компе 5 летней давности. Если индексы есть, значит косяк в CMS и стоит попробовать другую или тупо отрубить часть поиска(ну или попробовать оптимизировать :) ). Сам каталог нормально работает?