SQL vs.NoSQL 資料
關聯式 (SQL) 與非關聯式 (NoSQL) 是通常會在雲端原生應用程式中實作的兩種資料庫系統類型。 其以不同的方式建置、以不同的方式儲存資料，並以不同的方式存取。 在此節中，我們將探討這兩者。 此章稍後將探討名為 NewSQL 的新興資料庫技術。
「關聯式資料庫」是數十年來廣為使用的技術。 其成熟、經實證且廣泛實作。 不過也有許多競爭資料庫產品、工具與專業知識。 關聯式資料庫提供關聯式資料表的存放區。 這些資料表具有固定的結構描述、使用 SQL (結構化查詢語言) 來管理資料，並支援 ACID 保證：不可部分完成性、一致性、隔離性和耐用性。
「NoSQL 資料庫」是指高效能的非關聯式資料存放區。 其具備容易使用、可擴縮性、復原性與可用性等特性。 NoSQL 不會聯結標準化資料的資料表，而是會儲存非結構化或半結構化資料，而且通常是儲存在機碼值組或 JSON 文件中。 NoSQL 資料庫通常不會提供超出單一資料庫資料分割範圍的 ACID 保證。 需要不到一秒回應時間的大量服務偏好使用 NoSQL 資料存放區。
分散式雲端原生系統的 NoSQL 技術影響並非誇大。 此領域中新資料技術的激增造成以往僅仰賴關聯式資料庫的解決方案不是那麼受歡迎。
NoSQL 資料庫包含數種用於存取及管理資料的不同模型，每個模型都適合特定的使用案例。 圖 5-9 顯示四個常見模型。
圖 5-9：NoSQL 資料庫的資料模型
| 模型 | 特性 |
|---|---|
| 文件存放區 | 資料和中繼資料會以階層方式儲存在資料庫內以 JSON 為基礎的文件中。 |
| 機碼值存放區 | NoSQL 資料庫最簡單的方法，資料會以機碼值組的集合表示。 |
| Wide-Column 存放區 | 相關資料會以一組巢狀結構機碼值組的形式儲存在單一資料行中。 |
| 圖形存放區 | 資料會以節點、邊緣和資料屬性的形式儲存在圖形結構中。 |
CAP 定理
為了了解這些資料庫類型之間的差異，請考慮 CAP 定理，這是一組適用於存放狀態之分散式系統的原則。 圖 5-10 顯示 CAP 定理的三個屬性。
圖 5-10。 CAP 定理
此定理指出分散式資料系統將在一致性、可用性與資料分割容錯之間提供取捨。 而且，任何資料庫都只能保證三個屬性中的「兩個」：
一致性。 即使系統在所有複本更新之前必須封鎖要求，叢集中的每個節點還是會以最新的資料回應。 如果您針對目前正在更新的項目，查詢「一致的系統」，則在所有複本都成功更新之前，您將必須等候該回應。 不過，您將會收到最新的資料。 據瞭解，在 CAP 定理內容中使用「一致性」字詞所具有的技術意義，與在 ACID 保證內容中定義「一致性」的方式不同。
可用性。 系統中非失敗節點收到的每個要求都必須產生回應。 簡言之，如果您針對正在更新的項目查詢「可用的系統」，則將會取得服務當時所能提供的最佳可能答案。 但請注意，CAP 定理所定義的「可用性」在技術上與分散式系統中傳統意義上的「高可用性」不同。
資料分割容錯。 保證即使複寫的資料節點失敗或失去與其他複寫之資料節點的連線，系統仍會繼續運作。
CAP 定理說明與在網路分割期間管理一致性和可用性相關聯的取捨；不過，與一致性和效能相關的取捨也存在於沒有網路分割的情況下。 CAP 定理通常會進一步延伸至 PACELC ，以更全面地說明取捨。
注意
即使您選擇可用性而不是一致性，在網路磁碟分割時，可用性也會受到影響。 CAP 可用系統對其某些用戶端更具可用性，但不一定對其所有用戶端具有「高可用性」。
關聯式資料庫通常會提供一致性和可用性，但不會提供資料分割容錯。 其通常會佈建至單一伺服器，並透過將更多資源新增至該機器以進行垂直擴縮。
許多關聯式資料庫系統都支援內建的複寫功能，其中主資料庫的複本可以複製到其他次要伺服器執行個體。 寫入作業會對主要執行個體執行，並複寫至每個次要執行個體。 失敗時，主要執行個體可以容錯移轉至次要執行個體以提供高可用性。 次要執行個體也可以用來散發讀取作業。 雖然寫入作業一律會對主要複本進行，但讀取作業可以路由傳送至任何次要複本，以減少系統負載。
資料也可以跨多個節點水平分割，例如使用分區化功能。 但是，分區化會因為將資料分割為許多無法輕鬆通訊的片段，而大幅增加作業額外負荷。 管理成本很高且耗時。 包含資料表聯結、交易和參考完整性的關聯式功能，在分區化部署中的效能會大幅受影響。
您可以透過設定以同步或非同步方式進行複寫，來微調複寫一致性和復原點目標。 如果資料複本在「高度一致」或同步關聯式資料庫叢集中會發生網路連線中斷的情況，您將無法寫入資料庫。 系統會拒絕寫入作業，因為其無法將該變更複寫至其他資料複本。 每個資料複本都必須更新，交易才能完成。
NoSQL 資料庫通常支援高可用性和資料分割容錯。 其通常會水平擴增，而且通常是跨商用伺服器進行。 這種方法能以降低的成本，在地理區域內和跨地理區域提供極大的可用性。 您可以跨這些機器或節點分割和複寫資料，以提供備援和容錯。 一致性通常會透過共識通訊協定或仲裁機制微調。 在微調關聯式系統中同步與非同步複寫之間的取捨時，其可提供更多控制權。
如果資料複本在「高可用性」NoSQL 資料庫叢集中會發生網路連線中斷的情況，您仍然可以完成資料庫的寫入作業。 資料庫叢集會允許寫入作業，並在每個資料複本可供使用時加以更新。 支援多個可寫入複本的 NoSQL 資料庫可以透過避免在最佳化復原時間目標時進行容錯移轉，進一步強化高可用性。
新式 NoSQL 資料庫通常會實作資料分割功能作為其系統設計功能。 資料分割管理通常是內建至資料庫，而且路由是透過放置提示 (通常稱為資料分割索引鍵) 來達成。 彈性資料模型可讓 NoSQL 資料庫降低結構描述管理的負擔，並在部署需要資料模型變更的應用程式更新時改善可用性。
對於企業而言，高可用性和大規模可擴縮性通常比關聯式資料表聯結和參考完整性更重要。 開發人員可以實作技術與模式，例如 Sagas、CQRS 和非同步傳訊，以採用最終一致性。
現在，考慮 CAP 定理條件約束時，必須小心。 有一種新的資料庫類型稱為 NewSQL，其延伸了關聯式資料庫引擎，以支援 NoSQL 系統的水平可擴縮性和可調整的效能。
關聯式與NoSQL 系統的考量
根據特定資料需求，雲端原生型微服務可以實作關聯式、NoSQL 資料存放區或兩者。
| 在下列情況下，請考慮 NoSQL 資料存放區： | 在下列情況下，請考慮關聯式資料庫： |
|---|---|
| 您有大量工作負載需要大規模的可預測延遲 (例如，以毫秒為單位測量的延遲，同時每秒執行數百萬筆交易) | 您的工作負載量通常不超過每秒數千筆交易 |
| 您的資料是動態且經常變更的 | 您的資料是高度結構化資料，而且需要參考完整性 |
| 關聯性可以是反正規化資料模型 | 關聯性是透過標準化資料模型上的資料表聯結來表示 |
| 資料擷取很簡單，而且不是以資料表聯結表示 | 您處理複雜的查詢和報表 |
| 資料通常會跨地理位置複寫，而且您需要更精細地控制一致性、可用性和效能 | 資料通常是集中式的，或可以透過非同步方式跨區域複寫 |
| 您的應用程式將會部署到商用硬體，例如使用公用雲端 | 您的應用程式將會部署到大型的高階硬體 |
在下一節中，我們將探索 Azure 雲端中可用來儲存及管理雲端原生資料的選項。
資料庫即服務
若要開始，您可以佈建 Azure 虛擬機器，並為每個服務安裝您選擇的資料庫。 雖然您已完全控制環境，但您仍會放棄雲端平台的許多內建功能。 您也必須負責管理每個服務的虛擬機器和資料庫。 這種方法可能很快就會變得耗時且昂貴。
相反地，雲端原生應用程式偏好公開為資料庫即服務 (DBaaS) 的資料服務。 這些服務由雲端廠商完全管理，而且提供內建的安全性、可擴縮性和監視功能。 您不需要擁有服務，而是直接以支援服務的方式加以取用。 提供者會大規模操作資源，並全權負責效能和維護。
您可以跨雲端可用性區域 (Zone) 和區域 (Region) 加以設定，以達到高可用性。 其全都支援 Just-In-Time 容量和隨用隨付模型。 Azure 提供不同類型的受控資料服務選項，這些選項各有特定優點。
我們會先查看 Azure 中可用的關聯式 DBaaS 服務。 您會看到 Microsoft 的旗艦型 SQL Server 資料庫可供使用，以及數個開放原始碼選項。 然後，我們將討論 Azure 中的 NoSQL 資料服務。
Azure 關聯式資料庫
針對需要關聯式資料的雲端原生微服務，Azure 提供四個受控關聯式資料庫即服務 (DBaaS) 供應項目，如圖 5-11 所示。
圖 5-11。 Azure 中可用的受控關聯式資料庫
在上圖中，請注意每一個都位於常見的 DBaaS 基礎結構上，而且其關鍵功能都不需要額外費用。
這些功能對於需要佈建大量資料庫但管理資源有限的組織特別重要。 您可以透過選取處理核心、記憶體和基礎儲存體的數量，以分鐘為單位佈建 Azure 資料庫。 您可以即時調整資料庫，並動態調整資源，幾乎不需要停機。
Azure SQL Database
具備 Microsoft SQL Server 專業知識的開發小組應考慮 Azure SQL Database。 其是以 Microsoft SQL Server 資料庫引擎為基礎的完全受控關聯式資料庫即服務 (DBaaS)。 該服務的許多功能都與內部部署版本的 SQL Server 相同，而且執行最新的穩定版 SQL Server 資料庫引擎。
若要搭配雲端原生微服務使用，Azure SQL Database 有三個部署選項可供使用：
單一資料庫代表在 Azure 雲端中之 Azure SQL Database 伺服器上執行的完全受控 SQL Database。 該資料庫被視為獨立式，因為其沒有基礎資料庫伺服器的設定相依性。
受控執行個體是完全受控的 Microsoft SQL Server 資料庫引擎執行個體，可提供與內部部署 SQL Server 近乎 100% 的相容性。 此選項支援較大的資料庫，最多可達 35 TB，並放在 Azure 虛擬網路中，以取得更好的隔離。
Azure SQL Database 無伺服器是單一資料庫的計算層，可根據工作負載需求自動調整。 其只會針對每秒使用的計算量計費。 此服務非常適合具有間歇性、無法預測之使用模式並穿插無活動期間的工作負載。 無伺服器計算層在無活動期間也會自動暫停資料庫，此時只對儲存體計費。 其會在活動恢復時自動繼續執行資料庫。
除了傳統的 Microsoft SQL Server 堆疊之外，Azure 也提供三個熱門開放原始碼資料庫的受控版本。
Azure 中的開放原始碼資料庫
開放原始碼關聯式資料庫已成為雲端原生應用程式的熱門選擇。 相較於商業資料庫產品，許多企業更喜歡開放原始碼資料庫，尤其是為了節省成本時更是如此。 許多開發小組都享受其彈性、社群支援開發，以及工具和延伸模組的生態系統。 開放原始碼資料庫可以跨多個雲端提供者部署，協助將「廠商鎖定」的顧慮降到最低。
開發人員可以輕鬆地在 Azure VM 上自我裝載任何開放原始碼資料庫。 雖然此方法提供完整的控制，但您必須自行負責資料庫和 VM 的管理、監視及維護。
不過，Microsoft 透過提供數個熱門的開放原始碼資料庫作為「完全受控」的 DBaaS 服務，信守讓 Azure 維持為「開放平台」的承諾。
適用於 MySQL 的 Azure 資料庫
MySQL 是開放原始碼關聯式資料庫，也是以 LAMP 軟體堆疊為基礎建置之應用程式的關鍵要素。 許多大型組織 (包括 Facebook、Twitter 和 YouTube) 都選擇使用它來執行會「頻繁讀取資料」的工作負載。 社群版本是免費的，而企業版則需要授權購買。 該產品最初是在 1995 年建立，而在 2008 年由 Sun Microsystems 併購。 Oracle 在 2010 年取得 Sun 和 MySQL。
適用於 MySQL 的 Azure 資料庫是以開放原始碼 MySQL 伺服器引擎為基礎的受控關聯式資料庫服務。 其使用 MySQL Community 版本。 Azure MySQL 伺服器是該服務的系統管理點。 其是用於內部部署的相同 MySQL 伺服器引擎。 該引擎可以為每部伺服器建立單一資料庫，或共用資源的每部伺服器建立多個資料庫。 您可以繼續使用相同的開放原始碼工具來管理資料，而不需要學習新的技能或管理虛擬機器。
適用於 MariaDB 的 Azure 資料庫
MariaDB 伺服器是另一個熱門的開放原始碼資料庫伺服器。 當 Oracle 併購擁有 MySQL 的 Sun Microsystems 時，其被建立為 MySQL 的分支。 其目的是要確保 MariaDB 維持開放原始碼。 由於 MariaDB 是 MySQL 的分支，因此資料與資料表定義是相容的，而用戶端通訊協定、結構和 API 則非常接近。
MariaDB 擁有強大的社群，並由許多大型企業使用。 雖然 Oracle 會持續維護、增強及支援 MySQL，但 MariaDB 基礎會管理 MariaDB，以允許公眾對產品與文件進行貢獻。
適用於 MariaDB 的 Azure 資料庫是 Azure 雲端中完全受控的關聯式資料庫即服務。 該服務是以 MariaDB 社群版本伺服器引擎為基礎。 其可以利用可預測的效能和動態可擴縮性來處理任務關鍵性工作負載。
適用於 PostgreSQL 的 Azure 資料庫
PostgreSQL 是開放原始碼關聯式資料庫，具有超過 30 年的活躍開發。 PostgreSQL 在可靠性和資料完整性方面有著卓越的信譽。 其功能豐富、符合 SQL 規範，且被視為效能比 MySQL 好，特別是針對具有複雜查詢和大量寫入作業的工作負載。 許多大型企業 (包括 Apple、Red Hat 和 Fujitsu) 都已使用 PostgreSQL 建置產品。
適用於 PostgreSQL 的 Azure 資料庫是以開放原始碼 Postgres 資料庫引擎為基礎的完全受控關聯式資料庫服務。 該服務支援許多開發支援，包括 C++、JAVA、Python、Node、C# 和 PHP。 您可以使用命令列介面工具或 Azure 資料移轉服務，將 PostgreSQL 資料庫移轉至其中。
適用於 PostgreSQL 的 Azure 資料庫有兩個部署選項：
單一伺服器部署選項是多個資料庫的中央管理點，可供您部署許多資料庫。 定價是以核心和儲存體為基礎，並依每部伺服器為結構計算。
超大規模 (Citus) 選項是由 Citus Data 技術所提供。 其可藉由跨數百個節點「水平擴縮」單一資料庫來達到高效能，以提供快速的效能和規模。 此選項可讓引擎在記憶體中容納更多資料、跨數百個節點平行處理查詢，以及更快速地為資料編製索引。
Azure 中的 NoSQL 資料
Cosmos DB 是 Azure 雲端中完全受控的全域分散式 NoSQL 資料庫服務。 其已由世界各地的許多大型公司採用，包括 Coca-Cola、Skype、ExxonMobil 與 Liberty Mutual。
如果您的服務需要從世界各地快速回應、高可用性或彈性可擴縮性，Cosmos DB 是不錯的選擇。 圖 5-12 顯示 Cosmos DB。
圖 5-12：Azure Cosmos DB 概觀
上圖顯示 Cosmos DB 中可用的許多內建雲端原生功能。 在此節中，我們將進一步了解它們。
全域支援
雲端原生應用程式通常會有全球使用對象，而且需要全球規模。
您可以將 Cosmos 資料庫分散到各區域或全球各地，進而將資料放在靠近使用者的地方、改善回應時間，以及降低延遲。 您可以在不暫停或重新部署服務的情況下，在某個區域新增或移除資料庫。 Cosmos DB 會在背景自動將資料複寫到每個已設定的區域。
Cosmos DB 支援全域層級的主動/主動叢集，可讓您設定任何資料庫區域以同時支援「寫入和讀取」。
多重區域寫入通訊協定是 Cosmos DB 中啟用下列功能的重要功能：
無限制的彈性寫入和讀取的擴充性。
全球 99.999% 的讀寫可用性。
在 99% 的情況下，保證讀取和寫入服務時間不到 10 毫秒。
使用 Cosmos DB 多路連接 API 時，您的微服務會自動感知最接近的 Azure 區域，並將要求傳送到該區域。 Cosmos DB 會自動識別最靠近的區域，不需要任何設定變更。 如果某個區域無法使用，多路連接功能會自動將要求路由傳送至下一個最接近的可用區域。
多模型支援
將整合型應用程式重新平台化為雲端原生架構時，開發小組有時必須移轉開放原始碼、NoSQL 資料存放區。 Cosmos DB 可透過其「多模型」資料平台，協助您在這些 NoSQL 資料存放區中保留原有投資。 下表顯示支援的 NoSQL 相容性 API。
| 提供者 | 描述 |
|---|---|
| NoSQL API | 適用於 NoSQL 的 API 會以文件格式儲存資料 |
| Mongo DB API | 支援 Mongo DB API 和 JSON 文件 |
| Gremlin API | 支援使用圖形型節點和邊緣資料表示法的 Gremlin API |
| Cassandra API | 支援適用於寬資料行資料表示法的 Casandra API |
| 資料表 API | 支援具有進階增強功能的 Azure 表格儲存體 |
| PostgreSQL API | 適用於執行中 PostgreSQL 的任何規模受控服務 |
開發小組只要稍微變更資料或程式碼，就可以將現有的 Mongo、Gremlin 或 Cassandra 資料庫移轉至 Cosmos DB。 針對新的應用程式，開發小組可以選擇開放原始碼選項或內建的 SQL API 模型。
在內部，Cosmos 會以由基本資料類型所構成的簡單結構格式來儲存資料。 針對每個要求，資料庫引擎都會將基本資料轉譯為您選取的模型表示法。
在上表中，記下資料表 API 選項。 此 API 是 Azure 表格儲存體的演進。 兩者共用相同的基礎資料表模型，但 Cosmos DB 資料表 API 中多了 Azure 儲存體 API 中沒有的進階增強功能。 下表列出功能對比。
| 功能 | Azure 資料表儲存體 | Azure Cosmos DB |
|---|---|---|
| Latency | 快速 | 在全球各地皆提供讀取和寫入的個位數毫秒延遲 |
| 輸送量 | 每個資料表 20,000 個作業的限制 | 每個資料表的無限制作業 |
| 全域散發 | 具有選擇性單一次要讀取區域的單一區域 | 具有自動容錯移轉的全區域周全散發 |
| 編製索引 | 僅適用於資料分割和資料列索引鍵屬性 | 自動為所有屬性編製索引 |
| 定價 | 針對非經常性存取工作負載最佳化 (低輸送量對儲存體比) | 針對經常性存取工作負載最佳化 (高輸送量對儲存體比) |
使用 Azure 表格儲存體的微服務可以輕鬆地移轉至 Cosmos DB 資料表 API。 不需要任何程式碼變更。
可調整的一致性
稍早在關聯式與NoSQL 一節中，我們已討論資料一致性的主題。 資料一致性指的是資料的「完整性」 。 具有分散式資料的雲端原生服務依賴複寫，而且必須在讀取一致性、可用性和延遲之間做出基本取捨。
大部分分散式資料庫都可讓開發人員在兩個一致性模型之間進行選擇：強式一致性和最終一致性。 「強式一致性」是資料可程式性的黃金標準。 其保證查詢一律會傳回最新的資料，即使系統必須產生延遲以等候更新在所有資料庫複本之間複寫也一樣。 針對「最終一致性」設定的資料庫則會立即傳回資料，即使該資料不是最新的複本也一樣。 後者可提供更高的可用性、更大的規模，以及更高的效能。
Azure Cosmos DB 提供圖 5-13 所示五個定義完善的一致性模型。
圖 5-13：Cosmos DB 一致性層級
這些選項可讓您針對資料的一致性、可用性和效能做出精確的選擇和細微取捨。 下表顯示這些層級。
| 一致性層級 | 描述 |
|---|---|
| 最終 | 讀取沒有排序保證。 複本最終會收斂。 |
| 常數前置詞 | 讀取仍然為最終，但資料會依寫入的順序傳回。 |
| 會議 | 保證您可以讀取目前工作階段期間寫入的任何資料。 這是預設的一致性層級。 |
| 限定過期 | 依您指定的間隔讀取尾端寫入。 |
| 強式 | 保證讀取一定會傳回項目的最新已認可版本。 用戶端將絕不會看到未認可或部分的讀取。 |
在 9 號球後方：Cosmos DB 一致性層級說明一文中，Microsoft Program Manager Jeremy Likness 提供五個模型的絕佳說明。
資料分割
Azure Cosmos DB 採用自動資料分割來調整資料庫，以符合雲端原生服務的效能需求。
您可以透過建立資料庫、容器和項目來管理 Cosmos DB 資料中的資料。
容器位於 Cosmos DB 資料庫中，代表與結構描述無關的項目分組。 項目是您新增至容器的資料。 其會以文件、資料列、節點或邊緣表示。 系統會自動為新增至容器的所有項目編制索引。
若要分割容器，容器會分割為不同子集，稱為「邏輯資料分割」。 邏輯資料分割會根據與容器中各項目關聯的資料分割索引鍵值填滿。 圖 5-14 顯示兩個容器，每個容器都有一個以資料分割索引鍵值為基礎的邏輯資料分割。
圖 5-14：Cosmos DB 分割力學
請注意上圖中每個項目如何包含 'city' 或 'airport' 的資料分割索引鍵。 索引鍵會決定項目的邏輯資料分割。 具有城市代碼的項目會指派給左邊的容器，而具有機場代碼的項目則會指派給右邊的容器。 將資料分割索引鍵值與識別碼值結合會建立項目的索引，其能唯一識別該項目。
在內部，Cosmos DB 會自動管理實體資料分割區的邏輯資料分割放置，以便滿足容器的可擴縮性和效能需求。 隨著應用程式輸送量和儲存體需求增加，Azure Cosmos DB 會將邏輯資料分割轉散發到較多的伺服器。 轉散發作業是由 Cosmos DB 管理，而且叫用時不需中斷或停機。
NewSQL 資料庫
NewSQL 是一種新興的資料庫技術，結合了 NoSQL 的分散式可擴縮性和關聯式資料庫的 ACID 保證。 NewSQL 資料庫對於必須跨分散式環境處理大量資料的公司而言很重要，而且提供完整的交易支援與 ACID 合規性。 雖然 NoSQL 資料庫可以提供大量的可擴縮性，但其不保證資料一致性。 間歇性發生資料不一致的問題可能會對開發小組造成負擔。 開發人員必須在其微服務程式碼中建構保護機制，以管理不一致的資料所造成的問題。
雲端原生運算基金會 (CNCF) 有數個 NewSQL 資料庫專案。
| Project | 特性 |
|---|---|
| Cockroach DB | 符合 ACID 規範的關聯式資料庫，可全域擴縮。 將新節點新增至叢集，CockroachDB 會負責跨執行個體和地理位置平衡資料。 其會建立、管理及散發複本，以確保可靠性。 其是開放原始碼且可免費使用。 |
| TiDB | 支援混合式交易式和分析處理 (HTAP) 工作負載的開放原始碼資料庫。 其與 MySQL 相容，且具有水平可擴縮性、強式一致性和高可用性。 TiDB 的作用就像 MySQL 伺服器。 您可以繼續使用現有的 MySQL 用戶端程式庫，而不需要對應用程式進行廣泛的程式碼變更。 |
| YugabyteDB | 開放原始碼、高效能、分散式 SQL 資料庫。 其支援低查詢延遲、從失敗復原，以及全域資料散發等功能。 YugabyteDB 與 PostgreSQL 相容，而且可以處理擴增 RDBMS 和網際網路規模 OLTP 工作負載的作業。 該產品也支援 NoSQL，且與 Cassandra 相容。 |
| Vitess | Vitess 是一種資料庫解決方案，可用來部署、擴縮及管理大型 MySQL 執行個體叢集。 其可以在公用或私人雲端架構中執行。 Vites 結合並延伸許多重要的 MySQL 功能，而且同時提供垂直和水平分區化支援。 來自 YouTube，Vitess 自 2011 年起已提供所有 YouTube 資料庫流量。 |
上圖中的開放原始碼專案可從雲端原生運算基金會 (CNCF) 取得。 其中三個供應項目是完整的資料庫產品，其中包括 .NET 支援。 另一個 Vitess 是一種資料庫叢集系統，可水平擴縮大型 MySQL 執行叢集。
NewSQL 資料庫的主要設計目標是在 Kubernetes 中以原生方式運作，進而發揮平台的復原能力和可擴縮性等優點。
NewSQL 資料庫的設計目的是在轉瞬即逝的雲端環境 (其中基礎虛擬機器可能會在短暫通知後就重新開機或重新排程) 中蓬勃發展。 該資料庫的設計目的是為了在發生節點失敗的情況下確保資料的可用性，而不會造成資料遺失或停機。 例如，CockroachDB 能夠透過跨叢集中的節點維護任何資料的三份一致複本，在機器故障時確保資料的可用性。
Kubernetes 會使用「服務建構」，允許用戶端從單一 DNS 項目定址一組相同的 NewSQL 資料庫處理序。 透過將資料庫執行個體以及與其相關聯的服務位址去耦合，我們可以進行擴縮，而不會造成現有的應用程式執行個體中斷。 在給定時間將要求傳送至任何服務，一律會產生相同的結果。
在此案例中，所有資料庫執行個體都相等。 沒有主要或次要關聯性。 像是在 CockroachDB 中找到的「共識複寫」等技術，可讓任何資料庫節點處理任何要求。 如果接收負載平衡要求的節點具有本機所需的資料，其會立即回應。 如果沒有，該節點會變成閘道，並將要求轉送至適當的節點，以取得正確的答案。 從用戶端的觀點來看，每個資料庫節點都相同：雖然其背後有數十個或甚至數百個節點在運作，不過看起來就像具有單一機器系統一致性保證的單一「邏輯」資料庫。
如需 NewSQL 資料庫背後力學的詳細探討，請參閱 DASH：Kubernetes-Native 資料庫的四個屬性一文。
將資料移轉至雲端
其中一個更耗時的工作是將資料從某個資料平台移轉至另一個平台。 Azure 資料移轉服務可協助加速這類工作。 其能以停機時間最短的方式，將資料從數個外部資料庫來源移轉至 Azure 資料平台。 目標平台包含下列服務：
- Azure SQL Database
- 適用於 MySQL 的 Azure 資料庫
- 適用於 MariaDB 的 Azure 資料庫
- 適用於 PostgreSQL 的 Azure 資料庫
- Azure Cosmos DB
該服務提供建議，引導您完成執行小型或大型移轉所需的變更。
