WEBVTT

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

00:00:10.560 --> 00:00:12.975
Hey, bienvenue à un nouveau
épisode de Data Exposed.

00:00:12.975 --> 00:00:14.460
Je m'appelle Pedro Lopes.

00:00:14.460 --> 00:00:16.920
Je suis gestionnaire de programme dans le
Équipe d'ingénierie serveur SQL.

00:00:16.920 --> 00:00:18.510
Aujourd'hui, je vais parler

00:00:18.510 --> 00:00:20.670
à propos d'Intelligent
Base de données, en particulier,

00:00:20.670 --> 00:00:23.809
Traitement intelligent de requête
dans SQL Server 2019,

00:00:23.809 --> 00:00:25.925
et aussi La base de données Azure SQL.

00:00:25.925 --> 00:00:29.390
Alors allons-y. Sql
Server 2019 présente

00:00:29.390 --> 00:00:31.864
requête révolutionnaire
améliorations de la performance

00:00:31.864 --> 00:00:34.655
et ils sont les intelligents
Famille de traitement de requête.

00:00:34.655 --> 00:00:37.820
Ceux-ci constituent les dernières
La mission de Microsoft de s'assurer

00:00:37.820 --> 00:00:41.690
que les charges de travail parallèles critiques
améliorer lors de la course à l'échelle,

00:00:41.690 --> 00:00:45.470
tout en restant adaptatif à la
monde en constante évolution des données,

00:00:45.470 --> 00:00:47.855
que les données se déplace dans et
hors des bases de données.

00:00:47.855 --> 00:00:49.670
Dans cette vidé o, je vais vous donner

00:00:49.670 --> 00:00:51.980
un bref aperçu de la
Monde de base de données intelligent

00:00:51.980 --> 00:00:53.030
qui fait vraiment un saut

00:00:53.030 --> 00:00:56.150
l'avant avec le prochain
Serveur SQL 2019,

00:00:56.150 --> 00:00:58.700
et vous présenter un certain nombre
des caractéristiques que nous allons plonger

00:00:58.700 --> 00:01:02.130
dans plus profondément dans d'autres
vidéos de cette série.

00:01:03.170 --> 00:01:07.510
Traitement intelligent de requête
dans SQL Server est disponible par

00:01:07.510 --> 00:01:11.245
par défaut sur la dernière base de données
paramètre de niveau de compatibilité.

00:01:11.245 --> 00:01:13.210
Cela signifie qu'après avoir mis à niveau,

00:01:13.210 --> 00:01:15.130
cela peut être disponible juste par

00:01:15.130 --> 00:01:18.000
retourner l'interrupteur pour utiliser le
dernier paramètre de compatibilité.

00:01:18.000 --> 00:01:22.030
Traitement intelligent de requête
offre également un large impact

00:01:22.030 --> 00:01:23.440
qui améliore les performances des

00:01:23.440 --> 00:01:26.650
charges de travail existantes avec
un minimum d'efforts de mise en œuvre.

00:01:26.650 --> 00:01:28.390
Cela signifie vraiment que la plupart du temps,

00:01:28.390 --> 00:01:30.965
il n'y a aucun besoin de
refactorisez votre code.

00:01:30.965 --> 00:01:33.310
Le traitement intelligent des requêtes s'améliore

00:01:33.310 --> 00:01:36.190
charges de travail parallèles critiques
lorsque vous exécutez à l'échelle,

00:01:36.190 --> 00:01:39.355
et à mesure que les données circulent et
hors de votre base de données,

00:01:39.355 --> 00:01:41.380
nous nous adapterons à cela et

00:01:41.380 --> 00:01:44.660
maintenir un niveau de
performances prévisibles.

00:01:44.660 --> 00:01:47.450
Par exemple, en introduisant

00:01:47.450 --> 00:01:49.880
un mécanisme de rétroaction
dans l'utilisation de la mémoire,

00:01:49.880 --> 00:01:53.630
nous pouvons nous assurer que votre charge de travail
s'exécute d'une manière prévisible.

00:01:53.630 --> 00:01:58.190
Si une exécution de requête donnée
peut-être prendre trop de mémoire,

00:01:58.190 --> 00:01:59.750
nous pouvons le corriger et

00:01:59.750 --> 00:02:02.375
augmenter la concurrence
facteur de votre base de données.

00:02:02.375 --> 00:02:06.020
Si une exécution d'équité donnée
n'a pas assez de mémoire et

00:02:06.020 --> 00:02:09.560
finit par utiliser d'autres IO
tout au long est connu comme un déversement,

00:02:09.560 --> 00:02:11.315
alors nous pouvons aussi trouver que

00:02:11.315 --> 00:02:13.565
et corriger la situation
de sorte que l'opération

00:02:13.565 --> 00:02:15.260
exécute en mémoire et en

00:02:15.260 --> 00:02:18.200
performantcomme prévu dans
exécutions ultérieures.

00:02:18.200 --> 00:02:20.540
Cette fonctionnalité est désormais activée pour

00:02:20.540 --> 00:02:22.835
tous les modes d'exécution dans
le centre de base de données.

00:02:22.835 --> 00:02:27.170
Mode de lot pour plus d'entrepôt de données
et les charges de travail analytiques,

00:02:27.170 --> 00:02:31.410
et le mode ligne pour votre
charges de travail oLTP critiques.

00:02:31.700 --> 00:02:34.640
Nous allons aussi dans de nouveaux domaines

00:02:34.640 --> 00:02:37.220
que nous appelons
traitement approximatif des requêtes.

00:02:37.220 --> 00:02:40.640
Par exemple, pensez à un scénario
où une compagnie de chemin de fer garde

00:02:40.640 --> 00:02:42.350
suivi du nombre de billets qui sont

00:02:42.350 --> 00:02:44.935
acheté et utilisé dans le
l'ensemble du système ferroviaire.

00:02:44.935 --> 00:02:47.030
Ils gardent une trace de cette
afin de mettre en œuvre

00:02:47.030 --> 00:02:49.730
certaines mesures de contrôle des débits
quand c'est né cessaire,

00:02:49.730 --> 00:02:52.610
peut-être en adaptant le
horaires des trains,

00:02:52.610 --> 00:02:53.630
ou le nombre de trains en

00:02:53.630 --> 00:02:55.810
le système pour répondre à la
besoins du moment.

00:02:55.810 --> 00:02:58.920
Cette information est également
mise à jour dans un tableau de bord

00:02:58.920 --> 00:03:02.530
que les gens dans le centre-ville
Central peut jeter un oeil à.

00:03:02.530 --> 00:03:04.220
Maintenant, dans ce scénario, une partie de

00:03:04.220 --> 00:03:06.830
la charge de travail sera sûrement
pour exécuter une requête qui est

00:03:06.830 --> 00:03:09.020
constamment à la recherche d'obtenir

00:03:09.020 --> 00:03:12.005
le nombre de lignes de tous les
billets vendus et utilisés,

00:03:12.005 --> 00:03:14.600
et c'est probablement
venant d'un très

00:03:14.600 --> 00:03:17.605
grande écurie peut-être avec
milliards et milliards de lignes.

00:03:17.605 --> 00:03:20.540
Maintenant, cette requête récurrente
prendrait normalement

00:03:20.540 --> 00:03:23.735
ressources considérables sur
votre serveur, à savoir la mémoire.

00:03:23.735 --> 00:03:25.639
S'll est exécuté à plusieurs reprises,

00:03:25.639 --> 00:03:26.690
peut vraiment affecter

00:03:26.690 --> 00:03:28.900
les caractéristiques de performance
de votre base de données.

00:03:28.900 --> 00:03:30.670
Toutefois, dans ce scénario,

00:03:30.670 --> 00:03:32.750
la compagnie de chemin de fer
n'a pas nécessairement besoin

00:03:32.750 --> 00:03:35.830
un compte réel de tous les
billets vendus et utilisés.

00:03:35.830 --> 00:03:37.790
Mais un très haut
approximation est suffisant

00:03:37.790 --> 00:03:40.280
pour déclencher tous les
décision nécessaire.

00:03:40.280 --> 00:03:42.935
C'est là qu'approximative
compter distinct entre en vigueur,

00:03:42.935 --> 00:03:45.500
en permettant une requête
d'obtenir à plusieurs reprises

00:03:45.500 --> 00:03:48.185
le nombre approximatif
des billets vendus et utilisés

00:03:48.185 --> 00:03:51.080
sans les impacts graves à
les performances de votre base de données qui

00:03:51.080 --> 00:03:55.420
votre requête de comptage normale
prendrait aujourd'hui.

00:03:55.640 --> 00:03:58.695
En activant le mode Batch sur Row Store,

00:03:58.695 --> 00:03:59.950
nous déchaînons efficacement

00:03:59.950 --> 00:04:02.150
le mode de traitement qui est
particulièrement optimisé

00:04:02.150 --> 00:04:05.975
pour les charges de travail analytiques de plus de
n'importe quelle table de votre base de données.

00:04:05.975 --> 00:04:08.180
Cela signifie que même
pour les scénarios où

00:04:08.180 --> 00:04:10.385
un index de magasin de colonne
ne serait pas une option,

00:04:10.385 --> 00:04:14.395
le moteur de base de données peut encore
l'exécuter d'une manière optimisée.

00:04:14.395 --> 00:04:17.375
À son tour, cela ouvre la portée de

00:04:17.375 --> 00:04:20.630
caractéristiques comme Adaptive join
pour être utilisé par votre charge de travail.

00:04:20.630 --> 00:04:24.170
Joint adaptatif qui est seulement
disponible en mode lot peut

00:04:24.170 --> 00:04:28.940
maintenant être exploité à travers tous les
tables et la plupart de vos charges de travail.

00:04:29.590 --> 00:04:33.170
Nous nous sommes également attaqués à
la plupart des anti-modèles récurrents

00:04:33.170 --> 00:04:36.260
qui deviennent un problème pour
gestion des charges de travail de SQL Server.

00:04:36.260 --> 00:04:38.150
L'utilisation de Table
Variables et utilisation

00:04:38.150 --> 00:04:40.105
des UDF de Scalar, par exemple,

00:04:40.105 --> 00:04:42.440
et maintenant nous pouvons débloquer de nouveaux niveaux de

00:04:42.440 --> 00:04:46.375
l'optimisation des requêtes qui ont été
pas possible jusqu'à récemment.

00:04:46.375 --> 00:04:49.310
Tout cela, nous allons
discuter plus profondément et avec

00:04:49.310 --> 00:04:51.080
démos dans les vidéos à venir dans

00:04:51.080 --> 00:04:53.270
la série sur le
base de données intelligente,

00:04:53.270 --> 00:04:56.020
spécifiquement intelligent
traitement des requêtes.

00:04:56.020 --> 00:04:59.505
Mais si vous voulez savoir
plus à ce sujet aujourd'hui,

00:04:59.505 --> 00:05:04.200
alors s'il vous plaît aller à ce aka.ms/IQP

00:05:04.200 --> 00:05:06.899
URL où vous voyez tous
la documentation

00:05:06.899 --> 00:05:09.535
sur Intelligent Query
Traitement dans les bases de données SQL.

00:05:09.535 --> 00:05:13.100
Si vous voulez expérimenter
de ceux-ci par vous-même en ce moment,

00:05:13.100 --> 00:05:16.040
nous avons aussi des démos qui
vous pouvez regarder si vous

00:05:16.040 --> 00:05:18.980
aller à notre référentiel GitHub
et l'URL courte serait

00:05:18.980 --> 00:05:22.430
être aka.ms/IQPDemos où vous serez

00:05:22.430 --> 00:05:25.900
être en mesure de regarder tous ces
fonctionnalités et d'expérimenter par vous-même.

00:05:25.900 --> 00:05:27.795
Encore une fois, faites attention.

00:05:27.795 --> 00:05:28.980
Je vais bien tôt te parler.

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