WEBVTT

00:00:00.000 --> 00:00:03.000
>> SQL Server 2019 velký
Clustery dat poskytují

00:00:03.000 --> 00:00:06.585
spočítat fondy na snižování zátěže
zpracování distribuovaných dotazů.

00:00:06.585 --> 00:00:10.350
Řešení UC nám řekne vše o
dnes v datech vystavených.

00:00:10.350 --> 00:00:21.060
HUDBY

00:00:21.060 --> 00:00:25.215
>> Ahoj. Vítejte v jiné epizodě
Dat vystavených. Já jsem Jeroen.

00:00:25.215 --> 00:00:27.810
Dnes jsem připojen k řešení UC
hovořit o výpočtu

00:00:27.810 --> 00:00:30.690
fondy na serveru SQL Server
2019 velké datové clustery.

00:00:30.690 --> 00:00:33.000
Ahoj, UC. Díky za
znovu připojí k představení.

00:00:33.000 --> 00:00:34.155
>> Jistě.

00:00:34.155 --> 00:00:36.060
>> Vypočítat bazény?

00:00:36.060 --> 00:00:36.615
>> Ano.

00:00:36.615 --> 00:00:37.815
>> Co to je?

00:00:37.815 --> 00:00:40.980
>> Spočítat bazény. Jsou

00:00:40.980 --> 00:00:44.430
instance serveru SQL Server v podstatě
ve velkém datovém clusteru,

00:00:44.430 --> 00:00:48.725
který lze použít k převedení
zpracování distribuovaných dotazů.

00:00:48.725 --> 00:00:50.310
Takže na tomto obrázku

00:00:50.310 --> 00:00:54.870
mnoho komponent vidíme v
Velký datový cluster serveru SQL Server.

00:00:54.870 --> 00:00:58.570
Dnes se podíváme na
Tenhle výpočetní bazén.

00:00:58.570 --> 00:01:01.710
Tak o co jde? Je to
v podstatě soubor

00:01:01.710 --> 00:01:03.825
Instance serveru SQL Server, které jsou

00:01:03.825 --> 00:01:06.685
automaticky brochured
uvnitř velkého datového shluku,

00:01:06.685 --> 00:01:10.475
a jsou k dispozici pro
zpracování distribuovaných dotazů.

00:01:10.475 --> 00:01:11.405
>> Dobře.

00:01:11.405 --> 00:01:14.030
>> Toto je podobné PolyBase

00:01:14.030 --> 00:01:17.585
Skupiny škálování na serveru SQL Server 2016.

00:01:17.585 --> 00:01:21.490
Tato funkce nyní umožňuje

00:01:21.490 --> 00:01:25.174
přednastavený soubor instancí serveru SQL,

00:01:25.174 --> 00:01:27.890
který může provádět většinu
distribuované práce.

00:01:27.890 --> 00:01:28.930
>> Dobře.

00:01:28.930 --> 00:01:32.540
>> Dotazy mohou používat
výpočetního fondu nebo nepoužívat

00:01:32.540 --> 00:01:35.540
výpočetního fondu v závislosti
na typu dotazu.

00:01:35.540 --> 00:01:38.570
>> Jaký scénář bych
vybrat pro výpočetní bazén?

00:01:38.570 --> 00:01:40.720
>> Ano. Skvělé
Otázka. Tak se na to podíváme.

00:01:40.720 --> 00:01:44.270
Jedním z obvyklých scénářů je
Řekněme, že máte dva adresáře v

00:01:44.270 --> 00:01:45.950
HBP se stovkami a tisíci

00:01:45.950 --> 00:01:48.355
soubory a chcete se k nim připojit.

00:01:48.355 --> 00:01:50.000
V tomto scénáři tedy

00:01:50.000 --> 00:01:53.390
nechcete mít všechny
data na server SQL.

00:01:53.390 --> 00:01:53.720
>> Č.

00:01:53.720 --> 00:01:55.760
>> Která používá vaši aplikaci.

00:01:55.760 --> 00:01:57.785
Takže tam
výpočetní fond pomáhá.

00:01:57.785 --> 00:02:02.270
Takže může převzít většinu
práce na hbp

00:02:02.270 --> 00:02:03.680
a později zatáhněte za

00:02:03.680 --> 00:02:07.490
údaje nezbytné k výpočtu
bazén a spoj se tam.

00:02:07.490 --> 00:02:09.920
Takže to je v podstatě všechny vydělá,

00:02:09.920 --> 00:02:13.520
výpočetní svět do různých
Počítače se serverem SQL Server, které lze

00:02:13.520 --> 00:02:17.545
v různých uzlech
velký datový cluster,

00:02:17.545 --> 00:02:19.895
a používat tyto prostředky.

00:02:19.895 --> 00:02:21.590
Další scénáře

00:02:21.590 --> 00:02:23.570
připojujete data z

00:02:23.570 --> 00:02:26.780
různé zdroje dat, které
jsou rozděleny odlišně.

00:02:26.780 --> 00:02:31.760
Takže tam musíte sjednotit ten
rozdělení do oddílů v určité chvíli,

00:02:31.760 --> 00:02:33.530
a tam
výpočetní fond pomáhá.

00:02:33.530 --> 00:02:34.145
>> Dobře.

00:02:34.145 --> 00:02:36.710
>> Takže pokud je jedna tabulka distribuována podle

00:02:36.710 --> 00:02:40.465
ID zákazníka a další je
distribuováno podle ID objednávky,

00:02:40.465 --> 00:02:43.400
a pořád jsi
spojení podle ID zákazníka,

00:02:43.400 --> 00:02:46.590
To může udělat
usmíření.

00:02:46.590 --> 00:02:47.400
>> Dobře.

00:02:47.400 --> 00:02:50.070
>> Tak to jsou některé scénáře.

00:02:50.070 --> 00:02:54.259
Můžete také provádět podobné akce jako
Export dat do HDFS,

00:02:54.259 --> 00:02:56.930
a to je jiné místo
kde může pomoci výpočetní fond.

00:02:56.930 --> 00:02:59.090
>> Dobře. Výpočetní
fond vám pomůže

00:02:59.090 --> 00:03:01.550
paralelizace, měřítko
[neslyšitelný].

00:03:01.550 --> 00:03:02.185
>> Ano.

00:03:02.185 --> 00:03:05.430
>> Čtení z HDFS
a psát do hbp vůbec?

00:03:05.430 --> 00:03:06.030
>> Ano.

00:03:06.030 --> 00:03:07.350
>> Cool. Jak to funguje?

00:03:07.350 --> 00:03:09.300
Chci říct, můžeš nám Ukázat
trochu, jak to funguje?

00:03:09.300 --> 00:03:12.605
>> Ano. Jistý. Pojď sem.

00:03:12.605 --> 00:03:16.885
Vlastně jsem napojit na
Velký datový cluster serveru SQL Server,

00:03:16.885 --> 00:03:19.655
a konkrétně standardní
je zde zobrazena instance.

00:03:19.655 --> 00:03:22.280
Takže teď máme nové DMV,

00:03:22.280 --> 00:03:24.775
který se nazývá výpočetní fondy.

00:03:24.775 --> 00:03:25.545
>> Dobře.

00:03:25.545 --> 00:03:28.610
>> V podstatě ukazuje
výpočetní skupiny, které

00:03:28.610 --> 00:03:31.955
jsou zřízeny a dostupné
ve velkém datovém clusteru.

00:03:31.955 --> 00:03:35.960
Ve výchozím nastavení je pouze jeden a
tu informaci ukážeme.

00:03:35.960 --> 00:03:38.110
Potom můžete také zobrazit

00:03:38.110 --> 00:03:42.465
počet uzlů ve skutečnosti
v tom výpočetním bazénu.

00:03:42.465 --> 00:03:44.740
Tento dotaz skutečně zobrazuje,

00:03:44.740 --> 00:03:47.525
Kromě tohoto konkrétního
Instance serveru SQL Server,

00:03:47.525 --> 00:03:49.100
Mám dva výpočetní

00:03:49.100 --> 00:03:52.730
instance fondu, jak ukazuje
Tyto zvýrazněné řádky, správně?

00:03:52.730 --> 00:03:53.405
>> Ano.

00:03:53.405 --> 00:03:57.815
>> Existují další DMVs, které
můžete v podstatě najít

00:03:57.815 --> 00:04:03.195
informace o výpočtu
fond, jako je aktivita CPU,

00:04:03.195 --> 00:04:05.745
množství přidělené paměti,

00:04:05.745 --> 00:04:09.900
zda je dokonce k dispozici pro
dotaz a tak dál, správně?

00:04:09.900 --> 00:04:10.200
>> Správně.

00:04:10.200 --> 00:04:12.470
>> Tyto informace
které může DBA

00:04:12.470 --> 00:04:15.095
použít k řešení potíží s výpočetním fondem.

00:04:15.095 --> 00:04:16.145
>> Jistě.

00:04:16.145 --> 00:04:20.480
>> Můžete také
spuštění složitého dotazu v

00:04:20.480 --> 00:04:25.955
SQL Server, který může skutečně
jít a použít výpočetní bazén.

00:04:25.955 --> 00:04:26.270
>> Dobře.

00:04:26.270 --> 00:04:27.565
>> Takže v tomto příkladu

00:04:27.565 --> 00:04:32.869
Připojuji se k místní tabulce v jazyce SQL
Server s některými daty v HDFS,

00:04:32.869 --> 00:04:37.070
a také mám tabulku v
Orákulum, na které se dotazuji.

00:04:37.070 --> 00:04:40.265
Takže můžete v podstatě spustit dotaz a

00:04:40.265 --> 00:04:42.290
optimalizační dotaz
Automatické obrázky

00:04:42.290 --> 00:04:44.570
způsob použití výpočetního bazénu.

00:04:44.570 --> 00:04:47.630
V tomto případě bude
použít fond počítačů pro

00:04:47.630 --> 00:04:50.930
tabulky hbp a

00:04:50.930 --> 00:04:54.490
zbývající data jsou
všechny spojeny a vráceny.

00:04:54.490 --> 00:04:57.030
To je příklad
kde výpočetní fond

00:04:57.030 --> 00:05:00.060
transparentně pracuje na
získat výsledky.

00:05:00.060 --> 00:05:01.755
>> Cool. To vypadá opravdu dobře.

00:05:01.755 --> 00:05:04.220
V podstatě mohu napsat tento dotaz.

00:05:04.220 --> 00:05:07.040
Nyní mohu důvěřovat
výpočetní fond provede krok

00:05:07.040 --> 00:05:10.010
v místě, kde je rozumné
optimalizovat výkon, správně?

00:05:10.010 --> 00:05:10.535
>> Ano.

00:05:10.535 --> 00:05:13.115
>> Super. No, díky
hodně pro sdílení.

00:05:13.115 --> 00:05:14.015
>> Jistě.

00:05:14.015 --> 00:05:15.500
>> Doufám, že to bylo užitečné.

00:05:15.500 --> 00:05:20.150
Přihlaste se jako
na video a komentář.

00:05:20.150 --> 00:05:22.340
Doufám, že se příště uvidíme.
Dík za sledování.

00:05:22.340 --> 00:05:36.910
HUDBY