共計 4229 個字符，預(yù)計需要花費 11 分鐘才能閱讀完成。
這篇文章主要講解了“MySQL 重大新增的功能有哪些”，文中的講解內(nèi)容簡單清晰，易于學(xué)習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學(xué)習“MySQL 重大新增的功能有哪些”吧！
一、MySQL 的天然短板“數(shù)據(jù)分析”
MySQL，作為最為流行的一款開源數(shù)據(jù)庫，已經(jīng)得到非常廣泛地使用。從最新的 db-engines 指數(shù)可以看出，其在數(shù)據(jù)庫領(lǐng)域中占據(jù)了重要的位置。
但作為一款如此流行的數(shù)據(jù)庫產(chǎn)品，其存在一個明顯的短板就是數(shù)據(jù)分析。相信 MySQL 使用者都有這種感覺，在大規(guī)模數(shù)據(jù)情況下 MySQL 有些力不從心。盡管其內(nèi)核也在不斷加強這方面的能力（如最新 8.0 支持 hash join、直方圖等），但相較于其他數(shù)據(jù)庫仍然存在一定劣勢。其核心在于 MySQL 原生是為 OLTP 場景設(shè)計的，并沒有考慮 OLAP 場景。
雖然也有一些廠商通過擴展其存儲引擎，增強其數(shù)據(jù)分析能力，但總體來講還是不盡如人意。于是，通常的一種選擇就是在數(shù)據(jù)分析時，不得不將數(shù)據(jù)遷移到另一種數(shù)據(jù)庫 / 大數(shù)據(jù)架構(gòu)中。通過后者，去完成數(shù)據(jù)分析工作。在這一過程中，需要開發(fā)者自己定義 ETL 邏輯（可能基于日志解析或邏輯數(shù)據(jù)抽取），完成數(shù)據(jù)遷移。同時，在運行中需時刻關(guān)注數(shù)據(jù)同步，保證數(shù)據(jù)有效性。在使用上，還需編寫單獨的語句（異構(gòu)數(shù)據(jù)源的語句），來完成數(shù)據(jù)分析動作。
整個這一過程，無疑對用戶來說具有一定的使用門檻，且需要花費額外的精力去解決這一問題。相信 Oracle 原廠也是看到這一問題，因而推出了 MySQL Analytics Engine。
二、MAE 到底是個啥？
MySQL Analytics Engine（簡稱 MAE），籠統(tǒng)來說是一款內(nèi)置的分析引擎。通過它與 MySQL Database 的組合，可以使得數(shù)據(jù)庫管理員和應(yīng)用程序開發(fā)人員能夠直接將 MySQL 數(shù)據(jù)庫作為 OLTP 和 OLAP 工作負載的統(tǒng)一服務(wù)。其提供的“MySQL Database Service with Analytics Engine”，是由一個 MySQL DB 實例和多個分析節(jié)點組成。當分析功能被啟用時，分析服務(wù)將被安裝在 DB 實例上，其負責集群管理、數(shù)據(jù)加載、查詢執(zhí)行等。從用戶角度來看，可以通過標準的 MySQL JDBC/ODBC Connector 來連接使用。下面我們詳細展開看看。
首先從整體使用來看，對外提供統(tǒng)一的 MySQL Database Service。用戶仍然是通過傳統(tǒng)的方式去使用它，無論是 OLTP 還是 OLAP 場景。在這個服務(wù)的內(nèi)部，是包括了傳統(tǒng)的 OLTP 引擎和新的 Analytics 引擎。在數(shù)據(jù)上，也是存在兩份。前者仍然保存在例如 InnoDB 這樣的存儲引擎之中，后者則保存在一組節(jié)點構(gòu)成集群的內(nèi)存之中。正常事務(wù)操作帶來的數(shù)據(jù)變化，會透明地傳播到后面的分析集群中，以加速分析處理。這樣就使得客戶可以在單個數(shù)據(jù)庫平臺上同時運行 OLTP 和 OLAP 工作負載。簡言之，就是兩個計算引擎、兩份數(shù)據(jù)存儲。
MAE 的核心工作思想就是“化大為小”，通過分區(qū)機制，將數(shù)據(jù)打散后利用獨立的 CPU 資源進行處理。處理后的結(jié)果統(tǒng)一返回。
在 MAE 內(nèi)部，由多個分析節(jié)點組成。其具體節(jié)點數(shù)量，可由 MySQL 分析引擎提供的自動配置顧問自動獲得。在節(jié)點中，數(shù)據(jù)以一種混合列壓縮的格式存儲。這有助于向量化處理，從而獲得非常好的查詢性能。數(shù)據(jù)在內(nèi)存中運行之前被編碼和壓縮。這種壓縮和優(yōu)化的內(nèi)存使用，對于數(shù)值和字符串數(shù)據(jù)尤為顯著，可提高性能并減少內(nèi)存占用，從而為客戶降低成本。同時在每個節(jié)點中使用并行操作技術(shù)，這為分析提供了高緩存命中率，并提供良好的節(jié)點間可伸縮性。集群內(nèi)的每個分析節(jié)點和節(jié)點內(nèi)的每個核心都可以并行處理分區(qū)數(shù)據(jù)，包括并行掃描、連接、分組、聚合和 top- k 處理。
MySQL 分析引擎為分布式內(nèi)存分析處理實現(xiàn)了最新的算法。通過使用向量化的構(gòu)建和探測連接內(nèi)核，可以快速處理分區(qū)內(nèi)的連接。通過使用異步批處理 I /O，優(yōu)化了分析節(jié)點之間的網(wǎng)絡(luò)通信。算法的設(shè)計是為了使計算時間與跨節(jié)點的數(shù)據(jù)通信重疊，這有助于實現(xiàn)良好的可伸縮性。
MySQL 分析引擎與 MySQL 數(shù)據(jù)庫服務(wù)的集成為企業(yè)的所有 OLTP 和分析需求提供了一個單一的數(shù)據(jù)管理平臺。MySQL 分析引擎被設(shè)計成一個 MySQL 可插拔存儲引擎，它完全屏蔽了存儲層的所有底層實現(xiàn)細節(jié)，不讓最終用戶看到。用戶和應(yīng)用程序通過集群中的 MySQL 數(shù)據(jù)庫節(jié)點與 MySQL 分析交互。用戶通過標準工具和基于標準的 ODBC/JDBC 連接器連接到 MySQL 分析引擎。
MySQL 分析引擎支持與 MySQL 相同的 ANSI SQL 標準和 ACID 屬性，并支持不同的數(shù)據(jù)類型。這使得現(xiàn)有的應(yīng)用程序無需對其應(yīng)用程序進行任何更改就可以利用 MySQL 分析引擎，從而實現(xiàn)簡單快速的集成。一旦用戶向 MySQL 數(shù)據(jù)庫提交查詢，MySQL 查詢優(yōu)化器就會透明地決定是否將查詢卸載到分析集群以加速執(zhí)行。這是基于 MySQL 分析引擎是否支持查詢中引用的所有操作符和函數(shù)并且使用分析引擎處理查詢的估計時間比在 MySQL 中更少時，查詢將被下推到分析節(jié)點進行處理。處理之后，結(jié)果被發(fā)送回 MySQL 數(shù)據(jù)庫節(jié)點并返回給用戶。
由于 MySQL 分析引擎是一個內(nèi)存處理引擎，數(shù)據(jù)被持久化到 MySQL InnoDB 存儲引擎中。對表的任何更新都會自動實時地傳播到分析節(jié)點的內(nèi)存中。這使得后續(xù)查詢始終能夠訪問最新的數(shù)據(jù)。這是通過一個輕量級的更改傳播算法在后臺完成的，該算法可以跟上 MySQL 的數(shù)據(jù)更新率。同步原理未說明？
三、MAE 能為我們帶來什么？
從產(chǎn)品角度來看，MySQL Analytics Engine 是一種云原生服務(wù)，專門在 Oracle 云基礎(chǔ)設(shè)施中提供，為分析工作負載提供了令人信服的性能和成本。使用 MySQL 數(shù)據(jù)庫管理企業(yè)數(shù)據(jù)的組織現(xiàn)在可以使用 MySQL 分析引擎運行分析查詢，性能顯著提高，成本更低，不需要 ETL，并且支持實時分析。該服務(wù)可以只部署在云中，也可以部署在混合環(huán)境中，它簡化了事務(wù)和分析應(yīng)用程序的管理。從其推出產(chǎn)品上，可歸納為以下幾個理念：
ONE DB
這一產(chǎn)品最核心價值點就是統(tǒng)一處理場景。之前 MySQL 的在處理混合業(yè)務(wù)場景是不得不使用下面方式（如下圖）：
通過引入 MAE，增強 MySQL 能力，達到統(tǒng)一效果。
ONE SQL
第二個價值點在于，不僅僅是統(tǒng)一平臺，而且使用同樣的交互方式。原有的邏輯，不需要做任何的改變。無論是前端的事務(wù)交易場景，還是后端的數(shù)據(jù)可視化分析，均不需要做改變。這無疑對用戶的吸引力很大，可以有效保護用戶的已有軟件資產(chǎn)。
NO ETL
對用戶來說，不在需要關(guān)心數(shù)據(jù)同步的細節(jié)，不需要編寫額外的 ETL 作業(yè)。這將大大減少用戶的負擔。
NO TUNING
在 MAE 之前，用戶如果想解決數(shù)據(jù)分析問題，無外乎兩種。要么在庫內(nèi)解決，要么在庫外解決。在庫內(nèi)解決的話，需要對 MySQL 做大量的優(yōu)化工作或者采取針對分析場景的存儲引擎，這些都帶來了優(yōu)化的工作量。對于庫外方案同樣如此，用戶需要自己完成優(yōu)化工作。
而使用 MAE 則不需要顧慮這點。其利用了 Oracle 實驗室開發(fā)的自動機器學(xué)習 (AutoML) 功能來自動化服務(wù)的各個方面。由于這種自動化是基于機器學(xué)習的，系統(tǒng)可以智能地預(yù)測各種場景并采取行動，包括自動估算工作負載所需的分析節(jié)點數(shù)量。
當服務(wù)啟動時，需要將運行分析查詢的數(shù)據(jù)庫表加載到 MySQL 分析集群內(nèi)存中。所需集群的大小取決于加載所需的表和列，以及此數(shù)據(jù)在內(nèi)存中實現(xiàn)的壓縮。在傳統(tǒng)的配置中，用戶需要猜測集群的大小。由于空間限制，低估會導(dǎo)致數(shù)據(jù)加載或查詢執(zhí)行失敗。高估會導(dǎo)致不必要資源的額外成本。因此，用戶會不斷迭代，直到確定正確的集群大小，當更新表時，這種大小估計就會變得不準確。而 MAE 則可自動完成上述過程。
HIGH PERFORMANCE
MAE 作為一種分布式、可伸縮、內(nèi)存型、混合列式查詢引擎，其通過內(nèi)存中的矢量化處理及大規(guī)模節(jié)點間和節(jié)點內(nèi)并行處理來極速性能。同時查詢處理已針對 Oracle 云基礎(chǔ)設(shè)施做了優(yōu)化，包括節(jié)點間網(wǎng)絡(luò)帶寬優(yōu)化等。通過上述能力，MAE 提供了強大的分析能力。下面是針對其主要競品的性能對比。
MySQL Analytics vs MySQL
MySQL Analytics vs Amazon Aurora
MySQL Analytics vs Amazon Redshift
LOW COST
使用帶有分析引擎的 MySQL 數(shù)據(jù)庫服務(wù)的成本取決于配置的分析節(jié)點的數(shù)量。分析集群的大小取決于數(shù)據(jù)集的大小和工作負載的特性。一個分析節(jié)點可以容納大約 400GB 的數(shù)據(jù)。當客戶使用 Analytics Engine 遷移到 MySQL 數(shù)據(jù)庫服務(wù)時，他們的成本有望大幅降低。與 Amazon Aurora 和 Redshift 相比，MySQL 分析引擎的成本是其成本的 1 /3。
EASY SCALE
MAE 目前在一個集群中支持最多 24 個分析節(jié)點（上千個 Core），處理能力約為 10 TB 的分析數(shù)據(jù)。10TB 是在給定時刻可以填充到分析節(jié)點內(nèi)存中的大約數(shù)據(jù)量。MySQL 數(shù)據(jù)庫中存儲的數(shù)據(jù)量沒有限制，客戶可以選擇從 MySQL 數(shù)據(jù)庫模式中加載哪些表或列到分析節(jié)點的內(nèi)存中。如果查詢不再需要這些表，用戶可以從內(nèi)存中刪除這些表，為其他數(shù)據(jù)騰出空間。
EASY USE
MAE 將大量細節(jié)隱藏在后面，對于前端客戶來講使用非常簡單。只需要根據(jù)推薦大小配置分析集群、配置預(yù)加速查詢的對象、手工完成第一次加載。后面即可享受到分析集群帶來的加速能力。
通過查看執(zhí)行計劃，可以直觀看出是否使用了分析集群（下圖中的 Using secondary engine RAPID）
此外，針對混合云場景（即無法將數(shù)據(jù)部署到云端的客戶），可以利用 MySQL 復(fù)制將本地 MySQL 數(shù)據(jù)復(fù)制到 MySQL 分析引擎，同樣不需要 ETL。目前 MAE 僅在 Oracle Cloud Infrastructure (OCI) Gen 2 hardware 平臺提供。
寫在最后
MAE 的出現(xiàn)，很好地彌補了 MySQL 原生在數(shù)據(jù)分析場景的短板。相信，這一特性將更加擴大 MySQL 的使用范圍，為其在更大規(guī)模、更為重要的企業(yè)化應(yīng)用鋪平道路。比較遺憾的是，MAE 目前僅能在 OCI 中使用，目前國內(nèi)的廣大線下用戶還無法使用。
感謝各位的閱讀，以上就是“MySQL 重大新增的功能有哪些”的內(nèi)容了，經(jīng)過本文的學(xué)習后，相信大家對 MySQL 重大新增的功能有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！
