Можно ли обойтись без Entity-Attribute-Value?

Question

[Frank]

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

Тот же Magento Commerce для этих целей использует EAV структуру, из-за которой селект-запросы сильно усложняются и работают не очень быстро. Пока единственная мысль — периодически преобразовывать EAV в нормальную таблицу, из которой и будут идти выборки. Есть ли более эффективный способ в рамках MySQL или PostgreSQL?

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

Answer 1

[TimTowdy]

Проблема EAV в том, что каждое поле лежит независимо от объекта. Т.е. выборка 10-ти объектов, из 10-ти полей, сделает около 100 random seek. Варианты решения:
1. Memory таблицы — быстрый random seek, ограниченный размер и необходимость синхронизации с реальными данными.
2. Sphinx и ему подобные. Дополнительно храним данные в формате, более удобном для фасеточного поиска.
3. nosql — легче масштабировать, данные зачастую хранятся в памяти, отсутствие схемы, но при этом с возможностью создания индексов по полям.

Comments

[Frank]

Может вы в курсе, будет ли nosql работать быстрее, чем EAV? И вообще какой из предложенных вами способов быстрее в поиске по атрибутам хотя бы чисто теоретически?

[TimTowdy]

Всё зависит от конкретной nosql и конкретных данных. В большинстве случаев, будет как минимум не медленнее.
Если нужна гарантированная скорость — посмотрите в сторону фасеточного поиска с помощью Sphinx или Lucene/Solr. Реализация будет не самой удобной (хотя возможно уже есть какие-нибудь красивые обёртки), но скорость — на порядок выше. Но учтите, что поиск в этом случае делается по заранее заданным диапазонам — запрос вида «цена от 42.34$ до 123.45$» сделать не получится.

[DmitrySytkov]

сделает около 100 random seek

Странное утверждение. Если взять тот же MySQL, то выборка у вас будет, например, после одного прохода по каждой из 2ух таблиц (Сущность и Атрибут) с индексами. Т.е. 100 полей за 2 прохода по индексам.

[DmitrySytkov]

отсутствие схемы, но при этом с возможностью создания индексов по полям

Зависит от СУБД. Где-то можно.

Answer 2

[dkomanov]

Можно попробовать вариант с entity, у которого есть: идентификатор, общие поля (типа стоимости и наличия), поле для поиска (конкатенированные значения атрибутов через дикий разделитель) и поле с XML (или любой другой формат), в котором будет храниться вся информация.

Comments

[Frank]

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

[dkomanov]

Кстати, если количество атрибутов ограничено, то можно сделать таблицу entity (id, num_attr_1, num_attr_2, str_attr_1, str_attr_2 etc.). Все столбцы nullable. Хранить отдельно схему (тип сущности).