WEBVTT

00:00:00.000 --> 00:00:10.560
[음악].

00:00:10.560 --> 00:00:12.975
>> 이봐, 새로운
데이터 노출의 에피소드.

00:00:12.975 --> 00:00:14.460
제 이름은 페드로 로페스입니다.

00:00:14.460 --> 00:00:16.920
프로그램 관리자입니다.
SQL 서버 엔지니어링 팀.

00:00:16.920 --> 00:00:18.510
오늘, 나는 이야기 할거야

00:00:18.510 --> 00:00:20.670
지능형 에 대한
데이터베이스, 특히,

00:00:20.670 --> 00:00:23.809
지능형 쿼리 처리
SQL Server 2019에서

00:00:23.809 --> 00:00:25.925
또한 Azure SQL 데이터베이스.

00:00:25.925 --> 00:00:29.390
그래서 그것을 얻을 수 있습니다. Sql
서버 2019 소개

00:00:29.390 --> 00:00:31.864
획기적인 쿼리
성능 향상

00:00:31.864 --> 00:00:34.655
그리고 그들은 지능입니다
쿼리 처리 패밀리입니다.

00:00:34.655 --> 00:00:37.820
이 것들은 최신
마이크로 소프트의 임무는 있는지 확인

00:00:37.820 --> 00:00:41.690
중요한 병렬 워크로드
대규모 로 실행할 때 개선,

00:00:41.690 --> 00:00:45.470
에 적응하는 동안
끊임없이 변화하는 데이터 세계,

00:00:45.470 --> 00:00:47.855
데이터가 이동함에 따라
데이터베이스에서 제외됩니다.

00:00:47.855 --> 00:00:49.670
이 비디오에서, 나는 당신을 줄거야

00:00:49.670 --> 00:00:51.980
에 대한 간략한 개요
지능형 데이터베이스 세계

00:00:51.980 --> 00:00:53.030
정말 도약을 합니다.

00:00:53.030 --> 00:00:56.150
앞으로
SQL Server 2019,

00:00:56.150 --> 00:00:58.700
숫자를 소개합니다.
우리가 다이빙 할 기능의

00:00:58.700 --> 00:01:02.130
다른 더 깊은
이 시리즈의 비디오.

00:01:03.170 --> 00:01:07.510
지능형 쿼리 처리
에서 SQL Server에서 사용할 수 있습니다.

00:01:07.510 --> 00:01:11.245
최신 데이터베이스의 기본값
호환성 수준 설정.

00:01:11.245 --> 00:01:13.210
즉, 업그레이드한 후

00:01:13.210 --> 00:01:15.130
이 것을 통해 사용할 수 있습니다.

00:01:15.130 --> 00:01:18.000
스위치를 뒤집어
최신 호환성 설정.

00:01:18.000 --> 00:01:22.030
지능형 쿼리 처리
또한 광범위한 영향을 미칩니다.

00:01:22.030 --> 00:01:23.440
성능을 향상시킵니다.

00:01:23.440 --> 00:01:26.650
기존 워크로드와
최소한의 구현 노력을 할 수 있습니다.

00:01:26.650 --> 00:01:28.390
이것은 정말 대부분의 시간을 의미,

00:01:28.390 --> 00:01:30.965
제로 가 필요합니다.
코드를 리팩터링합니다.

00:01:30.965 --> 00:01:33.310
지능형 쿼리 처리가 향상됩니다.

00:01:33.310 --> 00:01:36.190
중요한 병렬 워크로드
대규모로 실행할 때,

00:01:36.190 --> 00:01:39.355
그리고 데이터가 유입될 때
데이터베이스에서

00:01:39.355 --> 00:01:41.380
우리는 그에 적응하고

00:01:41.380 --> 00:01:44.660
수준을 유지합니다.
예측 가능한 성능을 발휘합니다.

00:01:44.660 --> 00:01:47.450
예를 들어,

00:01:47.450 --> 00:01:49.880
피드백 메커니즘
메모리 사용량에,

00:01:49.880 --> 00:01:53.630
우리는 귀하의 워크로드를 보장 할 수 있습니다
예측 가능한 방식으로 실행됩니다.

00:01:53.630 --> 00:01:58.190
지정된 쿼리 실행이
어쩌면 너무 많은 메모리를 차지,

00:01:58.190 --> 00:01:59.750
우리는 그것을 수정할 수 있으며

00:01:59.750 --> 00:02:02.375
동시성 증가
데이터베이스의 요소입니다.

00:02:02.375 --> 00:02:06.020
특정 지분 실행의 경우
충분한 메모리를 얻지 못하고

00:02:06.020 --> 00:02:09.560
추가 IO를 사용하여 끝납니다.
전체적으로 유출로 알려져 있으며,

00:02:09.560 --> 00:02:11.315
우리는 또한 그것을 찾을 수 있습니다

00:02:11.315 --> 00:02:13.565
상황을 수정합니다.
작업이 수행되도록

00:02:13.565 --> 00:02:15.260
메모리에서 실행되고

00:02:15.260 --> 00:02:18.200
에서 예상대로 수행됩니다.
후속 실행을 수행합니다.

00:02:18.200 --> 00:02:20.540
이 기능은 이제

00:02:20.540 --> 00:02:22.835
에서 모든 실행 모드
데이터베이스 센터입니다.

00:02:22.835 --> 00:02:27.170
더 많은 데이터 웨어하우스를 위한 배치 모드
및 분석 워크로드,

00:02:27.170 --> 00:02:31.410
및 행 모드
중요한 OLTP 워크로드를 지원합니다.

00:02:31.700 --> 00:02:34.640
우리는 또한 새로운 지역으로 가고 있습니다.

00:02:34.640 --> 00:02:37.220
우리가 부르는
대략적인 쿼리 처리.

00:02:37.220 --> 00:02:40.640
예를 들어, 시나리오를 생각해 보십시오.
철도 회사가 유지하는 곳

00:02:40.640 --> 00:02:42.350
티켓 의 수를 추적

00:02:42.350 --> 00:02:44.935
구입 및 사용
전체 철도 시스템.

00:02:44.935 --> 00:02:47.030
그들은 이것을 추적합니다.
구현하기 위해

00:02:47.030 --> 00:02:49.730
일부 유량 제어 측정
필요할 때,

00:02:49.730 --> 00:02:52.610
아마도
열차의 일정,

00:02:52.610 --> 00:02:53.630
또는 열차 의 수

00:02:53.630 --> 00:02:55.810
시스템을 충족시킬 수 있습니다.
순간의 요구.

00:02:55.810 --> 00:02:58.920
이 정보는
대시보드에서 업데이트됨

00:02:58.920 --> 00:03:02.530
다운타운에 있는 사람들
중앙에서 살펴볼 수 있습니다.

00:03:02.530 --> 00:03:04.220
이제 이 시나리오에서

00:03:04.220 --> 00:03:06.830
워크로드는 확실히 될 것입니다
쿼리를 실행하려면

00:03:06.830 --> 00:03:09.020
지속적으로 얻는 것을 보고

00:03:09.020 --> 00:03:12.005
모든 행 수
판매 및 사용 티켓,

00:03:12.005 --> 00:03:14.600
그리고 이것은 아마
매우 에서 오는

00:03:14.600 --> 00:03:17.605
큰 안정아마도
수십억 개의 행이 있습니다.

00:03:17.605 --> 00:03:20.540
이제 이 되풀이 쿼리
일반적으로 차지할 것입니다.

00:03:20.540 --> 00:03:23.735
상당한 자원을
서버, 즉 메모리.

00:03:23.735 --> 00:03:25.639
반복적으로 실행되는 경우

00:03:25.639 --> 00:03:26.690
정말 영향을 미칠 수 있습니다

00:03:26.690 --> 00:03:28.900
성능 특성
데이터베이스의

00:03:28.900 --> 00:03:30.670
그러나 이 시나리오에서는

00:03:30.670 --> 00:03:32.750
철도 회사
반드시 필요한 것은 아닙니다.

00:03:32.750 --> 00:03:35.830
모든 의 실제 카운트
판매 및 사용 티켓.

00:03:35.830 --> 00:03:37.790
그러나 매우 높은
근사치로 충분합니다.

00:03:37.790 --> 00:03:40.280
모든
필요한 의사 결정을 내릴 수 있습니다.

00:03:40.280 --> 00:03:42.935
여기서 대략적인
카운트는 뚜렷하게 들어오고,

00:03:42.935 --> 00:03:45.500
쿼리를 허용하여
반복적으로 얻을 수 있습니다.

00:03:45.500 --> 00:03:48.185
대략적인 개수
판매 및 사용 티켓의

00:03:48.185 --> 00:03:51.080
심각한 영향을 미치지 않고
데이터베이스 성능은

00:03:51.080 --> 00:03:55.420
일반 카운트 쿼리
오늘 걸릴 것입니다.

00:03:55.640 --> 00:03:58.695
행 저장소에서 일괄 모드를 활성화하면

00:03:58.695 --> 00:03:59.950
우리는 효과적으로

00:03:59.950 --> 00:04:02.150
처리 모드
특히 최적화

00:04:02.150 --> 00:04:05.975
분석 워크로드에 대한
데이터베이스의 모든 테이블을 참조하십시오.

00:04:05.975 --> 00:04:08.180
이는
시나리오에 대한

00:04:08.180 --> 00:04:10.385
열 저장소 인덱스
옵션이 아닐 것입니다.

00:04:10.385 --> 00:04:14.395
데이터베이스 엔진은 여전히
최적화된 방식으로 실행합니다.

00:04:14.395 --> 00:04:17.375
그러면

00:04:17.375 --> 00:04:20.630
적응 조인과 같은 기능
워크로드에서 사용할 수 있습니다.

00:04:20.630 --> 00:04:24.170
적응 조인만
배치 모드에서 사용할 수 있습니다.

00:04:24.170 --> 00:04:28.940
이제 모든
테이블과 대부분의 워크로드를 제공합니다.

00:04:29.590 --> 00:04:33.170
우리는 또한 의 일부를 다루었다.
가장 반복적인 안티 패턴

00:04:33.170 --> 00:04:36.260
문제가 되는 경우
관리되는 SQL Server 워크로드를 처리합니다.

00:04:36.260 --> 00:04:38.150
표의 사용
변수 및 사용

00:04:38.150 --> 00:04:40.105
예를 들어, 스칼라 우디피의

00:04:40.105 --> 00:04:42.440
그리고 지금 우리는의 새로운 수준의 잠금을 해제 할 수 있습니다

00:04:42.440 --> 00:04:46.375
쿼리 최적화
최근까지는 불가능합니다.

00:04:46.375 --> 00:04:49.310
이 모든 것, 우리는
더 심도 있는 토론과 함께

00:04:49.310 --> 00:04:51.080
다가오는 동영상의 데모

00:04:51.080 --> 00:04:53.270
시리즈에 대한
지능형 데이터베이스,

00:04:53.270 --> 00:04:56.020
특히 지능적인
쿼리 처리.

00:04:56.020 --> 00:04:59.505
하지만 당신이 알고 싶은 경우에
오늘 그것에 대해 더 많은,

00:04:59.505 --> 00:05:04.200
다음이 aka.ms/IQP 이동하십시오

00:05:04.200 --> 00:05:06.899
모든 것을 볼 수 있는 URL
설명서

00:05:06.899 --> 00:05:09.535
지능형 쿼리에
SQL 데이터베이스에서 처리 중입니다.

00:05:09.535 --> 00:05:13.100
일부 를 실험하려는 경우
지금 혼자서,

00:05:13.100 --> 00:05:16.040
우리는 또한 데모를 가지고
당신은 당신이 볼 수 있습니다

00:05:16.040 --> 00:05:18.980
GitHub 리포지토리로 이동
그리고 짧은 URL은

00:05:18.980 --> 00:05:22.430
당신이 할 수있는 aka.ms/IQPDemos

00:05:22.430 --> 00:05:25.900
이 모든 것을 볼 수 있어야합니다.
기능 및 자신에 의해 실험.

00:05:25.900 --> 00:05:27.795
그래서 다시, 주의.

00:05:27.795 --> 00:05:28.980
나는 곧 당신에게 이야기 할 것이다.

00:05:28.980 --> 00:05:43.780
[음악].

