Вход • Регистрация

Всего найдено: 10

  • 24 октября 2014 г.
  • На сайте http://delta.spectr-site.ru/katalog-nedvizhimosti/, делаем поиск по каталогу с большим набором параметров.
    Проблема в том что при таком поиске ответ сервера составляет от 1 до 15 секунд, это связано видимо с большим кол-во объединяемых таблиц.
    Кто нибудь сталкивался с похожей ситуацией и если да то как решалась проблема?

    Один из вариантов увеличить мощность сервера, но я с таким первый раз столкнулся и хотелось бы узнать поможет ли это или же надо оптимизировать запросы к бд.
  •
  • 24 октября 2014 г.
  • Клиент скорее всего одобрит аренду не очень жирного сервера за 3-4т.р в месяц, но боюсь и этого может не хватить так как добавится ещё поиск по карте. Есть идея заменить часть характеристик на записи в таблице shop и сортировать напрямую по ней, тогда SQL должен получится легче, но занятие это уж больно долгое.

    PS. Спасибо за оценку) Да, все элементы работают на JS.
  • 24 октября 2014 г.
  • Огромное спасибо за совет!
    Попробую на нём развернутся. Но с поиском хочется и другое решение найти.
    Не каждый клиент хочет платить такие суммы за железо, а использовать на другие CMS из-за одного только поиска не хочется.

    Нет. Сам написал на JQuery, там же ничего сложного=)
    1. Для селектов(3 типа) 50-70 строчек примерно на каждый их вид.
    2. С чекбоксами/кнопками строчек 20.
    3. Функция, которая из html структуры делает ползунок.
    4. 6 табов для 6 видов поиска
    Всего не более 400-500 строк + JQuery UI для ползунков.

    Вот собственно и всё.
  •
  • 24 октября 2014 г. , редакция: 1414169819
  • Спасибо за совет. Попробую. А запрос сложный всего 1, тот что генерирует выборку, как раз таки по причинам большого кол-ва объединений таблиц как это подробно описал Dmitry (weissfl).

    И возникает вопрос сильно ли помогут при такой проблеме индексы и я правильно понимаю что индексировать следует SHOP_PARAM_ELEMENT и SHOP?
  •
  • 24 октября 2014 г. , редакция: 1414172407
  • Цитата
    Есть идея заменить часть характеристик на записи в таблице shop и сортировать напрямую по ней, тогда SQL должен получится легче, но занятие это уж больно долгое.

    Цитата
    - по итогу это получается самое правильное решения, для снижения ресурсоемкости фильтрации. Ну либо надо больше мощных серверов.


    С простыми типами данных(числа, галочки, строки) всё просто.
    Вопрос как реализовать селекты и мультиселекты?
    Ведь именно они дают наибольшую нагрузку БД.
  • 26 октября 2014 г. , редакция: 1414306437
  • Хм. В результате два варианта.
    1. Вынос большей части параметров в таблицу shop.
    2. VPS c SSD.

    Спасибо за подробную информацию(последовал совету и поглядел на запрос и как происходит выборка).

    Ну и возникает вопрос. Как выводить select? В документации не нашёл примеров.
    А хранить думаю можно в виде ENUM.
  •
  • 26 октября 2014 г.
  • Вынос на VPS за 900р в месяц не помог. Вот тариф https://hosting.reg.ru/vps/ssd
    Буду переносить характеристики в таблицу SHOP. Это серьёзно снижает нагрузку на БД(по 30-50мс снижается за один параметр в сложных запросах).
  •
  • 26 октября 2014 г. , редакция: 1414323229
  • Индексы для основных таблиц используемых в выборке(shop и shop_param_element) включены.
    Проблема не в количестве товаров, а в кол-ве INNER JOIN. Если их уменьшить в 3 раза запросы начинают летать, без всяких SSD.

    Вот такой запрос на обычном хостинге обрабатывается, 58 секунд.
    Код

    SELECT DISTINCT s.id FROM `diafan_shop` AS s INNER JOIN `diafan_shop_price` AS pr ON pr.good_id=s.id AND pr.trash='0' AND pr.date_start<=1414321401 AND (pr.date_start=0 OR pr.date_finish>=1414321401) AND pr.currency_id=0 AND pr.role_id=0 AND (pr.person='0') INNER JOIN `diafan_shop_param_element` AS pe24 ON pe24.element_id=s.id AND pe24.param_id='24' AND pe24.trash='0' AND pe24.value1='1' INNER JOIN `diafan_shop_param_element` AS pe2 ON pe2.element_id=s.id AND pe2.param_id='2' AND pe2.trash='0' AND pe2.value1 IN (1) INNER JOIN `diafan_shop_param_element` AS pe28 ON pe28.element_id=s.id AND pe28.param_id='28' AND pe28.trash='0' AND pe28.value1<=420 INNER JOIN `diafan_shop_param_element` AS pe9 ON pe9.element_id=s.id AND pe9.param_id='9' AND pe9.trash='0' AND pe9.value1<=100 INNER JOIN `diafan_shop_param_element` AS pe10 ON pe10.element_id=s.id AND pe10.param_id='10' AND pe10.trash='0' AND pe10.value1<=200 INNER JOIN `diafan_shop_param_element` AS pe11 ON pe11.element_id=s.id AND pe11.param_id='11' AND pe11.trash='0' AND pe11.value1<=200 INNER JOIN `diafan_shop_param_element` AS pe12 ON pe12.element_id=s.id AND pe12.param_id='12' AND pe12.trash='0' AND pe12.value1<=100 INNER JOIN `diafan_shop_param_element` AS pe14 ON pe14.element_id=s.id AND pe14.param_id='14' AND pe14.trash='0' AND pe14.value1<=100 INNER JOIN `diafan_shop_param_element` AS pe15 ON pe15.element_id=s.id AND pe15.param_id='15' AND pe15.trash='0' AND pe15.value1<=100 WHERE s.act1='1' AND s.trash='0' AND (s.access='0') AND s.site_id=4 AND s.date_start<=1414357140 AND (s.date_finish=0 OR s.date_finish>=1414357140) GROUP BY s.id, pr.price_id HAVING MIN(ROUND(pr.price))>=3000000 AND MIN(pr.price)<=50000000


    В итоге проблема в запросах функций:
    list_search_query_count и list_search. Которые отчасти дублируют.

Новости

  • Вышла очередная сборка DIAFAN.CMS 7.2.2
  • 18 июня
  • В сборке большое обновление demo-шаблона, дополнительная защита от спама, улучшение YML-импорта и еще много важного и интересного.
  • Не пропустите сборку DIAFAN.CMS 7.1.4
  • 24 апреля
  • В новой сборке совершили революцию в структурировании кастомизированной информации в шаблонах, добавили авторегистрацию пользователей, усовершенствовали защиту от спама, актуализировали накопительную скидку, а также улучшили производительность и стабильность работы системы.
  • Сборка DIAFAN.CMS 7.1.3
  • 12 января
  • После выхода сборки 7.1 мы выпустили уже три патча, в каждом из которых улучшаем административную часть сайта. Сборка DIAFAN.CMS 7.1.3 уже доступна к установке. 
Все новости

Форум

Перейти на форум