WEBVTT

00:00:00.000 --> 00:00:10.560
[MUZYKA].

00:00:10.560 --> 00:00:12.975
>> Hej, Witamy w nowym
odcinek danych narażonych.

00:00:12.975 --> 00:00:14.460
Nazywam się Pedro Lopes.

00:00:14.460 --> 00:00:16.920
Jestem menedżerem programu w
Zespół inżynierów programu SQL Server.

00:00:16.920 --> 00:00:18.510
Dzisiaj zamierzam mówić

00:00:18.510 --> 00:00:20.670
o inteligentnym
Baza danych, w szczególności

00:00:20.670 --> 00:00:23.809
Inteligentne przetwarzanie zapytań
w SQL Server 2019,

00:00:23.809 --> 00:00:25.925
a także usługi Azure SQL Database.

00:00:25.925 --> 00:00:29.390
Więc przejdźmy do niego. Sql
Serwer 2019 wprowadza

00:00:29.390 --> 00:00:31.864
przełomowe zapytanie
ulepszenia wydajności

00:00:31.864 --> 00:00:34.655
i są inteligentnym
Przetwarzanie kwerend rodziny.

00:00:34.655 --> 00:00:37.820
Tworzą one najnowsze
Misja firmy Microsoft, aby upewnić się,

00:00:37.820 --> 00:00:41.690
krytycznych obciążeń równoległych
poprawić podczas biegu na dużą skalę,

00:00:41.690 --> 00:00:45.470
pozostając adaptacyjnym do
nieustannie zmienia świat danych,

00:00:45.470 --> 00:00:47.855
jak dane są przenoszone i
z baz danych.

00:00:47.855 --> 00:00:49.670
W tym filmie, mam zamiar dać

00:00:49.670 --> 00:00:51.980
szybki przegląd
Inteligentny świat bazy danych

00:00:51.980 --> 00:00:53.030
że naprawdę ma skok

00:00:53.030 --> 00:00:56.150
do przodu z nadchodzącym
SQL Server 2019,

00:00:56.150 --> 00:00:58.700
i wprowadzenie do numeru
funkcji, które będziemy nurkować

00:00:58.700 --> 00:01:02.130
głębiej w innych
wideo z tej serii.

00:01:03.170 --> 00:01:07.510
Inteligentne przetwarzanie zapytań
w programie SQL Server jest dostępna przez

00:01:07.510 --> 00:01:11.245
Domyślnie w najnowszej bazie danych
ustawienie poziomu zgodności.

00:01:11.245 --> 00:01:13.210
Oznacza to, że po uaktualnieniu

00:01:13.210 --> 00:01:15.130
to może być dostępne tylko przez

00:01:15.130 --> 00:01:18.000
przekręć przełącznik, aby użyć
Najnowsze ustawienie kompatybilności.

00:01:18.000 --> 00:01:22.030
Inteligentne przetwarzanie zapytań
zapewnia także szerokie oddziaływanie

00:01:22.030 --> 00:01:23.440
który poprawia wydajność

00:01:23.440 --> 00:01:26.650
istniejących obciążeń z
minimalnym wysiłkiem wdrożeniowych.

00:01:26.650 --> 00:01:28.390
To naprawdę oznacza, że większość czasu,

00:01:28.390 --> 00:01:30.965
jest zerowa potrzeba
Refaktoryzuj swój kod.

00:01:30.965 --> 00:01:33.310
Inteligentne przetwarzanie zapytań poprawia

00:01:33.310 --> 00:01:36.190
krytyczne obciążenia równoległe
podczas biegu w skali,

00:01:36.190 --> 00:01:39.355
i w miarę jak przepływy danych
z bazy danych,

00:01:39.355 --> 00:01:41.380
będziemy dostosowywać się do tego i

00:01:41.380 --> 00:01:44.660
utrzymać poziom
i przewidywalną wydajność.

00:01:44.660 --> 00:01:47.450
Przykładowo, wprowadzając

00:01:47.450 --> 00:01:49.880
mechanizm sprzężenia zwrotnego
do użycia pamięci,

00:01:49.880 --> 00:01:53.630
możemy zapewnić, że obciążenie pracą
jest wykonywana w sposób przewidywalny.

00:01:53.630 --> 00:01:58.190
Jeśli wykonanie danego zapytania będzie
może zająć zbyt dużo pamięci,

00:01:58.190 --> 00:01:59.750
możemy je skorygować i

00:01:59.750 --> 00:02:02.375
zwiększyć współbieżność
współczynnika bazy danych.

00:02:02.375 --> 00:02:06.020
Jeżeli dana egzekucja kapitałowy
nie otrzymuje wystarczającej ilości pamięci i

00:02:06.020 --> 00:02:09.560
kończy się przy użyciu dodatkowych operacji we/wy
przez cały czas jest znany jako wyciek,

00:02:09.560 --> 00:02:11.315
następnie możemy również znaleźć, że

00:02:11.315 --> 00:02:13.565
i korygowania sytuacji
tak, aby operacja

00:02:13.565 --> 00:02:15.260
jest wykonywana w pamięci i

00:02:15.260 --> 00:02:18.200
działa zgodnie z oczekiwaniami w
późniejsze egzekucje.

00:02:18.200 --> 00:02:20.540
Ta funkcja jest teraz włączona dla

00:02:20.540 --> 00:02:22.835
wszystkie tryby wykonywania w
centrum bazy danych.

00:02:22.835 --> 00:02:27.170
Tryb wsadowy dla większej liczby hurtowni danych
i obciążeń analitycznych,

00:02:27.170 --> 00:02:31.410
i tryb wiersza dla
krytycznych obciążeń OLTP.

00:02:31.700 --> 00:02:34.640
Jedziemy również do nowych obszarów

00:02:34.640 --> 00:02:37.220
którego jesteśmy wzywając
przetwarzania kwerend przybliżonych.

00:02:37.220 --> 00:02:40.640
Na przykład, pomyśl o scenariuszu
gdzie firma kolejowa utrzymuje

00:02:40.640 --> 00:02:42.350
liczby biletów, które są

00:02:42.350 --> 00:02:44.935
zakupione i wykorzystane w
całego systemu kolejowego.

00:02:44.935 --> 00:02:47.030
Śledzą to
w celu wdrożenia

00:02:47.030 --> 00:02:49.730
Niektóre pomiary kontroli przepływu
gdy jest potrzebna,

00:02:49.730 --> 00:02:52.610
być może poprzez dostosowanie
harmonogramy pociągów,

00:02:52.610 --> 00:02:53.630
lub liczbę pociągów w

00:02:53.630 --> 00:02:55.810
systemu w celu spełnienia
potrzeb danej chwili.

00:02:55.810 --> 00:02:58.920
Informacje te są również
aktualizowane na pulpicie nawigacyjnym

00:02:58.920 --> 00:03:02.530
że ludzie w Downtown
Centralna może spojrzeć na.

00:03:02.530 --> 00:03:04.220
Teraz, w tej części scenariusza

00:03:04.220 --> 00:03:06.830
obciążenie pracą będzie z pewnością
, aby uruchomić kwerendę, która jest

00:03:06.830 --> 00:03:09.020
stale patrząc na uzyskanie

00:03:09.020 --> 00:03:12.005
Liczba rzędów wszystkich
bilety, które są sprzedawane i używane,

00:03:12.005 --> 00:03:14.600
i jest to prawdopodobnie
pochodzącym z bardzo

00:03:14.600 --> 00:03:17.605
duże stabilne być może z
miliardy i miliardy rzędów.

00:03:17.605 --> 00:03:20.540
Teraz ta powtarzająca się kwerenda
zwykle zajmie się

00:03:20.540 --> 00:03:23.735
znacznych zasobów na
serwera, a mianowicie pamięci.

00:03:23.735 --> 00:03:25.639
Jeśli jest wykonywana wielokrotnie,

00:03:25.639 --> 00:03:26.690
może naprawdę wpływać na

00:03:26.690 --> 00:03:28.900
charakterystykę działania
bazy danych.

00:03:28.900 --> 00:03:30.670
Jednak w tym scenariuszu

00:03:30.670 --> 00:03:32.750
przedsiębiorstwo kolejowe
niekoniecznie musi

00:03:32.750 --> 00:03:35.830
Rzeczywista liczba wszystkich
bilety, które są sprzedawane i używane.

00:03:35.830 --> 00:03:37.790
Ale bardzo wysoki
przybliżenie jest wystarczające

00:03:37.790 --> 00:03:40.280
, aby wyzwolić wszystkie
wymaganego podejmowania decyzji.

00:03:40.280 --> 00:03:42.935
W tym miejscu Przybliżona
Zliczanie odrębnych przychodzi,

00:03:42.935 --> 00:03:45.500
zezwalając na zapytanie
, aby wielokrotnie uzyskiwać

00:03:45.500 --> 00:03:48.185
Przybliżona liczba
biletów sprzedanych i używanych

00:03:48.185 --> 00:03:51.080
bez poważnego wpływu na
wydajność bazy danych, która

00:03:51.080 --> 00:03:55.420
normalnej kwerendy zliczania
zajmie dziś.

00:03:55.640 --> 00:03:58.695
Włączając tryb wsadowy w magazynie wierszy,

00:03:58.695 --> 00:03:59.950
skutecznie wyzwolić

00:03:59.950 --> 00:04:02.150
Tryb przetwarzania, który jest
Szczególnie zoptymalizowany

00:04:02.150 --> 00:04:05.975
dla obciążeń analitycznych
dowolnej tabeli w bazie danych.

00:04:05.975 --> 00:04:08.180
Oznacza to, że nawet
dla scenariuszy, w których

00:04:08.180 --> 00:04:10.385
indeks magazynu kolumn
nie byłaby opcją,

00:04:10.385 --> 00:04:14.395
aparat bazy danych może nadal
wykonać to w sposób zoptymalizowany.

00:04:14.395 --> 00:04:17.375
Z kolei otwiera to zakres

00:04:17.375 --> 00:04:20.630
funkcje, takie jak sprzężenie adaptacyjne
do użycia przez obciążenie pracą.

00:04:20.630 --> 00:04:24.170
Adaptacyjne sprzężenie, które jest
dostępne w trybie wsadowym mogą

00:04:24.170 --> 00:04:28.940
teraz być dźwignią we wszystkich
tabel i większości obciążeń.

00:04:29.590 --> 00:04:33.170
Zajęliśmy się również niektórymi
najbardziej powtarzające się anty-wzorców

00:04:33.170 --> 00:04:36.260
które stają się problemem dla
zarządzanych obciążeń programu SQL Server.

00:04:36.260 --> 00:04:38.150
Korzystanie z tabeli
Zmienne i użycie

00:04:38.150 --> 00:04:40.105
skalarnych UDFs, na przykład

00:04:40.105 --> 00:04:42.440
a teraz możemy odblokować nowe poziomy

00:04:42.440 --> 00:04:46.375
optymalizacji zapytań, które zostały
nie jest możliwe do niedawna.

00:04:46.375 --> 00:04:49.310
Wszystko to, będziemy
przedyskutować głębiej i z

00:04:49.310 --> 00:04:51.080
pokazy w nadchodzących filmach w

00:04:51.080 --> 00:04:53.270
serii o
Inteligentna baza danych,

00:04:53.270 --> 00:04:56.020
w szczególności inteligentne
przetwarzania zapytań.

00:04:56.020 --> 00:04:59.505
Ale jeśli chcesz wiedzieć
więcej o tym dzisiaj,

00:04:59.505 --> 00:05:04.200
następnie proszę przejść do tego aka.ms/IQP

00:05:04.200 --> 00:05:06.899
URL, gdzie widzisz wszystkie
dokumentacji

00:05:06.899 --> 00:05:09.535
na inteligentnym zapytaniu
Przetwarzanie w bazach danych SQL.

00:05:09.535 --> 00:05:13.100
Jeśli chcesz eksperymentować
tych przez siebie już teraz,

00:05:13.100 --> 00:05:16.040
Mamy również demo, które
można spojrzeć na

00:05:16.040 --> 00:05:18.980
Przejdź do naszego repozytorium GitHub
i krótki URL byłby

00:05:18.980 --> 00:05:22.430
być aka.ms/IQPDemos, gdzie będziesz

00:05:22.430 --> 00:05:25.900
być w stanie spojrzeć na te wszystkie
funkcje i eksperymentować samodzielnie.

00:05:25.900 --> 00:05:27.795
Więc znowu, dbać.

00:05:27.795 --> 00:05:28.980
Wkrótce będę mówił do Ciebie.

00:05:28.980 --> 00:05:43.780
[MUZYKA].