WEBVTT

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

00:00:10.560 --> 00:00:12.975
>> Hey, benvenuto a un nuovo
episodio di Data Exposed.

00:00:12.975 --> 00:00:14.460
Mi chiamo Pedro Lopes.

00:00:14.460 --> 00:00:16.920
Sono un Program Manager nel
Team di progettazione di SQL Server.

00:00:16.920 --> 00:00:18.510
Oggi parlerò

00:00:18.510 --> 00:00:20.670
su Intelligent
Database, in particolare,

00:00:20.670 --> 00:00:23.809
Elaborazione intelligente delle query
in SQL Server 2019,

00:00:23.809 --> 00:00:25.925
e anche il database SQL di Azure.

00:00:25.925 --> 00:00:29.390
Quindi cerchiamo di arrivare ad esso. Sql
Presentato Server 2019

00:00:29.390 --> 00:00:31.864
query rivoluzionaria
miglioramenti delle prestazioni

00:00:31.864 --> 00:00:34.655
e sono l'Intelligente
Famiglia Elaborazione query.

00:00:34.655 --> 00:00:37.820
Questi costituiscono le ultime novità
la missione di Microsoft per assicurarsi che

00:00:37.820 --> 00:00:41.690
che i carichi di lavoro paralleli critici
migliorare quando si corre su larga scala,

00:00:41.690 --> 00:00:45.470
pur rimanendo adattivo al
mondo dei dati in continua evoluzione,

00:00:45.470 --> 00:00:47.855
man mano che i dati si spostano e
database.

00:00:47.855 --> 00:00:49.670
In questo video, ho intenzione di darvi

00:00:49.670 --> 00:00:51.980
una rapida panoramica del
Mondo di database intelligente

00:00:51.980 --> 00:00:53.030
che fa davvero un salto

00:00:53.030 --> 00:00:56.150
in avanti con il prossimo
SQL Server 2019,

00:00:56.150 --> 00:00:58.700
e presentarvi un numero
di caratteristiche che ci tufferemo

00:00:58.700 --> 00:01:02.130
in più profondo in altri
video di questa serie.

00:01:03.170 --> 00:01:07.510
Elaborazione intelligente delle query
in SQL Server è disponibile da

00:01:07.510 --> 00:01:11.245
impostazione predefinita nel database più recente
l'impostazione del livello di compatibilità.

00:01:11.245 --> 00:01:13.210
Ciò significa che dopo l'aggiornamento,

00:01:13.210 --> 00:01:15.130
questo può essere disponibile solo da

00:01:15.130 --> 00:01:18.000
capovolgendo l'interruttore per utilizzare il
l'impostazione di compatibilità più recente.

00:01:18.000 --> 00:01:22.030
Elaborazione intelligente delle query
offre anche un ampio impatto

00:01:22.030 --> 00:01:23.440
che migliora le prestazioni

00:01:23.440 --> 00:01:26.650
carichi di lavoro esistenti con
minimo sforzo di implementazione.

00:01:26.650 --> 00:01:28.390
Questo significa davvero che la maggior parte del tempo,

00:01:28.390 --> 00:01:30.965
non c'è bisogno di zero bisogno di
refactoring del codice.

00:01:30.965 --> 00:01:33.310
Intelligent Query Processing migliora

00:01:33.310 --> 00:01:36.190
carichi di lavoro paralleli critici
quando si esegue su larga scala,

00:01:36.190 --> 00:01:39.355
e man mano che i dati
dal database,

00:01:39.355 --> 00:01:41.380
ci adatteremo a questo e

00:01:41.380 --> 00:01:44.660
mantenere un livello di
prestazioni prevedibili.

00:01:44.660 --> 00:01:47.450
Ad esempio, introducendo

00:01:47.450 --> 00:01:49.880
un meccanismo di feedback
nell'utilizzo della memoria,

00:01:49.880 --> 00:01:53.630
siamo in grado di garantire che il vostro carico di lavoro
viene eseguito in modo prevedibile.

00:01:53.630 --> 00:01:58.190
Se l'esecuzione di una determinata query
forse occupare troppa memoria,

00:01:58.190 --> 00:01:59.750
possiamo correggerlo e

00:01:59.750 --> 00:02:02.375
aumentare la concorrenza
fattore del database.

00:02:02.375 --> 00:02:06.020
Se una data esecuzione azionaria
non ottiene memoria sufficiente e

00:02:06.020 --> 00:02:09.560
finisce per utilizzare ulteriori IO
in tutto è conosciuto come una fuoriuscita,

00:02:09.560 --> 00:02:11.315
allora possiamo anche scoprire che

00:02:11.315 --> 00:02:13.565
e correggere la situazione
in modo che l'operazione

00:02:13.565 --> 00:02:15.260
viene eseguito in memoria e

00:02:15.260 --> 00:02:18.200
funziona come previsto in
esecuzioni successive.

00:02:18.200 --> 00:02:20.540
Questa funzione è ora abilitata per

00:02:20.540 --> 00:02:22.835
tutte le modalità di esecuzione in
il centro dati.

00:02:22.835 --> 00:02:27.170
Modalità batch per un maggiore data warehouse
e carichi di lavoro analitici,

00:02:27.170 --> 00:02:31.410
e la modalità riga per il
carichi di lavoro OLTP critici.

00:02:31.700 --> 00:02:34.640
Stiamo anche andando in nuove aree

00:02:34.640 --> 00:02:37.220
che stiamo chiamando
elaborazione approssimativa delle query.

00:02:37.220 --> 00:02:40.640
Ad esempio, si pensi a uno scenario
dove una società ferroviaria mantiene

00:02:40.640 --> 00:02:42.350
traccia dei numeri dei biglietti che sono

00:02:42.350 --> 00:02:44.935
acquistato e utilizzato nel
l'intero sistema ferroviario.

00:02:44.935 --> 00:02:47.030
Essi tengono traccia di questo
al fine di implementare

00:02:47.030 --> 00:02:49.730
alcune misurazioni di controllo del flusso
quando è necessario,

00:02:49.730 --> 00:02:52.610
forse adattando il
orari dei treni,

00:02:52.610 --> 00:02:53.630
o il numero di treni in

00:02:53.630 --> 00:02:55.810
il sistema per soddisfare il
esigenze del momento.

00:02:55.810 --> 00:02:58.920
Queste informazioni sono anche
aggiornato in una dashboard

00:02:58.920 --> 00:03:02.530
che la gente in centro
Centrale può dare un'occhiata.

00:03:02.530 --> 00:03:04.220
Ora, in questo scenario parte di

00:03:04.220 --> 00:03:06.830
il carico di lavoro sarà sicuramente
per eseguire una query che è

00:03:06.830 --> 00:03:09.020
costantemente alla ricerca di ottenere

00:03:09.020 --> 00:03:12.005
il conteggio delle righe di tutti i
biglietti venduti e utilizzati,

00:03:12.005 --> 00:03:14.600
e questo è probabilmente
proveniente da un molto

00:03:14.600 --> 00:03:17.605
grande stabile forse con
miliardi e miliardi di righe.

00:03:17.605 --> 00:03:20.540
Ora, questa query ricorrente
normalmente prendere

00:03:20.540 --> 00:03:23.735
notevoli risorse su
server, vale a dire la memoria.

00:03:23.735 --> 00:03:25.639
Se viene eseguito ripetutamente,

00:03:25.639 --> 00:03:26.690
può davvero influenzare

00:03:26.690 --> 00:03:28.900
le caratteristiche delle prestazioni
del database.

00:03:28.900 --> 00:03:30.670
Tuttavia, in questo scenario,

00:03:30.670 --> 00:03:32.750
la compagnia ferroviaria
non ha necessariamente bisogno

00:03:32.750 --> 00:03:35.830
un conteggio effettivo di tutti i
biglietti che vengono venduti e utilizzati.

00:03:35.830 --> 00:03:37.790
Ma un altissimo
l'approssimazione è sufficiente

00:03:37.790 --> 00:03:40.280
per innescare tutte le
il processo decisionale richiesto.

00:03:40.280 --> 00:03:42.935
Questo è dove approssimativo
conteggio distinto entra in gioco,

00:03:42.935 --> 00:03:45.500
consentendo una query
per ottenere ripetutamente

00:03:45.500 --> 00:03:48.185
il conteggio approssimativo
di biglietti venduti e utilizzati

00:03:48.185 --> 00:03:51.080
senza i gravi impatti di
le prestazioni del database che

00:03:51.080 --> 00:03:55.420
la query di conteggio normale
avrebbe preso oggi.

00:03:55.640 --> 00:03:58.695
Abilitando la modalità Batch nell'archivio righe,

00:03:58.695 --> 00:03:59.950
scateniamo efficacemente

00:03:59.950 --> 00:04:02.150
la modalità di elaborazione che è
particolarmente ottimizzato

00:04:02.150 --> 00:04:05.975
per i carichi di lavoro analitici oltre
qualsiasi tabella del database.

00:04:05.975 --> 00:04:08.180
Ciò significa che anche
per gli scenari in cui

00:04:08.180 --> 00:04:10.385
un indice dell'archivio colonne
non sarebbe un'opzione,

00:04:10.385 --> 00:04:14.395
il motore di database può ancora
eseguire questo in modo ottimizzato.

00:04:14.395 --> 00:04:17.375
A sua volta, questo apre l'ambito

00:04:17.375 --> 00:04:20.630
funzioni come Adaptive join
che devono essere utilizzati dal carico di lavoro.

00:04:20.630 --> 00:04:24.170
Join adattivo che è solo
disponibili in modalità batch può

00:04:24.170 --> 00:04:28.940
ora essere sfruttato in tutti i
tabelle e la maggior parte dei carichi di lavoro.

00:04:29.590 --> 00:04:33.170
Abbiamo anche affrontato alcune delle
anti-modelli più ricorrenti

00:04:33.170 --> 00:04:36.260
che diventano un problema per
carichi di lavoro di SQL Server gestiti.

00:04:36.260 --> 00:04:38.150
L'uso della tabella
Variabili e utilizzo

00:04:38.150 --> 00:04:40.105
delle funzioni definite dall'utente scalari, ad esempio,

00:04:40.105 --> 00:04:42.440
e ora siamo in grado di sbloccare nuovi livelli di

00:04:42.440 --> 00:04:46.375
ottimizzazione delle query che sono stati
possibile fino a poco tempo fa.

00:04:46.375 --> 00:04:49.310
Tutto questo, faremo
discutere più in profondità e con

00:04:49.310 --> 00:04:51.080
demo nei prossimi video in

00:04:51.080 --> 00:04:53.270
la serie circa il
database intelligente,

00:04:53.270 --> 00:04:56.020
specificamente intelligente
l'elaborazione delle query.

00:04:56.020 --> 00:04:59.505
Ma se volete sapere
di più su di esso oggi,

00:04:59.505 --> 00:05:04.200
poi si prega di andare a questo aka.ms/IQP

00:05:04.200 --> 00:05:06.899
URL in cui vengono visualizzati tutti
la documentazione

00:05:06.899 --> 00:05:09.535
su Intelligent Query
Elaborazione nei database SQL.

00:05:09.535 --> 00:05:13.100
Se si desidera sperimentare alcuni
di questi da soli in questo momento,

00:05:13.100 --> 00:05:16.040
abbiamo anche demo che
si può guardare se si

00:05:16.040 --> 00:05:18.980
vai al nostro repository GitHub
e l'URL breve sarebbe

00:05:18.980 --> 00:05:22.430
essere aka.ms/IQPDemos dove ti

00:05:22.430 --> 00:05:25.900
essere in grado di guardare a tutti questi
caratteristiche e sperimentare da soli.

00:05:25.900 --> 00:05:27.795
Quindi, di nuovo, fare attenzione.

00:05:27.795 --> 00:05:28.980
Parlerò con te presto.

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