WEBVTT

00:00:00.000 --> 00:00:10.530
[音樂]。

00:00:10.530 --> 00:00:13.170
嘿，大家好。歡迎光臨
這一幕資料暴露。

00:00:13.170 --> 00:00:15.240
我是特拉維斯·賴特集團
產品經理

00:00:15.240 --> 00:00:18.435
SQL 伺服器和 Azure 資料
微軟的工程團隊。

00:00:18.435 --> 00:00:22.335
今天我興奮地介紹
給你一個SQL伺服器2019年，

00:00:22.335 --> 00:00:24.945
最新發佈的 SQL 伺服器。

00:00:24.945 --> 00:00:28.515
SQL Server 正在慶祝其
今年25周年。

00:00:28.515 --> 00:00:31.830
已經相當長一段時間了。回首往會
在我職業生涯的早期

00:00:31.830 --> 00:00:34.230
我開始在 SQL Server 2000。

00:00:34.230 --> 00:00:36.300
在這25年的歷史中

00:00:36.300 --> 00:00:38.490
SQL Server 確實
來很長的路。

00:00:38.490 --> 00:00:40.050
它真的擴展了以滿足

00:00:40.050 --> 00:00:42.030
我們的需要
客戶隨時間而成為

00:00:42.030 --> 00:00:44.390
不同類型的資料
客戶需要

00:00:44.390 --> 00:00:47.060
收集和處理
和查詢已更改，

00:00:47.060 --> 00:00:49.310
和有更多的
和不同類型的

00:00:49.310 --> 00:00:51.965
資料庫引擎要求
已經來了。

00:00:51.965 --> 00:00:54.470
因此，讓我們回去旅行
下記憶體通道

00:00:54.470 --> 00:00:57.515
片刻，只是看看在哪裡
SQL 伺服器來自，

00:00:57.515 --> 00:00:59.390
然後我們再看一看
在 SQL Server 所在的位置

00:00:59.390 --> 00:01:02.515
接下來是 SQL Server 2019。

00:01:02.515 --> 00:01:05.350
讓我們從 SQL Server 2008 開始。

00:01:05.350 --> 00:01:07.295
SQL Server 2008 實際上是

00:01:07.295 --> 00:01:09.995
擴展支援
就在今年

00:01:09.995 --> 00:01:14.390
如果你快進一點看
在 SQL Server 2012 和 2014

00:01:14.390 --> 00:01:17.870
我們真的做了一些很大的改進
在性能和

00:01:17.870 --> 00:01:19.880
高可用性
介紹總是

00:01:19.880 --> 00:01:22.565
可用性組
對於高可用性，

00:01:22.565 --> 00:01:24.500
並在記憶體功能，以真正

00:01:24.500 --> 00:01:26.845
提升性能
資料庫。

00:01:26.845 --> 00:01:29.630
在 SQL Server 2016 和 2017 中

00:01:29.630 --> 00:01:31.295
我們真的改變了遊戲很多

00:01:31.295 --> 00:01:33.320
通過介紹一些
新功能

00:01:33.320 --> 00:01:37.885
要存儲和查詢的 SQL 伺服器
JSON 和圖形，

00:01:37.885 --> 00:01:41.210
我們也做了一些事情
非常令人驚訝，帶來

00:01:41.210 --> 00:01:45.580
SQL 伺服器到 Linux 和
SQL Server 2017 中的容器。

00:01:45.580 --> 00:01:47.895
在 SQL Server 2019 中，

00:01:47.895 --> 00:01:49.540
我們又改變了遊戲規則

00:01:49.540 --> 00:01:50.840
真正擴大和

00:01:50.840 --> 00:01:53.480
重新定義定義
什麼是 SQL Server。

00:01:53.480 --> 00:01:55.490
當然，SQL 伺服器仍然是

00:01:55.490 --> 00:01:58.220
關係資料庫
那是25年前的事了

00:01:58.220 --> 00:02:00.770
您仍然可以存儲
SQL Server 中的資料

00:02:00.770 --> 00:02:03.335
並在同一
的方式，你總是有。

00:02:03.335 --> 00:02:06.560
但與此同時，我們
重新定義 SQL 伺服器和

00:02:06.560 --> 00:02:09.920
擴展它遠遠超出只是
關係資料庫空間。

00:02:09.920 --> 00:02:14.135
因此，讓我們來看看什麼
我們在 SQL Server 2019 中所做的。

00:02:14.135 --> 00:02:17.045
在 SQL Server 2019 中，

00:02:17.045 --> 00:02:18.380
我們給你存取權限

00:02:18.380 --> 00:02:20.420
查詢和處理資料

00:02:20.420 --> 00:02:23.990
在邊界之外
傳統的 SQL Server 實例。

00:02:23.990 --> 00:02:26.840
通過採用 PolyBase 功能，我們首先

00:02:26.840 --> 00:02:30.445
在 SQL 伺服器中引入
2016 年到下一個水準。

00:02:30.445 --> 00:02:34.280
PolyBase 允許您創建
跨資料虛擬化層

00:02:34.280 --> 00:02:36.170
多個不同
資料來源，如

00:02:36.170 --> 00:02:38.810
Oracle 其他 SQL 伺服器實例。

00:02:38.810 --> 00:02:42.460
泰拉資料，MongoDB 和更多。

00:02:42.460 --> 00:02:46.460
我們還採取了 HDFS 和
火花，並建立在盒子裡。

00:02:46.460 --> 00:02:48.230
所以現在使用 SQL Server，

00:02:48.230 --> 00:02:52.370
您可以處理和存儲
資料 PB 刻度和

00:02:52.370 --> 00:02:57.650
處理和存儲資料
甚至是非結構化資料。

00:02:57.650 --> 00:03:01.520
您可以將 SQL Server 與
幾乎任何程式設計語言。

00:03:01.520 --> 00:03:04.310
你可以運行它漂亮的
現在很多平臺。

00:03:04.310 --> 00:03:06.155
使用 SQL Server 2019，

00:03:06.155 --> 00:03:08.000
當然，你可以在 Windows 上運行它。

00:03:08.000 --> 00:03:11.345
您也可以在
紅帽上的Linux，蘇薩，

00:03:11.345 --> 00:03:13.670
或Ubuntu，你可以運行
它在一個容器裡，

00:03:13.670 --> 00:03:15.320
你可以在庫伯內特斯上運行它。

00:03:15.320 --> 00:03:18.875
您可以在其他
處理器架構。

00:03:18.875 --> 00:03:20.630
使用 Azure SQL 資料庫邊緣，

00:03:20.630 --> 00:03:24.640
你可以在手臂上運行它64
像樹莓派一樣的設備，

00:03:24.640 --> 00:03:27.680
你可以運行它在
雲和 Azure SQL 資料庫，

00:03:27.680 --> 00:03:29.030
或者您可以在本地運行它，

00:03:29.030 --> 00:03:31.115
或者你可以運行它，
其他公共雲。

00:03:31.115 --> 00:03:32.720
那裡有很多的多功能性。

00:03:32.720 --> 00:03:36.130
您可以使用 SQL Server
它最適合你。

00:03:36.130 --> 00:03:39.290
SQL Server 2019 繼續

00:03:39.290 --> 00:03:42.190
擴展我們的行業領先
性能。

00:03:42.190 --> 00:03:45.710
SQL 伺服器已建立自身
多年來現在作為數位

00:03:45.710 --> 00:03:49.490
1 在 OLTP 性能方面
與TPC-H基準，

00:03:49.490 --> 00:03:50.990
並作為數位1在

00:03:50.990 --> 00:03:54.050
資料倉儲性能
與TPC-H基準。

00:03:54.050 --> 00:03:56.090
我們還引領了整個行業，

00:03:56.090 --> 00:03:58.670
最少數量
漏洞報告出任何

00:03:58.670 --> 00:04:01.910
主要資料庫引擎
在過去的八年裡

00:04:01.910 --> 00:04:06.010
根據國家研究所
標準和技術。

00:04:06.010 --> 00:04:08.330
因此，讓我們走近一點
看看只是一些

00:04:08.330 --> 00:04:11.075
SQL Server 2019 的亮點。

00:04:11.075 --> 00:04:12.770
讓我們從一些開始
改進，我們

00:04:12.770 --> 00:04:15.005
在性能空間。

00:04:15.005 --> 00:04:17.600
因此，首先，持久記憶體作為

00:04:17.600 --> 00:04:20.585
一項新技術
進入硬體市場。

00:04:20.585 --> 00:04:22.730
我們利用了
持久記憶

00:04:22.730 --> 00:04:24.785
真正提高性能。

00:04:24.785 --> 00:04:27.230
你不必做任何
對應用程式的更改，

00:04:27.230 --> 00:04:28.430
您可以存儲您的資料和

00:04:28.430 --> 00:04:31.330
持久記憶體
更快的性能。

00:04:31.330 --> 00:04:34.030
其次，對於智慧
查詢處理，

00:04:34.030 --> 00:04:36.440
我們真的擴展了
此處的系列功能

00:04:36.440 --> 00:04:38.990
正如你可以看到，在這
圖表包括手數

00:04:38.990 --> 00:04:41.615
新的方式，其中
查詢最佳化工具可以

00:04:41.615 --> 00:04:45.679
隨著時間的推移學習基於
執行查詢的去向，

00:04:45.679 --> 00:04:48.935
這些未來的執行
查詢可以改進，

00:04:48.935 --> 00:04:51.560
提高性能
您的應用程式

00:04:51.560 --> 00:04:55.225
時間，而你不必改變
您的應用程式的任何內容，

00:04:55.225 --> 00:04:57.980
最後，我們把TempDB

00:04:57.980 --> 00:05:01.415
記憶體更快
臨時資料庫的性能。

00:05:01.415 --> 00:05:03.650
接下來，讓我們來看看
一些改進，我們

00:05:03.650 --> 00:05:05.690
安全和合規性。

00:05:05.690 --> 00:05:08.330
首先，特別是GDPR，

00:05:08.330 --> 00:05:09.905
客戶面臨的

00:05:09.905 --> 00:05:13.220
更多的監管要求
他們必須見面。

00:05:13.220 --> 00:05:14.720
為了更容易，

00:05:14.720 --> 00:05:18.230
我們提供資料分類
功能開箱即用。

00:05:18.230 --> 00:05:21.850
您可以指向資料分類
引擎在您的資料庫，

00:05:21.850 --> 00:05:23.555
它會自動探索

00:05:23.555 --> 00:05:25.130
不同類型的
您擁有的資料

00:05:25.130 --> 00:05:29.425
您的資料庫，如
PCI 資料或 GDPR 資料，

00:05:29.425 --> 00:05:31.790
並自動
分類，並產生

00:05:31.790 --> 00:05:34.670
報告，你喜歡你看到
在此螢幕截圖中，

00:05:34.670 --> 00:05:37.625
你可以定義你自己的
分類規則。

00:05:37.625 --> 00:05:39.470
接下來在安全性方面，

00:05:39.470 --> 00:05:43.340
我們已經改進了始終加密
我們的用戶端加密

00:05:43.340 --> 00:05:44.645
技術，允許您

00:05:44.645 --> 00:05:47.630
分離加密
從資料庫中。

00:05:47.630 --> 00:05:50.270
這樣，
資料庫管理員

00:05:50.270 --> 00:05:53.120
無法解密
允許

00:05:53.120 --> 00:05:55.640
你在這裡分開的職責之間

00:05:55.640 --> 00:05:56.840
資料庫管理員和

00:05:56.840 --> 00:05:59.425
應用程式開發人員和使用者，

00:05:59.425 --> 00:06:01.910
最後，只是作為一個例子，在這裡

00:06:01.910 --> 00:06:03.950
改進，我們
使，因為我們也有

00:06:03.950 --> 00:06:06.230
添加了執行加密

00:06:06.230 --> 00:06:09.480
飛地內所有資料。

00:06:10.160 --> 00:06:15.050
現在，在開發人員的空間
和 DBA 工具，希望，

00:06:15.050 --> 00:06:16.670
你們都已經瞭解並嘗試

00:06:16.670 --> 00:06:19.595
Azure 資料工作室
新的跨平臺

00:06:19.595 --> 00:06:22.550
適用于所有類型的開源工具

00:06:22.550 --> 00:06:25.190
資料的人，無論你是
資料庫管理員，

00:06:25.190 --> 00:06:28.415
資料庫工程師
或資料科學家。

00:06:28.415 --> 00:06:33.350
此工具可供您使用
免費下載和使用，

00:06:33.350 --> 00:06:35.225
它被設計為

00:06:35.225 --> 00:06:39.200
多資料庫引擎，以便您可以
不僅將其用於 SQL 伺服器，

00:06:39.200 --> 00:06:41.510
也使用 SQL 伺服器

00:06:41.510 --> 00:06:44.060
雲，如
Azure SQL 資料庫或

00:06:44.060 --> 00:06:46.460
使用 Azure SQL 資料
倉庫也與

00:06:46.460 --> 00:06:49.370
其他資料庫引擎
像PostgreSQL和MySQL。

00:06:49.370 --> 00:06:52.460
改進之一，
人們最興奮

00:06:52.460 --> 00:06:55.340
和 Azure 資料工作室是
筆記本體驗。

00:06:55.340 --> 00:06:58.550
筆記本允許您創建
包含標記的檔

00:06:58.550 --> 00:07:01.670
和代碼儲存格一樣。

00:07:01.670 --> 00:07:03.380
在降價中，您可以描述

00:07:03.380 --> 00:07:06.470
一些分析，你正在做或
應執行的步驟，

00:07:06.470 --> 00:07:08.240
然後在代碼儲存格中

00:07:08.240 --> 00:07:10.640
混合
那些標記細胞，

00:07:10.640 --> 00:07:13.705
你可以有一些代碼，你
或其他人可以執行。

00:07:13.705 --> 00:07:17.250
我們有筆記本
TSQL，對於電源外殼，

00:07:17.250 --> 00:07:20.240
Python，而您

00:07:20.240 --> 00:07:23.075
可以在本地運行
或者你可以在Spark中運行它。

00:07:23.075 --> 00:07:25.910
非常強大
以協作方式

00:07:25.910 --> 00:07:29.915
其他人通過捕獲這
資訊和筆記本，

00:07:29.915 --> 00:07:32.180
和這些筆記本
可用於捕獲

00:07:32.180 --> 00:07:35.450
樣品或一些標準
操作程式或

00:07:35.450 --> 00:07:38.180
故障排除指南和共用
那些與其他人通過

00:07:38.180 --> 00:07:42.085
我們有的 Git 集成
內置到 Azure 資料工作室，

00:07:42.085 --> 00:07:43.685
最後，我們集成了

00:07:43.685 --> 00:07:45.650
一些很酷的技術從

00:07:45.650 --> 00:07:48.290
微軟研究稱為
允許的沙舞

00:07:48.290 --> 00:07:51.725
你做臨時資料
視覺化和探索

00:07:51.725 --> 00:07:54.020
使用一些很酷
圖表功能

00:07:54.020 --> 00:07:55.975
就在那裡裡面
Azure 資料工作室。

00:07:55.975 --> 00:07:59.585
因此，一定要抓取 Azure 資料
工作室，如果你還沒有。

00:07:59.585 --> 00:08:01.280
這是一個超級強大的工具，

00:08:01.280 --> 00:08:03.950
創新即將到來
有每月的基礎上，因為我們

00:08:03.950 --> 00:08:07.640
每月發佈
用於 Azure 資料工作室。

00:08:07.640 --> 00:08:11.270
因此，我們繼續雙倍

00:08:11.270 --> 00:08:14.180
我們的新方法

00:08:14.180 --> 00:08:16.820
我們如何看待不同
SQL 伺服器的平臺。

00:08:16.820 --> 00:08:18.500
在 SQL Server 2017 中，

00:08:18.500 --> 00:08:20.465
我們引入了對 Linux 的支援。

00:08:20.465 --> 00:08:22.100
但 SQL Server 2019

00:08:22.100 --> 00:08:24.470
我們採取，
下一步，通過創建

00:08:24.470 --> 00:08:27.620
更大的功能模仿
在 Windows 上的 SQL 伺服器之間，

00:08:27.620 --> 00:08:31.875
和 LINUX 上的 SQL 伺服器，通過帶來
PolyBase 和所有服務，

00:08:31.875 --> 00:08:35.680
分散式交易協調員
和複製到Linux，

00:08:35.680 --> 00:08:37.160
和幾乎檢查關閉

00:08:37.160 --> 00:08:39.515
所有框
資料庫引擎功能。

00:08:39.515 --> 00:08:42.200
所以你有近100
相容性百分比

00:08:42.200 --> 00:08:45.695
在 Windows 上的 SQL 伺服器之間
和 Linux 上的 SQL 伺服器。

00:08:45.695 --> 00:08:47.450
與紅帽合作

00:08:47.450 --> 00:08:49.880
我們還創建了rel
基於容器映射

00:08:49.880 --> 00:08:52.585
可在
微軟容器註冊表，

00:08:52.585 --> 00:08:54.170
你可以發現他們

00:08:54.170 --> 00:08:56.675
紅帽集裝箱
目錄。

00:08:56.675 --> 00:08:58.730
最後在預覽現在，

00:08:58.730 --> 00:09:02.080
我們有支援永遠上
庫貝內特斯的可用性組，

00:09:02.080 --> 00:09:04.610
這樣，您才能得到
總是在

00:09:04.610 --> 00:09:07.415
可用性組
用於橫向擴展讀取

00:09:07.415 --> 00:09:09.350
或高可用性

00:09:09.350 --> 00:09:13.760
生活在那裡的頂部
庫伯內特斯層下面。

00:09:13.970 --> 00:09:17.270
最後，可能
最重要的區域

00:09:17.270 --> 00:09:19.040
改進和公正

00:09:19.040 --> 00:09:21.290
攤開帳篷
的 SQL 伺服器，如果您

00:09:21.290 --> 00:09:24.215
將處理新的
方案類型，

00:09:24.215 --> 00:09:26.540
是改進，
我們在保利基地製作

00:09:26.540 --> 00:09:28.850
和資料虛擬化，因為我
在開頭提到，

00:09:28.850 --> 00:09:30.140
我們可以在那裡創建

00:09:30.140 --> 00:09:31.760
跨資料虛擬化層

00:09:31.760 --> 00:09:33.890
許多不同的資料
像甲骨文這樣的來源，

00:09:33.890 --> 00:09:37.755
其他 SQL 伺服器
實例和 Teradata。

00:09:37.755 --> 00:09:40.100
這使我們能夠帶來
資料在一起

00:09:40.100 --> 00:09:42.800
查詢時有多個資料來源，

00:09:42.800 --> 00:09:44.840
並真正最小化
使用

00:09:44.840 --> 00:09:47.420
ETL 作為集成方式
我們的資料在一起。

00:09:47.420 --> 00:09:50.705
沒有人喜歡建築和
維護 ETL 管道。

00:09:50.705 --> 00:09:54.200
所以我們想給你另一個
選項，您可以在

00:09:54.200 --> 00:09:58.385
除了 ETL，說明您
將資料整合在一起。

00:09:58.385 --> 00:10:00.545
在 SQL Server 2019 中，

00:10:00.545 --> 00:10:03.110
我們推出了一個新的
模式，我們如何部署

00:10:03.110 --> 00:10:07.970
SQL Server 通過引入新的
稱為大資料群集的模式，

00:10:07.970 --> 00:10:09.650
和大資料群集允許您

00:10:09.650 --> 00:10:12.440
部署 SQL 伺服器
實例與所有

00:10:12.440 --> 00:10:16.400
其典型功能
以及 HDFS 和

00:10:16.400 --> 00:10:20.825
一個集成解決方案中的火花
部署在庫伯內特斯，

00:10:20.825 --> 00:10:22.610
這為您提供了採取

00:10:22.610 --> 00:10:24.820
SQL 伺服器，並做所有的事情
執行 SQL 伺服器，

00:10:24.820 --> 00:10:26.750
但然後很容易集成

00:10:26.750 --> 00:10:29.120
與 HDFS 和
火花，所以你可以做

00:10:29.120 --> 00:10:32.600
高容量查詢
可擴展的資料

00:10:32.600 --> 00:10:34.400
出比你大1000倍

00:10:34.400 --> 00:10:37.070
可能存儲
和 SQL Server 今天，

00:10:37.070 --> 00:10:39.500
到幾十個甚至
數百 PB 的

00:10:39.500 --> 00:10:42.260
資料以及
能夠存儲和

00:10:42.260 --> 00:10:44.540
查詢和流程
非結構化資料，如

00:10:44.540 --> 00:10:48.174
HDFS 中的視頻檔或音訊檔，

00:10:48.174 --> 00:10:50.900
你有好處
擁有火花引擎

00:10:50.900 --> 00:10:53.260
那裡為數據準備
活動或做

00:10:53.260 --> 00:10:55.310
機器學習模型培訓或

00:10:55.310 --> 00:10:58.525
操作
火花內的模型。

00:10:58.525 --> 00:11:00.815
因此，由微軟提供

00:11:00.815 --> 00:11:02.660
集成的解決方案和支援

00:11:02.660 --> 00:11:05.420
一個集成的解決方案
和大資料集群，

00:11:05.420 --> 00:11:08.810
你得到一個共用的可擴展
資料湖建立

00:11:08.810 --> 00:11:12.545
任一 SQL 伺服器的 HDF
或火花可以訪問。

00:11:12.545 --> 00:11:15.500
這真的為您提供
完整的 AI 平臺

00:11:15.500 --> 00:11:17.420
做一切
從攝取

00:11:17.420 --> 00:11:22.070
通過存儲資料
在 HDFS 或 SQL 伺服器中，

00:11:22.070 --> 00:11:23.900
然後執行資料準備任務

00:11:23.900 --> 00:11:26.250
使用 Spark 或 SQL 伺服器，

00:11:26.250 --> 00:11:28.995
然後做機器
使用學習模型培訓

00:11:28.995 --> 00:11:31.185
要麼內置機器
學習庫

00:11:31.185 --> 00:11:34.380
火花或使用

00:11:34.380 --> 00:11:35.900
機器學習
內置於

00:11:35.900 --> 00:11:38.600
SQL 伺服器主實例
然後你就可以操作

00:11:38.600 --> 00:11:41.030
那些要麼在火花運行時

00:11:41.030 --> 00:11:43.520
通過做批次處理機器
學習評分，

00:11:43.520 --> 00:11:45.500
或者你可以在裡面做
預存程序

00:11:45.500 --> 00:11:47.090
例如，在 SQL Server 中，

00:11:47.090 --> 00:11:49.640
或者我們有辦法讓你
可以實際採取一個模型和

00:11:49.640 --> 00:11:53.180
自動包裝
在休息的 API 容器中，

00:11:53.180 --> 00:11:54.980
並規定
容器頂部

00:11:54.980 --> 00:11:56.600
大資料群集，以便

00:11:56.600 --> 00:11:58.220
易於應用
開發人員

00:11:58.220 --> 00:12:01.160
調用並使用
容器作為一種方式

00:12:01.160 --> 00:12:04.745
提交一些已評分的資料習慣
並獲取分數值。

00:12:04.745 --> 00:12:07.940
因此，它使一個真正的
完成 AI 平臺結束到

00:12:07.940 --> 00:12:09.500
結束能夠做
一切你需要

00:12:09.500 --> 00:12:11.770
圍繞 AI 和機器學習進行操作。

00:12:11.770 --> 00:12:14.615
所以希望，這給了
你快速介紹

00:12:14.615 --> 00:12:18.085
到 SQL Server 2019。

00:12:18.085 --> 00:12:22.085
這真的只是一個
視頻在一系列視頻

00:12:22.085 --> 00:12:24.080
在 SQL 2019 通道上

00:12:24.080 --> 00:12:26.465
你看到連結在這裡
螢幕底部，

00:12:26.465 --> 00:12:27.860
我們真的希望

00:12:27.860 --> 00:12:29.840
你有機會去
通過所有這些視頻。

00:12:29.840 --> 00:12:31.220
我們希望發佈也許周圍

00:12:31.220 --> 00:12:33.290
一百個視頻，進入很多

00:12:33.290 --> 00:12:37.730
關於一切的細節
這是 SQL Server 2019 中的新增功能。

00:12:37.730 --> 00:12:39.095
如果您有任何回饋，

00:12:39.095 --> 00:12:40.700
請張貼在
以下評論

00:12:40.700 --> 00:12:42.830
並訂閱該頻道。

00:12:42.830 --> 00:12:44.990
所以，謝謝你今天加入我們

00:12:44.990 --> 00:12:47.375
瞭解有關 SQL Server 2019 的更多資訊，

00:12:47.375 --> 00:12:49.220
我們會看到你出去
在下一個事件

00:12:49.220 --> 00:12:50.720
或 SQL 星期六。謝謝。

00:12:50.720 --> 00:13:05.290
[音樂]