WEBVTT

00:00:00.000 --> 00:00:10.560
(Музыка).

00:00:10.560 --> 00:00:12.975
Эй, добро пожаловать в новый
эпизод данных разоблачены.

00:00:12.975 --> 00:00:14.460
Меня зовут Педро Лопес.

00:00:14.460 --> 00:00:16.920
Я менеджер программы в
Инженерная команда сервера S'L.

00:00:16.920 --> 00:00:18.510
Сегодня я буду говорить

00:00:18.510 --> 00:00:20.670
о интеллектуальных
База данных, в частности,

00:00:20.670 --> 00:00:23.809
Интеллектуальная обработка запросов
в сервере S'L 2019,

00:00:23.809 --> 00:00:25.925
а также база данных Azure S'L.

00:00:25.925 --> 00:00:29.390
Так что давайте перейдем к нему. Sql
Сервер 2019 представляет

00:00:29.390 --> 00:00:31.864
новаторский запрос
повышение производительности

00:00:31.864 --> 00:00:34.655
и они интеллектуальные
Семья обработки запросов.

00:00:34.655 --> 00:00:37.820
Они составляют последние на
Миссия корпорации Майкрософт, чтобы убедиться,

00:00:37.820 --> 00:00:41.690
что критические параллельные рабочие нагрузки
улучшить при запуске в масштабе,

00:00:41.690 --> 00:00:45.470
оставаясь адаптивным к
постоянно меняющийся мир данных,

00:00:45.470 --> 00:00:47.855
как данные движется в и
из баз данных.

00:00:47.855 --> 00:00:49.670
В этом видео, я собираюсь дать вам

00:00:49.670 --> 00:00:51.980
краткий обзор
Интеллектуальный мир баз данных

00:00:51.980 --> 00:00:53.030
, что действительно принимает скачок

00:00:53.030 --> 00:00:56.150
вперед с предстоящим
Сервер S'L 2019,

00:00:56.150 --> 00:00:58.700
и познакомить вас с числом
особенностей, которые мы будем нырять

00:00:58.700 --> 00:01:02.130
глубже в других
видео в этой серии.

00:01:03.170 --> 00:01:07.510
Интеллектуальная обработка запросов
в сервере S'L доступен

00:01:07.510 --> 00:01:11.245
по умолчанию в последней базе данных
настройки уровня совместимости.

00:01:11.245 --> 00:01:13.210
Это означает, что после обновления,

00:01:13.210 --> 00:01:15.130
это может быть доступно только

00:01:15.130 --> 00:01:18.000
листать переключатель для использования
последние настройки совместимости.

00:01:18.000 --> 00:01:22.030
Интеллектуальная обработка запросов
также обеспечивает широкое воздействие

00:01:22.030 --> 00:01:23.440
что повышает производительность

00:01:23.440 --> 00:01:26.650
существующих рабочих нагрузок с
минимальные усилия по реализации.

00:01:26.650 --> 00:01:28.390
Это действительно означает, что большую часть времени,

00:01:28.390 --> 00:01:30.965
есть нулевая потребность в
рефакторинг кода.

00:01:30.965 --> 00:01:33.310
Интеллектуальная обработка запросов улучшает

00:01:33.310 --> 00:01:36.190
критические параллельные рабочие нагрузки
при запуске в масштабе,

00:01:36.190 --> 00:01:39.355
и по мере поступления данных в и
из вашей базы данных,

00:01:39.355 --> 00:01:41.380
мы адаптируемся к этому и

00:01:41.380 --> 00:01:44.660
поддерживать уровень
предсказуемой производительности.

00:01:44.660 --> 00:01:47.450
Например, путем введения

00:01:47.450 --> 00:01:49.880
механизм обратной связи
в память использования,

00:01:49.880 --> 00:01:53.630
мы можем гарантировать, что ваша рабочая нагрузка
выполняется предсказуемым образом.

00:01:53.630 --> 00:01:58.190
Если выполнение данного запроса
может быть, занимают слишком много памяти,

00:01:58.190 --> 00:01:59.750
мы можем исправить это и

00:01:59.750 --> 00:02:02.375
увеличить параллелизм
фактор вашей базы данных.

00:02:02.375 --> 00:02:06.020
Если данное исполнение акционерного капитала
не получает достаточно памяти и

00:02:06.020 --> 00:02:09.560
заканчивается использованием дополнительного итогового
по всему известен как разлив,

00:02:09.560 --> 00:02:11.315
то мы можем также обнаружить, что

00:02:11.315 --> 00:02:13.565
и исправить ситуацию
так что операция

00:02:13.565 --> 00:02:15.260
выполняет в памяти и

00:02:15.260 --> 00:02:18.200
выполняет, как и ожидалось в
последующих казней.

00:02:18.200 --> 00:02:20.540
Эта функция теперь включена для

00:02:20.540 --> 00:02:22.835
все режимы выполнения в
центр базы данных.

00:02:22.835 --> 00:02:27.170
Режим пакетов для большего хранилища данных
и аналитические нагрузки,

00:02:27.170 --> 00:02:31.410
и режим строки для вашего
критические рабочие нагрузки OLTP.

00:02:31.700 --> 00:02:34.640
Мы также идем в новые области

00:02:34.640 --> 00:02:37.220
которые мы называем
приблизительная обработка запросов.

00:02:37.220 --> 00:02:40.640
Например, подумайте о сценарии
где железнодорожная компания держит

00:02:40.640 --> 00:02:42.350
отслеживать количество билетов, которые

00:02:42.350 --> 00:02:44.935
купил и использовался в
вся железнодорожная система.

00:02:44.935 --> 00:02:47.030
Они отслеживают это
для реализации

00:02:47.030 --> 00:02:49.730
некоторые измерения управления потоком
когда это необходимо,

00:02:49.730 --> 00:02:52.610
возможно, адаптируя
расписание поездов,

00:02:52.610 --> 00:02:53.630
или количество поездов в

00:02:53.630 --> 00:02:55.810
системы для удовлетворения
потребности момента.

00:02:55.810 --> 00:02:58.920
Эта информация также
обновленв в приборной панели

00:02:58.920 --> 00:03:02.530
что люди в центре города
Центральный может взглянуть на.

00:03:02.530 --> 00:03:04.220
Теперь, в этом сценарии часть

00:03:04.220 --> 00:03:06.830
рабочая нагрузка будет, безусловно,
для запуска запроса, который

00:03:06.830 --> 00:03:09.020
постоянно глядя на получение

00:03:09.020 --> 00:03:12.005
строки кол всех
билеты, которые продаются и используются,

00:03:12.005 --> 00:03:14.600
и это, вероятно,
исходя из очень

00:03:14.600 --> 00:03:17.605
большой стабильной, возможно, с
миллиардов и миллиардов строк.

00:03:17.605 --> 00:03:20.540
Теперь этот повторяющийся запрос
как правило, занимают

00:03:20.540 --> 00:03:23.735
значительные ресурсы на
сервера, а именно памяти.

00:03:23.735 --> 00:03:25.639
Если он выполняется повторно,

00:03:25.639 --> 00:03:26.690
может реально повлиять на

00:03:26.690 --> 00:03:28.900
характеристики производительности
вашей базы данных.

00:03:28.900 --> 00:03:30.670
Однако в этом сценарии

00:03:30.670 --> 00:03:32.750
железнодорожная компания
не обязательно нужно

00:03:32.750 --> 00:03:35.830
фактический счет всех
билеты, которые продаются и используются.

00:03:35.830 --> 00:03:37.790
Но очень высокая
приближения достаточно

00:03:37.790 --> 00:03:40.280
чтобы вызвать все
требуется принятие решений.

00:03:40.280 --> 00:03:42.935
Это где приблизительно
рассчитывать различных приходит,

00:03:42.935 --> 00:03:45.500
позволяя запрос
неоднократно получать

00:03:45.500 --> 00:03:48.185
приблизительное количество
проданных и использованных билетов

00:03:48.185 --> 00:03:51.080
без серьезных последствий
производительность базы данных, которая

00:03:51.080 --> 00:03:55.420
ваш обычный запрос подсчета
займет сегодня.

00:03:55.640 --> 00:03:58.695
Включив режим пакета в строке магазина,

00:03:58.695 --> 00:03:59.950
мы эффективно развязать

00:03:59.950 --> 00:04:02.150
режим обработки, который
особенно оптимизированы

00:04:02.150 --> 00:04:05.975
для аналитических рабочих нагрузок над
любой таблицы в вашей базе данных.

00:04:05.975 --> 00:04:08.180
Это означает, что даже
для сценариев, где

00:04:08.180 --> 00:04:10.385
индекс магазина столбцов
не было бы вариантом,

00:04:10.385 --> 00:04:14.395
движок базы данных все еще может
выполнить это оптимизированным способом.

00:04:14.395 --> 00:04:17.375
Это, в свою очередь, открывает возможности для

00:04:17.375 --> 00:04:20.630
функции, такие как адаптивное соединение
для использования вашей рабочей нагрузкой.

00:04:20.630 --> 00:04:24.170
Адаптивное соединение, которое является только
доступны в пакетном режиме может

00:04:24.170 --> 00:04:28.940
Теперь использовать во всех
таблицы и большинство рабочих нагрузок.

00:04:29.590 --> 00:04:33.170
Мы также рассмотрели некоторые из
наиболее повторяющиеся антишаблоны

00:04:33.170 --> 00:04:36.260
которые становятся проблемой для
управляемые рабочие нагрузки сервера S'L.

00:04:36.260 --> 00:04:38.150
Использование таблицы
Переменные и использование

00:04:38.150 --> 00:04:40.105
Scalar UDF, например,

00:04:40.105 --> 00:04:42.440
и теперь мы можем разблокировать новые уровни

00:04:42.440 --> 00:04:46.375
оптимизация запросов, которые были
невозможно до недавнего времени.

00:04:46.375 --> 00:04:49.310
Все это, мы будем
обсудить глубже и с

00:04:49.310 --> 00:04:51.080
демо в предстоящих видео в

00:04:51.080 --> 00:04:53.270
серия о
интеллектуальная база данных,

00:04:53.270 --> 00:04:56.020
особенно умный
обработка запросов.

00:04:56.020 --> 00:04:59.505
Но если вы хотите знать,
больше об этом сегодня,

00:04:59.505 --> 00:05:04.200
то, пожалуйста, перейдите на этот aka.ms/IQP

00:05:04.200 --> 00:05:06.899
URL, где вы видите все
документация

00:05:06.899 --> 00:05:09.535
на Интеллектуальный запрос
Обработка в базах данных S'L.

00:05:09.535 --> 00:05:13.100
Если вы хотите поэкспериментировать некоторые
из них сами прямо сейчас,

00:05:13.100 --> 00:05:16.040
у нас также есть демо, которые
Вы можете посмотреть, если вы

00:05:16.040 --> 00:05:18.980
перейдите в наш репозиторий GitHub
и короткий URL будет

00:05:18.980 --> 00:05:22.430
быть aka.ms/IQPDemos, где вы будете

00:05:22.430 --> 00:05:25.900
быть в состоянии смотреть на все эти
функции и экспериментировать самостоятельно.

00:05:25.900 --> 00:05:27.795
Итак, еще раз, позаботьтесь.

00:05:27.795 --> 00:05:28.980
Я скоро поговорю с тобой.

00:05:28.980 --> 00:05:43.780
(Музыка).