powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Эффективность запросе в плане кеширования
24 сообщений из 24, страница 1 из 1
Эффективность запросе в плане кеширования
    #39871034
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добрый день, Уважаемые!

Скажите пожалуйста, если есть запросы, которые сами по себе формируют большой набор данных, но для одного и того же входного параметра, то можно не сильно заботиться в приложении и запрашивать каждый раз этот SQL запрос?

Поясню, запросы дёргаются такого типа:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
$idxID   = (int) ${Аргумент Запроса}
  SELECT  1 p1, a1.id p1, a1.isActive p2, "" p3, "" p4, "" p5 
  FROM    Tab_A   a1
  WHERE   a1.id=${idxID}
UNION ALL 
  SELECT  2 p1, c2.id p1, c2.isActive p2, c2.objB_Name p3, "" p4, "" p5 
  FROM    Tab_A   a2
  JOIN    Tab_AB  b2 ON b2.idx_A=a2.id
  JOIN    Tab_B   c2 ON c2.id=b2.idx_B
  WHERE   a2.id=${idxID}
UNION ALL 
...... И так далее несколько блоков с разным количеством JOIN-ов, и вложенных подзапросов во всяких IN..() и NOT IN () но везде в качестве дискриминатора идёт ${idxID}. 


Будет ли такой тип запросов эффективно кешироваться сервером MariaDB 10.3, всё на InnoDB. Т.е. как я понимаю - запрос должен напрягать сервер только в случае изменения данных в участвующих в запросе таблицах?
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39872705
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormotСкажите пожалуйста, если есть запросы, которые сами по себе формируют большой набор данных, но для одного и того же входного параметра, то можно не сильно заботиться в приложении и запрашивать каждый раз этот SQL запрос?


Не понял. Запросы "для одного и того же входного параметра" -- это один и тот же запрос, много раз выполняющийся?
Или разные ?

Если один -- конечно его не надо 200 раз выполнять.




Поясню, запросы дёргаются такого типа:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
  SELECT  1 p1, a1.id p1, a1.isActive p2, "" p3, "" p4, "" p5 
  FROM    Tab_A   a1
  WHERE   a1.id=${idxID}
UNION ALL 
  SELECT  2 p1, c2.id p1, c2.isActive p2, c2.objB_Name p3, "" p4, "" p5 
  FROM    Tab_A   a2
  JOIN    Tab_AB  b2 ON b2.idx_A=a2.id
  JOIN    Tab_B   c2 ON c2.id=b2.idx_B
  WHERE   a2.id=${idxID}
UNION ALL 



kormot
...... И так далее несколько блоков с разным количеством JOIN-ов, и вложенных подзапросов во всяких IN..() и NOT IN () но везде в качестве дискриминатора идёт ${idxID}.



Ну это вообще разные запросы (части одного запроса) и они вообще никак друг с другом не связаны.

kormotБудет ли такой тип запросов эффективно кешироваться сервером MariaDB 10.3, всё на InnoDB.


Кэшироваться будут данные для запроса. На сколько эффективно -- сказать невозможно.

kormotТ.е. как я понимаю - запрос должен напрягать сервер только в случае изменения данных в участвующих в запросе таблицах?

Нет, не только. Будет "напрягать" в любом случае.
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39872758
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivНе понял. Запросы "для одного и того же входного параметра" -- это один и тот же запрос, много раз выполняющийся?
Или разные ?

Если один -- конечно его не надо 200 раз выполнять.

Допустим запрашивается информация по такому-то товару. И соответственно по этому товару чтобы загрузить и "Общую информацию" и "Последние комментарии" и "Последние цены" и прочее прочее выполняются не 3+ отдельно запроса типа
Код: sql
1.
2.
3.
4.
$sql1 = 'SELECT ...'; //Запрос только общей информации
$sql2 = 'SELECT ...'; //Запрос последних N комментариев
$sql3 = 'SELECT ...'; //Запрос последних N цен
...


а один "мета запрос" с полем-дискриминатором, по которому уже данные разбираются в нужном месте
Код: sql
1.
2.
3.
4.
SELECT 0 flag, /* запрос полей с общей итнформацией */
 UNION ALL 
SELECT 1 flag, /* запрос другой информации */
.....


Где единственный параметр в запросе который может быть передан - это идентификатор товара.

MasterZivНу это вообще разные запросы (части одного запроса) и они вообще никак друг с другом не связаны.
kormotБудет ли такой тип запросов эффективно кешироваться сервером MariaDB 10.3, всё на InnoDB.

Кэшироваться будут данные для запроса. На сколько эффективно -- сказать невозможно.

А кеш запросов, если запрос будет один и тот же и без использования функций препятствующих его кешированию?
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39872769
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormotДопустим запрашивается информация по такому-то товару. И соответственно по этому товару
чтобы загрузить и "Общую информацию" и "Последние комментарии" и "Последние цены" и прочее
прочее выполняются не 3+ отдельно запроса а один "мета запрос" с полем-дискриминатором, по
которому уже данные разбираются в нужном месте
Тем самым ты создаёшь серверу геморрой при разборке своего мега-запроса, а себе - при
разборке его результатов. Это военная логика, секретная.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39872776
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТем самым ты создаёшь серверу геморрой при разборке своего мега-запроса, а себе - при
разборке его результатов. Это военная логика, секретная.
Т.е. несколько мелких запросов эффективней, чем один склееный?

Проведу сегодня/завтра измерения производительности, такого варианта и такого. Это интересно.
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873026
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В итоге тесты провёл. Получение данных одним 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.
//Сперва получаем случайную выборку данных (50 штук), для использования как аргумент в запросе
$tData	= [];
$result	= _SQL('test.sql', 'get:test-data', 50);
while($cur=mysqli_fetch_array($result, MYSQLI_NUM))
	$tData[]	= $cur[0];

//Каждый тест по 100 раз в одной итерации цикла будет выполняться
$iterNum = 100;

//Массив с временами каждого теста
$t	= [0, 0];

//Пробегаем цикл 5 раз для усреднения результата
for($j=0;$j<5;$j++){
	$t1	= microtime(true);
	for($i=0;$i<$iterNum;$i++) //Тест с UNION ALL'ом
		$result	= _TF_PerfMySQL_UNIONALL_1($tData);

	$t2= microtime(true);
	for($i=0;$i<$iterNum;$i++) //Тест с отдельными SELECT'ами
		$result	= _TF_PerfMySQL_UNIONALL_2($tData);

	$t3= microtime(true);
	$t[0]	+= $t2-$t1;
	$t[1]	+= $t3-$t2;
}

MyLog::_(_NOTE_, 'PerfMySQL with "UNION ALL": ', $t[0]/5);
MyLog::_(_NOTE_, 'PerfMySQL with "Many SELECT": ', $t[1]/5);

//Собственно сами тестовые функции
//Вариант с выполнением UNION ALL'а и последующим разбором результата
function _TF_PerfMySQL_UNIONALL_1(& $tData){
	$xObj		= [	
					'i' => [],
					'l'	=> []
				];

	//Полезная нагрузка. Пробегаем массив из 50 аргументов, для получения по ним данных
	foreach($tData as $k => $v){
		//Получаем результат
		$result		= _SQL('test.sql', 'test:union-all.1', $v);
		/* Запрос который формируется в данном случае такой :
			$sql		= 'SELECT	1 p0, a1.id p1, a1.data_A p2, "" p3, "" p4 '.
						'	FROM	test_A	a1 '.
						'	WHERE	a1.id='.$idxA.' '.
						' UNION ALL '.
						'	SELECT	2 p0, a2.id p1, a2.data_B p2, b2.idx_A p3, "" p4 '.
						'	FROM	test_B	a2 '.
						'	JOIN	test_AB	b2 ON b2.idx_B=a2.id '.
						'	WHERE	b2.idx_A='.$idxA;
		*/

		while($cur=mysqli_fetch_array($result, MYSQLI_NUM)){
			switch($cur[0]){ /* Типа разбор данных по флагу в каждом UNION ALL'е */
				case 1:
					$xObj['i'][$cur[1]]	= $cur[2];
					$xObj['l'][$cur[1]]	= [];
					break;

				case 2:
					$xObj['l'][$cur[3]][]	= $cur[1];
					break;
			}
		}
	}

	return true;
}

//Вариант с получением данных отдельными SELECT'ами
function _TF_PerfMySQL_UNIONALL_2(& $tData){
	$xObj		= [	
					'i' => [],
					'l'	=> []
				];

	//Полезная нагрузка
	foreach($tData as $k => $v){
		//Получаем результат A
/*		$sql		= 'SELECT	a1.id p1, a1.data_A p2, "" p3, "" p4 
					FROM	test_A	a1 
					WHERE	a1.id='.$idxA;*/

		$result	= _SQL('test.sql', 'test:union-all.2a', $v);
		$data	= mysqli_fetch_array($result, MYSQLI_NUM);

		$xObj['i'][$data[0]]	= $data[1];
		$xObj['l'][$data[0]]	= [];

		//Получаем связанные с ним B
/*
		$sql		= '	SELECT	a2.id p1, a2.data_B p2, b2.idx_A p3 
					FROM	test_B	a2 
					JOIN	test_AB	b2 ON b2.idx_B=a2.id 
					WHERE	b2.idx_A='.$idxA;
*/
		$result		= _SQL('test.sql', 'test:union-all.2b', $v);
		while($cur=mysqli_fetch_array($result, MYSQLI_NUM))
			$xObj['l'][$cur[2]][]	= $cur[0];
	}

	return true;
}
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873029
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormotВ итоге тесты провёл. Получение данных одним UNION ALL'ом порядка 20% быстрей чем
отдельными SELECT'ами.

В одном коннекте. Без параметров вообще. Ню-ню...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873109
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovВ одном коннекте. Без параметров вообще. Ню-ню...
Ну как без параметров то?
Именно что сначала до начала замеров, получаются 50 случайных idx_A и затем для каждого из этих элементов вызываются запросы. В них фигурирует как раз в каждом только $idxA как внешний параметр.

А то, что в одном коннекте, так тут мы же скорость запросов измеряем и проверка идёт что один составной запрос медленнее чем несколько простых. Тут именно исключаются накладные расходы всякие посторонние, которые негативно если б и влияли, то на отдельные SELECT'ы. Так что некорректность если некоторая и имеется в тесте, то она один хер в пользу отдельных SELECT'ов, а они на 20% медленней оказываются.

Вот результат, причём на другом компе с другой осью и инсталляцией LAMP'а вместо FAMP'а.
Код: sql
1.
2.
96 	08.10.19 09:28 	заметка 	_TEST_PerfMySQL 	PerfMySQL with "Many SELECT": 	0.33744645118713 	false
96 	08.10.19 09:28 	заметка 	_TEST_PerfMySQL 	PerfMySQL with "UNION ALL": 	0.26329436302185 	false
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873132
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormotТ.е. несколько мелких запросов эффективней, чем один склееный?
Какой критерий эффективности? Иными словами, эффективнее для кого и как?
Больше пакетов по сети кидать - больше расходы по времени уйдут на сеть.
То есть надо понимать, что в другой ситуации результаты могут быть прямо противоположные.
В Вашем случае вообще может быть выгоднее вытащить наружу a1.id, а в where написать не a1.id=${idxID}, а a1.id in (...) сразу для всех 50 параметров.
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873135
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей ВаскецовkormotТ.е. несколько мелких запросов эффективней, чем один склееный?
Какой критерий эффективности? Иными словами, эффективнее для кого и как?
Больше пакетов по сети кидать - больше расходы по времени уйдут на сеть.
То есть надо понимать, что в другой ситуации результаты могут быть прямо противоположные.
В Вашем случае вообще может быть выгоднее вытащить наружу a1.id, а в where написать не a1.id=${idxID}, а a1.id in (...) сразу для всех 50 параметров.
Так тут же чисто синтетический и примитивный тест.

Доставать в IN() все 50 значений незачем, это же для теста симулировалось выполнение для 50 разных аргументов просто запросы.

А критерий вполне очевиден, по описанному в 1 сообщении приницпу что эффективней (меньше время выполнения SQL запроса и последующий разбор результата в приложении). Сформировать 1 большой запрос для получения всей смежной информации или всю смежную информацию получать отдельными запросами.
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873138
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну как Вам ещё объяснить...
Попробуйте выполнить одновременно 1000 таких тестов с 1000 разных клиентов.
Время фиксируйте по максимальному времени среди всех, то есть, по худшему качеству обслуживания.
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873142
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, чего-то я всё же не могу понять.
Сергей, скажите пожалуйста что именно вы хотите сказать?
Что этот тест ничего не показывает или что при реальном и серьёзном по нагрузке использовании UNION ALL будет медленней чем много-SELECT вариант?
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873144
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я хочу до Вас донести, что этот тест показывает результаты только в той ситуации, в которой Вы его проводите. В других ситуациях могут быть совершенно иные результаты.
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873150
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Может быть, но пока то что можно померить - говорит о вполне однозначной картине.
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873295
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormotНу как без параметров то?

Совершенно без параметров. Вы формируете 50 разных запросов вместо использования одного,
параметризированного. Или 150 разных запросов вместо трёх.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873308
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovСовершенно без параметров. Вы формируете 50 разных запросов вместо использования одного,
параметризированного. Или 150 разных запросов вместо трёх.
И вот только после нескольких внимательных прочтений этого комментария, и подавления в себе мысли что Дмитрий просто говорит что-то не в тему, я наконец открыл для себя что такое параметризованные или подготовленные запросы.
Жесть конечно, за 20-ть то лет общения с PHP и MYSQL можно было бы и знать уже :)

Спасибо Дмитрий!
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873319
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А для тестирования и всё же в качестве более эффективному использованию в стартовом вопросе топика не подходит.

Параметризованные запросы эффективны же для многократного исполнения одного и того же запроса с параметром, в рамках одного сеанса.
А я в начальном вопросе же спрашивал - при загрузке странички как лучше запрашивать все данные по какой-либо сущности. Этот запросы (с UNION ALL'ом) или запросы (с SELECT'ами) должны выполниться по одному разу. Только получить данные и распихать их по внутренним структурам приложения.
И тест соответственно для тестирования такой же модели использования, и подготовленные выражения может для теста внутренней эффективности движка для двух вариантов запроса сравнил бы (сделаю сегодня такой тест), но в случае именно однократной необходимости в получении информации - выгоды нивелируются скорей всего подготовкой запросов.
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873333
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormotв случае именно однократной необходимости в получении информации - выгоды нивелируются
скорей всего подготовкой запросов.

Если только сервер не кэширует подготовленные запросы между сессиями. Именно в этом плане
я прочитал сабж. А о каком кэшировании думал ты, когда его писал?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873554
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovЕсли только сервер не кэширует подготовленные запросы между сессиями. Именно в этом плане
я прочитал сабж. А о каком кэшировании думал ты, когда его писал?
Я думал о таком кешировании, что если для одного и того же аргумента (напр. для одного и того же товара) запрашивается
Код: sql
1.
SELECT ... FROM ..... WHERE tovarID=${idx}

, и результат конкретно этого запроса кешируется (до момента пока в какой-либо из составляющих его таблиц не меняются данные).
Я думал так кеш запросов работает.
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873556
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormotЯ думал так кеш запросов работает.

Нет, так работает кэш резалт-сетов. И я понятия не имею есть ли он в Марии. Но даже в этом
случае кэширование трёх маленьких резалт-сетов не отличается от кэширования одного большого.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873568
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovЕсли только сервер не кэширует подготовленные запросы между сессиями.
К сожалению не кеширует. Мария по крайней мере:
Код: sql
1.
The scope of a prepared statement is the session within which it is created. Other sessions cannot see it.
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873583
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormotThe scope of a prepared statementis the session within which itis created.

Это не о том.

Лучше тебе идти в специализированный отдел форума.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873654
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а что запросы не в функции чтоли?
функции автоматом кэшируются, им только параметры подсовывай
kormotДопустим запрашивается информация по такому-то товару. И соответственно по этому товару чтобы загрузить и "Общую информацию" и "Последние комментарии" и "Последние цены" и прочее прочее выполняются не 3+ отдельно запроса типа
а один "мета запрос" с полем-дискриминатором, по которому уже данные разбираются в нужном месте
это всё бабкины грабли
максимальная скорость тут:
сделайте агрегацию всех своих запросов в одну отдельную таблицу
(вот этот самый запрос (а лучше 3), только на заднем плане)
в таблице будут все нужные данные безо всяких лишних телодвижений
вот и дёргайте из неё по ID, что вам там надо дёргать.
каждую минуту дописывайте в неё данные
либо чаще
либо вообще MATERIALIZED VIEW замутите в real-time (они сложнее)
...
Рейтинг: 0 / 0
Эффективность запросе в плане кеширования
    #39873716
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Уважаемые, вы с каждым постом всё повышаете и повышаете ставки :) В какой момент лучшее станет врагом хорошего? :)
...
Рейтинг: 0 / 0
24 сообщений из 24, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Эффективность запросе в плане кеширования
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]