WEBVTT

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

00:00:10.530 --> 00:00:13.170
Hé tout le monde. Bienvenue à
cet épisode de données exposées.

00:00:13.170 --> 00:00:15.240
Je suis Travis Wright Group
Chef de produit pour

00:00:15.240 --> 00:00:18.435
les données SQL Server et Azure
équipe d'ingénierie chez Microsoft.

00:00:18.435 --> 00:00:22.335
Aujourd'hui, je suis heureux de vous présenter
pour vous un serveur SQL 2019,

00:00:22.335 --> 00:00:24.945
le plus récent publié SQL Server.

00:00:24.945 --> 00:00:28.515
SQL Server célèbre son
25e anniversaire cette année.

00:00:28.515 --> 00:00:31.830
C'est un bon moment. En regardant en arrière
sur les premiers jours de ma carrière,

00:00:31.830 --> 00:00:34.230
J'ai commencé sur SQL Server 2000.

00:00:34.230 --> 00:00:36.300
Au cours de ces 25 ans d'histoire,

00:00:36.300 --> 00:00:38.490
SQL Server a vraiment
venir un long chemin.

00:00:38.490 --> 00:00:40.050
Il est vraiment élargi pour répondre

00:00:40.050 --> 00:00:42.030
les besoins de notre
clients au fil du temps comme

00:00:42.030 --> 00:00:44.390
les différents types de données
que les clients doivent

00:00:44.390 --> 00:00:47.060
recueillir et traiter
et la requête a changé,

00:00:47.060 --> 00:00:49.310
et comme il ya eu plus
et différents types de

00:00:49.310 --> 00:00:51.965
exigences du moteur de base de données
qui sont venus le long.

00:00:51.965 --> 00:00:54.470
Alors faisons un voyage de retour
vers le bas la voie de la mémoire pour

00:00:54.470 --> 00:00:57.515
un moment et il suffit de regarder où
SQL Server est venu de,

00:00:57.515 --> 00:00:59.390
et puis nous allons jeter un oeil
à l'endroit où SQL Server est

00:00:59.390 --> 00:01:02.515
prochaine étape avec SQL Server 2019.

00:01:02.515 --> 00:01:05.350
Commençons par SQL Server 2008.

00:01:05.350 --> 00:01:07.295
SQL Server 2008 est en fait

00:01:07.295 --> 00:01:09.995
hors de soutien étendu
juste cette an née.

00:01:09.995 --> 00:01:14.390
Si vous avancez un peu vers l'avant pour regarder
à SQL Server 2012 et 2014,

00:01:14.390 --> 00:01:17.870
nous avons vraiment fait de grandes améliorations
en termes de performance et de performance

00:01:17.870 --> 00:01:19.880
haute disponibilité par
l'introduction toujours

00:01:19.880 --> 00:01:22.565
sur les groupes de disponibilité
pour une grande disponibilité,

00:01:22.565 --> 00:01:24.500
et dans les capa cités de mémoire à vraiment

00:01:24.500 --> 00:01:26.845
stimuler les performances
de vos bases de données.

00:01:26.845 --> 00:01:29.630
Dans SQL Server 2016 et 2017,

00:01:29.630 --> 00:01:31.295
nous avons vraiment changer le jeu beaucoup

00:01:31.295 --> 00:01:33.320
en introduisant une certaine
nouvelles capacités dans

00:01:33.320 --> 00:01:37.885
SQL Server pour stocker et interroger
JSON et graphique aussi,

00:01:37.885 --> 00:01:41.210
et nous avons aussi fait quelque chose
très surprenant en apportant

00:01:41.210 --> 00:01:45.580
SQL Server à Linux et
conteneurs dans SQL Server 2017.

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

00:01:47.895 --> 00:01:49.540
nous changeons le jeu encore une fois,

00:01:49.540 --> 00:01:50.840
et vraiment en expansion et

00:01:50.840 --> 00:01:53.480
redéfinir la définition
de ce qu'est SQL Server.

00:01:53.480 --> 00:01:55.490
serveur SQL est bien sûr encore

00:01:55.490 --> 00:01:58.220
la base de données relationnelle
c'était il y a 25 ans.

00:01:58.220 --> 00:02:00.770
Vous pouvez toujours stocker
vos données dans SQL Server

00:02:00.770 --> 00:02:03.335
et le questionner dans le même
façon dont vous avez toujours.

00:02:03.335 --> 00:02:06.560
Mais en même temps, nous sommes
redéfinir SQL Server et

00:02:06.560 --> 00:02:09.920
l'étendre bien au-delà de la simple
l'espace de base de données relationnelle.

00:02:09.920 --> 00:02:14.135
Jetons donc un coup d'œil à ce que
nous faisons dans SQL Server 2019.

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

00:02:17.045 --> 00:02:18.380
nous vous donnons accès

00:02:18.380 --> 00:02:20.420
pour interroger et traiter les données

00:02:20.420 --> 00:02:23.990
en dehors de la limite d'un
instance traditionnelle SQL Server.

00:02:23.990 --> 00:02:26.840
En prenant PolyBase une fonctionnalité, nous

00:02:26.840 --> 00:02:30.445
introduit dans SQL Server
2016 au niveau suivant.

00:02:30.445 --> 00:02:34.280
PolyBase vous permet de créer un
couche de virtualisation des données à travers

00:02:34.280 --> 00:02:36.170
plusieurs différents
sources de données telles que

00:02:36.170 --> 00:02:38.810
Oracle d'autres instances de serveur SQL.

00:02:38.810 --> 00:02:42.460
Tera data, MongoDB et bien plus encore.

00:02:42.460 --> 00:02:46.460
Nous avons également pris HDFS et
étincelle et le construire dans la boîte.

00:02:46.460 --> 00:02:48.230
Alors maintenant, avec SQL Server,

00:02:48.230 --> 00:02:52.370
vous pouvez traiter et stocker
données de l'échelle de pétaoctet et

00:02:52.370 --> 00:02:57.650
traiter et stocker des données qui sont
sont même des données non structurées.

00:02:57.650 --> 00:03:01.520
Vous pouvez utiliser SQL Server avec
pratiquement n'importe quel langage de programmation.

00:03:01.520 --> 00:03:04.310
Vous pouvez l'exécuter sur jolie
beaucoup n'importe quelle plate-forme maintenant.

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

00:03:06.155 --> 00:03:08.000
vous pouvez l'exécuter sur Windows bien sûr.

00:03:08.000 --> 00:03:11.345
Vous pouvez également l'exécuter sur
Linux sur Red Hat, sur Suse,

00:03:11.345 --> 00:03:13.670
ou Ubuntu, vous pouvez courir
dans un conteneur,

00:03:13.670 --> 00:03:15.320
vous pouvez l'exécuter sur Kubernetes.

00:03:15.320 --> 00:03:18.875
Vous pouvez l'exécuter sur un autre
architectures de processeur maintenant.

00:03:18.875 --> 00:03:20.630
Avec le bord de base de données Azure SQL,

00:03:20.630 --> 00:03:24.640
vous pouvez l'exécuter sur un bras 64
dispositif comme un Raspberry Pi,

00:03:24.640 --> 00:03:27.680
et vous pouvez l'exécuter dans le
Base de données SQL Cloud et Azure,

00:03:27.680 --> 00:03:29.030
ou vous pouvez l'exécuter sur place,

00:03:29.030 --> 00:03:31.115
ou vous pouvez l'exécuter et
d'autres nuages publics.

00:03:31.115 --> 00:03:32.720
Il y a beaucoup de polyvalence là-bas.

00:03:32.720 --> 00:03:36.130
Vous pouvez utiliser SQL Server où que ce soit
il vous convient le mieux.

00:03:36.130 --> 00:03:39.290
SQL Server 2019 continue de

00:03:39.290 --> 00:03:42.190
développer notre chef de file dans l'industrie
représentation.

00:03:42.190 --> 00:03:45.710
SQL Server s'est établi
depuis de nombreuses années maintenant que le nombre

00:03:45.710 --> 00:03:49.490
1 en termes de performance OLTP
avec TPC-H Benchmarks,

00:03:49.490 --> 00:03:50.990
et comme le numéro 1 en termes de

00:03:50.990 --> 00:03:54.050
performances de l'entrepôt de données
avec TPC-H Benchmarks.

00:03:54.050 --> 00:03:56.090
Nous avons également mené l'industrie en ayant

00:03:56.090 --> 00:03:58.670
le moins de
vulnérabilités signalées à partir de

00:03:58.670 --> 00:04:01.910
des principaux moteurs de base de données
au cours des huit dernières années

00:04:01.910 --> 00:04:06.010
selon l'Institut national
normes et de la technologie.

00:04:06.010 --> 00:04:08.330
Alors, nous allons prendre un peu plus près
regarder quelques-uns des

00:04:08.330 --> 00:04:11.075
les faits saillants de SQL Server 2019.

00:04:11.075 --> 00:04:12.770
Commençons par quelques
améliorations que nous sommes

00:04:12.770 --> 00:04:15.005
dans l'espace de performance.

00:04:15.005 --> 00:04:17.600
Donc, tout d'abord, la mémoire persistante comme

00:04:17.600 --> 00:04:20.585
une nouvelle technologie qui est
sur le marché du matériel.

00:04:20.585 --> 00:04:22.730
Nous en avons profité
de mémoire persistante

00:04:22.730 --> 00:04:24.785
pour vraiment augmenter les performances.

00:04:24.785 --> 00:04:27.230
Vous n'avez pas à faire de
modifications apportées à votre application,

00:04:27.230 --> 00:04:28.430
et vous pouvez stocker vos données et

00:04:28.430 --> 00:04:31.330
mémoire persistante pour
performances plus rapides.

00:04:31.330 --> 00:04:34.030
Deuxièmement, pour les
traitement des requêtes,

00:04:34.030 --> 00:04:36.440
nous avons vraiment élargi le
famille de caractéristiques ici

00:04:36.440 --> 00:04:38.990
comme vous pouvez le voir dans ce
graphique pour inclure des lots

00:04:38.990 --> 00:04:41.615
de nouvelles façons où le
l'optimiseur de requête peut

00:04:41.615 --> 00:04:45.679
apprendre au fil du temps en fonction de la
exécution de la façon dont les requêtes vont,

00:04:45.679 --> 00:04:48.935
comment les exécutions futures de ces
les requêtes peuvent être améliorées,

00:04:48.935 --> 00:04:51.560
stimuler les performances
de vos applications sur

00:04:51.560 --> 00:04:55.225
temps sans que vous ayez à changer
rien dans vos applications,

00:04:55.225 --> 00:04:57.980
et enfin, nous avons mis le TempDB en

00:04:57.980 --> 00:05:01.415
mémoire pour encore plus rapide
performances de la base de données temporaire.

00:05:01.415 --> 00:05:03.650
Ensuite, jetons un oeil à
quelques améliorations que nous sommes

00:05:03.650 --> 00:05:05.690
en matière de sécurité et de conformité.

00:05:05.690 --> 00:05:08.330
Tout d'abord, en particulier avec GDPR,

00:05:08.330 --> 00:05:09.905
clients sont confrontés à des

00:05:09.905 --> 00:05:13.220
encore plus d'exigences réglementaires
qu'ils doivent rencontrer.

00:05:13.220 --> 00:05:14.720
Pour faciliter les choses,

00:05:14.720 --> 00:05:18.230
nous fournissons la classification des données
capacités hors de la boîte.

00:05:18.230 --> 00:05:21.850
Vous pouvez pointer la classification des données
moteur à votre base de données,

00:05:21.850 --> 00:05:23.555
et il découvrira automatiquement

00:05:23.555 --> 00:05:25.130
les différents types
des données que vous avez dans

00:05:25.130 --> 00:05:29.425
votre base de données telle que
Données PCI ou GDPR,

00:05:29.425 --> 00:05:31.790
et automatiquement
classer cela et produire

00:05:31.790 --> 00:05:34.670
rapports pour vous comme vous voyez
dans cette capture d'écran ici,

00:05:34.670 --> 00:05:37.625
et vous pouvez définir votre propre
règles de classification ainsi.

00:05:37.625 --> 00:05:39.470
Suivant en termes de sécurité,

00:05:39.470 --> 00:05:43.340
nous avons amélioré Toujours crypté
notre chiffrement côté client

00:05:43.340 --> 00:05:44.645
technologie qui vous permet de

00:05:44.645 --> 00:05:47.630
séparer le cryptage
de la base de données.

00:05:47.630 --> 00:05:50.270
De cette façon, le
administrateurs de base de données

00:05:50.270 --> 00:05:53.120
ne pas déchiffrer les données dans
la base de données qui permet

00:05:53.120 --> 00:05:55.640
vous de séparer les fonctions ici entre

00:05:55.640 --> 00:05:56.840
les administrateurs de base de données et

00:05:56.840 --> 00:05:59.425
les développeurs d'applications et les utilisateurs,

00:05:59.425 --> 00:06:01.910
et enfin juste comme un exemple ici de

00:06:01.910 --> 00:06:03.950
améliorations que nous sommes
faire comme nous l'avons aussi

00:06:03.950 --> 00:06:06.230
ajouté l'exécution du cryptage

00:06:06.230 --> 00:06:09.480
de toutes les données à l'intérieur des enclaves.

00:06:10.160 --> 00:06:15.050
Maintenant, dans l'espace de développeur
et les outils DBA, nous l'espérons,

00:06:15.050 --> 00:06:16.670
vous avez tous appris et essayé

00:06:16.670 --> 00:06:19.595
Azure Data Studio a
nouvelle plateforme transversale

00:06:19.595 --> 00:06:22.550
outil open-source pour tous les types

00:06:22.550 --> 00:06:25.190
de la personne de données que si vous êtes
un administrateur de base de données,

00:06:25.190 --> 00:06:28.415
un ingénieur de base de données,
ou un scientifique de données.

00:06:28.415 --> 00:06:33.350
Cet outil est disponible pour vous
à télécharger gratuitement et à utiliser,

00:06:33.350 --> 00:06:35.225
et il est conçu pour être

00:06:35.225 --> 00:06:39.200
Moteur de base de données multi afin que vous puissiez
l'utiliser non seulement avec SQL Server,

00:06:39.200 --> 00:06:41.510
mais aussi avec le serveur SQL en

00:06:41.510 --> 00:06:44.060
le Cloud tel que
Base de données Azure SQL ou

00:06:44.060 --> 00:06:46.460
avec les données Azure SQL
entrepôt aussi avec

00:06:46.460 --> 00:06:49.370
d'autres moteurs de base de données
comme PostgreSQL et MySQL.

00:06:49.370 --> 00:06:52.460
L'une des améliorations qui
les gens sont les plus excités par

00:06:52.460 --> 00:06:55.340
et Azure Data Studio est
l'expérience du carnet.

00:06:55.340 --> 00:06:58.550
Les carnets vous permettent de créer
un fichier qui contient la marque

00:06:58.550 --> 00:07:01.670
ainsi que les cellules de code.

00:07:01.670 --> 00:07:03.380
Dans le markdown, vous pouvez décrire

00:07:03.380 --> 00:07:06.470
une analyse que vous faites ou
étapes qui devraient être effectuées,

00:07:06.470 --> 00:07:08.240
et puis dans les cellules de code qui sont

00:07:08.240 --> 00:07:10.640
entremêlés avec
ces cellules de markdown,

00:07:10.640 --> 00:07:13.705
vous pouvez avoir un peu de code que vous
ou quelqu'un d'autre peut exécuter.

00:07:13.705 --> 00:07:17.250
Nous avons des carnets pour
TSQL, pour PowerShell,

00:07:17.250 --> 00:07:20.240
pour Python, et vous

00:07:20.240 --> 00:07:23.075
peut l'exécuter soit localement
ou vous pouvez l'exécuter dans Spark.

00:07:23.075 --> 00:07:25.910
C'est un très puissant
façon de collaborer avec

00:07:25.910 --> 00:07:29.915
d'autres personnes en capturant cette
d'information et de cahiers,

00:07:29.915 --> 00:07:32.180
et ces carnets
peut être utilisé pour capturer

00:07:32.180 --> 00:07:35.450
échantillons ou peut-être une norme
procédures d'exploitation ou

00:07:35.450 --> 00:07:38.180
guides de dépannage et de partager
ceux avec d'autres personnes à travers

00:07:38.180 --> 00:07:42.085
l'intégration Git que nous avons
intégré à Azure Data Studio,

00:07:42.085 --> 00:07:43.685
et enfin, nous avons intégré

00:07:43.685 --> 00:07:45.650
une technologie vraiment cool de

00:07:45.650 --> 00:07:48.290
Microsoft Research a appelé
SandDance qui permet

00:07:48.290 --> 00:07:51.725
vous de faire des données ad hoc
visualisation et exploration

00:07:51.725 --> 00:07:54.020
en utilisant certains vraiment cool
capacités de cartographie

00:07:54.020 --> 00:07:55.975
juste là à l'intérieur de
Studio de données Azure.

00:07:55.975 --> 00:07:59.585
Donc, certainement, allez saisir Les données Azure
Studio si vous n'avez pas déjà.

00:07:59.585 --> 00:08:01.280
C'est un outil super puissant,

00:08:01.280 --> 00:08:03.950
et l'innovation est à venir
là sur une base mensuelle que nous

00:08:03.950 --> 00:08:07.640
libérer tous les mois
pour Azure Data Studio.

00:08:07.640 --> 00:08:11.270
Nous continuons donc à doubler

00:08:11.270 --> 00:08:14.180
notre nouvelle approche

00:08:14.180 --> 00:08:16.820
comment nous regardons différents
plates-formes pour SQL Server.

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

00:08:18.500 --> 00:08:20.465
nous avons introduit le support pour Linux.

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

00:08:22.100 --> 00:08:24.470
nous prenons cela à la
prochaine étape en créant

00:08:24.470 --> 00:08:27.620
encore plus grande parodie fonctionnalité
entre SQL Server sur Windows,

00:08:27.620 --> 00:08:31.875
et SQL Server sur Linux en apportant
PolyBase et tous les services,

00:08:31.875 --> 00:08:35.680
coordonnateur des transactions distribuées
et la réplication de Linux,

00:08:35.680 --> 00:08:37.160
et que à peu près checks off

00:08:37.160 --> 00:08:39.515
toutes les cases pour le
caractéristiques du moteur de base de données.

00:08:39.515 --> 00:08:42.200
Donc, vous avez près de 100
pourcentage de compatibilité

00:08:42.200 --> 00:08:45.695
entre SQL Server sur Windows
et SQL Server sur Linux.

00:08:45.695 --> 00:08:47.450
En partenariat avec Red Hat,

00:08:47.450 --> 00:08:49.880
nous avons égale ment créé rel
images de conteneurs à base

00:08:49.880 --> 00:08:52.585
qui sont disponibles sur le
Registre des conteneurs Microsoft,

00:08:52.585 --> 00:08:54.170
et vous pouvez les découvrir en

00:08:54.170 --> 00:08:56.675
le conteneur Red Hat
catalogue ainsi.

00:08:56.675 --> 00:08:58.730
Enfin en avant-première en ce moment,

00:08:58.730 --> 00:09:02.080
nous avons le soutien pour toujours sur
groupes de disponibilité à Kubernetes,

00:09:02.080 --> 00:09:04.610
afin que vous puissiez obtenir le
avantages d'avoir toujours sur

00:09:04.610 --> 00:09:07.415
groupes de disponibilité
pour l'échelle des lectures

00:09:07.415 --> 00:09:09.350
ou pour une grande disponibilité

00:09:09.350 --> 00:09:13.760
vivre juste là sur le dessus de la
Kubernetes couche en dessous.

00:09:13.970 --> 00:09:17.270
Enfin, probablement le
zone la plus importante

00:09:17.270 --> 00:09:19.040
d'améliorations et juste

00:09:19.040 --> 00:09:21.290
étaler la tente
du serveur SQL si vous

00:09:21.290 --> 00:09:24.215
volonté de gérer de nouvelles
types de scénarios,

00:09:24.215 --> 00:09:26.540
est les améliorations qui
nous faisons dans PolyBase

00:09:26.540 --> 00:09:28.850
et la virtualisation des données que je
mentionné au début,

00:09:28.850 --> 00:09:30.140
où nous pouvons créer

00:09:30.140 --> 00:09:31.760
une couche de virtualisation des données à travers

00:09:31.760 --> 00:09:33.890
de nombreuses données différentes
sources comme Oracle,

00:09:33.890 --> 00:09:37.755
autre serveur SQL
et Teradata.

00:09:37.755 --> 00:09:40.100
Cela nous permet d'apporter
ensemble des données à travers

00:09:40.100 --> 00:09:42.800
sources de données multiples au moment de la requête,

00:09:42.800 --> 00:09:44.840
et vraiment minimiser
la nécessité d'utiliser

00:09:44.840 --> 00:09:47.420
ETL comme un moyen d'intégrer
nos données ensemble.

00:09:47.420 --> 00:09:50.705
Personne n'aime la construction et
l'entretien des pipelines ETL.

00:09:50.705 --> 00:09:54.200
Donc, nous voulons vous donner un autre
option que vous pouvez utiliser dans

00:09:54.200 --> 00:09:58.385
en plus d'ETL pour la façon dont vous
intégrer vos données ensemble.

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

00:10:00.545 --> 00:10:03.110
nous avons introduit un nouveau
modèle pour la façon dont nous déployons

00:10:03.110 --> 00:10:07.970
SQL Server en introduisant un nouveau
modèle appelé clusters big data,

00:10:07.970 --> 00:10:09.650
et les clusters big data vous permettent de

00:10:09.650 --> 00:10:12.440
déployer un serveur SQL
exemple avec tous les

00:10:12.440 --> 00:10:16.400
ses capacités typiques
avec HDFS et

00:10:16.400 --> 00:10:20.825
Spark dans une solution intégrée
comme déployé sur Kubernetes,

00:10:20.825 --> 00:10:22.610
qui vous donne la possibilité de prendre

00:10:22.610 --> 00:10:24.820
serveur SQL et faire toutes les choses
que vous faites un serveur SQL,

00:10:24.820 --> 00:10:26.750
mais ensuite facilement intégrer que

00:10:26.750 --> 00:10:29.120
avec HDFS et
étincelles afin que vous puissiez faire

00:10:29.120 --> 00:10:32.600
requêtes sur un volume élevé
données qui peuvent

00:10:32.600 --> 00:10:34.400
1000 fois plus grand que vous

00:10:34.400 --> 00:10:37.070
pourrait éventuellement stocker
et SQL Server aujourd'hui,

00:10:37.070 --> 00:10:39.500
jusqu'à dans les dizaines ou même
des centaines de pétaoctets de

00:10:39.500 --> 00:10:42.260
données ainsi que d'être
en mesure de stocker et de

00:10:42.260 --> 00:10:44.540
requête et processus
données non structurées comme

00:10:44.540 --> 00:10:48.174
fichiers vidéo ou audio dans HDFS,

00:10:48.174 --> 00:10:50.900
et vous avez l'avantage
d'avoir le moteur Spark

00:10:50.900 --> 00:10:53.260
là pour la préparation des données
activités ou pour faire

00:10:53.260 --> 00:10:55.310
Formation de modèle d'apprentissage automatique ou

00:10:55.310 --> 00:10:58.525
l'opérationnalisation de ceux
modèles à l'intérieur de Spark.

00:10:58.525 --> 00:11:00.815
Ainsi, par Microsoft fournissant

00:11:00.815 --> 00:11:02.660
une solution intégrée et soutenir

00:11:02.660 --> 00:11:05.420
qu'une solution intégrée
et les clusters big data,

00:11:05.420 --> 00:11:08.810
vous obtenez un partage évolutif
lac de données construit sur

00:11:08.810 --> 00:11:12.545
HDFS que soit SQL Server
ou Spark peut y accéder.

00:11:12.545 --> 00:11:15.500
Cela vous fournit vraiment
une plate-forme complète d'IA

00:11:15.500 --> 00:11:17.420
pour tout faire
de l'ingestion

00:11:17.420 --> 00:11:22.070
des données en les stockant
dans HDFS ou dans SQL Server,

00:11:22.070 --> 00:11:23.900
et ensuite faire des tâches de préparation de données

00:11:23.900 --> 00:11:26.250
en utilisant Spark ou SQL Server,

00:11:26.250 --> 00:11:28.995
et puis faire Machine
Formation modèle d'apprentissage à l'aide

00:11:28.995 --> 00:11:31.185
soit la machine intégrée
Bibliothèques d'apprentissage à

00:11:31.185 --> 00:11:34.380
Étincelle ou en utilisant

00:11:34.380 --> 00:11:35.900
l'apprentissage automatique
services intégrés dans

00:11:35.900 --> 00:11:38.600
l'instance SQL Server Master
et puis vous pouvez opérationnaliser

00:11:38.600 --> 00:11:41.030
ceux qui sont soit dans le Spark Runtime

00:11:41.030 --> 00:11:43.520
en faisant machine par lots
Apprentissage de la notation,

00:11:43.520 --> 00:11:45.500
ou vous pourriez le faire à l'intérieur
d'une procédure de magasin

00:11:45.500 --> 00:11:47.090
dans SQL Server par exemple,

00:11:47.090 --> 00:11:49.640
ou nous avons un moyen où vous
peut effectivement prendre un modèle et

00:11:49.640 --> 00:11:53.180
enveloppez-le automatiquement
dans un conteneur API de repos,

00:11:53.180 --> 00:11:54.980
et la disposition qui
conteneur sur le dessus de

00:11:54.980 --> 00:11:56.600
le cluster big data de sorte que

00:11:56.600 --> 00:11:58.220
il est facile pour l'application
développeurs à

00:11:58.220 --> 00:12:01.160
appeler et utiliser que
conteneur comme un moyen de

00:12:01.160 --> 00:12:04.745
soumettre certaines habitudes de données notées
et obtenir une valeur de score de retour.

00:12:04.745 --> 00:12:07.940
Donc, il fait pour un vraiment un
plate-forme ai complète fin à

00:12:07.940 --> 00:12:09.500
fin pour être en mesure de faire
tout ce dont vous avez besoin pour

00:12:09.500 --> 00:12:11.770
faire autour de l'IA et l'apprentissage automatique.

00:12:11.770 --> 00:12:14.615
Donc, j'espère que, qui donne
vous une introduction rapide

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

00:12:18.085 --> 00:12:22.085
Ce n'est vraiment qu'un
vidéo dans une série de vidéos

00:12:22.085 --> 00:12:24.080
sur la chaîne SQL 2019

00:12:24.080 --> 00:12:26.465
que vous voyez lié ici à
le bas de l'écran,

00:12:26.465 --> 00:12:27.860
et nous espérons vraiment que

00:12:27.860 --> 00:12:29.840
vous avez une chance d'aller
à travers toutes ces vidéos.

00:12:29.840 --> 00:12:31.220
Nous espérons publier peut-être autour de

00:12:31.220 --> 00:12:33.290
une centaine de vidé os qui vont dans beaucoup de

00:12:33.290 --> 00:12:37.730
détails sur tout
c'est nouveau dans SQL Server 2019.

00:12:37.730 --> 00:12:39.095
Si vous avez des commentaires,

00:12:39.095 --> 00:12:40.700
s'il vous plaît poster que dans
les commentaires ci-dessous

00:12:40.700 --> 00:12:42.830
et abonnez-vous à la chaîne.

00:12:42.830 --> 00:12:44.990
Merci de vous joindre à nous aujourd'hui pour

00:12:44.990 --> 00:12:47.375
en savoir plus sur SQL Server 2019,

00:12:47.375 --> 00:12:49.220
et nous vous verrons dehors
il à l'événement suivant

00:12:49.220 --> 00:12:50.720
ou SQL samedi. Je vous remercie.

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