Как правильно сделать выборку товаров по 100 параметрам (EAV)?

Question

[Александр]

Добрый день.
Дано: база товаров на 2 млн. строк.
Структура базы EAV
В таблице зависимостей названий характеристик и значений порядка 15 млн строк.
Задача - возможность все это как-то фильтровать, причем убирая заведомо тупиковые варианты в disable.
Делать сотни Select and and and - понимаю, что глупо, запихнуть все это в sphinx?
Может быть, просчитывать варианты заранее?
На хабре нашел такую вот статью https://habrahabr.ru/post/114113/ но из нее, к сожалению, особо ничего так и не понял.

Кто-нибудь сможет пояснить (разжевать)? либо подсказать еще варианты реализации задачи.
Спасибо.

Comments

[Максим]

Какая платформа? Не Magento случайно?

Answer 1

[Максим Тимофеев]

Не думаю, что эта статья решит все Ваши вопросы, но что бы понять ее надо вначале покурить тут:
http://ruhighload.com/post/Работа+с+индексами+в+MySQL
и тут:
https://habrahabr.ru/post/70640/

Answer 2

[Dmitry MiksIr]

Раз вам нужно убирать неподходящее в disable, то на реляционной базе, да еще с EAV - это будет ад, как по коду, так и по производительности.

Самое очевидное решение тут брать подходящие для этих задач решения, например, elasticsearch. Вот, например, статья про такой вариант https://blog.madewithlove.be/post/faceted-search-u...

Answer 3

[megorit]

Предлагается использовать битовые поля.
В один INTEGER ты упакуешь 32 BOOL. Это уже даст больше пользы, чем индексация.
INTEGER должен быть быстрее BIGINT. То есть будет несколько полей (4), вместо 100 с лишним.
Хранение набора чекбоксов в одном поле БД. Битовая...

Comments

[Dmitriy Ronzhin]

MySql не сможет использовать индекс при поиске. Если количество записей велико, то у Вас база просто упадет.

[megorit]

Dmitriy Ronzhin: MySQL поддерживает битовые операции, точно также как и Pure C. Для проверки поля/флага нужен битовый сдвиг и AND. Я таким не занимался, так что на счет производительности такой схемы не скажу. У MySQL самый маленький тип BOOL, который эквивалентен TINYINT(1), это 1 байт, в который можно упаковать 8 флагов, вместо одного.

[Dmitriy Ronzhin]

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

[megorit]

Dmitriy Ronzhin: А нафиг индексировать эти поля вообще? Тут запрос будет быстрее. Можно вместо того, чтобы делать условием SELECT'а 32 значения BOOL, одно INTEGER.

[Dmitriy Ronzhin]

Как зачем индексировать? Если запесей миллион, Вы хотите перебрать их все? Индекс помог бы это избежать, но тут его не получиться применить, т.к. требуются дополнительные вычисления

[megorit]

Dmitriy Ronzhin: На самом деле не так уж это много. Да и само это решение уже довольно сильно ускоряет поиск.

[Dmitriy Ronzhin]

Человек уже хринит данные с помощью Eav. Ему охота ускорить выборку, а не делать хранение проще. Для фасетного поиска лучше использовать специальные поиск. Движки или хотя бы добавить дополнительную что бы не плодить 100 JOINов design-pattern.ru/patterns/single-table-inheritanc...

Answer 4

[Dmitriy Ronzhin]

На мой взгляд, ускорение поиска нужно делать через денормализацию: или собирать индекс в отдельную таблицу или делать индекс чрез sphinx\elasticsearch. Обновлять индекс по крону или программно (при сохранении модели, к примеру)