|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
Добрый день, Уважаемые! Скажите пожалуйста, если есть запросы, которые сами по себе формируют большой набор данных, но для одного и того же входного параметра, то можно не сильно заботиться в приложении и запрашивать каждый раз этот SQL запрос? Поясню, запросы дёргаются такого типа: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Будет ли такой тип запросов эффективно кешироваться сервером MariaDB 10.3, всё на InnoDB. Т.е. как я понимаю - запрос должен напрягать сервер только в случае изменения данных в участвующих в запросе таблицах? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2019, 11:35 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
kormotСкажите пожалуйста, если есть запросы, которые сами по себе формируют большой набор данных, но для одного и того же входного параметра, то можно не сильно заботиться в приложении и запрашивать каждый раз этот SQL запрос? Не понял. Запросы "для одного и того же входного параметра" -- это один и тот же запрос, много раз выполняющийся? Или разные ? Если один -- конечно его не надо 200 раз выполнять. Поясню, запросы дёргаются такого типа: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
kormot ...... И так далее несколько блоков с разным количеством JOIN-ов, и вложенных подзапросов во всяких IN..() и NOT IN () но везде в качестве дискриминатора идёт ${idxID}. Ну это вообще разные запросы (части одного запроса) и они вообще никак друг с другом не связаны. kormotБудет ли такой тип запросов эффективно кешироваться сервером MariaDB 10.3, всё на InnoDB. Кэшироваться будут данные для запроса. На сколько эффективно -- сказать невозможно. kormotТ.е. как я понимаю - запрос должен напрягать сервер только в случае изменения данных в участвующих в запросе таблицах? Нет, не только. Будет "напрягать" в любом случае. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2019, 16:08 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
MasterZivНе понял. Запросы "для одного и того же входного параметра" -- это один и тот же запрос, много раз выполняющийся? Или разные ? Если один -- конечно его не надо 200 раз выполнять. Допустим запрашивается информация по такому-то товару. И соответственно по этому товару чтобы загрузить и "Общую информацию" и "Последние комментарии" и "Последние цены" и прочее прочее выполняются не 3+ отдельно запроса типа Код: sql 1. 2. 3. 4.
а один "мета запрос" с полем-дискриминатором, по которому уже данные разбираются в нужном месте Код: sql 1. 2. 3. 4.
Где единственный параметр в запросе который может быть передан - это идентификатор товара. MasterZivНу это вообще разные запросы (части одного запроса) и они вообще никак друг с другом не связаны. kormotБудет ли такой тип запросов эффективно кешироваться сервером MariaDB 10.3, всё на InnoDB. Кэшироваться будут данные для запроса. На сколько эффективно -- сказать невозможно. А кеш запросов, если запрос будет один и тот же и без использования функций препятствующих его кешированию? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2019, 16:55 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
kormotДопустим запрашивается информация по такому-то товару. И соответственно по этому товару чтобы загрузить и "Общую информацию" и "Последние комментарии" и "Последние цены" и прочее прочее выполняются не 3+ отдельно запроса а один "мета запрос" с полем-дискриминатором, по которому уже данные разбираются в нужном месте Тем самым ты создаёшь серверу геморрой при разборке своего мега-запроса, а себе - при разборке его результатов. Это военная логика, секретная. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2019, 17:06 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovТем самым ты создаёшь серверу геморрой при разборке своего мега-запроса, а себе - при разборке его результатов. Это военная логика, секретная. Т.е. несколько мелких запросов эффективней, чем один склееный? Проведу сегодня/завтра измерения производительности, такого варианта и такого. Это интересно. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2019, 17:09 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
В итоге тесты провёл. Получение данных одним UNION ALL'ом порядка 20% быстрей чем отдельными SELECT'ами. На всякий случай вот как всё это смоделировал: В таблицах Tab_A и Tab_B по 50 000 строк, в таблице Tab_AB порядка 62000. Код: php 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104.
... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2019, 21:40 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
kormotВ итоге тесты провёл. Получение данных одним UNION ALL'ом порядка 20% быстрей чем отдельными SELECT'ами. В одном коннекте. Без параметров вообще. Ню-ню... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2019, 21:45 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovВ одном коннекте. Без параметров вообще. Ню-ню... Ну как без параметров то? Именно что сначала до начала замеров, получаются 50 случайных idx_A и затем для каждого из этих элементов вызываются запросы. В них фигурирует как раз в каждом только $idxA как внешний параметр. А то, что в одном коннекте, так тут мы же скорость запросов измеряем и проверка идёт что один составной запрос медленнее чем несколько простых. Тут именно исключаются накладные расходы всякие посторонние, которые негативно если б и влияли, то на отдельные SELECT'ы. Так что некорректность если некоторая и имеется в тесте, то она один хер в пользу отдельных SELECT'ов, а они на 20% медленней оказываются. Вот результат, причём на другом компе с другой осью и инсталляцией LAMP'а вместо FAMP'а. Код: sql 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 07:31 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
kormotТ.е. несколько мелких запросов эффективней, чем один склееный? Какой критерий эффективности? Иными словами, эффективнее для кого и как? Больше пакетов по сети кидать - больше расходы по времени уйдут на сеть. То есть надо понимать, что в другой ситуации результаты могут быть прямо противоположные. В Вашем случае вообще может быть выгоднее вытащить наружу a1.id, а в where написать не a1.id=${idxID}, а a1.id in (...) сразу для всех 50 параметров. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 08:38 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
Сергей ВаскецовkormotТ.е. несколько мелких запросов эффективней, чем один склееный? Какой критерий эффективности? Иными словами, эффективнее для кого и как? Больше пакетов по сети кидать - больше расходы по времени уйдут на сеть. То есть надо понимать, что в другой ситуации результаты могут быть прямо противоположные. В Вашем случае вообще может быть выгоднее вытащить наружу a1.id, а в where написать не a1.id=${idxID}, а a1.id in (...) сразу для всех 50 параметров. Так тут же чисто синтетический и примитивный тест. Доставать в IN() все 50 значений незачем, это же для теста симулировалось выполнение для 50 разных аргументов просто запросы. А критерий вполне очевиден, по описанному в 1 сообщении приницпу что эффективней (меньше время выполнения SQL запроса и последующий разбор результата в приложении). Сформировать 1 большой запрос для получения всей смежной информации или всю смежную информацию получать отдельными запросами. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 08:43 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
Ну как Вам ещё объяснить... Попробуйте выполнить одновременно 1000 таких тестов с 1000 разных клиентов. Время фиксируйте по максимальному времени среди всех, то есть, по худшему качеству обслуживания. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 08:46 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
Да, чего-то я всё же не могу понять. Сергей, скажите пожалуйста что именно вы хотите сказать? Что этот тест ничего не показывает или что при реальном и серьёзном по нагрузке использовании UNION ALL будет медленней чем много-SELECT вариант? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 08:52 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
Я хочу до Вас донести, что этот тест показывает результаты только в той ситуации, в которой Вы его проводите. В других ситуациях могут быть совершенно иные результаты. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 08:54 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
Может быть, но пока то что можно померить - говорит о вполне однозначной картине. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 09:06 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
kormotНу как без параметров то? Совершенно без параметров. Вы формируете 50 разных запросов вместо использования одного, параметризированного. Или 150 разных запросов вместо трёх. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 12:44 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovСовершенно без параметров. Вы формируете 50 разных запросов вместо использования одного, параметризированного. Или 150 разных запросов вместо трёх. И вот только после нескольких внимательных прочтений этого комментария, и подавления в себе мысли что Дмитрий просто говорит что-то не в тему, я наконец открыл для себя что такое параметризованные или подготовленные запросы. Жесть конечно, за 20-ть то лет общения с PHP и MYSQL можно было бы и знать уже :) Спасибо Дмитрий! ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 12:54 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
А для тестирования и всё же в качестве более эффективному использованию в стартовом вопросе топика не подходит. Параметризованные запросы эффективны же для многократного исполнения одного и того же запроса с параметром, в рамках одного сеанса. А я в начальном вопросе же спрашивал - при загрузке странички как лучше запрашивать все данные по какой-либо сущности. Этот запросы (с UNION ALL'ом) или запросы (с SELECT'ами) должны выполниться по одному разу. Только получить данные и распихать их по внутренним структурам приложения. И тест соответственно для тестирования такой же модели использования, и подготовленные выражения может для теста внутренней эффективности движка для двух вариантов запроса сравнил бы (сделаю сегодня такой тест), но в случае именно однократной необходимости в получении информации - выгоды нивелируются скорей всего подготовкой запросов. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 13:06 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
kormotв случае именно однократной необходимости в получении информации - выгоды нивелируются скорей всего подготовкой запросов. Если только сервер не кэширует подготовленные запросы между сессиями. Именно в этом плане я прочитал сабж. А о каком кэшировании думал ты, когда его писал? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 13:21 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovЕсли только сервер не кэширует подготовленные запросы между сессиями. Именно в этом плане я прочитал сабж. А о каком кэшировании думал ты, когда его писал? Я думал о таком кешировании, что если для одного и того же аргумента (напр. для одного и того же товара) запрашивается Код: sql 1.
, и результат конкретно этого запроса кешируется (до момента пока в какой-либо из составляющих его таблиц не меняются данные). Я думал так кеш запросов работает. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 18:20 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
kormotЯ думал так кеш запросов работает. Нет, так работает кэш резалт-сетов. И я понятия не имею есть ли он в Марии. Но даже в этом случае кэширование трёх маленьких резалт-сетов не отличается от кэширования одного большого. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 18:23 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovЕсли только сервер не кэширует подготовленные запросы между сессиями. К сожалению не кеширует. Мария по крайней мере: Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 18:49 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
kormotThe scope of a prepared statementis the session within which itis created. Это не о том. Лучше тебе идти в специализированный отдел форума. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 19:19 |
|
Эффективность запросе в плане кеширования
|
|||
---|---|---|---|
#18+
а что запросы не в функции чтоли? функции автоматом кэшируются, им только параметры подсовывай kormotДопустим запрашивается информация по такому-то товару. И соответственно по этому товару чтобы загрузить и "Общую информацию" и "Последние комментарии" и "Последние цены" и прочее прочее выполняются не 3+ отдельно запроса типа а один "мета запрос" с полем-дискриминатором, по которому уже данные разбираются в нужном месте это всё бабкины грабли максимальная скорость тут: сделайте агрегацию всех своих запросов в одну отдельную таблицу (вот этот самый запрос (а лучше 3), только на заднем плане) в таблице будут все нужные данные безо всяких лишних телодвижений вот и дёргайте из неё по ID, что вам там надо дёргать. каждую минуту дописывайте в неё данные либо чаще либо вообще MATERIALIZED VIEW замутите в real-time (они сложнее) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 22:33 |
|
|
start [/forum/topic.php?fid=32&msg=39872705&tid=1539903]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
53ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
65ms |
get tp. blocked users: |
2ms |
others: | 14ms |
total: | 182ms |
0 / 0 |