WEBVTT

00:00:00.000 --> 00:00:10.530
[MÚSICA].

00:00:10.530 --> 00:00:13.170
>> Hey todos. Bem-vindo ao
Este episódio de dados expostos.

00:00:13.170 --> 00:00:15.240
Sou o Travis Wright Group
Gerente de produto para

00:00:15.240 --> 00:00:18.435
os dados do SQL Server e do Azure
equipe de engenharia da Microsoft.

00:00:18.435 --> 00:00:22.335
Hoje eu estou animado para introduzir
a você um SQL Server 2019,

00:00:22.335 --> 00:00:24.945
o SQL Server mais recente lançado.

00:00:24.945 --> 00:00:28.515
O SQL Server está comemorando seu
25º aniversário deste ano.

00:00:28.515 --> 00:00:31.830
Isso é muito tempo. Ao olhar para trás
nos primórdios da minha carreira,

00:00:31.830 --> 00:00:34.230
Comecei no SQL Server 2000.

00:00:34.230 --> 00:00:36.300
Nessa história de 25 anos,

00:00:36.300 --> 00:00:38.490
O SQL Server tem realmente
vir um longo caminho.

00:00:38.490 --> 00:00:40.050
É realmente expandido para atender

00:00:40.050 --> 00:00:42.030
as necessidades da nossa
clientes ao longo do tempo como

00:00:42.030 --> 00:00:44.390
os diferentes tipos de dados
que os clientes precisam

00:00:44.390 --> 00:00:47.060
coletar e processar
e a consulta foi alterada,

00:00:47.060 --> 00:00:49.310
e como houve mais
e diferentes tipos de

00:00:49.310 --> 00:00:51.965
requisitos do mecanismo de banco de dados
que vieram junto.

00:00:51.965 --> 00:00:54.470
Então vamos fazer uma viagem de volta
para baixo da faixa de memória para

00:00:54.470 --> 00:00:57.515
um momento e apenas olhar para onde
SQL Server veio,

00:00:57.515 --> 00:00:59.390
e então vamos dar uma olhada
em que o SQL Server é

00:00:59.390 --> 00:01:02.515
indo em seguida com o SQL Server 2019.

00:01:02.515 --> 00:01:05.350
Vamos começar com o SQL Server 2008.

00:01:05.350 --> 00:01:07.295
SQL Server 2008 é realmente

00:01:07.295 --> 00:01:09.995
de suporte estendido
apenas este ano.

00:01:09.995 --> 00:01:14.390
Se você jejua para a frente um bocado para olhar
no SQL Server 2012 e 2014,

00:01:14.390 --> 00:01:17.870
Nós realmente fizemos algumas grandes melhorias
em termos de desempenho e

00:01:17.870 --> 00:01:19.880
alta disponibilidade por
introduzindo sempre

00:01:19.880 --> 00:01:22.565
em grupos de disponibilidade
para alta disponibilidade,

00:01:22.565 --> 00:01:24.500
e em capacidades de memória para realmente

00:01:24.500 --> 00:01:26.845
impulsionar o desempenho
de seus bancos de dados.

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

00:01:29.630 --> 00:01:31.295
Nós realmente mudar o jogo muito

00:01:31.295 --> 00:01:33.320
introduzindo alguns
novas capacidades em

00:01:33.320 --> 00:01:37.885
SQL Server para armazenar e consultar
JSON e gráfico, bem como,

00:01:37.885 --> 00:01:41.210
e também fizemos algo
muito surpreendente, trazendo

00:01:41.210 --> 00:01:45.580
SQL Server para Linux e
contêineres no SQL Server 2017.

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

00:01:47.895 --> 00:01:49.540
Estamos mudando o jogo ainda mais,

00:01:49.540 --> 00:01:50.840
e realmente expandindo e

00:01:50.840 --> 00:01:53.480
Redefinindo a definição
do que o SQL Server é.

00:01:53.480 --> 00:01:55.490
SQL Server é claro ainda está

00:01:55.490 --> 00:01:58.220
o banco de dados relacional
Isso foi há 25 anos.

00:01:58.220 --> 00:02:00.770
Você ainda pode armazenar
seus dados no SQL Server

00:02:00.770 --> 00:02:03.335
e consultá-lo na mesma
maneira que você sempre tem.

00:02:03.335 --> 00:02:06.560
Mas ao mesmo tempo, estamos
redefinir o SQL Server e

00:02:06.560 --> 00:02:09.920
estendendo-o bem além de apenas
o espaço do banco de dados relacional.

00:02:09.920 --> 00:02:14.135
Então vamos dar uma olhada no que
Estamos fazendo no SQL Server 2019.

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

00:02:17.045 --> 00:02:18.380
Estamos dando-lhe acesso

00:02:18.380 --> 00:02:20.420
para consultar e processar dados

00:02:20.420 --> 00:02:23.990
fora do limite de um
instância tradicional do SQL Server.

00:02:23.990 --> 00:02:26.840
Ao tomar PolyBase um recurso que primeiro

00:02:26.840 --> 00:02:30.445
introduzido no SQL Server
2016 para o próximo nível.

00:02:30.445 --> 00:02:34.280
O PolyBase permite-lhe criar um
camada de virtualização de dados em

00:02:34.280 --> 00:02:36.170
vários diferentes
fontes de dados, como

00:02:36.170 --> 00:02:38.810
Oracle outras instâncias do SQL Server.

00:02:38.810 --> 00:02:42.460
Dados de tera, MongoDB e muito mais.

00:02:42.460 --> 00:02:46.460
Também fizemos HDFS e
faísca e construí-lo na caixa.

00:02:46.460 --> 00:02:48.230
Então agora com o SQL Server,

00:02:48.230 --> 00:02:52.370
Você pode processar e armazenar
dados a escala de petabytes e

00:02:52.370 --> 00:02:57.650
processar e armazenar dados
também são dados ainda não estruturados.

00:02:57.650 --> 00:03:01.520
Você pode usar o SQL Server com
praticamente qualquer linguagem de programação.

00:03:01.520 --> 00:03:04.310
Você pode executá-lo em muito
muito qualquer plataforma agora.

00:03:04.310 --> 00:03:06.155
Com o SQL Server 2019,

00:03:06.155 --> 00:03:08.000
Você pode executá-lo no Windows, é claro.

00:03:08.000 --> 00:03:11.345
Você também pode executá-lo em
Linux em Red Hat, em Susa,

00:03:11.345 --> 00:03:13.670
ou Ubuntu, você pode executar
-lo em um recipiente,

00:03:13.670 --> 00:03:15.320
Você pode executá-lo no kubernetes.

00:03:15.320 --> 00:03:18.875
Você pode executá-lo em um diferente
arquiteturas de processador agora.

00:03:18.875 --> 00:03:20.630
Com a borda do banco de dados SQL do Azure,

00:03:20.630 --> 00:03:24.640
Você pode executá-lo em um braço 64
dispositivo como um Raspberry Pi,

00:03:24.640 --> 00:03:27.680
e você pode executá-lo no
Nuvem e banco de dados SQL do Azure,

00:03:27.680 --> 00:03:29.030
ou você pode executá-lo no local,

00:03:29.030 --> 00:03:31.115
ou você pode executá-lo e
outras nuvens públicas.

00:03:31.115 --> 00:03:32.720
Há muita versatilidade lá.

00:03:32.720 --> 00:03:36.130
Você pode usar o SQL Server onde quer que
combina com você o melhor.

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

00:03:39.290 --> 00:03:42.190
expandir a nossa indústria líder
Desempenho.

00:03:42.190 --> 00:03:45.710
SQL Server estabeleceu-se
por muitos anos agora como o número

00:03:45.710 --> 00:03:49.490
1 em termos de desempenho OLTP
com benchmarks TPC-H,

00:03:49.490 --> 00:03:50.990
e como o número 1 em termos de

00:03:50.990 --> 00:03:54.050
desempenho do armazém de dados
com benchmarks TPC-H.

00:03:54.050 --> 00:03:56.090
Também lideramos a indústria

00:03:56.090 --> 00:03:58.670
o menor número de
vulnerabilidades relatadas de qualquer

00:03:58.670 --> 00:04:01.910
dos principais mecanismos de banco de dados
nos últimos oito anos

00:04:01.910 --> 00:04:06.010
de acordo com o Instituto Nacional
de padrões e tecnologia.

00:04:06.010 --> 00:04:08.330
Então, vamos tomar um mais perto
olhar para apenas alguns dos

00:04:08.330 --> 00:04:11.075
os destaques do SQL Server 2019.

00:04:11.075 --> 00:04:12.770
Vamos começar com alguns
melhorias que estamos

00:04:12.770 --> 00:04:15.005
fazendo no espaço de desempenho.

00:04:15.005 --> 00:04:17.600
Então, em primeiro lugar, a memória persistente como

00:04:17.600 --> 00:04:20.585
uma nova tecnologia que é
entrando no mercado de ferragens.

00:04:20.585 --> 00:04:22.730
Aproveitamos
de memória persistente

00:04:22.730 --> 00:04:24.785
para realmente impulsionar o desempenho.

00:04:24.785 --> 00:04:27.230
Você não tem que fazer qualquer
alterações ao seu aplicativo,

00:04:27.230 --> 00:04:28.430
e você pode armazenar seus dados e

00:04:28.430 --> 00:04:31.330
memória persistente para
desempenho mais rápido.

00:04:31.330 --> 00:04:34.030
Em segundo lugar, para
processamento de consultas,

00:04:34.030 --> 00:04:36.440
Nós realmente expandimos o
família de recursos aqui

00:04:36.440 --> 00:04:38.990
como você pode ver neste
gráfico para incluir lotes

00:04:38.990 --> 00:04:41.615
de novas formas de
otimizador de consulta pode

00:04:41.615 --> 00:04:45.679
aprender ao longo do tempo com base no
execução de como as consultas vão,

00:04:45.679 --> 00:04:48.935
como futuras execuções desses
consultas podem ser melhoradas,

00:04:48.935 --> 00:04:51.560
impulsionar o desempenho
de suas aplicações sobre

00:04:51.560 --> 00:04:55.225
tempo sem que você tenha que mudar
qualquer coisa em suas aplicações,

00:04:55.225 --> 00:04:57.980
e, por fim, colocamos o TempDB em

00:04:57.980 --> 00:05:01.415
memória para ainda mais rápido
desempenho do banco de dados Temp.

00:05:01.415 --> 00:05:03.650
Em seguida, vamos dar uma olhada
algumas melhorias que estamos

00:05:03.650 --> 00:05:05.690
segurança e conformidade.

00:05:05.690 --> 00:05:08.330
Em primeiro lugar, especialmente com o GDPR,

00:05:08.330 --> 00:05:09.905
Os clientes enfrentam

00:05:09.905 --> 00:05:13.220
requisitos regulamentares ainda mais
que eles têm que se encontrar.

00:05:13.220 --> 00:05:14.720
Para tornar isso mais fácil,

00:05:14.720 --> 00:05:18.230
Nós fornecemos a classificação de dados
capacidades fora da caixa.

00:05:18.230 --> 00:05:21.850
Você pode apontar a classificação dos dados
motor no seu banco de dados,

00:05:21.850 --> 00:05:23.555
e ele descobrirá automaticamente

00:05:23.555 --> 00:05:25.130
os diferentes tipos
de dados que você tem em

00:05:25.130 --> 00:05:29.425
seu banco de dados, como
Dados PCI ou dados do GDPR,

00:05:29.425 --> 00:05:31.790
e automaticamente
classificam e produzem

00:05:31.790 --> 00:05:34.670
relatórios para você como você vê
neste screenshot aqui,

00:05:34.670 --> 00:05:37.625
e você pode definir o seu próprio
regras de classificação também.

00:05:37.625 --> 00:05:39.470
Em seguida em termos de segurança,

00:05:39.470 --> 00:05:43.340
melhoramos sempre criptografado
nossa criptografia do lado do cliente

00:05:43.340 --> 00:05:44.645
tecnologia que permite que você

00:05:44.645 --> 00:05:47.630
separar a encriptação
do banco de dados.

00:05:47.630 --> 00:05:50.270
Dessa forma, o
administradores de banco de dados

00:05:50.270 --> 00:05:53.120
Não é possível descriptografar os dados em
o banco de dados que permite

00:05:53.120 --> 00:05:55.640
você para separar deveres aqui entre

00:05:55.640 --> 00:05:56.840
os administradores de banco de dados e

00:05:56.840 --> 00:05:59.425
os desenvolvedores de aplicativos e usuários,

00:05:59.425 --> 00:06:01.910
e, por último, apenas como um exemplo aqui de

00:06:01.910 --> 00:06:03.950
melhorias que estamos
fazendo como temos também

00:06:03.950 --> 00:06:06.230
Adicionado realizando a criptografia

00:06:06.230 --> 00:06:09.480
de todos os dados dentro de enclaves.

00:06:10.160 --> 00:06:15.050
Agora, no espaço do desenvolvedor
e ferramentas de DBA, espero,

00:06:15.050 --> 00:06:16.670
todos vocês aprenderam e tentaram

00:06:16.670 --> 00:06:19.595
O Azure Data Studio um
nova plataforma cruzada

00:06:19.595 --> 00:06:22.550
ferramenta de código aberto para todos os tipos

00:06:22.550 --> 00:06:25.190
de pessoa de dados como se você está
um administrador de banco de dados,

00:06:25.190 --> 00:06:28.415
um engenheiro de banco de dados,
ou um cientista de dados.

00:06:28.415 --> 00:06:33.350
Esta ferramenta está disponível para você
para baixar gratuitamente e usar,

00:06:33.350 --> 00:06:35.225
e destina-se a ser

00:06:35.225 --> 00:06:39.200
Multi motor de banco de dados para que você possa
usá-lo não apenas com o SQL Server,

00:06:39.200 --> 00:06:41.510
Mas também com o SQL Server em

00:06:41.510 --> 00:06:44.060
a nuvem, como
Banco de dados SQL do Azure ou

00:06:44.060 --> 00:06:46.460
com dados SQL do Azure
armazém também com

00:06:46.460 --> 00:06:49.370
outros mecanismos de banco de dados
como PostgreSQL e MySQL.

00:06:49.370 --> 00:06:52.460
Uma das melhorias que
as pessoas estão mais entusiasmados

00:06:52.460 --> 00:06:55.340
e o Azure Data Studio é
a experiência do notebook.

00:06:55.340 --> 00:06:58.550
Os notebooks permitem que você crie
um arquivo que contém marca

00:06:58.550 --> 00:07:01.670
para baixo, bem como células de código.

00:07:01.670 --> 00:07:03.380
No Markdown, você pode descrever

00:07:03.380 --> 00:07:06.470
alguma análise que você está fazendo ou
etapas que devem ser executadas,

00:07:06.470 --> 00:07:08.240
e, em seguida, nas células de código que são

00:07:08.240 --> 00:07:10.640
misturado com
as células de Markdown,

00:07:10.640 --> 00:07:13.705
Você pode ter algum código que você
ou outra pessoa pode executar.

00:07:13.705 --> 00:07:17.250
Temos cadernos para
TSQL, para o PowerShell,

00:07:17.250 --> 00:07:20.240
para Python, e você

00:07:20.240 --> 00:07:23.075
pode executá-lo localmente
ou você pode executá-lo no Spark.

00:07:23.075 --> 00:07:25.910
É um poderoso
maneira de colaborar com

00:07:25.910 --> 00:07:29.915
outras pessoas, capturando este
informações e cadernos,

00:07:29.915 --> 00:07:32.180
e estes cadernos
pode ser usado para capturar

00:07:32.180 --> 00:07:35.450
amostras ou talvez algum padrão
procedimentos operacionais ou

00:07:35.450 --> 00:07:38.180
guias de solução de problemas e compartilhar
aqueles com outras pessoas através

00:07:38.180 --> 00:07:42.085
a integração do git que temos
built-in para o Azure Data Studio,

00:07:42.085 --> 00:07:43.685
e, por último, integramos

00:07:43.685 --> 00:07:45.650
alguma tecnologia muito legal de

00:07:45.650 --> 00:07:48.290
Microsoft Research chamado
SandDance que permite

00:07:48.290 --> 00:07:51.725
você faça dados ad hoc
visualização e exploração

00:07:51.725 --> 00:07:54.020
usando alguns muito legal
recursos de gráficos

00:07:54.020 --> 00:07:55.975
ali dentro de
Azure Data Studio.

00:07:55.975 --> 00:07:59.585
Então, definitivamente, vá pegar dados do Azure
Estúdio, se você ainda não fez.

00:07:59.585 --> 00:08:01.280
É uma ferramenta super poderosa,

00:08:01.280 --> 00:08:03.950
e a inovação está chegando
em uma base mensal como nós

00:08:03.950 --> 00:08:07.640
liberar a cada mês
para o Azure Data Studio.

00:08:07.640 --> 00:08:11.270
Então, continuamos a dobrar-se em

00:08:11.270 --> 00:08:14.180
nossa nova abordagem para

00:08:14.180 --> 00:08:16.820
como olhamos para diferentes
plataformas para o SQL Server.

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

00:08:18.500 --> 00:08:20.465
Introduzimos suporte para Linux.

00:08:20.465 --> 00:08:22.100
Mas o SQL Server 2019,

00:08:22.100 --> 00:08:24.470
Estamos levando isso para o
próxima etapa, criando

00:08:24.470 --> 00:08:27.620
paródia ainda maior característica
entre o SQL Server no Windows,

00:08:27.620 --> 00:08:31.875
e SQL Server no Linux, trazendo
PolyBase e todos os serviços,

00:08:31.875 --> 00:08:35.680
Coordenador de transações distribuídas
e replicação para Linux,

00:08:35.680 --> 00:08:37.160
e que muito bonito verifica fora

00:08:37.160 --> 00:08:39.515
todas as caixas para o
recursos do mecanismo de banco de dados.

00:08:39.515 --> 00:08:42.200
Então você tem perto de 100
compatibilidade por cento

00:08:42.200 --> 00:08:45.695
entre o SQL Server no Windows
e SQL Server no Linux.

00:08:45.695 --> 00:08:47.450
Em parceria com a Red Hat,

00:08:47.450 --> 00:08:49.880
também criamos rel
com base em imagens de contentores

00:08:49.880 --> 00:08:52.585
que estão disponíveis no
Microsoft container Registry,

00:08:52.585 --> 00:08:54.170
e você pode descobri-los em

00:08:54.170 --> 00:08:56.675
o contentor Red Hat
Catálogo também.

00:08:56.675 --> 00:08:58.730
Por último em pré-visualização agora,

00:08:58.730 --> 00:09:02.080
Temos suporte para sempre em
grupos de disponibilidade no kubernetes,

00:09:02.080 --> 00:09:04.610
para que você possa obter o
benefícios de ter sempre em

00:09:04.610 --> 00:09:07.415
grupos de disponibilidade
para a escala para fora lê

00:09:07.415 --> 00:09:09.350
ou para alta disponibilidade

00:09:09.350 --> 00:09:13.760
vivendo bem ali em cima do
Camada de kubernetes embaixo.

00:09:13.970 --> 00:09:17.270
Por último, provavelmente o
área mais significativa

00:09:17.270 --> 00:09:19.040
de melhorias e apenas

00:09:19.040 --> 00:09:21.290
espalhando a tenda
do SQL Server se você

00:09:21.290 --> 00:09:24.215
vontade de lidar com novos
tipos de cenários,

00:09:24.215 --> 00:09:26.540
são as melhorias que
Estamos fazendo em PolyBase

00:09:26.540 --> 00:09:28.850
e virtualização de dados como eu
mencionado no início,

00:09:28.850 --> 00:09:30.140
onde podemos criar

00:09:30.140 --> 00:09:31.760
uma camada de virtualização de dados em

00:09:31.760 --> 00:09:33.890
muitos dados diferentes
fontes como a Oracle,

00:09:33.890 --> 00:09:37.755
outro SQL Server
instâncias e Teradata.

00:09:37.755 --> 00:09:40.100
Isso nos permite trazer
dados em conjunto

00:09:40.100 --> 00:09:42.800
várias fontes de dados no momento da consulta,

00:09:42.800 --> 00:09:44.840
e realmente minimizar
a necessidade de usar

00:09:44.840 --> 00:09:47.420
ETL como uma forma de integrar
nossos dados juntos.

00:09:47.420 --> 00:09:50.705
Ninguém gosta de construir e
manutenção de pipelines de ETL.

00:09:50.705 --> 00:09:54.200
Então nós queremos dar-lhe um outro
opção que você pode usar em

00:09:54.200 --> 00:09:58.385
Além de ETL para saber como você
integrar seus dados juntos.

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

00:10:00.545 --> 00:10:03.110
Introduzimos um novo
padrão de como implantamos

00:10:03.110 --> 00:10:07.970
SQL Server, introduzindo um novo
padrão chamado Big data clusters,

00:10:07.970 --> 00:10:09.650
e clusters de Big data permite que você

00:10:09.650 --> 00:10:12.440
implantar um SQL Server
instância com todos os

00:10:12.440 --> 00:10:16.400
suas capacidades típicas
juntamente com HDFS e

00:10:16.400 --> 00:10:20.825
Spark em uma solução integrada
como implantado no kubernetes,

00:10:20.825 --> 00:10:22.610
que lhe fornece a capacidade de tomar

00:10:22.610 --> 00:10:24.820
SQL Server e fazer todas as coisas
que você faça um SQL Server,

00:10:24.820 --> 00:10:26.750
Mas, em seguida, integrar facilmente

00:10:26.750 --> 00:10:29.120
juntamente com HDFS e
faíscas para que você possa fazer

00:10:29.120 --> 00:10:32.600
consultas em alto volume
dados que podem escalar

00:10:32.600 --> 00:10:34.400
1000 vezes maior do que você

00:10:34.400 --> 00:10:37.070
poderia armazenar
e o SQL Server hoje,

00:10:37.070 --> 00:10:39.500
até as dezenas ou mesmo
centenas de petabytes de

00:10:39.500 --> 00:10:42.260
dados, bem como ser
capaz de armazenar e

00:10:42.260 --> 00:10:44.540
consulta e processo
dados não estruturados como

00:10:44.540 --> 00:10:48.174
arquivos de vídeo ou arquivos de áudio no HDFS,

00:10:48.174 --> 00:10:50.900
e você tem o benefício
de ter o motor Spark

00:10:50.900 --> 00:10:53.260
lá para a preparação de dados
atividades ou para fazer

00:10:53.260 --> 00:10:55.310
Treinamento de modelo de aprendizado de máquina ou

00:10:55.310 --> 00:10:58.525
operacionalização dos
modelos dentro do Spark.

00:10:58.525 --> 00:11:00.815
Por isso, a Microsoft fornece

00:11:00.815 --> 00:11:02.660
uma solução integrada e apoiando

00:11:02.660 --> 00:11:05.420
que uma solução integrada
e clusters de Big data,

00:11:05.420 --> 00:11:08.810
Você recebe uma escalável compartilhada
Data Lake construído sobre

00:11:08.810 --> 00:11:12.545
HDFS que tanto o SQL Server
ou o Spark pode acessar.

00:11:12.545 --> 00:11:15.500
Isto realmente fornece-lhe
uma plataforma completa de ia

00:11:15.500 --> 00:11:17.420
para fazer tudo
da ingestão

00:11:17.420 --> 00:11:22.070
dos dados armazenando-
no HDFS ou no SQL Server,

00:11:22.070 --> 00:11:23.900
e, em seguida, fazer tarefas de preparação de dados

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

00:11:26.250 --> 00:11:28.995
e, em seguida, fazendo máquina
Aprendendo o treinamento do modelo usando

00:11:28.995 --> 00:11:31.185
ou o built-in máquina
Aprendendo bibliotecas em

00:11:31.185 --> 00:11:34.380
Spark ou usando

00:11:34.380 --> 00:11:35.900
o aprendizado de máquina
serviços integrados

00:11:35.900 --> 00:11:38.600
a instância do SQL Server Master
e então você pode operacionalizar

00:11:38.600 --> 00:11:41.030
aqueles ou no tempo de execução do Spark

00:11:41.030 --> 00:11:43.520
fazendo a máquina do grupo
Aprendendo a marcar,

00:11:43.520 --> 00:11:45.500
ou você poderia fazê-lo dentro
de um procedimento de loja

00:11:45.500 --> 00:11:47.090
no SQL Server, por exemplo,

00:11:47.090 --> 00:11:49.640
ou temos uma maneira onde você
pode realmente tomar um modelo e

00:11:49.640 --> 00:11:53.180
automaticamente envolvê-lo
em um contêiner de API REST,

00:11:53.180 --> 00:11:54.980
e provisão que
recipiente em cima de

00:11:54.980 --> 00:11:56.600
o cluster de Big data para que

00:11:56.600 --> 00:11:58.220
é fácil para a aplicação
desenvolvedores para

00:11:58.220 --> 00:12:01.160
chamar e usar esse
recipiente como uma forma de

00:12:01.160 --> 00:12:04.745
apresentar alguns hábitos de dados marcados
e obter um valor de Pontuação de volta.

00:12:04.745 --> 00:12:07.940
Assim faz para um realmente um
extremidade completa da plataforma AI

00:12:07.940 --> 00:12:09.500
fim de ser capaz de fazer
Tudo o que você precisa para

00:12:09.500 --> 00:12:11.770
fazer em torno de ia e aprendizado de máquina.

00:12:11.770 --> 00:12:14.615
Então, espero, que dá
Você uma introdução rápida

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

00:12:18.085 --> 00:12:22.085
Este é realmente apenas um
vídeo em uma série de vídeos

00:12:22.085 --> 00:12:24.080
no canal SQL 2019

00:12:24.080 --> 00:12:26.465
que você vê ligado aqui em
na parte inferior da tela,

00:12:26.465 --> 00:12:27.860
e nós realmente esperamos que

00:12:27.860 --> 00:12:29.840
Você tem a chance de ir
através de todos esses vídeos.

00:12:29.840 --> 00:12:31.220
Esperamos publicar talvez em torno de

00:12:31.220 --> 00:12:33.290
uma centena de vídeos que entram em lotes de

00:12:33.290 --> 00:12:37.730
detalhes sobre tudo
que é novo no SQL Server 2019.

00:12:37.730 --> 00:12:39.095
Se você tiver qualquer feedback,

00:12:39.095 --> 00:12:40.700
por favor poste que em
Os comentários abaixo

00:12:40.700 --> 00:12:42.830
e assine o canal.

00:12:42.830 --> 00:12:44.990
Então, obrigado por se juntar a nós hoje para

00:12:44.990 --> 00:12:47.375
Saiba mais sobre o SQL Server 2019,

00:12:47.375 --> 00:12:49.220
e nós vamos vê-lo fora
lá no próximo evento

00:12:49.220 --> 00:12:50.720
ou SQL sábado. Obrigado.

00:12:50.720 --> 00:13:05.290
MÚSICA