подойдет ли opencart под магазин одежды 100 000 товаров?

[EVMedvedev]

Хорошая тема вставлю свои 5 копеек.

У меня есть два проекта, базируются на VPS 2GB 2000mhz 50GB hdd.

Первый проект имел 350.000 товаров магазин автозапчастей avto-161.ru , сейчас он лежит 5й день )) из за перехода на 6ю версию HostCMS в которую я в общем по всем затратам влил около 45000р. очень разочарован этой системой, правда тех.поддержка у них отличная. на 5ой версии 350 000 товаров плюс кстати около 45000 категорий VPS тянул. Но на HostCMS нет модуля фильтры! Каких тут навалом. Вот сижу 3й день читаю форум пытаюсь вкурить , понял что 100.000 товаров это круто для Opencarta, но блин есть такой нужный фильтр товаров. Ну и еще не хватает нормального экспорта импорта товаров в CSV ... Через PHPMyadmin что то до конца вкурить не могу как импорт делать в таблице товар появляется на сайте нет. Может кто юзает данную фичу ? Подскажите что не так делаю. Пока тестирую на локальной машине . Если все устроит и получится с Опенкартом. То это однозначно мой выбор! Да и сообщество радует + цены действительно не высокие на модули. Пусть их разрабатывают фрилансеры. А вот коммерческие CMS это уже не мое однозначно.

 

Для проектов в сотни тысяч товаров да еще с качественной фильтрацией - только Magento. И дело даже не в количестве товаров и не в производительности. Дело в качестве поиске и фильтрации. То что есть в Magento нет ни в одном другом движке в коробочном варианте и даже допилами сделать не получится.

Змінено 2 червня 2014 користувачем EVMedvedev

[snastik]

Вы явно ни чего не понимаете в Magento. То что в ней 400 таблиц не говорит ни о чем. Для большой номенклатуры в ней есть специальный режим плоской таблицы, когда все данные о товаре собираются в одной плоской таблице и поиск всегда идет в один запрос по этой таблице без всяких JOIN. Собственно от части именно поэтому Magento берут для больших проектов а Опенкарт нет. Ваша калькуляция с умножениями - полный отстой.

 

Позвольте поспорить. С одной стороны вариант с плоской таблицей верный, с другой стороны, делать выборку из жирной таблицы овер 100мб средствами MYSQL - самоубийство, имхо, для очень большого проекта, надо дробить таблицы с товарами по категориям. А если копнуть еще дальше, то как бы мы не изголялись, выборку по фильтрам все равно придется делать с Join ами. Ну и в догонку, из того что я вскользь видел в магенто, сам фреймворк будет тяжелее в разы.

[cmd]

snastik, в чем смысл дробить таблицы по категориям? 0_о

4 Гб в мускуле лимит на таблицу, вроде, не просто вылезти с 100 000 товаров. Это по 10 Мб на строку надо...

[snastik]

snastik, в чем смысл дробить таблицы по категориям? 0_о

4 Гб в мускуле лимит на таблицу, вроде, не просто вылезти с 100 000 товаров. Это по 10 Мб на строку надо...

 

 

А памяти сколько надо для работы с этой таблицей, а выборку даже при помощи индексов делать по такой таблице? А если этих индексов штук 10, еще и половина fulltext? Попробуйте докрутить магазин с 20-30к товарами, только не с демо, а с полноценной таблицей, на VPSке с 1-2 GB мозгов, до меньше 1 сек загрузки, вот тогда нам будет о чем поговорить. 

[snastik]

1. Работать с плоской таблицей куда быстрее. Join'ы при формировании выборки создают ту же временную таблицу, только не в самом лучшем виде.

(и еще одно ограничение вылазит, временные таблицы не могут использовать механизм индексов, поэтому все промежуточные выборки надо делать как можно более ограниченными)

2. Дробить таблицу на куски надо. В MySQL есть партицирование

(Забыл дописать в предыдущем ответе, что дробление также существенно оправдано на системах с SAS, SATA дисками, а также системах, которые используют активное обновление данных (парсеры), так как в случае обновления общей таблицы при активном парсинге, она у вас будет практически всегда залочена, процессом INSERT).

3. Magento? Плавали, знаем :-) Знаем и про того, кто его тут продвигает - теоретический программист. Его кода никто не видел, но умных речей много.

(так пусть продвигает скок хочет, в любом случае цена реализации идентичных проектов на Magento и OC  - раза в три будет отличаться). А потолка в масштабирование OC я пока что не вижу. Не хватило ресурсов сервера - разнесли Apache и Mysql. Начало загинаться такое решение - банальная репликация и второй mysql спасает. А Apache  с проксирующим nginx отработает 100500 соединений. Минус мультиязычность + запросы без NOW(), нормальный размер кешей у Mysql  и никакой Magento не надо.

[EVMedvedev]

 

3. Magento? Плавали, знаем :-) Знаем и про того, кто его тут продвигает - теоретический программист. Его кода никто не видел, но умных речей много.

 

Значит плохо плавать умеете :-). Особенно на практике. Слов много, а дел маловато будет :-). А про Magento речь не для продвижения а для констатации фактов. Тут продвигать Мадженто бессмысленно. Среди пользователей ОС нет серьезных клиентов для такого движка. Рожденные ползать - летать не могут :-).

[EVMedvedev]

А потолка в масштабирование OC я пока что не вижу. Не хватило ресурсов сервера - разнесли Apache и Mysql. Начало загинаться такое решение - банальная репликация и второй mysql спасает. А Apache  с проксирующим nginx отработает 100500 соединений. Минус мультиязычность + запросы без NOW(), нормальный размер кешей у Mysql  и никакой Magento не надо.

Если не видите, это еще не значит что его нет. Просто вам они не видны :-). А когда я говорил про Мадженто, я говорил не о производительности, а о функциональности. Вы видимо читаете не внимательно. Может потому ни чего и не видите :-).

[EVMedvedev]

snastik, в чем смысл дробить таблицы по категориям? 0_о

4 Гб в мускуле лимит на таблицу, вроде, не просто вылезти с 100 000 товаров. Это по 10 Мб на строку надо...

 

Некоторые СУБД (типа MongoDB) шардинг поддерживают. В MySQL этого нет. Только репликация (если не считать платное расширение для шардинга для MySQL на файловом уровне). На хабре была статья как ребята шардинг для MySQL на PHP делали. Идея в общем понятная но для ОС соответственно утопичная.

Змінено 2 червня 2014 користувачем EVMedvedev

[freelancer]

а что за миф про 4Гб на Mysql?
http://dev.mysql.com/doc/refman/5.6/en/table-size-limit.html

[EVMedvedev]

Позвольте поспорить. С одной стороны вариант с плоской таблицей верный, с другой стороны, делать выборку из жирной таблицы овер 100мб средствами MYSQL - самоубийство, имхо, для очень большого проекта, надо дробить таблицы с товарами по категориям. А если копнуть еще дальше, то как бы мы не изголялись, выборку по фильтрам все равно придется делать с Join ами. Ну и в догонку, из того что я вскользь видел в магенто, сам фреймворк будет тяжелее в разы.

 

Кстати в Мадженто шардинг реализован. Там товары для разных магазинов или витрин (для мультиязычносит) в разные плоские таблицы сбрасываются. Так что даже при 1 000 000 товаров число записей в таблице будет навно 1 000 000 соответственно. Очевидно что для ОС выборка товаров из такой номенклатуры для нескольких языков предполагает JOIN таблицы с 1 000 000 записей с таблицами с текстовыми данными (описания) с количеством записей равным 1 000 000 умноженным на количество языков. Вывод очевиден.

Кстати в Мадженто выборка по атрибутам делается без JOIN. Все атрибуты сидят в плоской таблице. Так что тут ОС тоже проиграет с треском с его структурой данных для хранения атрибутов.

Я уж не говорю, что в Мадженто один и тот же атрибут одновременно может использоваться и для фильтрации и для сортировки и для комбинированного поиска по словам и атрибутам. И все это в коробке. Так что в части навигации ОС не тягаться с Мадженто.

[snastik]

Кстати в Мадженто шардинг реализован. Там товары для разных магазинов или витрин (для мультиязычносит) в разные плоские таблицы сбрасываются. Так что даже при 1 000 000 товаров число записей в таблице будет навно 1 000 000 соответственно. Очевидно что для ОС выборка товаров из такой номенклатуры для нескольких языков предполагает JOIN таблицы с 1 000 000 записей с таблицами с текстовыми данными (описания) с количеством записей равным 1 000 000 умноженным на количество языков. Вывод очевиден.

Кстати в Мадженто выборка по атрибутам делается без JOIN. Все атрибуты сидят в плоской таблице. Так что тут ОС тоже проиграет с треском с его структурой данных для хранения атрибутов.

Я уж не говорю, что в Мадженто один и тот же атрибут одновременно может использоваться и для фильтрации и для сортировки и для комбинированного поиска по словам и атрибутам. И все это в коробке. Так что в части навигации ОС не тягаться с Мадженто.

Что то вы какую то фантастику городите. Плоская таблица со всеми атрибутами, в таблице товаров или где????? Подробнее опишите ка структуру.

[snastik]

+ что вы там говорите, шардинг ???? поддерживается в магенто, на mysql ? из коробки?

[EVMedvedev]

Что то вы какую то фантастику городите. Плоская таблица со всеми атрибутами, в таблице товаров или где????? Подробнее опишите ка структуру.

 

При включении в разделе меню Каталог -> Каталог-> Пользовательский раздел двух опций:

- использовать плоскую структуру для категорий

- использовать плоскую структуру для товаров

Хранение этих данных из стандартной струткуры Мадженто (Entity-Attribure-Value) переводится в плоскую таблицу (см. таблицы catalog_category_flat_store_1 и catalog_product_flat_1) Соответственно если делать несколько витрин, для разных языков, то будут генериться таблицы х_2, ч_3 и так далее соответственно для товаров и категорий. В каждой таблице будут все данные по товару, но только на одном языке. Кстати к витринам товар может привязываться не только по языковому признаку, но и по признаку принадлежности к категориям, так что решение с распределением товаров разных категорий по разным таблицам ( о чем тут где то выше писали) в Мадженто тоже заложено от природы. Вот и плоские таблицы и вот и некое подобие шардинга, (хотя классический шардинг предполагает не только разбиение однотипных данных на группы, но и возможность параллельной обработки запросов на нескольких узлах как в MongoDB при разбросе узлов базы данных на отдельные сервера со своими копиями СУБД.).

 

Общая схема работы в этом случае такова:

- все правки вносятся в эталонный массив данных, построенный на принципах EAV

- запускается переиндексация, то есть обновление данных в плоских таблицах (см меню Система -> Менеджер индексации)

Если переиндексацию не сделать при включенных плоских таблицах, то во фронтофисе обновления видны не будут, только в админке, потому что в ней работа идет только с оригинальными данными в представлении EAV. Если не включать плоские таблицы, то Мадженто будет страшно тормозить, потому что выборка данных по объектам в этом случае ведется в последовательности Выбор сущности -> выбор атрибутов сущности -> выбор значений атрибутов сущности. То есть там нужно такие JOIN вырисовывать, что с дуба можно рухнуть.

 

А вообще в Мадженто работа с данными о товаре построена так:

- создаются атрибуты товара с разными типами данных, разными настройками их видимости в фильтрах, в сортировке, в расширенном поиске и т.п. (то есть задаются настройки использования атрибутов в навигации и для отображения)

- создаются наборы атрибутов для разных товаров

- создаются товары с выбранными наборами атрибутов (в эталонной базе данных в структуре EAV)

- на основе эталонных данных создаются таблицы для фронтофисов

Это сделано сознательно, чтобы иметь возможность:

- с одной стороны гибко строить модели данных для описания разнотипных товара (то есть использовать преимущества работы со слабо структурированными данными как в СУБД вроде MongoDB)

- с другой использовать все преимущества производительности реляционных СУБД при работе с плоскими таблицами.

 

При этом подчеркиваю: Я не предлагаю всем бросить Opencart и пересаживаться на Magento. Я просто констатирую факт, что для построения очень больших магазинов в движке должны присутствовать определенные функциональные возможности и что в одних движках эти функции есть, а в других нет. Я не собираюсь продвигать здесь Мадженто. Это бессмысленно, потому что у Мадженто и ОС совершенно разные пользователи, по задачам, по бюджетам и т.п. Тем более что пользователи ОС не моя клиентура и переманивать их на Мадженто - себе дороже. Все что пишется о Мадженто - пишется чисто из любви к искусству программирования, потому что с профессиональной точки зрения движок написан очень грамотно :-). Мадженто это сложный, профессиональный инструмент для построения очень больших и сложны торговых систем вроде магазинов Ламода или Ашана. Использовать Мадженто при построении маленьких магазинчиков так же бессмысленно, как строить на Опенкарте супермаркеты. Да и Мадженто это все таки скорее CMF а не готовый к употреблению инструмент.

В ОС отсутствуют многие механизмы, которые не нужны для маленьких магазинов, но крайне важны для больших. И в свою очередь Мадженто имеет много функционала, который нужен для больших магазинов, но совершенно избыточен для малых. Дополнять ОС недостающим функционалом так же бессмысленно как вырезать из Мадженто лишний. Каждый движок подходит для своего типа магазинов. Мадженто для больших, Prestashop для средних, Опенкарт для малых. И пусть им всем живется хорошо, каждому на своей лужайке :-).

[12strun]

..... А про Magento речь не для продвижения а для констатации фактов. Тут продвигать Мадженто бессмысленно. Среди пользователей ОС нет серьезных клиентов для такого движка. Рожденные ползать - летать не могут :-).

 

Совершенно согласна что Опенкарт  - для мелкой и средней рыбешки...) Хотела сама это ввернуть, но не успела...)

С удовольствием читаю тему...)... обзорная такая...)

[snastik]

Из того что до меня чуть чуть долшло - не структура  а велосипед какой то. При желании подобная надстройка в виде плоских таблиц дописывается к Opencart за месяц. Только вот я все равно так и не понял как в плоскую таблицу записываются значения атрибутов. Это что ли на каждый атрибут создается свое поле со значением?

[EVMedvedev]

Только вот я все равно так и не понял как в плоскую таблицу записываются значения атрибутов. Это что ли на каждый атрибут создается свое поле со значением?

Да. EAV механизм используется как объектный конструктор моделей данных. При разработке наборов атрибутов фактически строится что-то вроде ORM, на основе которой потом:

- сначала ведется эталонный массив данных в EAV структуре

- потом генерируются плоские таблицы для ускорения работы.

 

А на счет "сделать то же самое за месяц на ОС" - давайте. Хотелось бы посмотреть на это. Очень будет поучительно :-). А через пару тройку лет (или десятков лет) мы все восхитимся вашим творением :-).

Змінено 4 червня 2014 користувачем EVMedvedev

[andrey24]

Если опенкарт на среднюю рыбу и запросы 100к+ товаров, то в мадженту весь интернет копируете чтоли? Вот мне бы через года 2 и 1 месяц на большинство этих коммерсантов с 10к и 100к+ товарами глянуть, наверно даже домен не продлен :-D

[EVMedvedev]

Совершенно согласна что Опенкарт  - для мелкой и средней рыбешки...) Хотела сама это ввернуть, но не успела...)

С удовольствием читаю тему...)... обзорная такая...)

 

Да. Проблема в том, что многие разработчики, освоив один движок, начинают тянуть всех на него, рассказывая байки, что именно он является решением абсолютно всех проблем, хотя как известно универсальных решений не бывает.

[EVMedvedev]

Не юлите. Вам задали прямой вопрос: как атрибуты хранятся в базе. Не надо перескакивать на другой уровень абстракции: ORM, EAV,... В базе что?

Если вам эти термины не знакомы, то проблемы не в моем ответе, а вашей квалификации. Не можете понять, так и скажите.

[EVMedvedev]

..., наверно даже домен не продлен :-D

Вы хоть в курсе, что домен нужно каждый год продлевать? Так правилами установлено :-)

[snastik]

Да. EAV механизм используется как объектный конструктор моделей данных. При разработке наборов атрибутов фактически строится что-то вроде ORM, на основе которой потом:

- сначала ведется эталонный массив данных в EAV структуре

- потом генерируются плоские таблицы для ускорения работы.

 

А на счет "сделать то же самое за месяц на ОС" - давайте. Хотелось бы посмотреть на это. Очень будет поучительно :-). А через пару тройку лет (или десятков лет) мы все восхитимся вашим творением :-).

Защищайтесь сударь, отвечайте, как в плоской таблице вывалить 200+ атрибутов??????

И вы знаете пока что таких реализаций ну не надо, 50 к товаров на опенкарте с фильтром от фрилансера, чуть допиленным, но не доконца, потому что клиента все устроило (до 2 сек загрузка с выбранными атрибутами,  до1 сек загрузка страницы категории стоваром). Куда дальше оптимизировать? При этом. Не самый жирный VDS + VPS под базу. И работы на два дня ценою в 200 долларов. Подскажите, сколько стоить будет такая оптимизация Magento и на каком железе оно так же заживет?

И как быстро будут обновляться данные в ваших плоских таблицах с наличием постоянно работающего парсера?

[EVMedvedev]

Защищайтесь сударь, отвечайте, как в плоской таблице вывалить 200+ атрибутов??????

И вы знаете пока что таких реализаций ну не надо, 50 к товаров на опенкарте с фильтром от фрилансера, чуть допиленным, но не доконца, потому что клиента все устроило (до 2 сек загрузка с выбранными атрибутами,  до1 сек загрузка страницы категории стоваром). Куда дальше оптимизировать? При этом. Не самый жирный VDS + VPS под базу. И работы на два дня ценою в 200 долларов. Подскажите, сколько стоить будет такая оптимизация Magento и на каком железе оно так же заживет?

И как быстро будут обновляться данные в ваших плоских таблицах с наличием постоянно работающего парсера?

 

Так от чего защищаться то? Пока получается как с  санкциями Запада, слов много а защищаться не от чего :-). Проблема с количеством атрибутов в плоской таблице может появиться только в том случае если общее количество памяти для размещения одной записи будет выше 65К (ограничение MySQL), а это 255 строковых полей по 255 символов. Если же это будут численные данные, то сами понимаете ... :-).

 

А если 2 секунды загрузка не проблема, можно и EAV модель данных оставить, тогда вообще ограничений на количество атрибутов не будет хоть по  10 000 на товар колотите. Но тут ведь дело еще в том, что если я привязываю разные товары к разным категориям или разным магазинам, то генерятся разные плоские таблицы и набор атрибутов в них будет разный. Так что есть масса вариантов для снятия практически всех ограничений. Все продумано. Не зря в разработки Мадженто вложены миллионы баксов и более 10 лет работы. Над ней целая толпа народа работает в Киеве.

 

Да, на счет парсера, там все проще, поскольку если ведется нормальный учет и каждый товар имеет SKU то обновления можно делать без проблем. Это не OC где понятие складского учета практически отсутствует. А уж расчет дельты цен в атрибутах это вообще ..., хуже не придумать. Более того, там в коробке штатный датафлоу есть, которые по крону позволяет выгружать и загружать данные в CSV формате. Это кстати одна из причин, почему Мадженто берут для больших магазинов, когда есть налаженный учет в 1С.

Змінено 5 червня 2014 користувачем EVMedvedev

[snastik]

ооооо. Аргументы канешна. Жесть. Они очень похожи на аргументы приверженцев продвижения от Rookie. В разработку системы вложено, потрачено. В олимпиаду тоже говорят 50 ярдов потратили и 10 лет. Т.е. Пока что я не услышал для себя актуальных аргументов. А только цифры и затраты. Что касаемо всего остального, то цена вопроса разработки платформы - это отличный повод рубить с клиентов бабла на порядок больше. И реализовывать программно-аппаратный комплекс, а не установленный движок на недорогой хостинг. Так что не убедили.

[EVMedvedev]

ооооо. Аргументы канешна. Жесть. Они очень похожи на аргументы приверженцев продвижения от Rookie. В разработку системы вложено, потрачено. В олимпиаду тоже говорят 50 ярдов потратили и 10 лет. Т.е. Пока что я не услышал для себя актуальных аргументов. А только цифры и затраты. Что касаемо всего остального, то цена вопроса разработки платформы - это отличный повод рубить с клиентов бабла на порядок больше. И реализовывать программно-аппаратный комплекс, а не установленный движок на недорогой хостинг. Так что не убедили.

 

Ну если для вас чужие трудозатраты не аргумент, то это ваши проблемы. Любой вменяемый человек понимает, что чем больше вложено труда в изделие тем оно будет дороже. Это закон экономики :-). Это простейшая логика. Или вам не знакомо понятие "логика", как господину toporchillo не знакомы аббревиатуры EAV и ORM  :-)? Ну тогда медицина тут бессильна. Это то же самое что в детском саду объяснять, что такое синхрофазотрон :-D.

Змінено 6 червня 2014 користувачем EVMedvedev

[SPositive]

EVMedvedev, так у вас получилось отжать Magento-лицензию на неограниченное количество доменов?

http://magento-forum.ru/user/727/

 

:-D