WEBVTT

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

00:00:10.530 --> 00:00:13.170
>> Ehi tutti. Benvenuti a
questo episodio di dati esposti.

00:00:13.170 --> 00:00:15.240
Sono Travis Wright Group
Product Manager per

00:00:15.240 --> 00:00:18.435
i dati di SQL Server e Azure
team di progettazione presso Microsoft.

00:00:18.435 --> 00:00:22.335
Oggi sono entusiasta di presentare
a voi un SQL Server 2019,

00:00:22.335 --> 00:00:24.945
l'ultima versione rilasciata di SQL Server.

00:00:24.945 --> 00:00:28.515
SQL Server sta celebrando la sua
25o anniversario quest'anno.

00:00:28.515 --> 00:00:31.830
È un bel po'. Guardando indietro
nei primi giorni della mia carriera,

00:00:31.830 --> 00:00:34.230
Ho iniziato su SQL Server 2000.

00:00:34.230 --> 00:00:36.300
In quei 25 anni di storia,

00:00:36.300 --> 00:00:38.490
SQL Server ha davvero
venire una lunga strada.

00:00:38.490 --> 00:00:40.050
E 'davvero ampliato per soddisfare

00:00:40.050 --> 00:00:42.030
le esigenze del nostro
clienti nel tempo come

00:00:42.030 --> 00:00:44.390
i diversi tipi di dati
che i clienti devono

00:00:44.390 --> 00:00:47.060
raccogliere ed elaborare
e la query è cambiata,

00:00:47.060 --> 00:00:49.310
e come c'è stato più
e diversi tipi di

00:00:49.310 --> 00:00:51.965
requisiti del motore di database
che sono venuti avanti.

00:00:51.965 --> 00:00:54.470
Quindi facciamo un viaggio indietro
memoria in giù corsia per

00:00:54.470 --> 00:00:57.515
un momento e basta guardare dove
SQL Server è venuto da,

00:00:57.515 --> 00:00:59.390
e poi daremo un'occhiata
a dove SQL Server è

00:00:59.390 --> 00:01:02.515
andando avanti con SQL Server 2019.

00:01:02.515 --> 00:01:05.350
Iniziamo con SQL Server 2008.

00:01:05.350 --> 00:01:07.295
SQL Server 2008 è in realtà

00:01:07.295 --> 00:01:09.995
fuori supporto esteso
proprio quest'anno.

00:01:09.995 --> 00:01:14.390
Se si avanza veloce un po 'a guardare
in SQL Server 2012 e 2014,

00:01:14.390 --> 00:01:17.870
abbiamo davvero fatto alcuni grandi miglioramenti
in termini di prestazioni e

00:01:17.870 --> 00:01:19.880
elevata disponibilità
introdurre sempre

00:01:19.880 --> 00:01:22.565
sui gruppi di disponibilità
per un'elevata disponibilità,

00:01:22.565 --> 00:01:24.500
e nelle capacità di memoria per davvero

00:01:24.500 --> 00:01:26.845
migliorare le prestazioni
dei database.

00:01:26.845 --> 00:01:29.630
In SQL Server 2016 e 2017,

00:01:29.630 --> 00:01:31.295
abbiamo davvero cambiare il gioco un sacco

00:01:31.295 --> 00:01:33.320
con l'introduzione di alcuni
nuove funzionalità in

00:01:33.320 --> 00:01:37.885
SQL Server per archiviare ed eseguire query
JSON e grafico pure,

00:01:37.885 --> 00:01:41.210
e abbiamo anche fatto qualcosa
molto sorprendente portando

00:01:41.210 --> 00:01:45.580
DA SQL Server a Linux e
contenitori in SQL Server 2017.

00:01:45.580 --> 00:01:47.895
In SQL Server 2019,

00:01:47.895 --> 00:01:49.540
stiamo cambiando il gioco ancora una volta,

00:01:49.540 --> 00:01:50.840
e davvero in espansione e

00:01:50.840 --> 00:01:53.480
ridefinire la definizione
di SQL Server.

00:01:53.480 --> 00:01:55.490
SQL Server, naturalmente, è ancora

00:01:55.490 --> 00:01:58.220
il database relazionale
che è stato 25 anni fa.

00:01:58.220 --> 00:02:00.770
È ancora possibile memorizzare
i dati in SQL Server

00:02:00.770 --> 00:02:03.335
ed eseguirne una query nello stesso
modo che hai sempre.

00:02:03.335 --> 00:02:06.560
Ma allo stesso tempo, siamo
ridefinendo SQL Server e

00:02:06.560 --> 00:02:09.920
estenderlo ben oltre il solo
lo spazio del database relazionale.

00:02:09.920 --> 00:02:14.135
Quindi diamo un'occhiata a ciò che
stiamo facendo in SQL Server 2019.

00:02:14.135 --> 00:02:17.045
In SQL Server 2019,

00:02:17.045 --> 00:02:18.380
ti stiamo dando accesso

00:02:18.380 --> 00:02:20.420
per eseguire query ed elaborare i dati

00:02:20.420 --> 00:02:23.990
al di fuori del confine di un
dell'istanza di SQL Server tradizionale.

00:02:23.990 --> 00:02:26.840
Prendendo PolyBase una caratteristica che

00:02:26.840 --> 00:02:30.445
introdotto in SQL Server
2016 al livello successivo.

00:02:30.445 --> 00:02:34.280
PolyBase consente di creare un
livello di virtualizzazione dei dati in tutto

00:02:34.280 --> 00:02:36.170
più diversi
origini dati come

00:02:36.170 --> 00:02:38.810
Oracle altre istanze di SQL Server.

00:02:38.810 --> 00:02:42.460
Dati Tera, MongoDB e molto altro ancora.

00:02:42.460 --> 00:02:46.460
Abbiamo anche preso HDFS e
scintilla e costruirlo nella scatola.

00:02:46.460 --> 00:02:48.230
Così ora con SQL Server,

00:02:48.230 --> 00:02:52.370
è possibile elaborare e memorizzare
dati la scala petabyte e

00:02:52.370 --> 00:02:57.650
elaborare e memorizzare i dati che sono
sono anche dati non strutturati.

00:02:57.650 --> 00:03:01.520
È possibile utilizzare SQL Server con
praticamente qualsiasi linguaggio di programmazione.

00:03:01.520 --> 00:03:04.310
Si può eseguire su abbastanza
praticamente qualsiasi piattaforma ora.

00:03:04.310 --> 00:03:06.155
Con SQL Server 2019,

00:03:06.155 --> 00:03:08.000
è possibile eseguirlo su Windows, naturalmente.

00:03:08.000 --> 00:03:11.345
È anche possibile eseguirlo su
Linux su Red Hat, su Susa,

00:03:11.345 --> 00:03:13.670
o Ubuntu, è possibile eseguire
in un contenitore,

00:03:13.670 --> 00:03:15.320
si può eseguire su Kubernetes.

00:03:15.320 --> 00:03:18.875
È possibile eseguirlo su un
architetture di processore ora.

00:03:18.875 --> 00:03:20.630
Con il perimetro del database SQL di Azure,

00:03:20.630 --> 00:03:24.640
si può eseguire su un braccio 64
dispositivo come un Raspberry Pi,

00:03:24.640 --> 00:03:27.680
e si può eseguire nel
Database SQL di Cloud e Azure,

00:03:27.680 --> 00:03:29.030
oppure è possibile eseguirlo in locale,

00:03:29.030 --> 00:03:31.115
o si può eseguire e
altri Cloud pubblici.

00:03:31.115 --> 00:03:32.720
C'è molta versatilità lì.

00:03:32.720 --> 00:03:36.130
È possibile utilizzare SQL Server ovunque
ti si addice di più.

00:03:36.130 --> 00:03:39.290
SQL Server 2019 continua a

00:03:39.290 --> 00:03:42.190
espandere la nostra azienda leader nel settore
Prestazione.

00:03:42.190 --> 00:03:45.710
SQL Server si è stabilito
per molti anni ora come il numero

00:03:45.710 --> 00:03:49.490
1 in termini di prestazioni OLTP
con i benchmark TPC-H,

00:03:49.490 --> 00:03:50.990
e come il numero 1 in termini di

00:03:50.990 --> 00:03:54.050
prestazioni del data warehouse
con i benchmark TPC-H.

00:03:54.050 --> 00:03:56.090
Abbiamo anche guidato il settore avendo

00:03:56.090 --> 00:03:58.670
il minor numero di
vulnerabilità segnalate da qualsiasi

00:03:58.670 --> 00:04:01.910
dei principali motori di database
negli ultimi otto anni

00:04:01.910 --> 00:04:06.010
secondo l'Istituto Nazionale
standard e tecnologie.

00:04:06.010 --> 00:04:08.330
Quindi prendiamo un più vicino
guardare solo alcuni dei

00:04:08.330 --> 00:04:11.075
principali di SQL Server 2019.

00:04:11.075 --> 00:04:12.770
Cominciamo con alcuni
miglioramenti che stiamo

00:04:12.770 --> 00:04:15.005
nello spazio delle prestazioni.

00:04:15.005 --> 00:04:17.600
Quindi, prima di tutto, la memoria persistente come

00:04:17.600 --> 00:04:20.585
una nuova tecnologia che è
entrare nel mercato dell'hardware.

00:04:20.585 --> 00:04:22.730
Ne abbiamo approfittato
di memoria persistente

00:04:22.730 --> 00:04:24.785
per aumentare davvero le prestazioni.

00:04:24.785 --> 00:04:27.230
Non c'è bisogno di fare alcun
modifiche all'applicazione,

00:04:27.230 --> 00:04:28.430
ed è possibile memorizzare i dati e

00:04:28.430 --> 00:04:31.330
memoria persistente per
prestazioni più veloci.

00:04:31.330 --> 00:04:34.030
In secondo luogo, per
elaborazione delle query,

00:04:34.030 --> 00:04:36.440
abbiamo davvero ampliato il
famiglia di caratteristiche qui

00:04:36.440 --> 00:04:38.990
come si può vedere in questo
grafico per includere lotti

00:04:38.990 --> 00:04:41.615
di nuovi modi in cui il
query optimizer può

00:04:41.615 --> 00:04:45.679
imparare nel tempo sulla base del
l'esecuzione di come vanno le query,

00:04:45.679 --> 00:04:48.935
come le esecuzioni future di quelli
query possono essere migliorate,

00:04:48.935 --> 00:04:51.560
migliorare le prestazioni
delle vostre applicazioni oltre

00:04:51.560 --> 00:04:55.225
tempo senza dover cambiare
qualsiasi cosa nelle vostre applicazioni,

00:04:55.225 --> 00:04:57.980
e infine, abbiamo messo il TempDB in

00:04:57.980 --> 00:05:01.415
memoria per una memoria ancora più veloce
prestazioni del database temporaneo.

00:05:01.415 --> 00:05:03.650
Quindi, diamo un'occhiata a
alcuni miglioramenti siamo

00:05:03.650 --> 00:05:05.690
sicurezza e conformità.

00:05:05.690 --> 00:05:08.330
Prima di tutto, soprattutto con il GDPR,

00:05:08.330 --> 00:05:09.905
i clienti si trovano ad affrontare

00:05:09.905 --> 00:05:13.220
ancora più requisiti normativi
che devono incontrare.

00:05:13.220 --> 00:05:14.720
Per renderlo più facile,

00:05:14.720 --> 00:05:18.230
forniamo la classificazione dei dati
funzionalità scacciate dalla scatola.

00:05:18.230 --> 00:05:21.850
È possibile puntare la classificazione dei dati
motore al vostro database,

00:05:21.850 --> 00:05:23.555
e scoprirà automaticamente

00:05:23.555 --> 00:05:25.130
i diversi tipi
dei dati che avete in

00:05:25.130 --> 00:05:29.425
database, ad esempio
PCI o dati GDPR,

00:05:29.425 --> 00:05:31.790
e automaticamente
classificare che e produrre

00:05:31.790 --> 00:05:34.670
rapporti per voi come si vede
in questo screenshot qui,

00:05:34.670 --> 00:05:37.625
ed è possibile definire il proprio
regole di classificazione.

00:05:37.625 --> 00:05:39.470
Il prossimo in termini di sicurezza,

00:05:39.470 --> 00:05:43.340
abbiamo migliorato Always Encrypted
la nostra crittografia lato client

00:05:43.340 --> 00:05:44.645
tecnologia che consente di

00:05:44.645 --> 00:05:47.630
separare la crittografia
dal database.

00:05:47.630 --> 00:05:50.270
In questo modo, il
amministratori di database

00:05:50.270 --> 00:05:53.120
non è in grado di decrittografare i dati in
il database che permette

00:05:53.120 --> 00:05:55.640
di separare i doveri qui tra

00:05:55.640 --> 00:05:56.840
gli amministratori del database e

00:05:56.840 --> 00:05:59.425
sviluppatori e utenti dell'applicazione,

00:05:59.425 --> 00:06:01.910
e infine solo come esempio qui di

00:06:01.910 --> 00:06:03.950
miglioramenti che siamo
fare come abbiamo anche

00:06:03.950 --> 00:06:06.230
aggiunto l'esecuzione della crittografia

00:06:06.230 --> 00:06:09.480
di tutti i dati all'interno delle enclavi.

00:06:10.160 --> 00:06:15.050
Ora, nello spazio dello sviluppatore
e gli strumenti DBA, si spera,

00:06:15.050 --> 00:06:16.670
tutti avete imparato e provato

00:06:16.670 --> 00:06:19.595
Azure Data Studio a
nuova piattaforma multipiattaforma

00:06:19.595 --> 00:06:22.550
strumento open source per tutti i tipi

00:06:22.550 --> 00:06:25.190
della persona di dati come se sei
un amministratore di database,

00:06:25.190 --> 00:06:28.415
un ingegnere di database,
o un data scientist.

00:06:28.415 --> 00:06:33.350
Questo strumento è disponibile per te
da scaricare gratuitamente e utilizzare,

00:06:33.350 --> 00:06:35.225
ed è progettato per essere

00:06:35.225 --> 00:06:39.200
Motore di database multidatabase in modo da poter
usarlo non solo con SQL Server,

00:06:39.200 --> 00:06:41.510
ma anche con SQL Server in

00:06:41.510 --> 00:06:44.060
il Cloud come
Database SQL di Azure o

00:06:44.060 --> 00:06:46.460
con i dati SQL di Azure
magazzino anche con

00:06:46.460 --> 00:06:49.370
altri motori di database
come PostgreSQL e MySQL.

00:06:49.370 --> 00:06:52.460
Uno dei miglioramenti che
le persone sono più entusiasti

00:06:52.460 --> 00:06:55.340
e Azure Data Studio è
l'esperienza del notebook.

00:06:55.340 --> 00:06:58.550
I blocchi appunti consentono di creare
un file che contiene il segno

00:06:58.550 --> 00:07:01.670
verso il basso e le celle di codice.

00:07:01.670 --> 00:07:03.380
Nel markdown, è possibile descrivere

00:07:03.380 --> 00:07:06.470
qualche analisi che si sta facendo o
passaggi che devono essere eseguiti,

00:07:06.470 --> 00:07:08.240
e poi nelle celle di codice che sono

00:07:08.240 --> 00:07:10.640
mescolato con
quelle celle markdown,

00:07:10.640 --> 00:07:13.705
si può avere un po 'di codice che si
o qualcun altro può eseguire.

00:07:13.705 --> 00:07:17.250
Abbiamo quaderni per
TSQL, per PowerShell,

00:07:17.250 --> 00:07:20.240
per Python, e si

00:07:20.240 --> 00:07:23.075
può eseguirlo localmente
oppure è possibile eseguirlo in Spark.

00:07:23.075 --> 00:07:25.910
È un potente
modo per collaborare con

00:07:25.910 --> 00:07:29.915
altre persone catturando questo
informazioni e taccuini,

00:07:29.915 --> 00:07:32.180
e questi quaderni
può essere utilizzato per catturare

00:07:32.180 --> 00:07:35.450
campioni o forse qualche standard
procedure operative o

00:07:35.450 --> 00:07:38.180
guide alla risoluzione dei problemi e condividere
quelli con altre persone attraverso

00:07:38.180 --> 00:07:42.085
l'integrazione Git che abbiamo
incorporato in Azure Data Studio,

00:07:42.085 --> 00:07:43.685
e, infine, abbiamo integrato

00:07:43.685 --> 00:07:45.650
una tecnologia davvero cool da

00:07:45.650 --> 00:07:48.290
Microsoft Research ha chiamato
SandDance che permette

00:07:48.290 --> 00:07:51.725
di fare dati ad hoc
visualizzazione ed esplorazione

00:07:51.725 --> 00:07:54.020
utilizzando alcuni davvero cool
funzionalità di creazione di grafici

00:07:54.020 --> 00:07:55.975
proprio lì all'interno di
Azure Data Studio.Azure Data Studio.

00:07:55.975 --> 00:07:59.585
Quindi sicuramente, andare a prendere Azure Data
Studio se non l'hai già fatto.

00:07:59.585 --> 00:08:01.280
È uno strumento super potente,

00:08:01.280 --> 00:08:03.950
e l'innovazione sta arrivando
lì su base mensile come abbiamo

00:08:03.950 --> 00:08:07.640
rilascio ogni mese
per Azure Data Studio.

00:08:07.640 --> 00:08:11.270
Quindi continuiamo a raddoppiare

00:08:11.270 --> 00:08:14.180
il nostro nuovo approccio

00:08:14.180 --> 00:08:16.820
come guardiamo diversi
piattaforme per SQL Server.

00:08:16.820 --> 00:08:18.500
In SQL Server 2017,

00:08:18.500 --> 00:08:20.465
abbiamo introdotto il supporto per Linux.

00:08:20.465 --> 00:08:22.100
Ma SQL Server 2019,

00:08:22.100 --> 00:08:24.470
stiamo prendendo che al
passo successivo creando

00:08:24.470 --> 00:08:27.620
ancora più parodia caratteristica
tra SQL Server in Windows,

00:08:27.620 --> 00:08:31.875
e SQL Server su Linux portando
PolyBase e tutti i servizi,

00:08:31.875 --> 00:08:35.680
coordinatore delle transazioni distribuite
e la replica su Linux,

00:08:35.680 --> 00:08:37.160
e che praticamente controlla

00:08:37.160 --> 00:08:39.515
tutte le scatole per il
funzionalità del motore di database.

00:08:39.515 --> 00:08:42.200
Quindi hai quasi 100
compatibilità percentuale

00:08:42.200 --> 00:08:45.695
tra SQL Server in Windows
e SQL Server su Linux.

00:08:45.695 --> 00:08:47.450
In collaborazione con Red Hat,

00:08:47.450 --> 00:08:49.880
abbiamo anche creato rel
immagini di contenitori basate

00:08:49.880 --> 00:08:52.585
disponibili sul
Registro contenitori Microsoft,

00:08:52.585 --> 00:08:54.170
e si può scoprire in

00:08:54.170 --> 00:08:56.675
il Contenitore Cappello Rosso
catalogo pure.

00:08:56.675 --> 00:08:58.730
Infine in anteprima in questo momento,

00:08:58.730 --> 00:09:02.080
abbiamo il sostegno per sempre in
gruppi di disponibilità in Kubernetes,

00:09:02.080 --> 00:09:04.610
in modo da poter ottenere il
benefici di avere sempre in

00:09:04.610 --> 00:09:07.415
gruppi di disponibilità
per le letture di scalabilità orizzontale

00:09:07.415 --> 00:09:09.350
o per l'alta disponibilità

00:09:09.350 --> 00:09:13.760
vivere proprio lì in cima al
Kubernetes strato sotto.

00:09:13.970 --> 00:09:17.270
Infine, probabilmente il
area più significativa

00:09:17.270 --> 00:09:19.040
di miglioramenti e solo

00:09:19.040 --> 00:09:21.290
diffondendo la tenda
di SQL Server se si

00:09:21.290 --> 00:09:24.215
volontà di gestire nuovi
tipi di scenari,

00:09:24.215 --> 00:09:26.540
sono i miglioramenti che
stiamo facendo in PolyBase

00:09:26.540 --> 00:09:28.850
e la virtualizzazione dei dati come ho
menzionato all'inizio,

00:09:28.850 --> 00:09:30.140
dove possiamo creare

00:09:30.140 --> 00:09:31.760
un livello di virtualizzazione dei dati

00:09:31.760 --> 00:09:33.890
molti dati diversi
fonti come Oracle,

00:09:33.890 --> 00:09:37.755
altro SQL Server
e Teradata.

00:09:37.755 --> 00:09:40.100
Questo ci permette di portare
insieme i dati in tutto

00:09:40.100 --> 00:09:42.800
più origini dati in fase di query,

00:09:42.800 --> 00:09:44.840
e davvero minimizzare
la necessità di utilizzare

00:09:44.840 --> 00:09:47.420
ETL come modo per integrare
i nostri dati insieme.

00:09:47.420 --> 00:09:50.705
A nessuno piace costruire e
manutenzione delle pipeline ETL.

00:09:50.705 --> 00:09:54.200
Quindi vogliamo darvi un altro
opzione che è possibile utilizzare in

00:09:54.200 --> 00:09:58.385
oltre a ETL per come si
integrare i dati insieme.

00:09:58.385 --> 00:10:00.545
In SQL Server 2019,

00:10:00.545 --> 00:10:03.110
abbiamo introdotto un nuovo
modello per il modo in cui distribuiamo

00:10:03.110 --> 00:10:07.970
SQL Server introducendo un nuovo
modello chiamato cluster di Big Data,

00:10:07.970 --> 00:10:09.650
e i cluster di Big Data consentono di

00:10:09.650 --> 00:10:12.440
distribuire un server SQL
esempio con tutti

00:10:12.440 --> 00:10:16.400
le sue capacità tipiche
insieme all'HDFS e

00:10:16.400 --> 00:10:20.825
Spark in un'unica soluzione integrata
come schierato su Kubernetes,

00:10:20.825 --> 00:10:22.610
che ti dà la possibilità di prendere

00:10:22.610 --> 00:10:24.820
SQL Server e fare tutte le cose
che si fa un SQL Server,

00:10:24.820 --> 00:10:26.750
ma poi facilmente integrare che

00:10:26.750 --> 00:10:29.120
insieme all'HDFS e
scintille in modo da poter fare

00:10:29.120 --> 00:10:32.600
query su volumi elevati
dati che possono scalare

00:10:32.600 --> 00:10:34.400
1000 volte più grande di te

00:10:34.400 --> 00:10:37.070
potrebbe forse memorizzare
e SQL Server oggi,

00:10:37.070 --> 00:10:39.500
fino nelle decine o anche
centinaia di petabyte di

00:10:39.500 --> 00:10:42.260
dati, oltre ad essere
in grado di memorizzare e

00:10:42.260 --> 00:10:44.540
query e processo
dati non strutturati come

00:10:44.540 --> 00:10:48.174
video o file audio in HDFS,

00:10:48.174 --> 00:10:50.900
e si ha il beneficio
di avere il motore Spark

00:10:50.900 --> 00:10:53.260
lì per la preparazione dei dati
attività o per fare

00:10:53.260 --> 00:10:55.310
Formazione sul modello di Machine Learning o

00:10:55.310 --> 00:10:58.525
operativa di quelli
modelli all'interno di Spark.

00:10:58.525 --> 00:11:00.815
Così da Microsoft fornendo

00:11:00.815 --> 00:11:02.660
una soluzione integrata e supporto

00:11:02.660 --> 00:11:05.420
che una soluzione integrata
e cluster di Big Data,

00:11:05.420 --> 00:11:08.810
si ottiene una scalabile condivisa
data lake costruito su

00:11:08.810 --> 00:11:12.545
HDFS che SQL Server
o può accedervi Spark.

00:11:12.545 --> 00:11:15.500
Questo ti fornisce davvero
una piattaforma IA completa

00:11:15.500 --> 00:11:17.420
per fare tutto
dall'ingestione

00:11:17.420 --> 00:11:22.070
dei dati memorizzandoli
in HDFS o in SQL Server,

00:11:22.070 --> 00:11:23.900
e poi fare attività di preparazione dei dati

00:11:23.900 --> 00:11:26.250
utilizzando Spark o SQL Server,

00:11:26.250 --> 00:11:28.995
e poi fare Macchina
Formazione sul modello di apprendimento tramite

00:11:28.995 --> 00:11:31.185
sia la macchina integrata
Librerie di apprendimento in

00:11:31.185 --> 00:11:34.380
Spark o utilizzando

00:11:34.380 --> 00:11:35.900
l'apprendimento automatico
servizi integrati in

00:11:35.900 --> 00:11:38.600
l'istanza master di SQL Server
e poi si può rendere operativo

00:11:38.600 --> 00:11:41.030
quelli in Spark Runtime

00:11:41.030 --> 00:11:43.520
facendo batch Macchina
Imparare il punteggio,

00:11:43.520 --> 00:11:45.500
o si potrebbe fare all'interno
di una procedura di negozio

00:11:45.500 --> 00:11:47.090
in SQL Server, ad esempio,

00:11:47.090 --> 00:11:49.640
o abbiamo un modo in cui si
può effettivamente prendere un modello e

00:11:49.640 --> 00:11:53.180
avvolgerlo automaticamente
in un contenitore di API di riposo,

00:11:53.180 --> 00:11:54.980
e la fornitura che
contenitore in cima

00:11:54.980 --> 00:11:56.600
il cluster big data in modo che

00:11:56.600 --> 00:11:58.220
è facile per l'applicazione
sviluppatori di

00:11:58.220 --> 00:12:01.160
chiamare e utilizzare che
contenitore come un modo per

00:12:01.160 --> 00:12:04.745
inviare alcune abitudini di dati segnati
e ottenere un valore di punteggio indietro.

00:12:04.745 --> 00:12:07.940
Quindi rende per un davvero un
completa della piattaforma IA end to

00:12:07.940 --> 00:12:09.500
fine per essere in grado di fare
tutto il necessario

00:12:09.500 --> 00:12:11.770
AI e Machine Learning.

00:12:11.770 --> 00:12:14.615
Quindi, si spera, che dà
è una rapida introduzione

00:12:14.615 --> 00:12:18.085
in SQL Server 2019.

00:12:18.085 --> 00:12:22.085
Questo è davvero solo uno
video in una serie di video

00:12:22.085 --> 00:12:24.080
sul canale SQL 2019

00:12:24.080 --> 00:12:26.465
che si vede collegato qui a
nella parte inferiore dello schermo,

00:12:26.465 --> 00:12:27.860
e speriamo davvero che

00:12:27.860 --> 00:12:29.840
si ha la possibilità di andare
attraverso tutti questi video.

00:12:29.840 --> 00:12:31.220
Speriamo di pubblicare forse in giro

00:12:31.220 --> 00:12:33.290
un centinaio di video che vanno in un sacco di

00:12:33.290 --> 00:12:37.730
dettagli su tutto
che è una novità di SQL Server 2019.

00:12:37.730 --> 00:12:39.095
Se hai un feedback,

00:12:39.095 --> 00:12:40.700
si prega di postare che in
i commenti qui sotto

00:12:40.700 --> 00:12:42.830
e iscriviti al canale.

00:12:42.830 --> 00:12:44.990
Quindi, grazie per unirsi a noi oggi per

00:12:44.990 --> 00:12:47.375
ulteriori informazioni su SQL Server 2019,

00:12:47.375 --> 00:12:49.220
e ci vediamo fuori
lì al prossimo evento

00:12:49.220 --> 00:12:50.720
o SQL Sabato. Grazie.

00:12:50.720 --> 00:13:05.290
[MUSICA]