WEBVTT

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

00:00:10.500 --> 00:00:11.910
>> Witam i zapraszam z powrotem.

00:00:11.910 --> 00:00:14.970
Nazywam się JRJ, a ja jestem tutaj
opowiedzieć o jednym z

00:00:14.970 --> 00:00:18.915
najchętniej oczekiwanym
funkcje w SQL Server 2019,

00:00:18.915 --> 00:00:21.285
i to Wirtualizacja danych.

00:00:21.285 --> 00:00:23.175
Co to jest wirtualizacja danych,

00:00:23.175 --> 00:00:25.440
i dlaczego jest tak niecierpliwie oczekiwany?

00:00:25.440 --> 00:00:27.510
Cóż, po prostu umieścić,

00:00:27.510 --> 00:00:29.510
Wirtualizacja danych umożliwia

00:00:29.510 --> 00:00:31.670
wszystkie dane razem na

00:00:31.670 --> 00:00:35.780
czas kwerendy, a nie konieczności
tworzenie złożonych rurociągów ETL w

00:00:35.780 --> 00:00:40.535
Aby móc zjednoczy ć
danych w pojedynczej kwerendzie.

00:00:40.535 --> 00:00:44.150
Więc co mam zamiar
zrobić, to zamiast iść

00:00:44.150 --> 00:00:47.540
poprzez szczegółowe dane
Wirtualizacja na poziomie koncepcyjnym,

00:00:47.540 --> 00:00:49.730
Po prostu pokażę ci
różnice między

00:00:49.730 --> 00:00:52.430
zapytanie lokalne i
zapytanie zwirtualizowane,

00:00:52.430 --> 00:00:55.085
częściowo i w pełni zwirtualizowane.

00:00:55.085 --> 00:00:56.280
Aby to zrobić,

00:00:56.280 --> 00:00:58.010
co mamy zamiar zrobić, to
mamy zamiar przełączyć

00:00:58.010 --> 00:01:00.270
teraz do usługi Azure Data Studio,

00:01:00.270 --> 00:01:03.035
i można zobaczyć tutaj I
mieć otwarty skoroszyt,

00:01:03.035 --> 00:01:08.990
i przejdźmy do
rozpocząć ocenę.

00:01:08.990 --> 00:01:13.625
Więc tutaj można zobaczyć I
mają bardzo prostą kwerendę.

00:01:13.625 --> 00:01:17.030
Mam dwa lokalne
tabel w mojej bazie danych,

00:01:17.030 --> 00:01:19.160
i jeśli uruchomię tę kwerendę,

00:01:19.160 --> 00:01:23.405
można sobie wyobrazić wynik
wraca ładne i szybko.

00:01:23.405 --> 00:01:25.190
Mam około sekundy,

00:01:25.190 --> 00:01:28.045
i otrzymam mój zestaw danych
z powrotem do notebooka.

00:01:28.045 --> 00:01:31.630
Jeśli jednak wszystkie
dane nie było w programie SQL Server?

00:01:31.630 --> 00:01:36.200
Co zrobić, jeśli dane te były rzeczywiście
dostępne w zdalnych serwerach SQL,

00:01:36.200 --> 00:01:40.145
i chcieliśmy uzyskać dostęp do tego
danych w tym samym czasie?

00:01:40.145 --> 00:01:43.700
Cóż, można użyć wirtualizacji danych
rozwiązać ten problem.

00:01:43.700 --> 00:01:45.050
Ale aby to zrobić,

00:01:45.050 --> 00:01:47.030
musimy skonfigurować niektóre metadane.

00:01:47.030 --> 00:01:50.510
Więc pierwszą rzeczą, którą musimy
zrobić, to utworzyć klucz główny,

00:01:50.510 --> 00:01:53.720
i klucz główny to klucz wewnątrz

00:01:53.720 --> 00:01:55.910
bazy danych, której używamy do ochrony

00:01:55.910 --> 00:01:58.660
wszystkich innych metadanych wewnątrz niego.

00:01:58.660 --> 00:02:03.380
Widać z metadanych
tutaj, który algorytm używamy,

00:02:03.380 --> 00:02:06.110
po jego utworzeniu i
ciekawych rzeczy tak.

00:02:06.110 --> 00:02:10.745
Teraz muszę włączyć PolyBase
funkcji, aby móc

00:02:10.745 --> 00:02:16.310
dostęp do źródeł zdalnych
i zdalnych baz danych,

00:02:16.310 --> 00:02:19.220
i utworzyć poświadczenia bazy danych, aby

00:02:19.220 --> 00:02:23.495
być w stanie uwierzytelniać
z tymi zdalnymi źródłami,

00:02:23.495 --> 00:02:28.835
i można zobaczyć tutaj, że mam
stworzył kilka w przeszłości,

00:02:28.835 --> 00:02:30.200
jako para Oracle,

00:02:30.200 --> 00:02:32.225
i kilka SQL
również w nich.

00:02:32.225 --> 00:02:36.680
Ale dzisiaj, mamy zamiar pójść
względem źródła danych SQL,

00:02:36.680 --> 00:02:39.650
i można zobaczyć tutaj, że
w tym celu

00:02:39.650 --> 00:02:41.730
Muszę stworzyć
zewnętrznego źródła danych.

00:02:41.730 --> 00:02:45.390
Tutaj określaj moje
miejscu, w tym przypadku,

00:02:45.390 --> 00:02:49.160
adres programu SQL Server
gdzieś na platformie Azure,

00:02:49.160 --> 00:02:51.874
i zdam w tym poświadczeniu

00:02:51.874 --> 00:02:54.425
, aby włączyć to uwierzytelnianie
się odbyć.

00:02:54.425 --> 00:02:56.590
Więc przejdźmy do przodu i stworzyć, że

00:02:56.590 --> 00:03:00.880
i widać jeszcze raz, nie ma
metadane wewnątrz bazy danych.

00:03:00.880 --> 00:03:03.040
Teraz, co do zasady,

00:03:03.040 --> 00:03:06.290
Lubię utrzymywać zewnętrzną
tabel, które definiują

00:03:06.290 --> 00:03:08.465
te obiekty zewnętrznego źródła danych

00:03:08.465 --> 00:03:11.210
oddzielone od moich wewnętrznych tabel,

00:03:11.210 --> 00:03:12.890
i ja czynić ów przy pomocy pewien schemat.

00:03:12.890 --> 00:03:16.500
Więc przejdźmy do przodu i
Tworzenie schematu zewnętrznego,

00:03:17.660 --> 00:03:23.350
i teraz możemy zejdzie tu i
stworzyć naszą pierwszą zewnętrzną tabelę.

00:03:23.350 --> 00:03:25.730
Pierwsza tabela zewnętrzna
Zamierzamy stworzyć jest

00:03:25.730 --> 00:03:28.240
strumieni kliknij internetowych, które
jest pierwszą tabelą,

00:03:28.240 --> 00:03:31.315
i w tym przypadku jest to
bardziej jak tabela fakt,

00:03:31.315 --> 00:03:34.755
i zamierzamy je przechowywać.

00:03:34.755 --> 00:03:36.490
Tak więc w tej zewnętrznej bazie danych,

00:03:36.490 --> 00:03:38.375
mamy dokładnie tę samą bazę danych.

00:03:38.375 --> 00:03:44.200
Jesteśmy po prostu używać go ponownie, aby
zilustrowania tego scenariusza.

00:03:44.200 --> 00:03:50.515
Teraz możemy dostać się na proces
wirtualizowania strumienia kliknięć,

00:03:50.515 --> 00:03:52.900
tabeli clickstreams sieci Web.

00:03:52.900 --> 00:03:56.500
Tutaj widać, że mam
tej samej tabeli clickstreams sieci Web,

00:03:56.500 --> 00:03:58.660
ale teraz używam schematu EXT.

00:03:58.660 --> 00:04:01.060
Więc mam dostęp do tabeli zewnętrznej,

00:04:01.060 --> 00:04:02.440
ale do wszystkich intencji i celów,

00:04:02.440 --> 00:04:05.630
reszta zapytania
jest dokładnie taka sama.

00:04:05.630 --> 00:04:08.225
Jeśli uruchomię tę kwerendę teraz,

00:04:08.225 --> 00:04:10.120
Powiedzmy, że ma
nieco dłużej, ponieważ

00:04:10.120 --> 00:04:12.100
pójdziemy i
zdalnie uzyskać te dane,

00:04:12.100 --> 00:04:14.905
i można powiedzieć, że to
około 3,5 sekund.

00:04:14.905 --> 00:04:17.260
Ale widzimy, że mamy

00:04:17.260 --> 00:04:20.785
dane tutaj i
jest dokładnie taka sama.

00:04:20.785 --> 00:04:23.710
Więc wszystko pod maską

00:04:23.710 --> 00:04:27.065
jest całkowicie przejrzysty
dla mnie jako użytkownika.

00:04:27.065 --> 00:04:29.920
Teraz co jeśli ja rzeczywiście iść naprzód i

00:04:29.920 --> 00:04:33.250
wirtualizować drugi
tabeli zewnętrznej w tej kwerendzie?

00:04:33.250 --> 00:04:35.680
Pamiętacie, że pierwszy
jeden był Web clipstreams,

00:04:35.680 --> 00:04:38.905
że druga
jest tabelą zapasów.

00:04:38.905 --> 00:04:41.090
Więc przejdźmy do przodu i to zrobić,

00:04:41.090 --> 00:04:45.650
i teraz mam zarówno
tabel zwirtualizowanych.

00:04:47.290 --> 00:04:52.290
Więc teraz, co się dzieje, gdy
Uruchamiam to ostatnie zapytanie?

00:04:52.290 --> 00:04:57.565
To ostatnie zapytanie będzie
uruchomić dokładnie tę samą kwerendę,

00:04:57.565 --> 00:05:01.670
ale zarówno zewnętrzne, jak
tabele są zwirtualizowane,

00:05:01.940 --> 00:05:05.275
i można zobaczyć, że faktycznie
zapytanie jest prawie tak

00:05:05.275 --> 00:05:09.375
szybko jak pierwszy
wersji lokalnej kwerendy.

00:05:09.375 --> 00:05:12.530
Teraz dlaczego to jest? Dlaczego dostajemy
tej różnicy w wydajności?

00:05:12.530 --> 00:05:14.780
Cóż, powodem jest
że jeśli spojrzeć na

00:05:14.780 --> 00:05:17.000
Serwerów SQL
wystarczająco inteligentny za pomocą

00:05:17.000 --> 00:05:20.600
Optymalizator oparty na kosztach
zrozumieć, że

00:05:20.600 --> 00:05:24.725
Obie tabele są zewnętrzne i
pochodzą one z tego samego źródła,

00:05:24.725 --> 00:05:28.400
i że widać, że
może wcisnąć ten sprzężenie i

00:05:28.400 --> 00:05:32.030
agregacja w dół
przed tym zdalnym źródłem.

00:05:32.030 --> 00:05:34.190
Więc jesteśmy wykorzystując moc obliczeniową

00:05:34.190 --> 00:05:37.445
tego źródła zdalnego, aby rozwiązać
tej kwerendy w czasie rzeczywistym.

00:05:37.445 --> 00:05:41.030
Ale to daje szybki przegląd
możliwości, które

00:05:41.030 --> 00:05:44.750
wydostać się z korzystania z danych
Technologia wirtualizacji

00:05:44.750 --> 00:05:48.470
i jak można rzeczywiście
wyraźnie przedstawić, że dane

00:05:48.470 --> 00:05:50.390
z powrotem do użytkownika końcowego bez

00:05:50.390 --> 00:05:52.520
dokonywać fizycznych kopii tych danych,

00:05:52.520 --> 00:05:54.410
bez konieczności przesuwania lub budowania

00:05:54.410 --> 00:05:56.420
złożony rurociąg ETL w

00:05:56.420 --> 00:05:58.910
Aby móc
danych zapytania w czasie rzeczywistym.

00:05:58.910 --> 00:06:00.510
Dziękuję bardzo za dołączenie,

00:06:00.510 --> 00:06:02.960
i czekam na złapanie
już wkrótce.

00:06:02.960 --> 00:06:17.560
MUZYKI