WEBVTT

00:00:00.000 --> 00:00:10.500
[音楽]。

00:00:10.500 --> 00:00:11.910
>> こんにちは、お帰りなさい。

00:00:11.910 --> 00:00:14.970
私の名前はJRJ、私はここにいます
の1つについてあなたに話すために

00:00:14.970 --> 00:00:18.915
最も熱心に予想される
SQL Server 2019 の機能,

00:00:18.915 --> 00:00:21.285
データの仮想化です。

00:00:21.285 --> 00:00:23.175
データ仮想化とは何か、

00:00:23.175 --> 00:00:25.440
そして、なぜそれが非常に熱心に期待されているのですか?

00:00:25.440 --> 00:00:27.510
まあ、簡単に言えば、

00:00:27.510 --> 00:00:29.510
データ仮想化により、

00:00:29.510 --> 00:00:31.670
すべてのデータをまとめる

00:00:31.670 --> 00:00:35.780
クエリ時間を実行する必要はなさかではなく、
で複雑な ETL パイプラインを構築する

00:00:35.780 --> 00:00:40.535
統一できるようにするために
単一のクエリ内のデータ。

00:00:40.535 --> 00:00:44.150
だから私は何をするつもりなのか
行くよりむしろ行く

00:00:44.150 --> 00:00:47.540
データの詳細を通じて
概念レベルでの仮想化、

00:00:47.540 --> 00:00:49.730
見せてやるだけだ
両者の違い

00:00:49.730 --> 00:00:52.430
ローカル クエリと
仮想化クエリ,

00:00:52.430 --> 00:00:55.085
部分的にも完全に仮想化も。

00:00:55.085 --> 00:00:56.280
そのためには、

00:00:56.280 --> 00:00:58.010
私たちがやることは
私たちは切り替えるつもりです

00:00:58.010 --> 00:01:00.270
今、Azureデータスタジオに、

00:01:00.270 --> 00:01:03.035
そして、あなたはここで私を見ることができます
ブックを開い、

00:01:03.035 --> 00:01:08.990
そして、中に入りましょうと
評価を開始します。

00:01:08.990 --> 00:01:13.625
だから、ここであなたは私を見ることができます
非常に単純なクエリを持っています。

00:01:13.625 --> 00:01:17.030
私は2つのローカルを持っています
私のデータベース内のテーブル、

00:01:17.030 --> 00:01:19.160
そのクエリを実行すると、

00:01:19.160 --> 00:01:23.405
あなたは結果を想像することができます
素敵で迅速に戻ってきます。

00:01:23.405 --> 00:01:25.190
私は約1秒を持っている、

00:01:25.190 --> 00:01:28.045
そして、私は私のデータセットを取得します
ノートブックに戻ります。

00:01:28.045 --> 00:01:31.630
しかし、そのすべてが
データが SQL Server にありませんでしたか?

00:01:31.630 --> 00:01:36.200
そのデータが実際にあった場合
リモート SQL サーバーで利用可能,

00:01:36.200 --> 00:01:40.145
そして、私たちは、そのアクセスをしたかった
すべてのデータを同時に?

00:01:40.145 --> 00:01:43.700
データ仮想化を使用できます。
その問題を解くために。

00:01:43.700 --> 00:01:45.050
しかし、それを行うために、

00:01:45.050 --> 00:01:47.030
いくつかのメタデータを設定する必要があります。

00:01:47.030 --> 00:01:50.510
だから、私たちが最初にする必要があるもの
マスターキーを作成する

00:01:50.510 --> 00:01:53.720
マスターキーは内部のキーです

00:01:53.720 --> 00:01:55.910
保護に使用するデータベース

00:01:55.910 --> 00:01:58.660
その中の他のすべてのメタデータ。

00:01:58.660 --> 00:02:03.380
メタデータから見ることができます
ここでは、どのアルゴリズムを使用しているのか、

00:02:03.380 --> 00:02:06.110
作成時、
そんな面白いこと。

00:02:06.110 --> 00:02:10.745
今、私はポリベースを有効にする必要があります
可能にするために機能

00:02:10.745 --> 00:02:16.310
リモート ソースへのアクセス
およびリモート データベース、

00:02:16.310 --> 00:02:19.220
をクリックし、データベース資格情報を作成します。

00:02:19.220 --> 00:02:23.495
認証できる
これらのリモートソースに対して、

00:02:23.495 --> 00:02:28.835
そして、あなたは私が持っていることをここで見ることができます
過去にいくつか作成し、

00:02:28.835 --> 00:02:30.200
オラクルのカップルとして、

00:02:30.200 --> 00:02:32.225
そして、SQLのカップル
そこにも1つ。

00:02:32.225 --> 00:02:36.680
でも今日は行く
SQL データ ソースに対して、

00:02:36.680 --> 00:02:39.650
そして、あなたはここで見ることができます
そのためには、

00:02:39.650 --> 00:02:41.730
を作成する必要があります。
外部データ ソース。

00:02:41.730 --> 00:02:45.390
ここでは、
場所、この場合、

00:02:45.390 --> 00:02:49.160
SQL Server アドレス
アズールのどこかで、

00:02:49.160 --> 00:02:51.874
そして、私はその資格情報を渡します

00:02:51.874 --> 00:02:54.425
その認証を有効にするには
を実行します。

00:02:54.425 --> 00:02:56.590
それでは、先に行って作成してみましょう。

00:02:56.590 --> 00:03:00.880
そして、あなたは再び見ることができます、
データベース内のメタデータ。

00:03:00.880 --> 00:03:03.040
さて、一般的なルールとして、

00:03:03.040 --> 00:03:06.290
私は外部を維持するのが好きです
定義するテーブル

00:03:06.290 --> 00:03:08.465
これらの外部データ ソース オブジェクト

00:03:08.465 --> 00:03:11.210
私の内部テーブルとは別に、

00:03:11.210 --> 00:03:12.890
そして、私はスキーマを使用してそれを行います。

00:03:12.890 --> 00:03:16.500
それでは、先に行きましょう
外部スキーマを作成し、

00:03:17.660 --> 00:03:23.350
そして今、私たちはここに来ることができ、
最初の外部テーブルを作成します。

00:03:23.350 --> 00:03:25.730
最初の外部テーブル
私たちは作成するつもりです

00:03:25.730 --> 00:03:28.240
ウェブクリックストリーム
は最初のテーブルです。

00:03:28.240 --> 00:03:31.315
そして、この場合、それは
よりファクトテーブルのように、

00:03:31.315 --> 00:03:34.755
そして、私たちはそれを保存するつもりです。

00:03:34.755 --> 00:03:36.490
したがって、その外部データベースでは、

00:03:36.490 --> 00:03:38.375
私たちはまったく同じデータベースを持っています。

00:03:38.375 --> 00:03:44.200
もう一度使って
このシナリオを説明します。

00:03:44.200 --> 00:03:50.515
さて、私たちはプロセスに取り組むことができます
クリックストリームの仮想化の、

00:03:50.515 --> 00:03:52.900
Web クリックストリーム テーブル。

00:03:52.900 --> 00:03:56.500
ここでは、私が持っていることがわかります
同じテーブル Web クリックストリーム、

00:03:56.500 --> 00:03:58.660
しかし、今、私はEXTスキーマを使用しています。

00:03:58.660 --> 00:04:01.060
だから私は外部テーブルにアクセスしている

00:04:01.060 --> 00:04:02.440
しかし、すべての意図と目的に、

00:04:02.440 --> 00:04:05.630
クエリの残りの部分
はまったく同じです。

00:04:05.630 --> 00:04:08.225
ここでそのクエリを実行すると、

00:04:08.225 --> 00:04:10.120
それが必要だとしましょう
理由から少し長い

00:04:10.120 --> 00:04:12.100
私たちは行くつもりです
そのデータをリモートで取得し、

00:04:12.100 --> 00:04:14.905
そして、あなたはそれを言うことができる
約3.5秒。

00:04:14.905 --> 00:04:17.260
しかし、私たちは、我々が持っていることがわかります

00:04:17.260 --> 00:04:20.785
そのデータはここで
全く同じです。

00:04:20.785 --> 00:04:23.710
だから、フードの下のすべて

00:04:23.710 --> 00:04:27.065
は完全に透明です
ユーザーとして私に。

00:04:27.065 --> 00:04:29.920
さて、私が実際に先に行くとし、

00:04:29.920 --> 00:04:33.250
2 番目の仮想化
このクエリの外部テーブル

00:04:33.250 --> 00:04:35.680
あなたは最初のことを覚えている
1つはウェブクリップストリームで、

00:04:35.680 --> 00:04:38.905
2番目の
は項目テーブルです。

00:04:38.905 --> 00:04:41.090
それでは、先に行って、それを行いましょう

00:04:41.090 --> 00:04:45.650
そして今、私は両方を持っている
テーブルが仮想化されます。

00:04:47.290 --> 00:04:52.290
だから今、何が起こるか
この最後のクエリを実行しますか?

00:04:52.290 --> 00:04:57.565
この最後のクエリは、
まったく同じクエリを実行します。

00:04:57.565 --> 00:05:01.670
しかし、両方の外部
テーブルは仮想化され、

00:05:01.940 --> 00:05:05.275
そして、あなたは実際にそれを見ることができます
クエリはほぼ同じ

00:05:05.275 --> 00:05:09.375
最初のように速い
バージョン、ローカル クエリ。

00:05:09.375 --> 00:05:12.530
どうしてなの?なぜ我々は得るのか
パフォーマンスのこの違い?

00:05:12.530 --> 00:05:14.780
まあ、その理由は
あなたが見れば

00:05:14.780 --> 00:05:17.000
SQL サーバー
十分に知的な使用

00:05:17.000 --> 00:05:20.600
コストベースのオプティマイザ
それを理解するために

00:05:20.600 --> 00:05:24.725
両方のテーブルが外部であり、
彼らは同じソースから来て、

00:05:24.725 --> 00:05:28.400
そして、それが見ることができること
この結合をプッシュし、

00:05:28.400 --> 00:05:32.030
集計ダウン
そのリモート ソースに対して。

00:05:32.030 --> 00:05:34.190
そこで、私たちは次の計算を活用しています。

00:05:34.190 --> 00:05:37.445
解決するリモート ソース
このクエリをリアルタイムで実行します。

00:05:37.445 --> 00:05:41.030
しかし、それはあなたに簡単な概要を提供します
ユーザーが持つ機能の

00:05:41.030 --> 00:05:44.750
データの使用から抜け出す
仮想化技術

00:05:44.750 --> 00:05:48.470
そして、あなたが実際にできる方法
そのデータを透過的に提示する

00:05:48.470 --> 00:05:50.390
エンド ユーザーに戻る必要なしに

00:05:50.390 --> 00:05:52.520
そのデータの物理的なコピーを作成し、

00:05:52.520 --> 00:05:54.410
移動またはビルドすることなく

00:05:54.410 --> 00:05:56.420
の複雑な ETL パイプライン

00:05:56.420 --> 00:05:58.910
可能な順序
リアルタイムでデータをクエリします。

00:05:58.910 --> 00:06:00.510
参加してくださってありがとうございます。

00:06:00.510 --> 00:06:02.960
そして、私はキャッチすることを楽しみにしています
すぐにまたあなたと一緒にアップ。

00:06:02.960 --> 00:06:17.560
[音楽]