WEBVTT

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

00:00:10.500 --> 00:00:11.910
>> Ahoj a Vítej zpátky.

00:00:11.910 --> 00:00:14.970
Jmenuji se JRJ a jsem zde
abych vám řekl o jednom z

00:00:14.970 --> 00:00:18.915
nejdychtivě očekávané
funkce serveru SQL Server 2019,

00:00:18.915 --> 00:00:21.285
a to je virtualizace dat.

00:00:21.285 --> 00:00:23.175
Co je virtualizace dat,

00:00:23.175 --> 00:00:25.440
a proč se tak dychtivě očekává?

00:00:25.440 --> 00:00:27.510
No, jednoduše řečeno,

00:00:27.510 --> 00:00:29.510
virtualizace dat umožňuje

00:00:29.510 --> 00:00:31.670
přenést všechna data dohromady na

00:00:31.670 --> 00:00:35.780
čas dotazu, nikoli
vytváření složitých kanálů ETL v

00:00:35.780 --> 00:00:40.535
aby bylo možné sjednotit
data v jediném dotazu.

00:00:40.535 --> 00:00:44.150
Tak co budu
je spíše než jít

00:00:44.150 --> 00:00:47.540
prostřednictvím podrobných údajů o údajích
virtualizace v konceptuální úrovni,

00:00:47.540 --> 00:00:49.730
Jen ti ukážu
rozdíly mezi

00:00:49.730 --> 00:00:52.430
místní dotaz a
virtualizovaný dotaz,

00:00:52.430 --> 00:00:55.085
Jak částečně, tak plně virtualizovány.

00:00:55.085 --> 00:00:56.280
Aby to tak bylo,

00:00:56.280 --> 00:00:58.010
Co budeme dělat, je
Přepínám na to

00:00:58.010 --> 00:01:00.270
nyní do Azure Data Studio,

00:01:00.270 --> 00:01:03.035
a můžete zde vidět, že
mít sešit otevřený,

00:01:03.035 --> 00:01:08.990
a Pojďme dovnitř a
začít vyhodnocovat.

00:01:08.990 --> 00:01:13.625
Takže tady vidíte, že jsem
mají velmi jednoduchý dotaz.

00:01:13.625 --> 00:01:17.030
Mám dvě místní
tabulky v databázi,

00:01:17.030 --> 00:01:19.160
a pokud tento dotaz spustím,

00:01:19.160 --> 00:01:23.405
Dokážete si představit výsledek
Vrátí se hezky a rychle.

00:01:23.405 --> 00:01:25.190
Mám asi vteřinu,

00:01:25.190 --> 00:01:28.045
a dostanu svou datovou sadu
zpátky do zápisníku.

00:01:28.045 --> 00:01:31.630
Ale co když to všechno
data nebyla na serveru SQL Server?

00:01:31.630 --> 00:01:36.200
Co kdyby tyto údaje skutečně
k dispozici na vzdálených serverech SQL,

00:01:36.200 --> 00:01:40.145
a my jsme chtěli mít přístup k tomuto
dat najednou?

00:01:40.145 --> 00:01:43.700
Můžete použít virtualizaci dat
vyřešit tento problém.

00:01:43.700 --> 00:01:45.050
Ale za tím účelem,

00:01:45.050 --> 00:01:47.030
je třeba nastavit některá metadata.

00:01:47.030 --> 00:01:50.510
Takže první věc, kterou musíme
udělat je vytvořit hlavní klíč,

00:01:50.510 --> 00:01:53.720
a hlavní klíč je klíč uvnitř

00:01:53.720 --> 00:01:55.910
databázi, kterou používáte k ochraně

00:01:55.910 --> 00:01:58.660
všechna ostatní metadata uvnitř této oblasti.

00:01:58.660 --> 00:02:03.380
Můžete vidět z metadat
, který algoritmus používáte,

00:02:03.380 --> 00:02:06.110
Při vytvoření a
takové zajímavé věci.

00:02:06.110 --> 00:02:10.745
Nyní musím povolit PolyBase
funkce, aby bylo možné

00:02:10.745 --> 00:02:16.310
přístup ke vzdáleným zdrojům
a vzdálených databázích,

00:02:16.310 --> 00:02:19.220
a vytvořit pověření databáze pro

00:02:19.220 --> 00:02:23.495
být schopen ověřovat
proti těmto vzdáleným zdrojům,

00:02:23.495 --> 00:02:28.835
a můžete zde vidět, že jsem
v minulosti několik jich vytvořilo,

00:02:28.835 --> 00:02:30.200
jako dvojice Oracle,

00:02:30.200 --> 00:02:32.225
a několik SQL
i ty tam.

00:02:32.225 --> 00:02:36.680
Ale dneska pojedeme
se zdrojem dat SQL,

00:02:36.680 --> 00:02:39.650
a můžete zde vidět, že
za tím účelem,

00:02:39.650 --> 00:02:41.730
Potřebuji vytvořit
externím zdroji dat.

00:02:41.730 --> 00:02:45.390
Zde upřesním své
místo, v tomto případě

00:02:45.390 --> 00:02:49.160
adresu serveru SQL Server
někde v Azure,

00:02:49.160 --> 00:02:51.874
a předím Toto pověření

00:02:51.874 --> 00:02:54.425
Povolit toto ověřování
.

00:02:54.425 --> 00:02:56.590
Tak pojďme a vytvořte to,

00:02:56.590 --> 00:03:00.880
a uvidíte, že je
metadata uvnitř databáze.

00:03:00.880 --> 00:03:03.040
Nyní, zpravidla,

00:03:03.040 --> 00:03:06.290
Rád bych si udržel vnější
tabulky definující

00:03:06.290 --> 00:03:08.465
těchto externích objektů DataSource

00:03:08.465 --> 00:03:11.210
oddělit od vnitřních tabulek,

00:03:11.210 --> 00:03:12.890
a to dělám pomocí schématu.

00:03:12.890 --> 00:03:16.500
Tak pojďme a
vytvořit externí schéma,

00:03:17.660 --> 00:03:23.350
a teď můžeme přijít sem dolů a
vytvořit první externí tabulku.

00:03:23.350 --> 00:03:25.730
První externí tabulka
vytvoříme

00:03:25.730 --> 00:03:28.240
webové klepnutí na datové proudy, které
je první tabulka,

00:03:28.240 --> 00:03:31.315
a v tomto případě je
více jako tabulka faktů,

00:03:31.315 --> 00:03:34.755
a to si budeme muset uložit.

00:03:34.755 --> 00:03:36.490
V této externí databázi tedy

00:03:36.490 --> 00:03:38.375
Máme přesně stejnou databázi.

00:03:38.375 --> 00:03:44.200
Jen to znovu využíváme, abychom
ilustraci tohoto scénáře.

00:03:44.200 --> 00:03:50.515
Teď se můžeme dostat na proces
virtualizace clickstream,

00:03:50.515 --> 00:03:52.900
tabulky webových stránek clickstreamů.

00:03:52.900 --> 00:03:56.500
Zde můžete vidět, že mám
stejné webové stránky s možností kliknutí na tabulku

00:03:56.500 --> 00:03:58.660
Nyní však používám schéma EXT.

00:03:58.660 --> 00:04:01.060
Takže mám přístup k externímu stolu,

00:04:01.060 --> 00:04:02.440
ale pro všechny záměry a účely,

00:04:02.440 --> 00:04:05.630
zbývající část dotazu
je úplně stejný.

00:04:05.630 --> 00:04:08.225
Pokud tento dotaz spustím nyní,

00:04:08.225 --> 00:04:10.120
Řekněme, že to zabere
ještě trochu déle, protože

00:04:10.120 --> 00:04:12.100
Jedeme a
získat tato data vzdáleně,

00:04:12.100 --> 00:04:14.905
a dalo by se říct, že je to
asi 3,5 sekund.

00:04:14.905 --> 00:04:17.260
Ale vidíme, že máme

00:04:17.260 --> 00:04:20.785
Tato data zde a
je to úplně stejné.

00:04:20.785 --> 00:04:23.710
Takže všechno pod kapucí

00:04:23.710 --> 00:04:27.065
je zcela transparentní
pro mě jako uživatele.

00:04:27.065 --> 00:04:29.920
A co když ve skutečnosti půjdu napřed a

00:04:29.920 --> 00:04:33.250
virtualizovat druhou
externí tabulku v tomto dotazu?

00:04:33.250 --> 00:04:35.680
Pamatujete si, že první
jeden z nich byl webový proud,

00:04:35.680 --> 00:04:38.905
že druhá
je tabulka položek.

00:04:38.905 --> 00:04:41.090
Tak pojďme a udělej to,

00:04:41.090 --> 00:04:45.650
a teď mám oba
virtualizované tabulky.

00:04:47.290 --> 00:04:52.290
A teď, co se stane, když
Ten poslední dotaz?

00:04:52.290 --> 00:04:57.565
Tento poslední dotaz bude
spustit přesně stejný dotaz,

00:04:57.565 --> 00:05:01.670
ale vnější
tabulky jsou virtualizovány,

00:05:01.940 --> 00:05:05.275
a můžete vidět, že skutečně
dotaz je téměř stejný jako

00:05:05.275 --> 00:05:09.375
rychle jako první
verze, místní dotaz.

00:05:09.375 --> 00:05:12.530
A teď proč? Proč se nám
Tento rozdíl v výkonu?

00:05:12.530 --> 00:05:14.780
No, důvod je
že když se podíváte na

00:05:14.780 --> 00:05:17.000
SQL servery
dostatečně inteligentní pomocí

00:05:17.000 --> 00:05:20.600
Optimizér založený na nákladech
pochopit, že

00:05:20.600 --> 00:05:24.725
obě tabulky jsou externí a
pocházejí ze stejného zdroje,

00:05:24.725 --> 00:05:28.400
a že může vidět, že
může toto spojení zmáčknout a

00:05:28.400 --> 00:05:32.030
agregační
proti tomuto vzdálenému zdroji.

00:05:32.030 --> 00:05:34.190
Takže jsme si vypůjčíme výpočet

00:05:34.190 --> 00:05:37.445
Tento vzdálený zdroj pro překlad
Tento dotaz v reálném čase.

00:05:37.445 --> 00:05:41.030
To vám však poskytuje rychlý přehled
o možnostech, které jste

00:05:41.030 --> 00:05:44.750
získat informace z používání dat
technologie virtualizace

00:05:44.750 --> 00:05:48.470
a jak můžete skutečně
transparentně prezentovat tyto údaje

00:05:48.470 --> 00:05:50.390
zpět na koncového uživatele bez nutnosti

00:05:50.390 --> 00:05:52.520
vytvořit fyzické kopie těchto dat,

00:05:52.520 --> 00:05:54.410
bez nutnosti ji přesouvat nebo stavět

00:05:54.410 --> 00:05:56.420
komplexní plynovod ETL v

00:05:56.420 --> 00:05:58.910
aby bylo možné
Dotazovat se na data v reálném čase.

00:05:58.910 --> 00:06:00.510
Díky za spojení,

00:06:00.510 --> 00:06:02.960
a těším se na zachycení
brzy s tebou.

00:06:02.960 --> 00:06:17.560
HUDBY