WEBVTT

00:00:00.000 --> 00:00:10.500
[MUSIK].

00:00:10.500 --> 00:00:11.910
>> Hallo und willkommen zurück.

00:00:11.910 --> 00:00:14.970
Mein Name ist JRJ, und ich bin hier
um Ihnen von einem der

00:00:14.970 --> 00:00:18.915
die mit Spannung erwarteten
Funktionen in SQL Server 2019,

00:00:18.915 --> 00:00:21.285
und das ist Datenvirtualisierung.

00:00:21.285 --> 00:00:23.175
Was ist Datenvirtualisierung,

00:00:23.175 --> 00:00:25.440
und warum wird so mit Spannung gerechnet?

00:00:25.440 --> 00:00:27.510
Nun, einfach gesagt,

00:00:27.510 --> 00:00:29.510
Datenvirtualisierung ermöglicht es Ihnen,

00:00:29.510 --> 00:00:31.670
alle Ihre Daten zusammenzuführen unter

00:00:31.670 --> 00:00:35.780
Abfragezeit statt
komplexe ETL-Pipelines in

00:00:35.780 --> 00:00:40.535
um in der Lage zu sein,
die Daten in einer einzelnen Abfrage.

00:00:40.535 --> 00:00:44.150
Also, was ich werde
tun ist, anstatt zu gehen

00:00:44.150 --> 00:00:47.540
durch die Details der Daten
Virtualisierung auf konzeptioneller Ebene,

00:00:47.540 --> 00:00:49.730
Ich werde dir nur zeigen
die Unterschiede zwischen

00:00:49.730 --> 00:00:52.430
eine lokale Abfrage und eine
virtualisierte Abfrage,

00:00:52.430 --> 00:00:55.085
sowohl teilweise als auch vollständig virtualisiert.

00:00:55.085 --> 00:00:56.280
Um das zu tun,

00:00:56.280 --> 00:00:58.010
was wir tun werden, ist
wir werden umschalten

00:00:58.010 --> 00:01:00.270
jetzt zu Azure Data Studio,

00:01:00.270 --> 00:01:03.035
und Sie können hier sehen, ich
eine Arbeitsmappe geöffnet haben,

00:01:03.035 --> 00:01:08.990
und lassen Sie uns hineingehen und
beginnen, dies zu bewerten.

00:01:08.990 --> 00:01:13.625
Hier können Sie also sehen, dass ich
eine sehr einfache Abfrage haben.

00:01:13.625 --> 00:01:17.030
Ich habe zwei lokale
Tabellen in meiner Datenbank,

00:01:17.030 --> 00:01:19.160
und wenn ich diese Abfrage ausführe,

00:01:19.160 --> 00:01:23.405
Sie könnten sich das Ergebnis vorstellen
kommt schön und schnell zurück.

00:01:23.405 --> 00:01:25.190
Ich habe etwa eine Sekunde,

00:01:25.190 --> 00:01:28.045
und ich erhalte meinen Datensatz
zurück im Notizbuch.

00:01:28.045 --> 00:01:31.630
Was jedoch, wenn all dies
Daten nicht im SQL Server enthalten?

00:01:31.630 --> 00:01:36.200
Was wäre, wenn diese Daten tatsächlich
in Remote-SQL-Servern verfügbar,

00:01:36.200 --> 00:01:40.145
und wir wollten darauf zugreifen, dass
Daten gleichzeitig?

00:01:40.145 --> 00:01:43.700
Nun, Sie können Datenvirtualisierung verwenden
um dieses Problem zu lösen.

00:01:43.700 --> 00:01:45.050
Aber um es zu tun,

00:01:45.050 --> 00:01:47.030
wir müssen einige Metadaten einrichten.

00:01:47.030 --> 00:01:50.510
Das erste, was wir brauchen, um
ist es, einen Hauptschlüssel zu erstellen,

00:01:50.510 --> 00:01:53.720
und ein Hauptschlüssel ist ein Schlüssel innerhalb

00:01:53.720 --> 00:01:55.910
die Datenbank, die wir zum Schutz verwenden

00:01:55.910 --> 00:01:58.660
alle anderen Metadaten darin.

00:01:58.660 --> 00:02:03.380
Sie können aus den Metadaten sehen
hier, welchen Algorithmus wir verwenden,

00:02:03.380 --> 00:02:06.110
wenn es erstellt wird, und
Interessante Dinge wie diese.

00:02:06.110 --> 00:02:10.745
Jetzt muss ich die PolyBase
um in der Lage zu sein,

00:02:10.745 --> 00:02:16.310
Zugriff auf Remotequellen
und entfernte Datenbanken,

00:02:16.310 --> 00:02:19.220
und erstellen Sie eine Datenbankanmeldeinformationen, um

00:02:19.220 --> 00:02:23.495
in der Lage sein, sich zu authentifizieren
gegen diese entfernten Quellen,

00:02:23.495 --> 00:02:28.835
und Sie können hier sehen, dass ich
in der Vergangenheit ein paar erstellt,

00:02:28.835 --> 00:02:30.200
als ein paar Oracle,

00:02:30.200 --> 00:02:32.225
und ein paar SQL
auch dort.

00:02:32.225 --> 00:02:36.680
Aber heute gehen wir
gegen eine SQL-Datenquelle,

00:02:36.680 --> 00:02:39.650
und Sie können hier sehen, dass
um dies zu tun,

00:02:39.650 --> 00:02:41.730
Ich muss eine
externe Datenquelle.

00:02:41.730 --> 00:02:45.390
Hier spezisiere ich meine
Standort, in diesem Fall,

00:02:45.390 --> 00:02:49.160
eine SQL Server-Adresse
irgendwo in Azure,

00:02:49.160 --> 00:02:51.874
und ich gebe diese Anmeldeinformationen

00:02:51.874 --> 00:02:54.425
, um diese Authentifizierung zu aktivieren
stattfinden.

00:02:54.425 --> 00:02:56.590
Lassen Sie uns also weitermachen und das schaffen,

00:02:56.590 --> 00:03:00.880
und Sie können wieder sehen, gibt es
die Metadaten in der Datenbank.

00:03:00.880 --> 00:03:03.040
Nun gilt in der Regel:

00:03:03.040 --> 00:03:06.290
Ich mag es, die externe
Tabellen, die definieren,

00:03:06.290 --> 00:03:08.465
diese externen Datenquellenobjekte

00:03:08.465 --> 00:03:11.210
getrennt von meinen internen Tabellen,

00:03:11.210 --> 00:03:12.890
und ich tue dies mit einem Schema.

00:03:12.890 --> 00:03:16.500
Lassen Sie uns also vorangehen und
erstellen Sie ein externes Schema,

00:03:17.660 --> 00:03:23.350
und jetzt können wir hierher kommen und
erstellen Sie unsere erste externe Tabelle.

00:03:23.350 --> 00:03:25.730
Die erste externe Tabelle
wir erstellen werden, ist

00:03:25.730 --> 00:03:28.240
Web-Klick-Streams, die
ist die erste Tabelle,

00:03:28.240 --> 00:03:31.315
und in diesem Fall ist es
eher wie eine Faktentabelle,

00:03:31.315 --> 00:03:34.755
und wir werden das speichern.

00:03:34.755 --> 00:03:36.490
In dieser externen Datenbank

00:03:36.490 --> 00:03:38.375
wir haben genau die gleiche Datenbank.

00:03:38.375 --> 00:03:44.200
Wir verwenden es einfach wieder, um
dieses Szenario zu veranschaulichen.

00:03:44.200 --> 00:03:50.515
Jetzt können wir auf den Prozess
der Virtualisierung eines Clickstreams,

00:03:50.515 --> 00:03:52.900
die Tabelle web clickstreams.

00:03:52.900 --> 00:03:56.500
Hier können Sie sehen, ich habe die
gleiche Tabelle Web Clickstreams,

00:03:56.500 --> 00:03:58.660
aber jetzt verwende ich das EXT-Schema.

00:03:58.660 --> 00:04:01.060
Also greife ich auf die externe Tabelle zu,

00:04:01.060 --> 00:04:02.440
sondern in jeder Hinsicht,

00:04:02.440 --> 00:04:05.630
der Rest der Abfrage
ist genau das gleiche.

00:04:05.630 --> 00:04:08.225
Wenn ich diese Abfrage jetzt ausführe,

00:04:08.225 --> 00:04:10.120
nehmen wir an, es braucht eine
etwas länger, weil

00:04:10.120 --> 00:04:12.100
wir werden gehen und
diese Daten aus der Ferne zu erhalten,

00:04:12.100 --> 00:04:14.905
und man könnte sagen, es ist
ca. 3,5 Sekunden.

00:04:14.905 --> 00:04:17.260
Aber wir können sehen, dass wir

00:04:17.260 --> 00:04:20.785
dass Daten hier und
es ist genau das gleiche.

00:04:20.785 --> 00:04:23.710
Also alles unter der Haube

00:04:23.710 --> 00:04:27.065
ist völlig transparent
für mich als Benutzer.

00:04:27.065 --> 00:04:29.920
Nun, was, wenn ich tatsächlich voran gehe und

00:04:29.920 --> 00:04:33.250
Virtualisieren Sie die zweite
externe Tabelle in dieser Abfrage?

00:04:33.250 --> 00:04:35.680
Sie erinnern sich, dass die erste
einer war Web-Clipstreams,

00:04:35.680 --> 00:04:38.905
dass die zweite
ist die Elementtabelle.

00:04:38.905 --> 00:04:41.090
Also lasst uns weitermachen und das tun,

00:04:41.090 --> 00:04:45.650
und jetzt habe ich beides
Tabellen virtualisiert.

00:04:47.290 --> 00:04:52.290
Nun also, was passiert, wenn
Ich führe diese letzte Abfrage aus?

00:04:52.290 --> 00:04:57.565
Diese letzte Abfrage wird
genau die gleiche Abfrage ausführen,

00:04:57.565 --> 00:05:01.670
aber sowohl externe
Tabellen werden virtualisiert,

00:05:01.940 --> 00:05:05.275
und Sie können sehen, dass tatsächlich
Die Abfrage ist fast so

00:05:05.275 --> 00:05:09.375
schnell wie der erste
Version, die lokale Abfrage.

00:05:09.375 --> 00:05:12.530
Warum ist das nun so? Warum bekommen wir
dieser Leistungsunterschied?

00:05:12.530 --> 00:05:14.780
Nun, der Grund ist, dass
dass, wenn Sie sich

00:05:14.780 --> 00:05:17.000
die SQL-Server
intelligent genug mit

00:05:17.000 --> 00:05:20.600
seinen kostenbasierten Optimierer
zu verstehen, dass

00:05:20.600 --> 00:05:24.725
beide Tabellen sind extern und
sie kommen aus derselben Quelle,

00:05:24.725 --> 00:05:28.400
und dass sie sehen kann, dass
es kann diese Verknüpfung schieben und

00:05:28.400 --> 00:05:32.030
die Aggregation nach unten
gegen diese Entferntquelle.

00:05:32.030 --> 00:05:34.190
Wir nutzen also die Berechnung

00:05:34.190 --> 00:05:37.445
diese Remotequelle, um sie aufzulösen
diese Abfrage in Echtzeit.

00:05:37.445 --> 00:05:41.030
Aber das gibt Ihnen einen schnellen Überblick
der Fähigkeiten, die Sie

00:05:41.030 --> 00:05:44.750
Aus der Verwendung von Daten
Virtualisierungstechnologie

00:05:44.750 --> 00:05:48.470
und wie Sie tatsächlich
transparent darstellen, dass Daten

00:05:48.470 --> 00:05:50.390
zurück zu einem Endbenutzer, ohne

00:05:50.390 --> 00:05:52.520
physische Kopien dieser Daten anfertigen,

00:05:52.520 --> 00:05:54.410
ohne es verschieben oder bauen zu müssen

00:05:54.410 --> 00:05:56.420
eine komplexe ETL-Pipeline in

00:05:56.420 --> 00:05:58.910
um in der Lage zu sein,
Abfragedaten in Echtzeit.

00:05:58.910 --> 00:06:00.510
Vielen Dank für ihren Beitritt,

00:06:00.510 --> 00:06:02.960
und ich freue mich darauf,
bald wieder mit Ihnen.

00:06:02.960 --> 00:06:17.560
[MUSIK]