Альтернатива EAV, структура базы?

Question

[KLUBS]

Добрый день!


В интернет-магазине встает вопрос о дополнительных параметрах товаров. Параметров конечное число. Много типов товаров. Первое что приходит в голову — примерная архитектура EAV. В интернетах пишут что это плохо и альтернатива — для каждого типа товара создавать свою таблицу в базе.


Хотелось бы знать, чем же все таки это плохо. Реальные причины, а не вымышленные что «не тру». И посмотреть структуру базы, как с ней работать если сделать для каждого типа товара свою таблицу. Как показать например все товары в наличии. Или все товары красного цвета. Если есть несколько таблиц для каждого типа товара… Не могу придумать оптимальную схему.


Используется ms sql 2008.


И еще… Я изначально знаю все возможные параметры, т.е. будет 2 таблицы… Products и ProductsDescriptors в которой записано ProductID(int), DescriptorID(int), DescriptorValue(str). И знаю какой ID что подразумевает на этапе создания. Т.е. это не интернет-магазин для абстрактных товаров, а товары я знаю. Например DescriptorID=7 отвечает за цвет телевизора…

Comments

[shagguboy]

а чем ЕАВ не нравится?

[KLUBS]

А можно поподробнее как это применяется и строится?

[Сергей Протько]

После непродолжительного похода по гуглу в голову закралась мысль что EAB это лишь EAV в транслите.

Чем может не устраивать EAV? Производительность — единственная проблема.

[KLUBS]

а какая проблема с производительностью? еще 1 таблица для параметров продуктов…

[shagguboy]

простите производительность каких запросов вас не устраивает?

Answer 1

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

Структура базы. На тестах 250 тыс. товаров с 10 тыс. параметров (10 параметров на один товар) отрабатывает менее чем за 1 мс на posgresql, так что самым тормозным местом будет явно не база.

>Хотелось бы знать, чем же все таки это плохо.
Ни чего плохого в EAV нет. Если под текущий размер базы выделены достаточные аппаратные ресурсы и в базе в нормальном виде расставлены индексы, то самым тормозным местом будет явно не база. Так что «советчиков» которые без конкретных аргументов так говорят можно сразу спокойно слать лесом.

Comments

[EugeneOZ]

Что значит «отрабатывает»? Запрос кэшированный или нет? Сравнивалась ли скорость с выборкой из обычной таблицы? Больше подробностей, пожалуйста.
Я Вам по опыту заявляю, что EAV это монструозный тормоз. Да и в теории, после прослушивания курса www.db-class.org/course/auth/welcome я могу добавить, что EAV это извращение вообще над идеей реляционных баз данных. Если недостаточно моего мнения, то почитайте здесь: en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model#The_critical_role_of_metadata_in_EAV_systems или здесь: stackoverflow.com/questions/tagged/entity-attribute-value?sort=votes&pagesize=50 ну или погуглите и почитайте о том, как сейчас авторы Magento мечтают избавиться от выбранной ими EAV.

Автору я уже тоже отвечал и советовал более подходящие БД (Mongo) или лучше продумать структуру БД, но, видимо, не хочется телодвижений и хочется убедить себя вопреки здравому смыслу (который однозначно автор осязает, иначе не спрашивал бы).

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

«Отрабатывает» значит выполняет sql запрос.

=> SELECT COUNT(*) FROM goods;
 count
--------
 250000
(1 row)
=> SELECT COUNT(*) FROM goods_option;
 count
-------
 10000
(1 row)
=> SELECT COUNT(*) FROM goods_option_link;
  count
---------
 2500000
(1 row)

EXPLAIN ANALYZE показывает. что запрос получения карточки конкретного товара (у которого 10 параметров) занимает ~0.15 мс. PHP часть думает больше, чем запрос отрабатывается в postgresql-е.

Я всяких умных курсов не слушал. Я инженер и решаю конкретные задачи в конкретных условиях. Бизнес мало интересуют эти технические заморочки. Но представителям бизнеса хочется любое количество типов товара с любым набором характеристик и так, что бы при появлении нового типа не приходилось привлекать разработчиков которые буду что-то там колдовать в структуру таблиц. И конечно же это должно быстро и безбагово работать при увеличении каталога до миллиона позиций.
Вот и я решаю эти задачи. Поэтому у меня простой PHP движок которые держит поток в 300 запросов/сек с времени генерации страницы ~0,015 сек долговременно (т.е. ~25 миллионов в сутки). На отрезке в 5 секунд он мог обработать кратковременный всплеск нагрузки до 1000 запросов/сек с генерацией
страниц ~0.070 сек. При этом PHP часть потребляет менее 200 МБ ОЗУ. В целом же вся связка nginx+php-fpm+postgresql+redis кушает ~1-1,5 Гб.

Если завтра изменятся условия которые покажут, что EAV мне не подходит, я без проблем применю более оптимальную структуру. И уж точно я ни когда не буду религиозным фанатиком кричащим: %username%, твой %lang% гавно и %struct% монструозный монстр потому как я инженер и практик. И критерий адекватности для меня — эффективное выполнение поставлено задачи, а не абстрактные рассуждения теоретиков.

[EugeneOZ]

Рассмешили кодом запроса, спасибо. После такого с Вами не о чем спорить, извините.

[ztxn]

alekciy, вы продемонстрировали вырожденный случай EAV. В вашем случае понятие entity — вырождено т.к представленно обособленной таблицей. Подобные структуры называют UDA (user defined attributes) и, действительно, в них нет ничего страшного. В том смысле, что в этой модели еще можно использовать средства датабазы для контроля целостности, в отличии от классической EAV, где приходится целостность обеспечивать самостоятельно, а в условиях конкурентного доступа это вемьма и весьма не тривиальная задача, и решить ее эффективнее чем это делает СУБД для классической реляционной модели, порой, бывает просто невозможно.

Однако применимость такого подхода имеет ряд ограничений, в которые, вы, очевидно, вписываетесь. Но по вашему частному случаю, мне думается, рано обобщать. Действительно, получить карточку одного товара, используя данную струтуру не составляет проблемы. Но представить товарную иерархию в табличном виде это уже серьезная проблема, вам придется выполнить столько же джойнов, сколько атрибутов определено у сущности. Если вам нужно осуществлять отбор лишь по одному атрибуту или же по нескольким, применяя оператор OR к предикатам, то тоже проблем нет. Но если вам нужно отбирать по значениям нескольких атрибутов, к предикатам отбора применяя оператор AND, это становится весьма проблемотичным. Стоит так же отметить, что при таком подходе, определяемые пользователем атрибуты не могут быть использованы логикой приложения. Т.к. в жизненном цикле приложение код атрибута может быть изменен пользователем.

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

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

>Действительно, получить карточку одного товара, используя данную струтуру не составляет проблемы.
Иерархия в отдельной таблице в виде AL или NS по ситуации. Связь с товар-лист_дерева через треть таблицу. Это покрывает текущие бизнес требования. В частности поиск по конкретным атрибутам не требуется, для интернет магазина одежды логика поиска «хочу красную рубашку ХХ размера» обычно приводит к быстрой выборке рубашек с использованием индекса и более медленной, но в рамках приложения быстрой, фильтрации по значениям атрибутов. Это с лихвой перекрывает текущие требования причем с большим запасом. Если бы это был каталог компьютерного оборудования с частым поиском по набору атрибутов, то конечно же такая структура бы не использовалась.

За наводку на UDA спасибо.

Answer 2

[Сергей Протько]

Обычно для интернет-магазинов EAV структура приблизительно следующая:
Категория (* — *) Опция ( 1 — *) Значение ( * — 1 ) Продукт
Поиск товаров допустим реализуется через INNER JOIN и создает довольно большие накладные расходы. Это единственный, и довольно существенный минус этого подхода. Решается он использованием вьюх в базе данных, или же NoSQL решений. Так же есть варианты использовать фасеточный поиск, например через Sphinx. Но гибкость разработки как по мне довольно большой плюс.

В вашем случае, если реализовать ваш вариант с таблицей дескриптеров, получается такая структура:
Товар (* — *) Значение ( 1 — * ) Дескриптер.
Причем, если значения дескриптеров вам известны, то логично вынести это скажем в ENUM или еще как. По сути это не есть паттрен EAV, это просто одна из тех самых альтернатив.

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

Answer 3

[vladar]

Вообще, лучшая альтернатива EAV — schemaless-базы, тот же MongoDB, например. Другой вариант — использовать SQL (EAV или отдельные таблицы) + schemaless поисковик (например, elasticsearch).