20 SQL-запросов на загрузку страницы, действительно рассмотрел много? [закрытый]
Итак, сначала я должен был внести эту коррекцию в ваш RDD (который соответствует вашему фактическому выходу):
rdd = sc.parallelize([('X01',41,'US',3),
('X01',41,'UK',1),
('X01',41,'CA',2),
('X02',72,'US',4),
('X02',72,'UK',6),
('X02',72,'CA',7),
('X02',72,'XX',8)])
Как только я сделал эту коррекцию, это сделало трюк:
df.select($"ID", $"Age").groupBy($"ID").agg($"ID", first($"Age") as "Age")
.join(
df.select($"ID" as "usID", $"Country" as "C1",$"Score" as "US"),
$"ID" === $"usID" and $"C1" === "US"
)
.join(
df.select($"ID" as "ukID", $"Country" as "C2",$"Score" as "UK"),
$"ID" === $"ukID" and $"C2" === "UK"
)
.join(
df.select($"ID" as "caID", $"Country" as "C3",$"Score" as "CA"),
$"ID" === $"caID" and $"C3" === "CA"
)
.select($"ID",$"Age",$"US",$"UK",$"CA")
Не так элегантно, как ваш стержень, конечно.
7 ответов
Можно обычно приносить все данные в двух или трех больших запросах вместо на двадцати маленьких. Уменьшение количества запросов так же важно как, если не самый важный, чем, пишущий оптимальные запросы для максимизации производительности.
, Конечно, необходимо всегда анализировать планы запросов и цель к оптимальным запросам, быть ими маленький или большой.
вещь состоит в том, что плохо разработанные веб-страницы делают много запросов, один на каждую крошечную небольшую задачу, которая могла легко быть сгруппирована в едином запросе.
, Например, плохо разработал stackoverflow, мог делать запрос для получения всех идентификаторов вопроса, которые он покажет на основной странице, затем сделает один запрос на каждый вопрос получить сводку и голоса. Затем у Вас есть легко 20 бесполезных запросов. Хорошо разработанный сделает единый запрос, получающий всю информацию обо всех вопросах, которые она отобразит.
, Конечно, влияние этого всего уменьшается с хорошим кэшированием, которое является тем, что все большие сайты делают, тот способ, которым на самом деле можно сделать много запросов и все еще получить достойную производительность.
Это больше о кэшировании.
, Если Вы получаете высокое количество параллельных просмотров страницы, и каждый просмотр страницы делает много запросов, он не имеет большой смысл поразить базу данных каждый. единственный. время. Особенно, когда много данных, возвращающихся, будет полудинамическими справочными данными, которые только изменяются время от времени (в противоположность сессии или данным реального времени, которые всегда изменяются).
можно также кэшировать те результаты базы данных с помощью memcached или что-то подобное. Необходимо не обязательно кэшировать целую страницу (хотя, именно это, делает большая часть Wordpress, кэширующего плагины), поскольку это уничтожает интерактивность, но можно кэшироваться на основе данных данными.
существует также проблема оптимизации запросов. Особенно избегая страшной ситуации N+1, где Вы делаете один запрос для родительской записи, затем дополнительный запрос для каждый из его детей. Задержка распространения в прямом и обратном направлениях назад и вперед к одной только базе данных уничтожит Ваше выполнение рендеринга страницы, не говоря уже о горе причины на самом DB.
Ответ действительно зависит от нескольких ключевых вещей: - объем трафика Вашего сайта - бюджета IT для Вашей поддержки - сложность сайта и ресурсов, требуемых оптимизировать
, Если у Вас есть веб-сайт, который получает несколько хитов в день, затем кто заботится о приблизительно 20 запросах. На обороте, если Вы - Amazon затем, Вы собираетесь предложить необходимое содержание по большим затратам на инфраструктуру.
Примерно все остальные в мире где-нибудь между теми двумя экстремальными значениями и должны балансироваться на основе их собственных ресурсов.
Единственная другая вещь, которую я скажу, кэшируется, Ваш друг.
Если необходимо сделать 20 запросов, то пусть будет так, но это раздражало бы меня немного, если бы это была первая полоса.
Объединяющиеся запросы, если это возможно, могут помочь, но думающий о кэшировании самая важная часть.
я в настоящее время обновляю сайт, где данные, которые изменяются 5 или 6 раз в год, являются запрошенными тысячами времен день, с помощью некоторого очень противного SQL для превращения его в дерево, но могут быть сохранены как древовидная структура приблизительно в 200k RAM. (700k состояния отображения на первой полосе также, но это - другая история...), Это вид вещей, которые наносят вред веб-сайтам ни о каком серьезном основании.
Так, нет никакого магического числа относительно того, сколько запросов Вы должны или не должны делать, но думать о каждых из них даже при кэшировании некоторых из них в течение только 5 минут которые будут иметь огромное значение, если когда-нибудь Вы поразите первую полосу digg.
5 минут кэширования всего на 1 запросе могли удалить тысячи хитов DB, когда Ваш сайт находится в условиях стресса.
Учитывая, что, за исключением использования Ajax, каждая страница является атомарной, я не нашел настолько трудным генерировать довольно сложные страницы в 3 или меньше запросах. Концептуально, установленное на страницу типичное включает:
- информация о Контексте (связанный с сессией и другим глобальным состоянием);
- Заголовок (и связанные соединения 1:0-1);
- Деталь (1:M от 2).
Это берет некоторым планирование заранее; но с другой стороны это - легкое осуществление рефакторинга в большинстве случаев.
Мое эмпирическое правило, подавляют первые полосы к под 5-7, если это возможно, в зависимости от типа сайта.
страницы Interior, в зависимости от того, в чем они нуждаются, могли бы иметь больше, но я делаю то, что я могу для хранения его под 20.
Однако одновременно, в зависимости от то, что Вы пытаетесь сделать И что типы кэширования Вас делают с той информацией 20, не может быть плохим, если 15 из них в большой степени кэшируются...
Количество запросов не так важно все время. Это действительно, как Вы обрабатываете соединения. Если у Вас есть организация пула подключений затем, она действительно не имеет значения и физическое местоположение вопросов серверов. Если Ваши серверы друг рядом с другом в дата-центре, настраивающем соединение, вероятно, действительно быстро. Большую часть времени Ваш веб-сайт тратит загрузку, если это - база данных, управляемый сайт будет потраченным ожиданием соединений для открытия и данных, которые будут выбраны. Иллюстрация для открытия соединения это берет 100 - 300 мс. Таким образом, если необходимо открыть 20 соединений для каждого доступа к базе данных, это составляет 4 - 6 секунд, просто открывающихся и заключительные соединения.
, Так как Jeff Atwood использует LINQ, я предполагаю, что он только открывает единственное соединение, выполняя его 20 запросов и затем закрывая соединение. Все это, вероятно, происходит довольно быстрое.
кроме того, база данных Jeff работает на той же реальной машине и использует внутреннюю коммуникацию машины для общения с базой данных и не сетью, таким образом, действительно нет никакой задержки, которую Вы связали бы с открытием соединения типа TCP. (Он говорил об этом на подкасте Hanselminutes несколько недель назад.)
у меня есть подобная конфигурация для одного из моих сайтов с помощью LINQ и с базой данных по тому же полю. Когда я выполняю сайт на своей локальной машине, поражающей базу данных по серверу в другом состоянии, требуется до 6 секунд для загрузки нескольких данных тяжелые страницы. Когда я выполняю сайт на сервере, загрузках страницы в меньше, чем секунда, потому что все локально для сервера.