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 Server エンジニアリング チーム。

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
たとえば、スカラー UDF の

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
[音楽]。

