Как обойти множество JOIN в EAV ?

Question

[nepster-web]

Задача разработать фильтр поиска товаров по типу яндекс.маркет.
Как пример, это фильтр поиска по кондиционерам: market.yandex.ua/guru.xml?CMD=-RR%3D5%2C0%2C0%2C0-...

в предыдущем своем вопросе я узнал про EAV структуру, почитал понял все минусы и плюсы. Еще я видел множество рекомендаций в сторону mongodb и sphinx. Я хочу попробовать скомбинировать это дело таким образом, чтобы избавиться от множество джоинов и связывающих таблиц в mysql.

Если следовать EAV, у нас есть следующие таблицы: Товары, Категории, Атребуты, Значение Атрибутов, Свзязь Товар Категория, Связь Товар Атрибуты, Связь Атрибут Значение.

В результате чего, если к примеру мы находимся в разделе Кондиционеры и нужно показать все кондиционеры цена которых от 1000 до 5000, производителя Самсунг и с Сенсором Движения.

Тоесть запрос будет примерно такой:

SELECT * FROM Товары
JOIN Категории WHERE Кондиционеры
JOIN  Связь Товар Атрибуты
JOIN Связь Атрибут Значение WHERE цена AND самсунг AND Сенсором Движения

Возможно джоинов будет даже больше. Все бы ничего, но на большой базе это будет печально. А товары будут заполняться быстро их будет много.

Я бы хотел убрать таблицы связей и оставить только следующие:
- Товары
- Категории
- Атрибуты
- Значения

Теперь собственно вопрос в котором я запутался, как можно использовать mongodb и sphinx для поиска товаров ?

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

Также я не как не могу понять для чего нужен sphinx. Тоесть везде описывают что это крутой поисковой движок, у меня всегда складывалось впечатление, что это крутой аналог LIKE. Собственно подходит ли он для заметы JOIN ?

Answer 1

[alexandre108]

Хорошее описание варианта с Mongodb
habrahabr.ru/post/259219/#73

Answer 2

[Назар Мокринский]

У вас реляционные данные, использовать для этого нужно реляционную БД (которой являются MySQL, PostgreSQL и многие другие), но никак не MongoDB.
Если вас не смущает 3-5 JOIN (не должны) - то используйте. У меня в одном проекте было около 8-10 JOIN, при правильном составлении запросов и кэшировании скорость в несколько милисекунд (около 10 в среднем, в зависимости от запроса) считаю приемлемой.

Comments

[FanatPHP]

Не 3-5, а 3-5 ДЕСЯТКОВ джойнов. И я бы поостререгся называть EAV реляционной структурой.

[iliyaisd]

FanatPHP: в таком случае можно создать кеш, который обновлять скажем раз в неделю, только с подставленными данными. С любым noSQL вам будет очень неудобно, хотя на редисе я такое делал - просто ищем нужный ID зависимых данных и подставляем.

[FanatPHP]

iliyaisd: какой кэш?

[iliyaisd]

FanatPHP: с подставленными уже нужными данными, которые подтягивались джойнами.

[FanatPHP]

iliyaisd: В КАКОМ ФОРМАТЕ КЭШ? Что с ним потом делать? Как использовать?

[iliyaisd]

FanatPHP: просто дополнительная таблица бд, из которой можносделать выборку по какому-то основному ид, с уже подставленными зависимыми данными. Он генерируется раз в сколько-то там.

[FanatPHP]

iliyaisd: Пойми, ты несешь какой-то бред. Если бы такая таблица в принципе была возможна, ТО В НЕЙ БЫ СРАЗУ И ХРАНИЛИ. У тебя в голове облака и фантазии. Ты не понимаешь, о чем идет речь, и сыпешь бессмысленными фразами. Попробуй сначала представить себе эту таблицу. Ко всему прочему, таблица с выборкой по айди не нужна. Она и так есть. Ты не можешь даже понять вопрос, который не про поиск по айди, а про поиск по параметрам.

[iliyaisd]

FanatPHP: вы сюда пришли вопрос обсудить или кислотой в окружающих поплеваться? Наверное это я не выдумал на ходу, а описал то, как реально использовалось на моей практике. Если у нас очень много данных и очень много зависимых таблиц (требующих кучу джойнов), то вполне нормально подготовить временную таблицу - кэш, в которую положить уже приджойненные выборки. Это почти как использовать представление, только данные уже готовые, их не надо джойнить на лету, это быстро работает. При этом можно оставить 3-4 нужных поля, содержащие айди (а не значения), по которым можно сделать выборку. А можно вообще все айди хранить в этой же таблице, если нужно делать выборку по всему. Именно это автор и хочет сделать, но с точки зрения хранения это неправильно. Поэтому такие кеши генерируются по правильно хранимым данным раз в какое-то время - например, каждую ночь, когда нагрузка минимальна.

[FanatPHP]

iliyaisd: ты просто услышал пару знакомых слов и пришел рассказывать о своем опыте. Ты мне доказываешь про свой опыт, что это работает. Всё это хорошо, но только твой "опыт" НИКАКОГО ОТНОШЕНИЯ к данному вопросу не имеет. Здесь проблема совсем не в количестве зависимых таблиц и джойнов. ЕЩЕ РАЗ: здесь проблема не в том что много данных, а в том, что они РАЗ-НО-РОД-НЫ-Е! И если бы можно было их поместить в одну талицу, то вопроса вообще бы не было. Не говоря уже о том, что сами по себе джойны не представляют проблемы, и кэшировать их не нужно - и твоой кэш легко заменятеся БД, спроектированной не кривыми руками.

[nepster-web]

я думал о таблице с кешем, но мне эта идея кажется сомнительной. Тоесть таблица с миллиардами записей и комбинациями товара и фильтров, которая обновляется каждую ночью, ну как-то стремно. Возможно для 90 годов это было не плохое решение, но я не верю и не хочу верить, что это хороший вариант.

На практике, если кто-то добавит товар или изменит товар, то скажем в том-же поиске изменения пройдут, аж ночью. Возможно такое, что после этого времени, это уже никому не нужно.

Answer 3

[FanatPHP]

1. Монга как раз решает проблему таблицы связей. Собственно, потому ее тебе и рекомендуют, что она решает ту самую задачу, что ты сейчас описал - избавляет от связей. В ней можно тупо писать "цвет: красный, обогрев: есть, минимальная температура охлаждения: 16" - вот примерно так запрос и выглядит, в виде JSON. Но тут могут быть проблемы с индексами (индексируемых полей тысячи, столько индексов не напасешься), а перебором много не наищешь.

2. И тут приходит на помощь свинкс.
Самый тупой вариант - генерировать т е к с т. Сфинкс же полнотекстовый поиск? Ну вот и нагенерировать текст, такой же, как я выше написал, в котором перечислены все параметры. Ищет замечательно. Для более продвинутых вариантов гуглить sphinx faceted search

Comments

[nepster-web]

FanatPHP А подскажи пожалуйста если я буду использовать mongodb для хранения фильтов товаров, то можно будет работать без костылей с сфинксом (так как таблиц связей в основной базе не будет) ?

[FanatPHP]

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

[nepster-web]

FanatPHP

В смысле в монго дб хранить что-то такое:

"_id" : ObjectId(),
"item_id" : int,
"country_id" : int,
"city_id" : int,
"category_id" : int,
"attributes" : [int, int, int...]

Выборку делать из монго, например вот так:
{country_id: 1, services: {$all: [10, 20]}}

Получать коллекцию и по item_id уже делать запрос и получать товар из основной базы. Тоесть 0 джоинов. Получается сфинкс для фильтров товаров тут вообще не нужен.

Но теперь задача сделать так, что если я пишу Черный Айфон, выборка должна пройти и показать все черные айфоны (А этого добра будет много, так как поиск проходит по базе магазинов).
А как я понял, то в сфинкс нужно забивать запрос, который индексируется, а так как у нас нет таблиц связей в основной базе, то тут я и запутася собственно.

[FanatPHP]

я не понимаю, зачем в монге хранить что-то такое

[nepster-web]

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

[FanatPHP]

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

[nepster-web]

FanatPHP:
я пытаюсь вот эту статью понять:
habrahabr.ru/post/186572

[FanatPHP]

Ну так и в статье в монге хранятся сами товары. Делать запрос и получать сразу товар.