Уменьшение количества запросов при выводе тегов в списке

zerkms

TDD infected
Команда форума
В кэш у нас будут помещаться уже хорошие данные, готовые к использованию, а твой запрос вернёт полуфабрикат, который придётся ещё и группировать вручную. Так что не надо пенять на субд и кэш, коли сам выбираешь непонятно что.

В кэш нужно ложить то что нужно ложить, а не все выборки подряд, лишь бы закешировать.

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

Sad Spirit

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

В кэш нужно ложить то что нужно ложить, а не все выборки подряд, лишь бы закешировать.
в русском языке вообще ложить не нужно, нужно только класть.

Наверное именно поэтому в фейсбуке и нет джоинов (по их конференциям), что они не знают где оптимизировать, а просто денормализуют. Какие глупые, им бы тебя почитать.
99,99% посетителей этого форума не пишут и никогда не будут писать фейсбук. или ты считаешь, что решения, используемые в фейсбуке, надо без изменений применять к корпоративному сайту / интранету / всему остальному?
 

zerkms

TDD infected
Команда форума
Sad Spirit
Я не считаю, что их нужно бездумно применять. Я считаю, что в данном конкретном случае денормализация, которую я предложил, уместна, потому что она сильно сокращает дисковые чтения, убирает из запроса LEFT JOIN, уменьшает трафик на сеть при передаче данных (у тебя будет дублирование данных сущностей) и избавляет от необходимости реализации алгоритмов аггрегированая (в приложении: отборка данных сущности + её тегов, в цикле).

С твоим запросом как раз кэш субд (запросов) будет тратиться куда менее разумно, потому что для каждого из тегов будут продублированы данные сущности.

Этого недостаточно?
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Sad Spirit
Я не считаю, что их нужно бездумно применять. Я считаю, что в данном конкретном случае денормализация, которую я предложил, уместна, потому что она сильно сокращает дисковые чтения,
сокращает дисковые чтения за счёт хранения на диске второй копии информации? ну-ну.

убирает из запроса LEFT JOIN,
см. выше про железную голову.

уменьшает трафик на сеть при передаче данных (у тебя будет дублирование данных сущностей) и избавляет от необходимости реализации алгоритмов аггрегированая (в приложении: отборка данных сущности + её тегов, в цикле).
вот тут согласен, но можно процидурку написать или агрегировать при помощи какого-нить group_concat

С твоим запросом как раз кэш субд (запросов) будет тратиться куда менее разумно, потому что для каждого из тегов будут продублированы данные сущности.
у меня в СУБД нету кэша запросов, не написали: все силы на оптимизатор ушли. :`[
 

zerkms

TDD infected
Команда форума
сокращает дисковые чтения за счёт хранения на диске второй копии информации? ну-ну.
конечно сокращает. Операций выборки списка сущностей на сферическом ресурсе на порядок (если не больше) больше операций поиска по тегам.

см. выше про железную голову.
Не аргумент. Если можно не делать джоин - то зачем его делать?
 

phprus

Moderator
Команда форума
zerkms, Sad Spirit
Господа. Ваш спор напоминает спор слепого с немым.

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

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


А описанная ситуация где-то посередине. Писать большой и сложный запрос для обычного сайта не выгодно с точки зрения времени написания запроса. Реализовывать денормализованную схему тоже не выгодно, так как она увеличивает сложность кода, появляется риск несогласованного состояния данных. ИМХО в данном случае лучше написать несколько запросов попроще, а данные свести в скрипте.
 

Romancer

Новичок
Если вы не против, перелопатив свой код, я остановился на методе zerkms.
Для меня он будет самый оптимальный.
Спасибо ВСЕМ за советы, очень полезно было!
 
Сверху