WEBVTT

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

00:00:10.560 --> 00:00:12.975
>> Hola, bienvenidos a un nuevo
episodio de Data Exposed.

00:00:12.975 --> 00:00:14.460
Mi nombre es Pedro Lopes.

00:00:14.460 --> 00:00:16.920
Soy Gerente de Programas en el
Equipo de ingeniería de SQL Server.

00:00:16.920 --> 00:00:18.510
Hoy, voy a estar hablando

00:00:18.510 --> 00:00:20.670
acerca de Inteligente
Base de datos, específicamente,

00:00:20.670 --> 00:00:23.809
Procesamiento inteligente de consultas
en SQL Server 2019,

00:00:23.809 --> 00:00:25.925
y también Azure SQL Database.

00:00:25.925 --> 00:00:29.390
Así que vamos a hacerlo. Sql
Server 2019 presenta

00:00:29.390 --> 00:00:31.864
consulta innovadora
mejoras de rendimiento

00:00:31.864 --> 00:00:34.655
y son los Inteligentes
Familia de procesamiento de consultas.

00:00:34.655 --> 00:00:37.820
Estos conforman lo último en
la misión de Microsoft para asegurarse de que

00:00:37.820 --> 00:00:41.690
que las cargas de trabajo paralelas críticas
mejorar cuando se ejecuta a escala,

00:00:41.690 --> 00:00:45.470
adaptación a la
mundo de datos en constante cambio,

00:00:45.470 --> 00:00:47.855
a medida que los datos se mueven y
de las bases de datos.

00:00:47.855 --> 00:00:49.670
En este video, te voy a dar

00:00:49.670 --> 00:00:51.980
una rápida visión general de la
Mundo de bases de datos inteligentes

00:00:51.980 --> 00:00:53.030
que realmente da un salto

00:00:53.030 --> 00:00:56.150
adelante con el próximo
SQL Server 2019,

00:00:56.150 --> 00:00:58.700
y presentarles un número
de características que vamos a bucear

00:00:58.700 --> 00:01:02.130
en más profundo en otros
videos en esta serie.

00:01:03.170 --> 00:01:07.510
Procesamiento inteligente de consultas
en SQL Server está disponible por

00:01:07.510 --> 00:01:11.245
por defecto en la última base de datos
configuración del nivel de compatibilidad.

00:01:11.245 --> 00:01:13.210
Eso significa que después de actualizar,

00:01:13.210 --> 00:01:15.130
esto puede estar disponible sólo por

00:01:15.130 --> 00:01:18.000
volteando el interruptor para usar el
configuración de compatibilidad más reciente.

00:01:18.000 --> 00:01:22.030
Procesamiento inteligente de consultas
también ofrece un impacto amplio

00:01:22.030 --> 00:01:23.440
que mejora el rendimiento de

00:01:23.440 --> 00:01:26.650
cargas de trabajo existentes con
mínimo esfuerzo de implementación.

00:01:26.650 --> 00:01:28.390
Esto realmente significa que la mayoría de las veces,

00:01:28.390 --> 00:01:30.965
no hay necesidad cero de
refactorizar el código.

00:01:30.965 --> 00:01:33.310
El procesamiento inteligente de consultas mejora

00:01:33.310 --> 00:01:36.190
cargas de trabajo paralelas críticas
cuando se ejecuta a escala,

00:01:36.190 --> 00:01:39.355
y a medida que los datos fluyen y
fuera de su base de datos,

00:01:39.355 --> 00:01:41.380
nos adaptaremos a eso y

00:01:41.380 --> 00:01:44.660
mantener un nivel de
rendimiento predecible.

00:01:44.660 --> 00:01:47.450
Por ejemplo, mediante la introducción de

00:01:47.450 --> 00:01:49.880
un mecanismo de retroalimentación
en el uso de memoria,

00:01:49.880 --> 00:01:53.630
podemos asegurar que su carga de trabajo
se ejecuta de una manera predecible.

00:01:53.630 --> 00:01:58.190
Si una ejecución de consulta determinada
tal vez ocupar demasiada memoria,

00:01:58.190 --> 00:01:59.750
podemos corregirlo y

00:01:59.750 --> 00:02:02.375
aumentar la simultaneidad
factor de su base de datos.

00:02:02.375 --> 00:02:06.020
Si una ejecución de capital determinada
no tiene suficiente memoria y

00:02:06.020 --> 00:02:09.560
termina usando E/S adicional
en todo se conoce como un derrame,

00:02:09.560 --> 00:02:11.315
entonces también podemos encontrar que

00:02:11.315 --> 00:02:13.565
y corregir la situación
para que la operación

00:02:13.565 --> 00:02:15.260
se ejecuta en la memoria y

00:02:15.260 --> 00:02:18.200
actúa como se esperaba en
ejecuciones posteriores.

00:02:18.200 --> 00:02:20.540
Esta característica ahora está habilitada para

00:02:20.540 --> 00:02:22.835
todos los modos de ejecución en
el centro de bases de datos.

00:02:22.835 --> 00:02:27.170
Modo por lotes para más almacenamiento de datos
y cargas de trabajo analíticas,

00:02:27.170 --> 00:02:31.410
y el modo de fila para su
cargas de trabajo olTP críticas.

00:02:31.700 --> 00:02:34.640
También vamos a nuevas áreas

00:02:34.640 --> 00:02:37.220
que estamos llamando
procesamiento aproximado de consultas.

00:02:37.220 --> 00:02:40.640
Por ejemplo, piense en un escenario
donde una compañía ferroviaria mantiene

00:02:40.640 --> 00:02:42.350
seguimiento del número de entradas que son

00:02:42.350 --> 00:02:44.935
comprados y utilizados en el
todo el sistema ferroviario.

00:02:44.935 --> 00:02:47.030
Hacen un seguimiento de esto
con el fin de implementar

00:02:47.030 --> 00:02:49.730
algunas mediciones de control de flujo
cuando se necesita,

00:02:49.730 --> 00:02:52.610
tal vez mediante la adaptación de la
horarios de los trenes,

00:02:52.610 --> 00:02:53.630
o el número de trenes en

00:02:53.630 --> 00:02:55.810
el sistema para cumplir con el
necesidades del momento.

00:02:55.810 --> 00:02:58.920
Esta información también es
actualizado en un tablero

00:02:58.920 --> 00:03:02.530
que la gente en el centro de la ciudad
Central puede echar un vistazo.

00:03:02.530 --> 00:03:04.220
Ahora, en este escenario parte de

00:03:04.220 --> 00:03:06.830
la carga de trabajo será sin duda
para ejecutar una consulta que es

00:03:06.830 --> 00:03:09.020
constantemente buscando la obtención de

00:03:09.020 --> 00:03:12.005
el recuento de filas de todos los
entradas que se venden y utilizan,

00:03:12.005 --> 00:03:14.600
y esto es probablemente
viniendo de un muy

00:03:14.600 --> 00:03:17.605
gran estable tal vez con
miles de millones y miles de millones de filas.

00:03:17.605 --> 00:03:20.540
Ahora, esta consulta recurrente
normalmente tomaría

00:03:20.540 --> 00:03:23.735
considerables recursos en
su servidor, a saber, la memoria.

00:03:23.735 --> 00:03:25.639
Si se ejecuta repetidamente,

00:03:25.639 --> 00:03:26.690
realmente puede afectar

00:03:26.690 --> 00:03:28.900
las características de rendimiento
de su base de datos.

00:03:28.900 --> 00:03:30.670
Sin embargo, en este escenario,

00:03:30.670 --> 00:03:32.750
la compañía ferroviaria
no necesariamente necesita

00:03:32.750 --> 00:03:35.830
un recuento real de todos los
entradas que se venden y utilizan.

00:03:35.830 --> 00:03:37.790
Pero un muy alto
aproximación es suficiente

00:03:37.790 --> 00:03:40.280
para desencadenar todos los
toma de decisiones requerida.

00:03:40.280 --> 00:03:42.935
Aquí es donde se aproxima
cuenta distinta entra en,

00:03:42.935 --> 00:03:45.500
al permitir una consulta
para obtener repetidamente

00:03:45.500 --> 00:03:48.185
el conteo aproximado
de entradas vendidas y usadas

00:03:48.185 --> 00:03:51.080
sin los graves impactos
el rendimiento de la base de datos que

00:03:51.080 --> 00:03:55.420
su consulta de recuento normal
tomaría hoy.

00:03:55.640 --> 00:03:58.695
Al habilitar el modo por lotes en el almacén de filas,

00:03:58.695 --> 00:03:59.950
efectivamente desatamos

00:03:59.950 --> 00:04:02.150
el modo de procesamiento que es
especialmente optimizado

00:04:02.150 --> 00:04:05.975
para cargas de trabajo analíticas a lo largo de
cualquier tabla de su base de datos.

00:04:05.975 --> 00:04:08.180
Esto significa que incluso
para escenarios en los que

00:04:08.180 --> 00:04:10.385
un índice de almacén de columnas
no sería una opción,

00:04:10.385 --> 00:04:14.395
el motor de base de datos todavía puede
ejecutar esto de una manera optimizada.

00:04:14.395 --> 00:04:17.375
A su vez, esto abre el alcance de la

00:04:17.375 --> 00:04:20.630
características como La unión adaptable
para ser utilizado por su carga de trabajo.

00:04:20.630 --> 00:04:24.170
Unión adaptativa que es sólo
disponible en modo por lotes puede

00:04:24.170 --> 00:04:28.940
ahora ser aprovechado en todos los
tablas y la mayoría de sus cargas de trabajo.

00:04:29.590 --> 00:04:33.170
También abordamos algunos de los
la mayoría de los antipatrones recurrentes

00:04:33.170 --> 00:04:36.260
que se convierten en un problema para
cargas de trabajo administradas de SQL Server.

00:04:36.260 --> 00:04:38.150
El uso de la tabla
Variables y el uso

00:04:38.150 --> 00:04:40.105
de las UDF escalares, por ejemplo,

00:04:40.105 --> 00:04:42.440
y ahora podemos desbloquear nuevos niveles de

00:04:42.440 --> 00:04:46.375
optimización de consultas que se
no es posible hasta hace poco.

00:04:46.375 --> 00:04:49.310
Todo esto, vamos a
discutir más profundo y con

00:04:49.310 --> 00:04:51.080
demostraciones en los próximos videos en

00:04:51.080 --> 00:04:53.270
la serie sobre el
base de datos inteligente,

00:04:53.270 --> 00:04:56.020
específicamente inteligente
procesamiento de consultas.

00:04:56.020 --> 00:04:59.505
Pero si quieres saber
más sobre él hoy,

00:04:59.505 --> 00:05:04.200
entonces por favor vaya a este aka.ms/IQP

00:05:04.200 --> 00:05:06.899
URL donde se ve todo
la documentación

00:05:06.899 --> 00:05:09.535
en Consulta Inteligente
Procesamiento en bases de datos SQL.

00:05:09.535 --> 00:05:13.100
Si quieres experimentar un poco
de estos por ti mismo en este momento,

00:05:13.100 --> 00:05:16.040
también tenemos demostraciones que
se puede mirar si

00:05:16.040 --> 00:05:18.980
ir a nuestro repositorio GitHub
y la URL corta

00:05:18.980 --> 00:05:22.430
ser aka.ms/IQPDemos donde usted

00:05:22.430 --> 00:05:25.900
ser capaz de mirar a todos estos
características y experimentar por sí mismo.

00:05:25.900 --> 00:05:27.795
Así que de nuevo, cuídate.

00:05:27.795 --> 00:05:28.980
Te hablaré pronto.

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