anonymous@RULINUX.NET~# | Last login: 2024-11-14 08:45:24 |
Регистрация Вход | Новости | Разметка | Пользователи | Галерея | Форум | Статьи | Неподтвержденное | Трекер | Правила форума | F.A.Q. | Ссылки | Поиск |
Форум - Web-development | [RSS] |
Есть MySQL, один известный отечественный php cms, в базе хранится каталог товаров, товаров ~15к штук. Всё это счастье хранится по схеме entity-attribute-value (она же vertical database model), то есть есть таблица для товаров, таблица для свойств и таблица для значений этих свойств.
То есть (названия упрощены для читабельности):
items -- id, name, date_created, ...
properties -- id, type, name, sort, ....
property_values -- id, item_id, property_id, value, value_numeric, ...
Свойств дохренища (суммарно - примерно 600), но у конкретного типа товара примерно 50. Типов много, свойства для разных типов пересекаются.
И по всему этому аду оказалось нужно делать поиск по свойствам, поиск делается пользователем, угадать его намерения невозможно. ORM для запроса по десятку свойств генерит десяток JOIN-ов, что выглядит очень забавно, и выполянется по 10 секунд. Это, естественно, не вариант, так как нужно, чтобы всё летало. Хардвар менять нельзя, БД менять нельзя, структуру портить нельзя (впрочем, можно добавить лишнюю таблицу, например), а скорость повысить нужно. Вручную делать тоже не очень, т.к. ничего кроме JOIN-ов в голову не приходит.
Кэшировать все запросы заранее не так просто, т.к. некоторые свойства - числовые. Например, с диапазоном от 1 до 30000. Соответственно, может быть 30 тысяч вариантов запросов только с этим свойством. И этих свойств много.
Какие есть варианты, кроме как доставать всю огромную кучу товаров простым запросом и заниматься фильтрацией в приложении? Или, всё же, что-то придумать с кэшем?
SystemV(*) (2012-06-19 14:41:06)
Отредактировано SystemV по причине "не указана"
Emacs-w3m/1.4.468 w3m/0.5.3
|
|
|
Скрыть
Re:EAV, сложные запросы.>ОМГ! Это же еще в конце 90-х прокляли.
|
Скрыть
Re:EAV, сложные запросы.> ОМГ! Это же еще в конце 90-х прокляли
|
Скрыть
Re:EAV, сложные запросы.Ты извини, но всем требованиям удовлетворить ИМХО невозможно: нет желания выявлять паттерны использования системы, нет желания поставить нормальную БД, нет желания экстенсивно увеличить производительность системы за счёт апгрейда железа и даже нет желания оптимизировать запросы вручную (что, впрочем, бесполезно в виду нежелания 1).
|
Скрыть
Re:EAV, сложные запросы.> Тормоза именно на шаге получении объектов из БД с заданными свойствами, и этот шаг в обоих случаях будет.
|
Скрыть
Re:EAV, сложные запросы.>нет желания поставить нормальную БД, нет желания экстенсивно увеличить производительность системы за счёт апгрейда железа
|
Скрыть
Re:EAV, сложные запросы.>Храни в текстовом поле ХМЛ-ку с описанием всех свойств объекта и вытягивай только её.
|
Скрыть
Re:EAV, сложные запросы.> Не "нет желания", а "нет возможности".
|
Скрыть
Re:EAV, сложные запросы.> Возможно. А разбирать товары на подходящие и неподходящие уже в приложении? Или как-то силами БД?
|
Скрыть
Re:EAV, сложные запросы.>Это, естественно, не вариант, так как нужно, чтобы всё летало. Хардвар менять нельзя, БД менять нельзя, структуру портить нельзя (впрочем, можно добавить лишнюю таблицу, например), а скорость повысить нужно.
|
Скрыть
Re:EAV, сложные запросы.>Для плоской таблицы нужно будет возиться с ALTER TABLE, а это тоже большой удар по производительности. Я встречал таблицы, где alter по 20 минут отрабатывал.
|
Скрыть
Re:EAV, сложные запросы.>Какие есть варианты, кроме как доставать всю огромную кучу товаров простым запросом и заниматься фильтрацией в приложении?
|
Скрыть
Re:EAV, сложные запросы.>"нет возможности". Проект, мягко говоря, низкобюджетный, Владелец же не имеет у себя придворного разработчика, который на каждый чих будет лазить в код и допиливать его под новую структуру. Тогда сломается всё остальное, и нет ресурсов, чтобы всё это чинить.
|
Скрыть
Re:EAV, сложные запросы.>Давай определимся - ты можешь быстро найти ИД объекта(ов) по критерию или нет?
|
Скрыть
Re:EAV, сложные запросы.>говно в говне на говне и говном погоняет. а ты впрягаешься ассенизатором.
|
Скрыть
Re:EAV, сложные запросы.Индексы построены по полям, участвующим в критериях? И что мешает попробовать поднять это на постгресе? Разработчеги не предусмотрели абстракции от БД? |
Скрыть
Re:EAV, сложные запросы.>> ОМГ! Это же еще в конце 90-х прокляли
Ax-Xa-Xa(*)(2012-06-19 17:36:38)
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5 |
Скрыть
Re:EAV, сложные запросы.>>говно в говне на говне и говном погоняет. а ты впрягаешься ассенизатором.
Ax-Xa-Xa(*)(2012-06-19 17:38:19)
Отредактировано Ax-Xa-Xa по причине "не указана" Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5 |
Скрыть
Re:EAV, сложные запросы.> Сначало это работало просто замечательно и красиво. Но со временем когда объектов набиралось от 5-10 тыщ всё это начинало жутко тормозить и ничего, ничего нельзя было с этим поделать. И дальше хуже и хуже. Как-то так)))
|
Скрыть
Re:EAV, сложные запросы.>Индексы построены по полям, участвующим в критериях?
|
Скрыть
Re:EAV, сложные запросы.> Странно это вообще обсуждать сейчас, спустя 10 лет после описываемых событий, когда время уже расставило всё по своим местам
Ax-Xa-Xa(*)(2012-06-19 17:52:55)
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5 |
Скрыть
Re:EAV, сложные запросы.> Да, индексы есть.
|
Скрыть
Re:EAV, сложные запросы.> известный отечественный php cms
|
Скрыть
Re:EAV, сложные запросы.>Деньги не пахнут же:)
|
Скрыть
Re:EAV, сложные запросы.> Если ничего не загружено на 100% то хз
|
Скрыть
Re:EAV, сложные запросы.>если у него проц загружен на 100%, и при этом львиную долю отъедает MySQL - то что в этом случае?
|
|
|
|
Этот тред читают 7 пользователей: |
Анонимных: 7 Зарегистрированных: 0 |
Re:EAV, сложные запросы.
> хранится по схеме entity-attribute-value (она же vertical database model)
ОМГ! Это же еще в конце 90-х прокляли. По моему только КЭШ. Или втихаря перевести на плоские таблицы или на Монгу если не получится структурировать. Клиенты сказать, что это КЭШ))) А его структуру реплицировать по крону периодически)))
Прочитал еще раз, не понял ты собираешься кэшировать запросы БД что ли? По моему надо готовые объекты кэшировать, ведь учитывая примененную схему, пытались объектно-ориентированную БД сэмулировать нее?
Отредактировано Ax-Xa-Xa по причине "не указана"
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5