rulinux.net - Форум - Web-development - EAV, сложные запросы.

Re:EAV, сложные запросы.

Wed, 20 Jun 2012 11:03:07 +0400

Это почему?

Re:EAV, сложные запросы.

Wed, 20 Jun 2012 09:02:21 +0400

>если у него проц загружен на 100%, и при этом львиную долю отъедает MySQL - то что в этом случае?
такого не может быть, чтобы mysql упиралась в проц а не в дисковые операции

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 17:08:47 +0400

> Если ничего не загружено на 100% то хз

Хорошо, а вот, допустим, если у него проц загружен на 100%, и при этом львиную долю отъедает MySQL - то что в этом случае?

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 16:55:43 +0400

>Деньги не пахнут же:)
Ну судя по всему тебе так обломятся такие же деньги как тем киргизам которые плитку кладут. Так зачем голову морочить если плитку класть проще и по деньгам столько же?

А не пахнут вот такие деньги http://sport.mail.ru/football2012/news/9320381 и за такие конечно голову понапрягать я бы согласился

>Мне интересно, что можно придумать именно в данных условиях.
серебряной пули нет. для начала хотя бы поставить профилировщики и посмотреть что грузится на 100%, проц или диск, или постоянный своп из-за 100% загрузки памяти, т.е. поискать бутылочное горло. Если ничего не загружено на 100% то хз, CMS же ты твикать не будешь, а как можно курочить базу сверху которой cms на php?

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 16:51:13 +0400

> известный отечественный php cms

Почитал что пишут о йом благодарные пользователи.. Отзывы какбэ намекают, что надо менять систему...

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 14:48:43 +0400

> по item_id, и по property_id, и по value

А по value_numeric и пр?

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 14:08:00 +0400

> Да, индексы есть.

Тогда, наверное, MySQL на свалку. Привёл бы хоть полный пример запроса штоле.

> Предусмотрели только мускуль и оракл.

Есть такая штука как Oracle for nischebrodes - если тебе не требуется хранить больше 11Гб данных, а для задачи хватает 1Гб памяти и одного ядра процессора - можно легально поставить его. Хотя что-то мне сдаётся, что к системе, которая работает и с мускулем и с ораклом, постгрес должен прикручиваться тоже как-то несложно.

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 13:52:55 +0400

> Странно это вообще обсуждать сейчас, спустя 10 лет после описываемых событий, когда время уже расставило всё по своим местам

Ничего странного))) Систем нашел древний артефакт, спросил как его распилить. Даем советы)))

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 13:50:01 +0400

>Индексы построены по полям, участвующим в критериях?
Да, индексы есть. И по item_id, и по property_id, и по value.

>И что мешает попробовать поднять это на постгресе? Разработчеги не предусмотрели абстракции от БД?
Предусмотрели только мускуль и оракл.

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 13:48:27 +0400

> Сначало это работало просто замечательно и красиво. Но со временем когда объектов набиралось от 5-10 тыщ всё это начинало жутко тормозить и ничего, ничего нельзя было с этим поделать. И дальше хуже и хуже. Как-то так)))

Мне кажется что разработчиков объектов не следует допускать к архитектуре хранилищ БД, не говоря уже о настройки их производительности. Во-первых все объектно-ориентированные программасты склонны верить в чудеса - например они почему-то все уверены, что скорость доступа к данным упирается не в скорость самого медленного устройства в компьютере каковым по праву считается дисковый накопитель, и не в их изуродованный разум, неспособный спроектировать нормально работающую, не дефективную by design систему, а в архитектуру той или иной реализации СУБД. Странно это вообще обсуждать сейчас, спустя 10 лет после описываемых событий, когда время уже расставило всё по своим местам и в продакшене сейчас везде нормально работает ОРМ над традиционной плоской архитектурой, а иерархические СУБД интересны лишь редким криворуким маргиналам.

> Я здесь я не понял "глубину вашей мысли" уважаемый анонимус)))

Я спросил в чём профит от перехода на плоские таблицы если рассматривать вопрос в отрыве от ~~фека~~ реалий MySQL.

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 13:41:15 +0400

> Я бы за такую работу не брался дешевле чем за $15000 в месяц после уплаты налогов.
ЕГЭ сдай сначала)))

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 13:38:19 +0400

>>говно в говне на говне и говном погоняет. а ты впрягаешься ассенизатором.
> Деньги не пахнут же:)

Систем я тебе удивляюсь, человек явно бредит, но ты всё равно пытаешься с ним беседовать)))

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 13:36:38 +0400

>> ОМГ! Это же еще в конце 90-х прокляли
> Кто проклял? Мускулевцы?

Все кто это пробовал, и я в том числе. Тогда модно было пережевывать за бутылочкой пива тему объектно-ориентирных БД, а ничего похожего на Монгу не было даже в проекте. И народ пробовал через такую схему замутить аля ООБД.

Сначало это работало просто замечательно и красиво. Но со временем когда объектов набиралось от 5-10 тыщ всё это начинало жутко тормозить и ничего, ничего нельзя было с этим поделать. И дальше хуже и хуже. Как-то так)))

>> втихаря перевести на плоские таблицы
> Не знаю как для мускуля, но с Т.З. нормальной БД - в чём профит??
Я здесь я не понял "глубину вашей мысли" уважаемый анонимус)))

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 13:32:46 +0400

Индексы построены по полям, участвующим в критериях? И что мешает попробовать поднять это на постгресе? Разработчеги не предусмотрели абстракции от БД?

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 13:32:03 +0400

>говно в говне на говне и говном погоняет. а ты впрягаешься ассенизатором.
Деньги не пахнут же:)

Я прекрасно понимаю всю эту ситуацию, однако это уже оффтоп. Мне интересно, что можно придумать именно в данных условиях.

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 13:30:10 +0400

>Давай определимся - ты можешь быстро найти ИД объекта(ов) по критерию или нет?
Не могу. У меня тормозят sql-запросы, в которых множество JOIN-ов, через которые я получаю список нужных товаров по данным критериям.

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 13:11:21 +0400

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

>"нет возможности"
нет возможности у них значит нет возможности и у нас. "нищим милостыню не подаю"(С)

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 13:07:24 +0400

>Какие есть варианты, кроме как доставать всю огромную кучу товаров простым запросом и заниматься фильтрацией в приложении?
есть вариант самому обратиться к авторам CMS. или перевести на них стрелки

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 13:04:59 +0400

>Для плоской таблицы нужно будет возиться с ALTER TABLE, а это тоже большой удар по производительности. Я встречал таблицы, где alter по 20 минут отрабатывал.
ох уж эти мне инженегры от сохи. Ты бредишь. У тебя или 15000 строк в номенклатуре или таблицы которые по 20 минут обрабатываются, ты уж определись. Таблица с 15000 строк даже на одном IDE жестком диске обрабатывается за 1,5 сек

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 12:52:22 +0400

>Это, естественно, не вариант, так как нужно, чтобы всё летало. Хардвар менять нельзя, БД менять нельзя, структуру портить нельзя (впрочем, можно добавить лишнюю таблицу, например), а скорость повысить нужно.
Уволься. Или убейся. Я бы за такую работу не брался дешевле чем за $15000 в месяц после уплаты налогов. А иначе пусть другого ассенизатора ищут

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 12:48:46 +0400

> Возможно. А разбирать товары на подходящие и неподходящие уже в приложении? Или как-то силами БД?

Минуточку, ты говорил, что у тебя тормоза с извлечение уже найденного объекта. Давай определимся - ты можешь быстро найти ИД объекта(ов) по критерию или нет?

> Я просто не очень знаю, можно ли через мускулевый xpath делать какие-нибудь запросы с типом, вроде x > value > y. Тут у меня в знаниях пробел.

А я даже не знаю есть ли в мускуле xpath.

Просто если у тебя идёт поиск объекта по значениям каких-то свойств, то по идее обычно можно построить индексы по тому, что ты ищешь, вплоть до full text search или что там в мускуле и играть чисто на индексах, без сквозного сканирования всех таблиц, участвующих в этом безобразии. А уже потом, когда идентификаторы объектов, извиняюсь за тавтологию, идентифицированы - тогда уже вытащить с диска только те блоки данных, которые содержат интересующие тебя данные. При этом индексы и данные лежат обычно на разных файловых системах, индексы помещаются в собственном кеше БД или ОС и удерживаются там дольше данных поскольку постоянно используются и как-то подразумевается, что тормоза возникают именно как ты сказал при извлечении объекта, при чём с мержем данных из множества таблиц. Нормальная БД всё это сделает в одном запросе, а про мускул у меня какие-то смутные подозрения.

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 12:35:24 +0400

> Не "нет желания", а "нет возможности".

Возможность есть всегда. Просто производительность системы не настолько важно для заказчика, чтобы тратиться на неё. Т.е. нет желания.

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

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

> Хуже того, возможность владельцу через админку стирать и добавлять свойства остаётся, так что хардкодить некоторые запросы тоже не так хорошо. Владелец же не имеет у себя придворного разработчика, который на каждый чих будет лазить в код и допиливать его под новую структуру.

Само по себе это, наверное, не проблема

> Предложи что-нибудь другое, кроме кучи JOIN-ов для данной схемы. Проблема ещё в том, что данный поиск - отнюдь не единственная задача всего приложения, и переделывать всю структуру, соответственно, нельзя. Тогда сломается всё остальное, и нет ресурсов, чтобы всё это чинить.

А я ебу что там в этом мускуле может работать эффективно, с использованием индексов? Я подозреваю он у тебя будет тормозить даже если ты его таблицы все целиком закешируешь. Чтобы профита добиццо, кеш должен быть умный, он должен кешировать объекты на уровне приложения, предоставляя параллельный доступ к ним разным сессиям, выполняющимся одновременно. Однако функциональность приложения анализировать всё равно придётся и, грубо говоря, заменять все компоненты.

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 12:20:57 +0400

>Храни в текстовом поле ХМЛ-ку с описанием всех свойств объекта и вытягивай только её.
Возможно. А разбирать товары на подходящие и неподходящие уже в приложении? Или как-то силами БД?

Я просто не очень знаю, можно ли через мускулевый xpath делать какие-нибудь запросы с типом, вроде x > value > y. Тут у меня в знаниях пробел.

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 12:15:23 +0400

>нет желания поставить нормальную БД, нет желания экстенсивно увеличить производительность системы за счёт апгрейда железа
Не "нет желания", а "нет возможности".

>нет желания выявлять паттерны использования системы
Проект, мягко говоря, низкобюджетный, так что заказывать маркетинговое исследование на тему "по каким параметрам пользователь будет чаще искать" никто не будет. На глаз - неясно. Хуже того, возможность владельцу через админку стирать и добавлять свойства остаётся, так что хардкодить некоторые запросы тоже не так хорошо. Владелец же не имеет у себя придворного разработчика, который на каждый чих будет лазить в код и допиливать его под новую структуру.

>и даже нет желания оптимизировать запросы вручную
Предложи что-нибудь другое, кроме кучи JOIN-ов для данной схемы. Проблема ещё в том, что данный поиск - отнюдь не единственная задача всего приложения, и переделывать всю структуру, соответственно, нельзя. Тогда сломается всё остальное, и нет ресурсов, чтобы всё это чинить.

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 12:07:26 +0400

> Тормоза именно на шаге получении объектов из БД с заданными свойствами, и этот шаг в обоих случаях будет.

Мы же тут вроде обсуждали, что мускуль работает с джойнами как последний пидорас. Храни в текстовом поле ХМЛ-ку с описанием всех свойств объекта и вытягивай только её.. Думаю будет быстрее.. Но это опять же противоречит нежеланию что-то менять ручками.

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 12:01:55 +0400

Ты извини, но всем требованиям удовлетворить ИМХО невозможно: нет желания выявлять паттерны использования системы, нет желания поставить нормальную БД, нет желания экстенсивно увеличить производительность системы за счёт апгрейда железа и даже нет желания оптимизировать запросы вручную (что, впрочем, бесполезно в виду нежелания 1).

> Или, всё же, что-то придумать с кэшем?

По-моему это противоречит нежеланиям 1 и 3.

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 11:56:53 +0400

> ОМГ! Это же еще в конце 90-х прокляли

Кто проклял? Мускулевцы?

> втихаря перевести на плоские таблицы

Не знаю как для мускуля, но с Т.З. нормальной БД - в чём профит??

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 11:22:37 +0400

>ОМГ! Это же еще в конце 90-х прокляли.
Видимо нету другого варианта хранить неизвестное заранее количество свойств в реляционной БД. Впрочем, от этого не легче.

>Или втихаря перевести на плоские таблицы
Там выходит по 500 колонок, меня такая вещь пугает. Проблема ещё в том, что EAV там не просто так, а потому что пользователь может мышкой через админку создать новое свойство, удалить старое и устраивать всякие преобразования. Для плоской таблицы нужно будет возиться с ALTER TABLE, а это тоже большой удар по производительности. Я встречал таблицы, где alter по 20 минут отрабатывал. Не вариант, увы.

>или на Монгу если не получится структурировать. Клиенты сказать, что это КЭШ))) А его структуру реплицировать по крону периодически)))
Похоже, что придётся что-то такое устраивать. Тоже не самый приятный вариант, так как владельцы сервера - совсем левые люди, которые очень медленно реагируют на просьбы, да и, наверное, не в курсе, как ставить mongodb. Но это уже другая история.

>Прочитал еще раз, не понял ты собираешься кэшировать запросы БД что ли? По моему надо готовые объекты кэшировать,
Я пока ничего не собираюсь, я только рассматриваю варианты:)

Можно кэшировать результаты запросов, это просто реализуется (уже есть, на самом деле), но их уж очень много. В смысле, можно кэшировать и SQL, и результаты запросов в виде объектов, но выходит примерно то же самое. Тормоза именно на шаге получении объектов из БД с заданными свойствами, и этот шаг в обоих случаях будет.

Можно кэшировать просто все объекты, да. Тогда у нас уже будет простой sql-запрос, но придётся уже в приложении разбираться, какой объект подходит под нужный критерий, какой - нет. Меня смущает перекладывание все работы по поиску на несчастный php. Будет огромный цикл c if-ами.

Re:EAV, сложные запросы.

Tue, 19 Jun 2012 10:59:36 +0400

> хранится по схеме entity-attribute-value (она же vertical database model)
ОМГ! Это же еще в конце 90-х прокляли. По моему только КЭШ. Или втихаря перевести на плоские таблицы или на Монгу если не получится структурировать. Клиенты сказать, что это КЭШ))) А его структуру реплицировать по крону периодически)))

Прочитал еще раз, не понял ты собираешься кэшировать запросы БД что ли? По моему надо готовые объекты кэшировать, ведь учитывая примененную схему, пытались объектно-ориентированную БД сэмулировать нее?

EAV, сложные запросы.

Tue, 19 Jun 2012 10:41:06 +0400

Есть 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 тысяч вариантов запросов только с этим свойством. И этих свойств много.

Какие есть варианты, кроме как доставать всю огромную кучу товаров простым запросом и заниматься фильтрацией в приложении? Или, всё же, что-то придумать с кэшем?