Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 14
Или взять что то готовое типа Magento и не морочить себе голову
ключевой момент — в любой непонятной ситуации используй MongoDB :)
Использую такую структуру Products — ProductAttributes — ProductAttributeValues.
Сущность Product включает в себя общие свойства продукта вроде имени, цены, описания, ссылки на изображение + набор динамических аттрибутов.
Сущность ProductAttribute описывает свойство продукта, которое может быть чем угодно, например, на свойство мощность ссылаются холодильники и пылесосы, но не сковородки. Кроме того, описываем тип данных строка, число, и т.д. и такие метаданные как единица измерения, например, вольты, что в основном нужно для отображения.
Последняя сущность ProductAttributeValue содержит конкретное значение и ссылку на продукт которому оно принадлежит, иногда клиент хочет иметь диапазон и тогда таблица имеет два значения от и до.
Т.е. структура достаточно простая и эффективная и легко расширяется, до описанных задач. В принципе 50 000 товаров и особых проблем не испытываю + легко строить фильтры. Единственное, что пришлось перестроить мышление с традиционного подхода с наследованием и добавлением отличных свойств продукта в сторону более менее плоской структуры свойств и работы с ними как с массивом.
Хотелось бы спросить что вы думаете о таком подходе и какие подводные камни могут быть?
Сущность Product включает в себя общие свойства продукта вроде имени, цены, описания, ссылки на изображение + набор динамических аттрибутов.
Сущность ProductAttribute описывает свойство продукта, которое может быть чем угодно, например, на свойство мощность ссылаются холодильники и пылесосы, но не сковородки. Кроме того, описываем тип данных строка, число, и т.д. и такие метаданные как единица измерения, например, вольты, что в основном нужно для отображения.
Последняя сущность ProductAttributeValue содержит конкретное значение и ссылку на продукт которому оно принадлежит, иногда клиент хочет иметь диапазон и тогда таблица имеет два значения от и до.
Т.е. структура достаточно простая и эффективная и легко расширяется, до описанных задач. В принципе 50 000 товаров и особых проблем не испытываю + легко строить фильтры. Единственное, что пришлось перестроить мышление с традиционного подхода с наследованием и добавлением отличных свойств продукта в сторону более менее плоской структуры свойств и работы с ними как с массивом.
Хотелось бы спросить что вы думаете о таком подходе и какие подводные камни могут быть?
По-моему, с вашим подходом всё в порядке. Данных у вас, я так понимаю, не то чтобы очень много, поэтому запросы хоть и (относительно) тяжёлые, но могут кэшироваться.
Кстати, в Django обычно в таких случаях указывают свою модель для M2M, с дополнительными полями (то есть в данном случае многие товары связываются со многими атрибутами товаров, а конкретное значение задаётся как одно из дополнительных полей). Так получается удобнее с точки зрения интерфейса.
Для отображения, наверно, лучше указывать шаблон, а не единицу измерения. Потому что иногда может потребоваться, например, отображать число справа, а не слева. Опять же, в некоторых случаях оно отбивается пробелом, а в некоторых нет.
Но в целом я думаю, что если с вашим объёмом данных (тут, пожалуй, важно не только количество товаров, но и количество свойств) это работает достаточно быстро, то почему бы и нет. Хотя интереса ради можете попробовать посчитать, сколько уходит времени на обработку свойств и посмотреть, какие именно используются SQL-запросы. На основе этого обычно можно примерно прикинуть, какую нагрузку система сможет нормально выдержать (ну, а потом, в идеале, провести полноценное нагрузочное тестирование).
Кстати, в Django обычно в таких случаях указывают свою модель для M2M, с дополнительными полями (то есть в данном случае многие товары связываются со многими атрибутами товаров, а конкретное значение задаётся как одно из дополнительных полей). Так получается удобнее с точки зрения интерфейса.
Для отображения, наверно, лучше указывать шаблон, а не единицу измерения. Потому что иногда может потребоваться, например, отображать число справа, а не слева. Опять же, в некоторых случаях оно отбивается пробелом, а в некоторых нет.
Но в целом я думаю, что если с вашим объёмом данных (тут, пожалуй, важно не только количество товаров, но и количество свойств) это работает достаточно быстро, то почему бы и нет. Хотя интереса ради можете попробовать посчитать, сколько уходит времени на обработку свойств и посмотреть, какие именно используются SQL-запросы. На основе этого обычно можно примерно прикинуть, какую нагрузку система сможет нормально выдержать (ну, а потом, в идеале, провести полноценное нагрузочное тестирование).
По-моему, с вашим подходом всё в порядке. Данных у вас, я так понимаю, не то чтобы очень много, поэтому запросы хоть и (относительно) тяжёлые, но могут кэшироваться.
Да уж на BigData не перетендую. Кеширование поднял не сразу, так как без него работало приемлемо. Единственное, что тормозило это пересчёт количества товаров для каждой опции фильтра, но это решилось кешированием на уровне бд.
Для отображения, наверно, лучше указывать шаблон, а не единицу измерения. Потому что иногда может потребоваться, например, отображать число справа, а не слева. Опять же, в некоторых случаях оно отбивается пробелом, а в некоторых нет.
Шаблон уже выбирается в UI в зависимости от этой величины, культуры и задачи.
Но в целом я думаю, что если с вашим объёмом данных (тут, пожалуй, важно не только количество товаров, но и количество свойств) это работает достаточно быстро, то почему бы и нет. Хотя интереса ради можете попробовать посчитать, сколько уходит времени на обработку свойств и посмотреть, какие именно используются SQL-запросы. На основе этого обычно можно примерно прикинуть, какую нагрузку система сможет нормально выдержать (ну, а потом, в идеале, провести полноценное нагрузочное тестирование).
Магазин достаточно специфически и большая нагрузка не ожидается, но померить конечно нужно. В основном запросы оптимизировал, а в UI так чтобы уложиться в комфортное время загрузки для пользователя. Так что, мест где можно прооптимизировать достаточно.
Спасибо за ответ и статью.
(Возможно) при сравнении (нескольких) похожих продуктов (по нескольким параметрам) (при большом наборе товаров) вылезут тормоза.
Удобный e-commerce — это же сплошные фасеты. А они убьют любой ORM. Думаю самое логичное использовать «родные» для этих целей индексы (elasticsearch). Разобрать в режиме live 500к товаров по десятку группировок и фильтров — нет ничего проще и быстрее :)
Кстати по поводу django‑reversion-compare на офф. github расширения хранится старая версия, которая не работает с django 1.6, я нашел форкнутую версию с исправлением тут: github.com/Jbonnett/django-reversion-compare, правда ставить пришлось слегка коряво, заменяя папку reversion_compare в env/lib/python2.7/site-packages, после установки самого расширения через pip install django‑reversion-compare
P.S. Не судите строго, только начинаю работать с django
P.S. Не судите строго, только начинаю работать с django
Получается я могу установить pip install github.com/Jbonnett/django-reversion-compare?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пять вещей, которые нужно учесть, продумывая архитектуру интернет‑магазина