WEBVTT

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

00:00:10.500 --> 00:00:11.910
>> Ciao e bentornato.

00:00:11.910 --> 00:00:14.970
Mi chiamo JRJ, e sono qui
per parlarvi di uno dei

00:00:14.970 --> 00:00:18.915
il più ansiosamente atteso
funzionalità di SQL Server 2019,

00:00:18.915 --> 00:00:21.285
e questa è la virtualizzazione dei dati.

00:00:21.285 --> 00:00:23.175
Che cos'è la virtualizzazione dei dati,

00:00:23.175 --> 00:00:25.440
e perché è così ansiosamente anticipato?

00:00:25.440 --> 00:00:27.510
Beh, in poche parole,

00:00:27.510 --> 00:00:29.510
la virtualizzazione dei dati consente di

00:00:29.510 --> 00:00:31.670
riunire tutti i dati

00:00:31.670 --> 00:00:35.780
tempo di query, piuttosto che dover
costruire pipeline ETL complesse in

00:00:35.780 --> 00:00:40.535
per essere in grado di unificare
i dati in una singola query.

00:00:40.535 --> 00:00:44.150
Quindi quello che ho intenzione di
fare è piuttosto che andare

00:00:44.150 --> 00:00:47.540
attraverso i dettagli dei dati
virtualizzazione a livello concettuale,

00:00:47.540 --> 00:00:49.730
Vi mostrerò solo
le differenze tra

00:00:49.730 --> 00:00:52.430
una query locale e un
query virtualizzata,

00:00:52.430 --> 00:00:55.085
sia parzialmente che completamente virtualizzato.

00:00:55.085 --> 00:00:56.280
Quindi, per farlo,

00:00:56.280 --> 00:00:58.010
quello che stiamo andando a fare è
stiamo andando a passare sopra

00:00:58.010 --> 00:01:00.270
ora in Azure Data Studio,

00:01:00.270 --> 00:01:03.035
e potete vedere qui io
avere una cartella di lavoro aperta,

00:01:03.035 --> 00:01:08.990
e andiamo in e
iniziare a valutarlo.

00:01:08.990 --> 00:01:13.625
Così qui potete vedere io
avere una query molto semplice.

00:01:13.625 --> 00:01:17.030
Ho due locali
tabelle nel database,

00:01:17.030 --> 00:01:19.160
e se eseguo quella query,

00:01:19.160 --> 00:01:23.405
si potrebbe immaginare il risultato
torna bello e rapidamente.

00:01:23.405 --> 00:01:25.190
Ho circa un secondo,

00:01:25.190 --> 00:01:28.045
e ottengo il mio set di dati
nel taccuino.

00:01:28.045 --> 00:01:31.630
Tuttavia, cosa succede se tutto ciò
dati non era in SQL Server?

00:01:31.630 --> 00:01:36.200
E se i dati erano in realtà
disponibile in SQL Server remoti,

00:01:36.200 --> 00:01:40.145
e volevamo accedere a quella
tutti allo stesso tempo?

00:01:40.145 --> 00:01:43.700
Beh, è possibile utilizzare la virtualizzazione dei dati
per risolvere questo problema.

00:01:43.700 --> 00:01:45.050
Ma per farlo,

00:01:45.050 --> 00:01:47.030
abbiamo bisogno di impostare alcuni metadati.

00:01:47.030 --> 00:01:50.510
Quindi la prima cosa che dobbiamo
fare è creare una chiave master,

00:01:50.510 --> 00:01:53.720
e una chiave master è una chiave all'interno

00:01:53.720 --> 00:01:55.910
il database che usiamo per proteggere

00:01:55.910 --> 00:01:58.660
tutti gli altri metadati al suo interno.

00:01:58.660 --> 00:02:03.380
È possibile vedere dai metadati
qui quale algoritmo stiamo usando,

00:02:03.380 --> 00:02:06.110
quando viene creato, e
cose interessanti del genere.

00:02:06.110 --> 00:02:10.745
Ora ho bisogno di abilitare il PolyBase
funzione per essere in grado di

00:02:10.745 --> 00:02:16.310
accedere a fonti remote
e database remoti,

00:02:16.310 --> 00:02:19.220
e creare una credenziale del database per

00:02:19.220 --> 00:02:23.495
essere in grado di autenticare
contro quelle fonti remote,

00:02:23.495 --> 00:02:28.835
e potete vedere qui che ho
ne hanno creati alcuni in passato,

00:02:28.835 --> 00:02:30.200
come un paio di Oracle,

00:02:30.200 --> 00:02:32.225
e un paio di SQL
quelli in là pure.

00:02:32.225 --> 00:02:36.680
Ma oggi, stiamo andando a
su un'origine dati SQL,

00:02:36.680 --> 00:02:39.650
e potete vedere qui che
per farlo,

00:02:39.650 --> 00:02:41.730
Ho bisogno di creare un
origine dati esterna.

00:02:41.730 --> 00:02:45.390
Qui, specificherò il mio
posizione, in questo caso,

00:02:45.390 --> 00:02:49.160
un indirizzo SQL Server
da qualche parte in Azure,

00:02:49.160 --> 00:02:51.874
e passo in quella credenziale

00:02:51.874 --> 00:02:54.425
per abilitare tale autenticazione
luogo.

00:02:54.425 --> 00:02:56.590
Quindi andiamo avanti e creare che,

00:02:56.590 --> 00:03:00.880
e si può vedere di nuovo, c'è
i metadati all'interno del database.

00:03:00.880 --> 00:03:03.040
Ora, come regola generale,

00:03:03.040 --> 00:03:06.290
Mi piace mantenere l'esterno
tabelle che definiscono

00:03:06.290 --> 00:03:08.465
tali oggetti origine dati esterna

00:03:08.465 --> 00:03:11.210
separato dalle mie tabelle interne,

00:03:11.210 --> 00:03:12.890
e lo faccio usando uno schema.

00:03:12.890 --> 00:03:16.500
Quindi andiamo avanti e
creare uno schema esterno,

00:03:17.660 --> 00:03:23.350
e ora possiamo venire qui e
creare la nostra prima tabella esterna.

00:03:23.350 --> 00:03:25.730
La prima tabella esterna
stiamo andando a creare è

00:03:25.730 --> 00:03:28.240
flussi di clic sul web che
è la prima tabella,

00:03:28.240 --> 00:03:31.315
e in questo caso è
più simile a una tabella dei fatti,

00:03:31.315 --> 00:03:34.755
e lo memorizzeremo.

00:03:34.755 --> 00:03:36.490
Quindi, in quel database esterno,

00:03:36.490 --> 00:03:38.375
abbiamo esattamente lo stesso database.

00:03:38.375 --> 00:03:44.200
Lo stiamo solo usando di nuovo per
illustrare questo scenario.

00:03:44.200 --> 00:03:50.515
Ora, possiamo entrare nel processo
di virtualizzare un clickstream,

00:03:50.515 --> 00:03:52.900
nella tabella dei clickstream Web.

00:03:52.900 --> 00:03:56.500
Qui potete vedere che ho il
stesso clickstream web tabella,

00:03:56.500 --> 00:03:58.660
ma ora sto usando lo schema EXT.

00:03:58.660 --> 00:04:01.060
Quindi sto accedendo alla tabella esterna,

00:04:01.060 --> 00:04:02.440
ma a tutti gli effetti,

00:04:02.440 --> 00:04:05.630
il resto della query
è esattamente lo stesso.

00:04:05.630 --> 00:04:08.225
Se eseguo la query ora,

00:04:08.225 --> 00:04:10.120
diciamo che ci vuole un
un po 'più a lungo perché

00:04:10.120 --> 00:04:12.100
stiamo andando ad andare e
ottenere quei dati da remoto,

00:04:12.100 --> 00:04:14.905
e si potrebbe dire che è
circa 3,5 secondi.

00:04:14.905 --> 00:04:17.260
Ma possiamo vedere che abbiamo

00:04:17.260 --> 00:04:20.785
che i dati qui e
è esattamente lo stesso.

00:04:20.785 --> 00:04:23.710
Quindi tutto sotto il cofano

00:04:23.710 --> 00:04:27.065
è completamente trasparente
a me come utente.

00:04:27.065 --> 00:04:29.920
Ora, cosa succede se io effettivamente andare avanti e

00:04:29.920 --> 00:04:33.250
virtualizzare il secondo
tabella esterna in questa query?

00:04:33.250 --> 00:04:35.680
Ti ricordi che il primo
uno era clipstream web,

00:04:35.680 --> 00:04:38.905
che il secondo
è la tabella degli articoli.

00:04:38.905 --> 00:04:41.090
Quindi andiamo avanti e facciamolo,

00:04:41.090 --> 00:04:45.650
e ora ho entrambi
tabelle virtualizzate.

00:04:47.290 --> 00:04:52.290
Così ora, cosa succede quando
Ho eseguito quest'ultima domanda?

00:04:52.290 --> 00:04:57.565
Quest'ultima query sta per
eseguire esattamente la stessa query,

00:04:57.565 --> 00:05:01.670
ma sia esterni
le tabelle sono virtualizzate,

00:05:01.940 --> 00:05:05.275
e si può vedere che in realtà
la query è quasi come

00:05:05.275 --> 00:05:09.375
veloce come il primo
versione, la query locale.

00:05:09.375 --> 00:05:12.530
E perché? Perché otteniamo
questa differenza di prestazioni?

00:05:12.530 --> 00:05:14.780
Beh, il motivo è
che se si guarda

00:05:14.780 --> 00:05:17.000
SQL Server
abbastanza intelligente utilizzando

00:05:17.000 --> 00:05:20.600
il suo ottimizzatore basato sui costi
per capire che

00:05:20.600 --> 00:05:24.725
entrambe le tabelle sono esterne e
provengono dalla stessa fonte,

00:05:24.725 --> 00:05:28.400
e che si può vedere che
può spingere questo giunto e

00:05:28.400 --> 00:05:32.030
l'aggregazione verso il basso
contro quella fonte remota.

00:05:32.030 --> 00:05:34.190
Quindi stiamo sfruttando l'elaborazione di

00:05:34.190 --> 00:05:37.445
che l'origine remota per risolvere
questa query in tempo reale.

00:05:37.445 --> 00:05:41.030
Ma questo ti dà una rapida panoramica
delle capacità che si

00:05:41.030 --> 00:05:44.750
uscire dall'utilizzo dei dati
tecnologia di virtualizzazione

00:05:44.750 --> 00:05:48.470
e come si può effettivamente
presentare in modo trasparente tali dati

00:05:48.470 --> 00:05:50.390
a un utente finale senza dover

00:05:50.390 --> 00:05:52.520
fare copie fisiche di tali dati,

00:05:52.520 --> 00:05:54.410
senza doverlo spostare o costruire

00:05:54.410 --> 00:05:56.420
una complessa pipeline ETL in

00:05:56.420 --> 00:05:58.910
per essere in grado di
eseguire query sui dati in tempo reale.

00:05:58.910 --> 00:06:00.510
Grazie mille per aver aderito,

00:06:00.510 --> 00:06:02.960
e non vedo l'ora di catturare
con voi di nuovo presto.

00:06:02.960 --> 00:06:17.560
[MUSICA]