Лучший Ответ SmetDenis , 10 June 2014 - 20:07
Доброго времени суток.
Прощу прощения за долгий ответ, занимаюсь новой версией.
1. Скорость работы фильтра не зависит от настройки тизеров.
Как понимаю, скорость фильтра - это непосредственно скорость поиска, т.е сопутствующих запросов в БД.
Если у вас одновременно на странице выводится несколько десятков (а то и сотен) тизеров, тогда конечно, вывести данные напрямую из объекта материала будет быстрее, минуя проверку полей на доступ и рендеры шаблонов самих элементов.
Тут можно выиграть только если используются заведомо сложные элементы (цена, например), где нужно не просто вывести значение, а еще вычислить что-нибудь и показать виджет итд.
2. Если говорить о поиске, то опять же зависит от того, по каким полям вы ищите, какой поиск и какого рода данные там хранятся. Лучше смотреть на конкретные примеры. Однозначно нельзя сказать. Запросы в базу собираются динамически + умеют частично и эффективно кешироваться на уровне MySQL.
Вот несколько мыслей по поводу.
- MySQL оперативнее ищет по числам (т.е если мы используем диапазон), нежели по тексту.
- Точный поиск всегда работает быстрее полнотекстового.
- Поиск по textarea - самый медленный (причин много).
- Если вы ищите по категориям и у вас используется множественная привязка одного материал ко многих (и таких привязок оооочень много), то это снижает скорость. Например, у нас 100 категорий и 2000 материалов. Максимально привязано все ко всему. Получается, что 2000 * 100 ~ 200 000 будет участвовать в запросе. Но я лично не представляю логическое обоснование таким сайтам =)
- 300 категорий - это много только для человека. MySQL легко орудует тысячами записями. Для него это рутина и бытовуха =).
- Множественные поля конечно усложняют поиск, но не критично. Конечно если у вас на одно поле не приходится 10+ значений и подобных полей в материале 5-10. Т.е получается что на 1 материал индекс будет хранить как минимум 5-10 записей.
- Большое количество полей в одно материале проявится после ~20-30 штук (считаю только те, которые содержат полезные данные для поиска). Просто в этом случае можно упереться в некоторые ограничения MySQL. Не критично и зависит от пунктов выше.
- Количество приложений и типов сильной роли не играет, т.к на уровне базы данных типы имеют физически разные таблицы, а каталоги - это простейшее индексируемое поле.
Для больших сайтов (например, 20 000 +) можно для оптимизации
- отключить проверку даты публикаций и проверку на доступ к группе пользователя. Это частично ускорит выборки.
- отключить индексирование textarea (если по нему не ищите). Это уменьшит объем базы данных.
----
В силу невероятно глупых мнений о базах данных их размерах и кол-ве запросов в популярных очерках незадачливых, не побоюсь этого слова, "web-мастеров" - у людей складываются не правильные понятия о принципе работы баз данных.
Скажу вам как человек, который делал даже такие вещи как автодополнение на лету по 8 миллионной базе весом в 35Гб. Все зависит от конкретного запроса и индексов. Можно сделать 300 запросов, при этом сайт будет грузится 0,5 сек или 10 запросов в туже саму базы за теми же данными, но уже все будет тормозить в 5 секунд.
Поэтому лучше рассматривать конкретные примеры.
PS Ну и конечно, хоть и 100 000 материалов загрузить можно и нужно только терпение, но сразу скажу - будет тормозить. Чудес не бывает. Примерно с таких объемов начинаются индивидуальные разработки.
PSS Надеюсь ответил на ваше небольшое тестирование =)
Перейти к сообщению 
Тема закрыта
