Форум Пользователи Пыхослёт
новые сообщения ответы на мои сообщения избранное скрытые темы случайный топик открыть всё в новых вкладках

Форум → Разработка → Базы данных → еавэ

еавэ

  • kostyl

    Сообщения: 5210 Репутация: N Группа: Джедаи

    Spritz 30 декабря 2010 г. 1:10

    Короче я пишу для того, что бы знатоки работы мускула ёбнули краем глаза, так скажем, а если затестили бы сами, то вообще бы было идеально.
    Есть у нас такая мега супер хрень как EAV. Объяснять не буду, но кратко скажу, что есть таблица объектов, таблица описания свойств объектов и таблица в которой хранятся значения свойств объектов. При поиске по значениям свойств объектов, тобишь по последней таблице в EAV есть одна хуйня. В лучшем случае - сколько критериев поиска - столько добавляется в запрос конструкций типа LEFT JOIN. Например:
    LEFT JOIN objvals ov ON (ov.object_id = o.id AND ov.prop_id = 4)

    И так для каждого свойства по которому идёт поиск.
    Такие запросы могут сильно нагружать мускул и он может отваливаться нафиг так что скрипт и в кешь ничего не успевает положить.
    Посему у меня ряд вопросов к вышеупомянутым гражданам.
    1. Как лучше поставить индексы?
    2. Какой движок таблиц лучше юзать?
    3. Так как это поиск то вполне нормально могут прибавиться SQL_CALC_FOUND_ROWS и LIMIT. Может надо разбивать на два запроса где один с count() или как то обойтись без лимита.
    4. На сколько SQL_CALC_FOUND_ROWS и LIMIT грузят мускул в данном случае, может виноваты они или один из них, а не куча LEFT JOIN?

    Заранее благодарю

  • Абырвалг

    Сообщения: 6480 Репутация: N Группа: Джедаи

    Spritz 30 декабря 2010 г. 2:03, спустя 52 минуты 50 секунд

    так, я твою тему не читал еще, но тут в РСС пришла какая-то ссылка про еавэ (ее я тоже еще не читал)
    http://xobb.citylance.biz/2010/12/eav/

    эвот

  • Абырвалг

    Сообщения: 6480 Репутация: N Группа: Джедаи

    Spritz 30 декабря 2010 г. 2:24, спустя 21 минуту 52 секунды

    так эта, кодогенерация вам в помощь. На основе вашей EAV-модели генерируйте flat-таблицы

  • kostyl

    Сообщения: 5210 Репутация: N Группа: Джедаи

    Spritz 30 декабря 2010 г. 10:44, спустя 8 часов 19 минут 40 секунд

    Абырвалг, ты не читал, что я спрашиваю да? ))

  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 30 декабря 2010 г. 11:07, спустя 22 минуты 49 секунд

    kostyl, запомни, что JOIN = foreach() {тут был код без жойна), соответственно каждый жойн обворачивает сложность еще в форич.

    calc found rows - на сложных выборках часто зло, особенное зло когда резльтатов получаются десятки и сотни тысяч.
    Спустя 76 сек.
    ибо на псевдокоде он работает так

    create tamporary table 'temp_found_rows_table_xxx';
    select …. INTO TABLE temp_found_rows_table_xxxx;

    return select count(*) from temp_found_rows_table_xxx; drop temporary table …._xxxx;
    Спустя 54 сек.
    исли результатов больше, чем max_temp_table_size, то это дело начинает свопиться на диск, если запросов паралельно много - пизда файловой подсистеме и все зависает к хуям нахуй в итоге
    Сапожник без сапог

  • kostyl

    Сообщения: 5210 Репутация: N Группа: Джедаи

    Spritz 30 декабря 2010 г. 11:20, спустя 13 минут 35 секунд

    phpdude, ну хоть что то, спасибо, буду знат про calc found rows.. джоины это я шарю.. там надо индексы грамотно поставить…

  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 30 декабря 2010 г. 11:24, спустя 3 минуты 22 секунды

    грамотно поставить

    слова "очень" не хватает в фразе)
    Сапожник без сапог

  • AlexB

    Сообщения: 4306 Репутация: N Группа: в ухо

    Spritz 30 декабря 2010 г. 11:30, спустя 5 минут 50 секунд


    kostyl, запомни, что JOIN = foreach() {тут был код без жойна), соответственно каждый жойн обворачивает сложность еще в форич.

    Вот здесь я не соглашусь даже с самим великим дудом. Индекс по полю, по котрому осуществляется JOIN сводит трудоемкость "приджоивания" практически к нулю, если например во второй таблице это поле тоже имеет индекс (а чаще всего это так и бывает т.к. чаще всего оно primary key). Оно и понятно, базе не надо делать полный foreach, она подсоединит уже известные строки из второй таблицы.

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

  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 30 декабря 2010 г. 11:31, спустя 1 минуту 31 секунду

    AlexB, я не говорил что он его не использует :-)

    я говорил что это еще один форич, и это так в любом случае, вопрос только в сложности форича.

    при жойне даже по индексу можно вылезти за рамки join buffer size и тогда это уже будет "обычный" форич, проверено :)
    Сапожник без сапог

  • AlexB

    Сообщения: 4306 Репутация: N Группа: в ухо

    Spritz 30 декабря 2010 г. 11:42, спустя 10 минут 36 секунд


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


    при жойне даже по индексу можно вылезти за рамки join buffer size и тогда это уже будет "обычный" форич, проверено :)
    Можно, но скорее всего это означает либо косяк кода, либо то, что маштабы проекта не соответствуют скромному хостингу с его скромными настройками мускула. И тут уже ничем не поможешь…

  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 30 декабря 2010 г. 11:55, спустя 12 минут 55 секунд

    И тут уже ничем не поможешь…

    ну это спорно =) но это уже нетривиальная задача.

    я не говорил бояться жойнов, я говорил что кодогенерация жойнов может плохо сказаться на результате и все :)

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

  • kostyl

    Сообщения: 5210 Репутация: N Группа: Джедаи

    Spritz 30 декабря 2010 г. 12:00, спустя 5 минут 29 секунд

    хитростей работы с limit

    чё за хитрости?

  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 30 декабря 2010 г. 12:03, спустя 3 минуты

    kostyl, сам научишься, а то мне скоро рассказывать нечего будет :D
    Спустя 21 сек.
    должен же я травить байки то :D

    зы: 15999
    Сапожник без сапог

  • AlexB

    Сообщения: 4306 Репутация: N Группа: в ухо

    Spritz 30 декабря 2010 г. 12:35, спустя 31 минуту 36 секунд


    хитростей работы с limit

    чё за хитрости?
    Даю подсказку: Поищи по форуму, 100% обсуждали, как постраничное разбиение лучше делать ..

  • kostyl

    Сообщения: 5210 Репутация: N Группа: Джедаи

    Spritz 30 декабря 2010 г. 13:21, спустя 46 минут 17 секунд

    AlexB, ну мыж недавно говорили об этом вроде же..

Пожалуйста, авторизуйтесь, чтобы написать комментарий!

наше все Форум Пользователи Пыхослёт Slack Тикеты
социализация
(ц) пыха.ру / с 2007 года         Total: 0.009s         Часовой пояс — Europe/Moscow
ПИПИСЬКА