WEBVTT

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

00:00:10.500 --> 00:00:11.910
Salut et bienvenue à nouveau.

00:00:11.910 --> 00:00:14.970
Je m'appelle JRJ, et je suis là.
pour vous parler de l'un des

00:00:14.970 --> 00:00:18.915
le plus attendu
fonctionnalités dans SQL Server 2019,

00:00:18.915 --> 00:00:21.285
et c'est la virtualisation des données.

00:00:21.285 --> 00:00:23.175
Qu'est-ce que la virtualisation des données,

00:00:23.175 --> 00:00:25.440
et pourquoi est-il si attendu?

00:00:25.440 --> 00:00:27.510
Eh bien, tout simplement,

00:00:27.510 --> 00:00:29.510
la virtualisation des données vous permet de

00:00:29.510 --> 00:00:31.670
rassembler toutes vos données à

00:00:31.670 --> 00:00:35.780
temps de requête plutôt que d'avoir à
construire des pipelines ETL complexes en

00:00:35.780 --> 00:00:40.535
afin d'être en mesure d'unifier
les données dans une seule requête.

00:00:40.535 --> 00:00:44.150
Donc, ce que je vais faire
faire est plutôt que d'aller

00:00:44.150 --> 00:00:47.540
à travers les détails des données
virtualisation au niveau conceptuel,

00:00:47.540 --> 00:00:49.730
Je vais juste te montrer
les différences entre les

00:00:49.730 --> 00:00:52.430
une requête locale et un
requête virtualisée,

00:00:52.430 --> 00:00:55.085
à la fois partiellement et entièrement virtualisé.

00:00:55.085 --> 00:00:56.280
Donc, pour ce faire,

00:00:56.280 --> 00:00:58.010
ce que nous allons faire est
nous allons passer au-dessus

00:00:58.010 --> 00:01:00.270
maintenant à Azure Data Studio,

00:01:00.270 --> 00:01:03.035
et vous pouvez voir ici, je
avoir un cahier de travail ouvert,

00:01:03.035 --> 00:01:08.990
et nous allons entrer et
commencer à évaluer cela.

00:01:08.990 --> 00:01:13.625
Donc ici vous pouvez voir que je
avoir une requête très simple.

00:01:13.625 --> 00:01:17.030
J'ai deux locaux
tableaux dans ma base de données,

00:01:17.030 --> 00:01:19.160
et si je fais cette requête,

00:01:19.160 --> 00:01:23.405
vous pouvez imaginer le résultat
revient agréable et rapide.

00:01:23.405 --> 00:01:25.190
J'ai environ une seconde,

00:01:25.190 --> 00:01:28.045
et je reçois mon jeu de données
dans le carnet.

00:01:28.045 --> 00:01:31.630
Cependant, que se passe-t-il si tout cela
données n'était pas dans le serveur SQL?

00:01:31.630 --> 00:01:36.200
Et si ces données étaient en fait
disponibles dans les serveurs SQL distants,

00:01:36.200 --> 00:01:40.145
et nous voulions accéder à cette
données en même temps?

00:01:40.145 --> 00:01:43.700
Eh bien, vous pouvez utiliser la virtualisation des données
pour résoudre ce problème.

00:01:43.700 --> 00:01:45.050
Mais pour ce faire,

00:01:45.050 --> 00:01:47.030
nous devons mettre en place des métadonnées.

00:01:47.030 --> 00:01:50.510
Donc, la première chose que nous devons
faire est de créer une clé maître,

00:01:50.510 --> 00:01:53.720
et une clé principale est une clé à l'intérieur

00:01:53.720 --> 00:01:55.910
la base de données que nous utilisons pour protéger

00:01:55.910 --> 00:01:58.660
toutes les autres métadonnées à l'intérieur.

00:01:58.660 --> 00:02:03.380
Vous pouvez voir à partir des métadonnées
ici quel algorithme nous utilisons,

00:02:03.380 --> 00:02:06.110
quand il est créé, et
des choses intéressantes comme ça.

00:02:06.110 --> 00:02:10.745
Maintenant, j'ai besoin d'activer le PolyBase
caractéristique afin d'être en mesure de

00:02:10.745 --> 00:02:16.310
accéder à des sources distantes
et les bases de données à distance,

00:02:16.310 --> 00:02:19.220
et créer une base de données d'identification pour

00:02:19.220 --> 00:02:23.495
être en mesure d'authentifier
contre ces sources distantes,

00:02:23.495 --> 00:02:28.835
et vous pouvez voir ici que j'ai
créé quelques-uns dans le passé,

00:02:28.835 --> 00:02:30.200
comme un couple d'Oracle,

00:02:30.200 --> 00:02:32.225
et un couple de SQL
ceux là-dedans aussi.

00:02:32.225 --> 00:02:36.680
Mais aujourd'hui, nous allons y aller
contre une source de données SQL,

00:02:36.680 --> 00:02:39.650
et vous pouvez voir ici que
pour ce faire,

00:02:39.650 --> 00:02:41.730
J'ai besoin de créer un
source de données externe.

00:02:41.730 --> 00:02:45.390
Ici, je précise mon
emplacement, dans ce cas,

00:02:45.390 --> 00:02:49.160
une adresse SQL Server
quelque part dans Azure,

00:02:49.160 --> 00:02:51.874
et je passe dans cette accréditation

00:02:51.874 --> 00:02:54.425
pour permettre cette authentification
avoir lieu.

00:02:54.425 --> 00:02:56.590
Alors allons-y et créons ça,

00:02:56.590 --> 00:03:00.880
et vous pouvez voir à nouveau, il ya
les métadonnées à l'intérieur de la base de données.

00:03:00.880 --> 00:03:03.040
Maintenant, en règle générale,

00:03:03.040 --> 00:03:06.290
J'aime garder l'extérieur
tableaux qui définissent

00:03:06.290 --> 00:03:08.465
ces objets de source de données externes

00:03:08.465 --> 00:03:11.210
séparé de mes tables internes,

00:03:11.210 --> 00:03:12.890
et je le fais à l'aide d'un schéma.

00:03:12.890 --> 00:03:16.500
Alors allons-y et
créer un schéma externe,

00:03:17.660 --> 00:03:23.350
et maintenant nous pouvons venir ici et
créer notre première table externe.

00:03:23.350 --> 00:03:25.730
La première table externe
nous allons créer est

00:03:25.730 --> 00:03:28.240
flux de clics web qui
est la première table,

00:03:28.240 --> 00:03:31.315
et dans ce cas, c'est
plus comme une table de faits,

00:03:31.315 --> 00:03:34.755
et nous allons stocker ça.

00:03:34.755 --> 00:03:36.490
Donc, dans cette base de données externe,

00:03:36.490 --> 00:03:38.375
nous avons exactement la même base de données.

00:03:38.375 --> 00:03:44.200
Nous l'utilisons à nouveau pour
illustrer ce scénario.

00:03:44.200 --> 00:03:50.515
Maintenant, nous pouvons entrer dans le processus
de virtualiser un clickstream,

00:03:50.515 --> 00:03:52.900
la table clickstreams web.

00:03:52.900 --> 00:03:56.500
Ici, vous pouvez voir que j'ai le
même table web clickstreams,

00:03:56.500 --> 00:03:58.660
mais maintenant j'utilise le schéma EXT.

00:03:58.660 --> 00:04:01.060
Donc j'accède à la table extérieure,

00:04:01.060 --> 00:04:02.440
mais à toutes fins utiles,

00:04:02.440 --> 00:04:05.630
le reste de la requête
est exactement la même chose.

00:04:05.630 --> 00:04:08.225
Si j'exécute cette requête maintenant,

00:04:08.225 --> 00:04:10.120
prenons dis-le un
un peu plus longtemps parce que

00:04:10.120 --> 00:04:12.100
nous allons aller et
obtenir ces données à distance,

00:04:12.100 --> 00:04:14.905
et vous pourriez dis-le
environ 3,5 secondes.

00:04:14.905 --> 00:04:17.260
Mais nous pouvons voir que nous avons

00:04:17.260 --> 00:04:20.785
que les données ici et
c'est exactement la même chose.

00:04:20.785 --> 00:04:23.710
Donc tout sous le capot

00:04:23.710 --> 00:04:27.065
est complètement transparent
pour moi en tant qu'utilisateur.

00:04:27.065 --> 00:04:29.920
Et si j'allais de l'avant et

00:04:29.920 --> 00:04:33.250
virtualiser la seconde
table externe dans cette requête?

00:04:33.250 --> 00:04:35.680
Vous vous souvenez que la première
l'un était clipstreams web,

00:04:35.680 --> 00:04:38.905
que le second
est la table d'article.

00:04:38.905 --> 00:04:41.090
Alors allons-y et faisons ça,

00:04:41.090 --> 00:04:45.650
et maintenant j'ai les deux
tables virtualisées.

00:04:47.290 --> 00:04:52.290
Alors maintenant, ce qui se passe quand
J'exécute cette dernière requête ?

00:04:52.290 --> 00:04:57.565
Cette dernière requête va
exécuter exactement la même requête,

00:04:57.565 --> 00:05:01.670
mais les deux externes
tables sont virtualisées,

00:05:01.940 --> 00:05:05.275
et vous pouvez voir que réellement
la requête est presque aussi

00:05:05.275 --> 00:05:09.375
rapide comme le premier
version, la requête locale.

00:05:09.375 --> 00:05:12.530
Pourquoi c'est ça ? Pourquoi obtenons-nous
cette différence de performance?

00:05:12.530 --> 00:05:14.780
Eh bien, la raison en est
que si vous regardez

00:05:14.780 --> 00:05:17.000
les serveurs SQL
assez intelligent en utilisant

00:05:17.000 --> 00:05:20.600
son optimiseur basé sur les coûts
pour comprendre que

00:05:20.600 --> 00:05:24.725
les deux tables sont externes et
ils viennent de la même source,

00:05:24.725 --> 00:05:28.400
et qu'il peut voir que
il peut pousser cette jointure et

00:05:28.400 --> 00:05:32.030
l'agrégation vers le bas
contre cette source distante.

00:05:32.030 --> 00:05:34.190
Donc, nous tirons parti du calcul de

00:05:34.190 --> 00:05:37.445
cette source à distance pour résoudre
cette requête en temps réel.

00:05:37.445 --> 00:05:41.030
Mais cela vous donne un aperçu rapide
des capacités que vous

00:05:41.030 --> 00:05:44.750
sortir de l'utilisation des données
technologie de virtualisation

00:05:44.750 --> 00:05:48.470
et comment vous pouvez réellement
transparent présenter que les données

00:05:48.470 --> 00:05:50.390
retour à un utilisateur final sans avoir à

00:05:50.390 --> 00:05:52.520
faire des copies physiques de ces données,

00:05:52.520 --> 00:05:54.410
sans avoir à le déplacer ou à construire

00:05:54.410 --> 00:05:56.420
un pipeline ETL complexe en

00:05:56.420 --> 00:05:58.910
afin d'être en mesure de
données de requête en temps réel.

00:05:58.910 --> 00:06:00.510
Merci beaucoup d'avoir rejoint,

00:06:00.510 --> 00:06:02.960
et j'ai hâte d'attraper
avec vous bientôt.

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