Полная Версия: Перекрестный запрос с Count и группировкой
| Цитата (depp @ 8.04.2016 - 11:41) |
| откуда эта информация у вас? |
Из личного опыта.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
| Цитата (twin @ 8.04.2016 - 15:19) |
| Из личного опыта. |
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
_____________
Стимулятор ~yoomoney - 41001303250491
Хорошо, не из личного. Пруфы искать лень, да и особо без надобности. Тут нужно просто включить логику и немного анализа.
Есть такая штука - memcached. Её очень часто применят для кэширования запросов. И очень редко, в исключительных случаях наоборот. Так какое место тоньше?
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Есть такая штука - memcached. Её очень часто применят для кэширования запросов. И очень редко, в исключительных случаях наоборот. Так какое место тоньше?
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
| Цитата (twin @ 8.04.2016 - 17:22) |
| memcached. Её очень часто применят для кэширования запросо |
это у вас тоже из личного опыта?
twin некомпетентен, для вас это стало открытием?
| Цитата (depp @ 8.04.2016 - 13:36) |
| это у вас тоже из личного опыта? |
Это логика. Логика с опытом не имеет ничего общего.
Ну хорошо, не хотите логики, поищем пруфы. Хотя все пруфы тоже основаны на чьем то личном опыте и логических заключениях. Не понятно, чем мой не устраивает.
Вот раз.
Вот два.
Вот три
Вот ликбез
Дальше сами гуглите.
Везде стараются снять нагрузку с сервера БД.
А теперь покажите ме систему или хотя бы схему, где вопросы оптимизации решаются путем переноса нагрузки на сторону СУБД.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
twin, нагрузка с БД снимается путём денормализации, оптимизации индексов, самих запросов и настроек сервера. Дальше масштабирование.
Мемкашу, ты вообще не в тему приплёл учитывая что кеширование и на стороне БД есть.
Мемкашу, ты вообще не в тему приплёл
учитывая что кеширование и на стороне БД есть.| Цитата (twin @ 8.04.2016 - 17:04) |
| А теперь покажите ме систему или хотя бы схему, где вопросы оптимизации решаются путем переноса нагрузки на сторону СУБД. |
это когда 50-100 строк логики на РНР заменяется одним запросом...
увеличивается ли нагрузка на БД? ну может быть, и то не факт, а вот нагрузка всего проекта уменьшается однозначно, тут и к бабке не ходи.
Всё упирается в нежелание читать книги
_____________
Стимулятор ~yoomoney - 41001303250491
Я не про оптимизацию базы говорю. А об оптимизации всей системы.
А если масштабирование невозможно? Допустим это шаред.
Представь ситуацию, что ты полностью исчерпал возможности СУБД. Индексы расставил, запросы оптимизировал (тут как раз и идет речь об оптимизации запросов кстати), а все равно сервак на пределе. И внутренний кэш не справляется. Что нужно делать? Симать нагрузку. Один из популярных способов - как раз мемкэш. Так что приплел я как раз правильно.
Я спросил, почему так? Покажи мне случай, когда нужно кэшировать результаты работы PHP, а не СУБД. Пусть там останутся те же запросы на пределе, а нагрузка снимется путем кэширования вычислений скриптов.
А если масштабирование невозможно? Допустим это шаред.
Представь ситуацию, что ты полностью исчерпал возможности СУБД. Индексы расставил, запросы оптимизировал (тут как раз и идет речь об оптимизации запросов кстати), а все равно сервак на пределе. И внутренний кэш не справляется. Что нужно делать? Симать нагрузку. Один из популярных способов - как раз мемкэш. Так что приплел я как раз правильно.
Я спросил, почему так? Покажи мне случай, когда нужно кэшировать результаты работы PHP, а не СУБД. Пусть там останутся те же запросы на пределе, а нагрузка снимется путем кэширования вычислений скриптов.
| Цитата (Valick @ 8.04.2016 - 14:55) |
| это когда 50-100 строк логики на РНР заменяется одним запросом... |
Опять же вернемся к моему опыту. Он есть, я больше 5 лет на хайлоад проекте работаю. Как только появляется тяжелый запрос, так сразу начинают выть админы. Ни разу за это время мне не предъявили за скрипты. Больше скажу. Мне даже приходилось эмулировать JOIN на PHP и собирать там результаты двух атомарных запросов. Потому что один сложный сожрал дохрена ресурса СУБД. А на стороне PHP эта хрень работает до сих пор, не вызывая никаких вопросов.
| Цитата (Valick @ 8.04.2016 - 14:55) |
| Всё упирается в нежелание читать книги |
В книгах не всегда есть ответы на все вопросы. На многие приходится искать ответ, набивая собственные шишки.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
| Цитата (twin @ 8.04.2016 - 19:10) |
| Допустим это шаред. |
| Цитата (twin @ 8.04.2016 - 19:10) |
| Один из популярных способов - как раз мемкэш. |
| Цитата (twin @ 8.04.2016 - 19:10) |
| я больше 5 лет на хайлоад проекте работаю |
вы это серьезно?
| Цитата (depp @ 8.04.2016 - 15:19) |
| вы это серьезно? |
Что именно? Эти три фразы не имеют общей подоплеки.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
| Цитата (twin @ 8.04.2016 - 18:10) |
| Потому что один сложный сожрал дохрена ресурса СУБД. А на стороне PHP эта хрень работает до сих пор, не вызывая никаких вопросов. |
Мне лично это говорит о том что у вас нет нормального специалиста по БД
Это всё лишь борьба с последствиями, мне лично гораздо интереснее побороть причину.
| Цитата (twin @ 8.04.2016 - 18:10) |
| В книгах не всегда есть ответы на все вопросы. |
В книгах есть информация, которая позволяет не создавать себе проблем и не искать ненужные ответы набивая себе шишки.
Касательно данной темы, не надо никаких голословных заявлений. Есть БД, есть данные в БД, есть запрос который обрабатывает эти данные.
_____________
Стимулятор ~yoomoney - 41001303250491
| Цитата (Valick @ 8.04.2016 - 16:00) |
| Мне лично это говорит о том что у вас нет нормального специалиста по БД |
А мне это говорит, что ты работу под нагрузками знаешь только в теории.
| Цитата |
| В теории, теория и практика неразделимы. На практике это не так. © Yoggi Berra |
| Цитата (Valick @ 8.04.2016 - 16:00) |
| Это всё лишь борьба с последствиями, мне лично гораздо интереснее побороть причину. |
Как раз наоборот. Масштабирование - крайняя мера. Борьба с последствиями. Если есть хоть какая то возможность его избежать, нужно это сделать. То есть побороть причину.
Если один запрос выполняется долго, а будучи разделенным на два - быстро, то ничего страшного, что PHP отработает чуть дольше. Он как трактор, ему всё нипочем. А вот оптимальность запросов - притча воязыцах.
Вот тебе задачка. Побори, раз интересно.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
twin, у вас достаточно высокий уровень bad practice
| Цитата (depp @ 8.04.2016 - 20:26) |
| twin, у вас достаточно высокий уровень bad practice |
откуда эта информация у вас?
_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
| Цитата (depp @ 8.04.2016 - 16:26) |
| twin, у вас достаточно высокий уровень bad practice |
Удивил
Я это часто слышу от людей с шаблонным мышлением. Вчера вот даже статью написал по этому поводу.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Здесь расположена полная версия этой страницы.