PHP & MySQL построение архитектуры динамических фильтров для интернет каталога

Question

[Igogo2012]

Добрый день!
У меня возникла потребность в написании модуля интернет каталога.
И в нем нужно учесть возможность присутствия динамических полей, на пример может быть каталог одежды и у него будут динамически созданы поля (пол, размер) или на пример каталог автомобилей с динамическими полями (год выпуска, пробег, объем двигателя), количество полей тоже динамическое. И нужно создать к этому добру возможность фильтрации и сортировки.
Может быть кто то сталкивался с такой задачей?
Подскажите как вы организовывали архитектуру базы данных так что бы была возможность сортировки и фильтрации данных по динамическим полям?

Comments

[EugeneOZ]

Исключительно MySQL? Такие задачи легче решать с нестрого структурированным коллекциями. Например, RethinkDB, MongoDB.

Answer 1

[Антон]

По-моему то, что вам нужно называется entity-attribute-value. Плюсы, минусы, критику и особенности реализации можно по этому словосочетанию поискать — написано много.
Личного опыта, к сожалению, нет.

Comments

[Sergey Cherepanov]

В Magento именно так каталог и реализован. Можно туда подсмотреть ;)

[Sergey Cherepanov]

Правда при большом обьеме данных будет тормозить как не крути :) поэтому придется думать над индексацией, крутить Sphinx например.

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

«Большой» это сколько и при запросах какого вида?

Имею на руках каталог в 500 разнотипных товаров, в среднем 20 свойств на товар, 200 тыс. товарных позиций более 2 миллионов значений свойств. Все фильтры динамические. Поиск по 10 характеристикам (значения как единичные скалярные, так и набор значений, так и диапазон) занимает порядка 50 мс. Для веб приложения это допустимая величина.

Так что не сказал бы, что это очень тормозная архитектура. Просто требует бОльшей «аккуратности». А минус её сказывается когда появляется желание копаться в ней ручками. Вместо простых запросов по нужным полям требуется городить join-ы дабы вытащить нужные атрибуты. В остальном все равно в итоге решает код самого приложения. Если через API можно получить все требуемые данные с нужной фильтрацией, то копаться в самой базе и не требуется.

[maxic]

В opencart тот же принцип, и по ним фильтр

Answer 2

[wscms]

Создаете таблицу attribute с полями attribute_id, attribute_name
В этой таблице только текстовая информация, то есть собственно «Год выпуска», «Пробег», «Объем двигателя» и так далее

Создаете таблицу attribute_to_product с полями
id, product_id, attribute_id, attribute_value

И джойнами склеиваете таблицу products с аттрибутами

Comments

[EugeneOZ]

Крайне не рекомендую этого делать. Для примера, почитайте истории разработчиков Magenta, как они сейчас уходят от EAV.

[wscms]

EugeneOZ, ссылку не подскажете?

[Sergey Cherepanov]

Никуда они не уходят, в каталоге оно так и остается. Ушли только в сущьнастях где нет динамических наборов атрибутов, типа Заказы, Корзины и тд.

Answer 3

[el777]

Как вариант можно рассмотреть PgSQL + hstore.
Система позволяет хранить в базе неструктурированные данные типа «хешей» и, самое главное, индексированно(!) по ним искать.
Делал пробный вариант, поиск по базе порядка 100К строк рандомных данных занимает около 100 мс.
Наврядли будет больше артикулов платьев или моделей авто.

Comments

[egorinsk]

100 мс — это много, это значит что скорее всего идет полный перебор таблицы.

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

Поддерживаю. 100 мс много. У меня EAV более чем на 2000К записей с фильтром по 10 характеристикам выдает 50 мс.

Кстати, учитывая pgsql. Надеюсь что pgbounser или любой другой пулер соединений работает? В pg установка соединения крайне «дорогая» операция которая легко может под себя откушать 20 мс.

[el777]

Немного напутал цифры, 100 мс — это без индекса, с индексом около 1-2 мс.

Answer 4

[S0mnium]

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

Answer 5

[Артем Спиридонов]

Если значения дискретные, можно сделать так.

Сначала все денормализовать до упора.

Группы товаров
— ID
— Название

Товары:
— ID
— Название

Свойства
— ID
— Группа товаров
— Название

Значения свойств
— ID
— ID свойства
— Значение

Значения свойств товара
— ID
— ID товара
— ID свойства
— ID значения свойства

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

— добавить к товарам сериализованные данные {Свойство: Значение свойства}
— добавить обработку сериализации при действиях: добавление, редактирование, отбражение

На этом этапе уже будет работать намного быстрее.

Теперь, если нужно сделать высоконагруженный сервис — добавить кеширующие индексы. Такие специальные таблицы:
— запрос
— сериализованный результат последней выборки
— флаг актуальности выборки

И добавить метод, пересчитывающий флаг актуальности выборки при добавлении и редактировании.

Если интерфейс навороченный, индексов должно быть столько же, сколько наворотов.

Двигайтесь последовательно, используйте SCRUM или хотя бы UML — тогда сделаете в течении дня.

Comments

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

Правда запросы будут жуткие — сложные и медленные.

Это из личного опыта, или теория?
Медленные это сколько и на каких запросах?
Что есть жуткие?

[Артем Спиридонов]

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

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

[Артем Спиридонов]

Да! В тексте попутал местами нормализацию и денормализацию!

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

customtema, хотелось бы услышать ответ на вопросы заданные мною выше.
«Ты мне мяса давай, мяса!» (с)

[Артем Спиридонов]

Отвечаю :)

Нормализация, денормализация, построение таблиц сущностей, связи «один ко многим», связи «многие ко многим» — это и из личного опыта, и из теории.

Медленные запросы — относительное понятие, зависящее от условий эксплуатации проекта и движка СУБД. Специфика вашего ТЗ мне неизвестна, но могу порекомендовать изучить проектирование СУБД. Это интересная тема. Если лень читать — есть много доступных видео. Например, в недавно упомянутым на хабре Лекториуме.

Жуткие — исключительно эмпирическое понятие, означающее нечто страшное, или вызывающее сильные чувства.

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

customtema, я о другом. Приходилось ли на практике реализовывать именно эту задачу? Т.е. указанную автором. Просто рассуждение о медленности запросов в ответе носит уж очень теоретический характер. Поэтому мне хотелось бы услышать конкретные цифры. Объем каталога, количество позиций, используемая РСУБД, фильтр и требуемое на выборку время. Чуть выше el777 писал о своем опыте и полученные цифры для веб приложения считаться медленными не могут.

[Артем Спиридонов]

Да. На сайте менее 1000 уников в день, поэтому до индексов я просто не дошел. Значения денормализованы прям в дизайне в таблице товаров, и три дополнительные таблицы (сущности параметров, значений параметров и связей многие-ко-многим) позволяют гибко редактировать и искать различными способами.

Точных данных по производительности под рукой нет. Визуально это был профайлер CodeIgniter-а, и время выполнения запросов на тестовой БД с 5000 товарами не превышало 100мс на ноутбуке Dell Latitude D600 (Pentium 3, 512 МБ ОЗУ...). На сервере все работает просто шикарно. ОС Debian Etch.