Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 35
Time per request: 44.224 [ms]
ab выдает не самые честные цифры. Рекомендую httperf + директиву $upstream_response_time для лога nginx-а. На основании такого теста можно получить более реальную картину влияния нагрузки на движок и сервер.
Для каталога товаров актуален такой функционал как поиск. Сколько времени занимает поиск в духе "найти все товары которые произвел Х, стоимость которых не больше Y, а параметр Z равен W" («найти смартофоны Samsung по цене не более 20 круб и диагональю 4'' „)?
Хороший вопрос. Большинство большое количество разработчиков думают об оптимизации кода, забывая про оптимизацию базы данных. Я как раз стараюсь разработать такую платформу, которая позволит работать с базой данных максимально быстро. В частности есть возможность переопределить классы и вынести данные в отдельные таблицы без проблем для функционала. Большинство классов — это расширение modResource. Записи содержатся в таблице site_content с другими документами. Связанные расширяющие данные — это modTemplateVar. Но value в modTemplateVar — текстовое поле, со своими вытекающими. Потому для тех же ShopmodxResourceProduct есть связанный класс ShopmodxProduct с своими данными в отдельной таблице и ключем resource_id=id. Описание объекта здесь. А вот в этой таблице уже есть специфические поля, такие как sm_price. В каждом отдельном магазине уже будет докручиваться индивидуальная структура и логика, исходя из бизнес-логики.
Запросы будут довольно сложные, но если правильно все оптимизировать, то проблем не будет.
Вот пример: простая выборка
Вот уже более сложный запрос
Выполнение 0,000
Запросы будут довольно сложные, но если правильно все оптимизировать, то проблем не будет.
Вот пример: простая выборка
SELECT c.id, c.pagetitle FROM `modx_site_content` as c
left join modx_shopmodx_products as p on p.resource_id = p.id
WHERE sm_price
limit 10
Вот уже более сложный запрос
SELECT c.id, c.pagetitle, sm_price FROM `modx_site_content` as c
inner join modx_shopmodx_products as p on p.resource_id = c.id
WHERE sm_price between 500 and 1000
order by sm_price desc
limit 10Выполнение 0,000
Приведенные sql слишком простые. Выборка по цене это только один критерий запроса. Я же говорю о 2-6 параметров (как показывает мой опыт именно только используют в фильтре при поиске конкретного товара). Сколько для этого варианта получиться? Хотя бы по 4 критериям: 2 являются диапазонами значений (к примеру, цена и диагональ), а 2 — конкретные значения (к примеру, марка производителя и наличие 3G). Кстати, при этом сколько товаров находится в магазине (13 000)?
Правильно ли я понимаю, что если завтра у меня появляется новый товар с новым набором характеристик, то как минимум придется изменить/добавить структуру таблиц (изменить код?)?
В каждом отдельном магазине уже будет докручиваться индивидуальная структура и логика, исходя из бизнес-логики.
Правильно ли я понимаю, что если завтра у меня появляется новый товар с новым набором характеристик, то как минимум придется изменить/добавить структуру таблиц (изменить код?)?
Приведенные sql слишком простые. Выборка по цене это только один критерий запроса.Вы еще смотрите, что там сортировка. Одна сортировка может пяти условий стоить.
Давайте я не буду сейчас приводить кучу запросов, а просто скажу, что целый год поддерживал весь биллинг в сотовой компании на Оракле, и вы мне поверите на слово, что проблем с запросами не будет.
Правильно ли я понимаю, что если завтра у меня появляется новый товар с новым набором характеристик, то как минимум придется изменить/добавить структуру таблиц (изменить код?)?Нет. В большинстве случаев ничего не придется делать. Для этого есть TV-параметры. Но если будет специфическая задача, то многое действий не потребуется — расширили класс, создали для него расширенную таблицу. перенесли все записи туда, а в описании класса указали имя другой таблицы.
Нельзя сделать полностью универсальный магазин. Это — платформа. И она изначально подразумевает, что какие-то манипуляции с объектами потребуются. Так же как мы берем чистый MODX и пишем для него сниппеты, плагины и т.п. Но вам не понадобится лезть в код shopModx.
Давайте я не буду сейчас приводить кучу запросов,
А я не это прошу. Я хочу узнать, сколько времени будет отрабатывать запрос при >=13 ктоварах и 4 критериях поиска.
действий не потребуется — расширили класс, создали для него расширенную таблицу.
Т.е. привлечение разработчика под эту задачу обязательно.
Я хочу узнать, сколько времени будет отрабатывать запрос при >=13 ктоварах и 4 критериях поиска.Так же в пределах 0.03 сек, ито пессимистичный прогноз. Сложности с выборкой — это таблиц 10, и как минимум в трех из них несколько сотен тысяч записей.
Т.е. привлечение разработчика под эту задачу обязательно.Со временем я буду добавлять готовые решение, да может и сообщество подсобит, но пока пишется именно платформа, а она да, потребует для реализации конкретных магазинов программиста. Но это чисто для крупных магазинов. Для небольших (до 1000 товаров) можно обойтись штатными средствами modResource + modTemplate + modTemplateVar + getResource и прочие штатные компоненты. Там 100% MODX-технологии без всяких.
да может и сообщество подсобит
Уж не то ли сообщество из которого вашими стараниями ушли практически все толковые разработчики и в котором вы единственный автор статей за последние пару месяцев вам подсобит?
Пришли униженные и оскорбленные троллить топик :-)
Уж не ты ли среди этих топов? Завсегдатай раздела «Вопросы».
Уж не ты ли среди этих топов? Завсегдатай раздела «Вопросы».
Вот в этом весь Николай. Тыкать, переходить на личности и не воспринимать критику со стороны. Никто не собирается троллить ваш топик. И да — я задавал много вопросов и продолжаю задавать вопросы, потому что не считаю себя умнее всех как некоторые, а пока продолжаю учиться. А вот подобный выпады с вашей стороны — обычная низость, не более того.
А подобный ВАШ заход сюда — это очередная попытка перевести акцент с полезной информации на уже избитую 4-ехмесячную тему. Забудь уже про меня. Есть что сказать по существу — милости прошу, отвечу на лубой технический вопрос по сабжу. А беспонтовый троллинг — не конструктив.
Уже даже Дмитрий говорит, что нужны технологии, а не повздорившие программисты. Меня не слушаешь, так его хоть послушай.
Уже даже Дмитрий говорит, что нужны технологии, а не повздорившие программисты. Меня не слушаешь, так его хоть послушай.
Да не о чем с вами говорить. Если вы следите за жизнью нового сообщества, то там по поводу вашего клипа я вопрос задавал уже, можете зайти и ответить. А разводить тут холивар нет ни желания ни настроения, скоро все изменится и вы прекрасно это знаете. Пока вы делаете ваши «решения для разработчиков (с)» заканчивается работа над решением для всех, в котором все вышеописанное уже реализовано и прекрасно работает с >20к ресурсов. Обратитесь к Диме, он вам даст реальные ссылки.
Я к вам на ваш сайт не лезу, у вас там своя жизнь и наверняка я буду там лишним. Потому отвечать там ничего не буду.
А вот про >20к ресурсов хотелось бы статью видеть. Я видел, что Дмитрий с бумкака (вроде) делали магазин. Но это на Эво. Речь не о том, что лучше, а что хуже, но мне надо на Рево.
То, что сейчас реализовано в modxShop — это еще совсем малая часть от планируемого. А то, что в нем сейчас мало файлов и мало кода — это совсем не показатель малой работы. Наоборот. Посмотрите на гитхабе изменения с версии 0.0.1 до текущей, и увидите, что количество файлов и кода только сокращается. И это не регресс, а прогресс, так как применяются самые глубокие познания MODX-а. Покажите другой такой компонент для Ревы.
А вот про >20к ресурсов хотелось бы статью видеть. Я видел, что Дмитрий с бумкака (вроде) делали магазин. Но это на Эво. Речь не о том, что лучше, а что хуже, но мне надо на Рево.
То, что сейчас реализовано в modxShop — это еще совсем малая часть от планируемого. А то, что в нем сейчас мало файлов и мало кода — это совсем не показатель малой работы. Наоборот. Посмотрите на гитхабе изменения с версии 0.0.1 до текущей, и увидите, что количество файлов и кода только сокращается. И это не регресс, а прогресс, так как применяются самые глубокие познания MODX-а. Покажите другой такой компонент для Ревы.
Подоплека вопроса выше была такая: "Какие индексы используются в вашей базе? Т.к. используя TV парметры для хранения значений дополнительных характеристик невозможно сделать быстрые фильтры по базе из 13к товаров." Собственно это и попытался уточнить alekciy
Помимо этого был добавлен верный вопрос
Запросы приведеные выше тестировались на базе какого объема?
Правильно ли я понимаю, что если завтра у меня появляется новый товар с новым набором характеристик, то как минимум придется изменить/добавить структуру таблиц
Помимо этого был добавлен верный вопрос
Кстати, при этом сколько товаров находится в магазине (13 000)?
Запросы приведеные выше тестировались на базе какого объема?
Верно. Я когда-то вел разработки на MODx-а и даже делал модификацию ядра. В том числе работал в TV параметрами. И считаю структуру бд не оптимальной для создания больших каталогов с произвольным набором параметров. Даже для 13 ктоваров.
P.S. Собственно было интересно сравнить с собственным решением. У меня 800 ктоваров (значений атрибутов 8 миллионов) при этом у товара может быть произвольное количество атрибутов, товары так же произвольны. Структура таблиц остается неизменной (что-то близкое к EAV но не оно). Так вот, запросы по 4 параметрам: 2 диапазона и 2 статических значения занимают порядка 0.0002 сек (0.2 мс). И лишь запросы по 10 параметрам начинают «тормозить» требуя 0.3-0.5 мс. Это на уровне СУБД. Сам же движок такие поисковые запросы отрабатывает за 10-150 мс в зависимости от степени попадания в кэш.
P.S. Собственно было интересно сравнить с собственным решением. У меня 800 ктоваров (значений атрибутов 8 миллионов) при этом у товара может быть произвольное количество атрибутов, товары так же произвольны. Структура таблиц остается неизменной (что-то близкое к EAV но не оно). Так вот, запросы по 4 параметрам: 2 диапазона и 2 статических значения занимают порядка 0.0002 сек (0.2 мс). И лишь запросы по 10 параметрам начинают «тормозить» требуя 0.3-0.5 мс. Это на уровне СУБД. Сам же движок такие поисковые запросы отрабатывает за 10-150 мс в зависимости от степени попадания в кэш.
И считаю структуру бд не оптимальной для создания больших каталогов с произвольным набором параметров
Все верно. Для быстрого создания прототипа сайта MODX идельно подходит. И интерейс админки очень быстро кастомизируется. Но то, как с этими данными приходится работать из фронта — волосы дыбом встают. Поэтому до сих пор еще каждый пишет свои велосипеды и как-то пытается улучшать код. В свое вермя для Evolution версии был плгин который создавал отдельную таблицу для хранения TV праметров. И при добавлении нового TV парметрка в базу отправляется запрос ALTER TABLE в эту таблицу. Но опять таки, даже сейчас еще нет средств позволяющих красиво фильтровать данные по этой таблице.
Таким образом, TV параметры могут помочь программисту быстро накидать интерфейс для редактирования данных. А все данные зерклировать куда-то в другое место. Собственно я подробно эту схему в статье про плагин TagSaver описал.
Так и я не говорю, что база MODX-а идеальная. Потому и делается упор на то, что для индивидуального магазина нужно создавать индивидуальные таблицы и свои индексы настраивать, без этого никак.
Но: в том же битриксе, который в России сами знаете какое положение на рынке eCommerce занимает, по сути такая же система TV-параметров применяется. Это говорит о том, что такая структура TV-шек — максимально гибкая для быстрой настройки через админку. Но наверняка на крупных магазинах так же создаются свои таблицы.
Но: в том же битриксе, который в России сами знаете какое положение на рынке eCommerce занимает, по сути такая же система TV-параметров применяется. Это говорит о том, что такая структура TV-шек — максимально гибкая для быстрой настройки через админку. Но наверняка на крупных магазинах так же создаются свои таблицы.
У меня 800 ктоваров (значений атрибутов 8 миллионов)
Есть ссылка на ваш проект?
Подоплека вопроса выше была такая: «Какие индексы используются в вашей базе? Т.к. используя TV парметры для хранения значений дополнительных характеристик невозможно сделать быстрые фильтры по базе из 13к товаров.»Это еще почему? Чем таблица TV отличается от других таблиц? Ее отличие и ограничение только в том, что колонка value — текстовое поле (о этом говорил выше), и элементарная выборка с сортировкой цен, к примеру, даст глупый результат, и для корректности придется тип данных налету конвертировать, что однозначно скажется на производительности.
Проблемы из-за предполагаемого большого кол-ва JOIN-ов? Так делайте один JOIN, а варианты TV-шек загоняйте в условие IN(), и будет практически тоже самое. А таблица контента и TV-шек так же надо связать вторичными ключами, без этого никак.
И напомню: объекты расширяемые. Специально для своего магазина можете создать отдельную таблицу со специфическими колонками и фигачить данные туда.
Запросы приведеные выше тестировались на базе какого объема?Заявленного. 13000 товаров + 43000 TV-шек. Или вас в мегабайтах интересует?
Или вас в мегабайтах интересует?
Запросы приведеные выше тестировались на базе какого объема?
И конкретный ответ:
13000 товаров + 43000 TV-шек
Дальнейшие выводы каждый сделает сам для себя.
Кстати, по оптимизации базы Ревы подробно писал здесь: newpg.ru/nashi-proekty/filmografiya.tv/optimizatsiya-bazy-dannyh.html
По моему, проблема базы сильно преувеличена. Я тоже раньше переживал, что при 7 килотоваров с кучей ТВ и посещаемостью 10килоюзеров/сутки все будет тормозить. Да, оно подтормаживало, но после переезда на VPS ничего не тормозило, а уж при переезде на выделенный сервак (за 50 евро у хетцнера) вообще все летает. Замечу, речь идет о ево, но у него тоже постоянно все любят говорить про «оптимизацию» базы.
А выделять товары в отдельную таблицу стоит лишь из-за того, что в основном дереве их не удобно редактировать.
А выделять товары в отдельную таблицу стоит лишь из-за того, что в основном дереве их не удобно редактировать.
А выделять товары в отдельную таблицу стоит лишь из-за того, что в основном дереве их не удобно редактировать.Ставьте для своих товаров show_in_tree=0, устанавливайте groupEdit, и заявленная проблема перестанет быть проблемой (само собой речь о Рево).
По моему, проблема базы сильно преувеличена.А по-моему вообще не преувеличена. Если одна выборка выполняется даже 0,3 сек., то вся страница никак не сможет быть отдана менее чем за это 0,3 сек. Оптимизировав базу можно сократить нагрузку в десятки раз. У меня один закрытый проект есть (система пропусков), там поиск выполняется после каждой добавленной буквы в поисковую строку. Записей очень много и запросы сложные, из нескольких таблиц. Так вот когда с ростом базы нагрузка возрастала, просто оптимизация базы (без изменения запросов), позволяла сократить время выполнения запроса с нескольких секунд до нескольких тысячных секунды.
Тут опять же надо уточнять о каком железе идет речь.
А большинство «оптимизаций» ведут к тому, что при очередном обновлении системы надо будет заново все «оптимизировать» (к базе это конечно в меньшей степени относится), что добавит проблем и повышает вероятность добавления багов.
ПС. Самая правильная оптимизация — убеждать разработчиков modx в тех или иных «оптимизациях».
А большинство «оптимизаций» ведут к тому, что при очередном обновлении системы надо будет заново все «оптимизировать» (к базе это конечно в меньшей степени относится), что добавит проблем и повышает вероятность добавления багов.
ПС. Самая правильная оптимизация — убеждать разработчиков modx в тех или иных «оптимизациях».
А большинство «оптимизаций» ведут к тому, что при очередном обновлении системы надо будет заново все «оптимизировать»Сорри, с чего это вдруг оптимизация в виде правильной настройки ключей у связанных таблиц должна как-то пострадать при очередном обновлении системы?
ПС. Самая правильная оптимизация — убеждать разработчиков modx в тех или иных «оптимизациях».Нельзя под все оптимизироваться. Вот судя по вашему нику — вы админ. У вас есть на вооружении Ось, которую поставил, и только пиво попиваешь?
Простите за оффтопик, но почему Ваши комментарии практически всегда заминусованы во множестве тем?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка интернет-магазина 13000+ товаров на MODX Revolution. Часть 1