資料庫與之戰

⑴ 資料庫的作用是什麼

資料庫的作用：

資料庫是為了實現一定目的按某種規則和方法組織起來的「數據」的「集合」。

資料庫可以直觀的理解為存放數據的倉庫，只不過這個倉庫是在計算機的大容量存儲器上，而且數據必須按照一定的格式存放，因為它不僅需要存放，而且要便於查找。

資料庫可以做到：

⑴ 實現數據共享

數據共享包含所有用戶可同時存取資料庫中的數據，也包括用戶可以用各種方式通過介面使用資料庫，並提供數據共享。

⑵ 減少數據的冗餘度

同文件系統相比，由於資料庫實現了數據共享，從而避免了用戶各自建立應用文件。減少了大量重復數據，減少了數據冗餘，維護了數據的一致性。

⑶ 數據的獨立性

數據的獨立性包括邏輯獨立性（資料庫中資料庫的邏輯結構和應用程序相互獨立）和物理獨立性（數據物理結構的變化不影響數據的邏輯結構）。

⑷ 數據實現集中控制

文件管理方式中，數據處於一種分散的狀態，不同的用戶或同一用戶在不同處理中其文件之間毫無關系。利用資料庫可對數據進行集中控制和管理，並通過數據模型表示各種數據的組織以及數據間的聯系。

⑸ 數據一致性和可維護性，以確保數據的安全性和可靠性

主要包括：安全性控制、完整性控制、並發控制，使在同一時間周期內，允許對數據實現多路存取，又能防止用戶之間的不正常交互作用。

⑹ 故障恢復

由資料庫管理系統提供一套方法，可及時發現故障和修復故障，從而防止數據被破壞。資料庫系統能盡快恢復資料庫系統運行時出現的故障，可能是物理上或是邏輯上的錯誤。比如對系統的誤操作造成的數據錯誤等。

(1)資料庫與之戰擴展閱讀：

資料庫管理系統：

資料庫管理系統是為管理資料庫而設計的電腦軟體系統，一般具有存儲、截取、安全保障、備份等基礎功能。

資料庫管理系統可以依據它所支持的資料庫模型來作分類，例如關系式、XML；或依據所支持的計算機類型來作分類，例如伺服器群集、行動電話；

或依據所用查詢語言來作分類，例如sql、XQuery；或依據性能沖量重點來作分類，例如最大規模、最高運行速度；亦或其他的分類方式。

不論使用哪種分類方式，一些DBMS能夠跨類別，例如，同時支持多種查詢語言。

⑵ 資料庫技術的發展趨勢

資料庫技術的發展趨勢:
根據資料庫應用及多家分析機構的評估，資料庫技術發展將以應用為導向，面向業務服務，並與計算機網路和人工智慧等技術結合，為新型應用提供多種支持。
（1）雲資料庫和混合數據快速發展
雲資料庫（Cloud Database）簡稱為雲庫， 是在雲計算環境中部署和虛擬化的資料庫。將各種關系型資料庫看成一系列簡單的二維表，並基於簡化版本的SQL或訪問對象進行操作。使傳統關系型資料庫通過提交一個有效地鏈接字元串即可加入雲資料庫，雲資料庫可解決數據集中更廣泛的異地資源共享問題。
（2）數據集成與數據倉庫
數據倉庫（Data Warehouse）是面向主題、集成、相對穩定、反映歷史變化的數據集合，是決策支持系統和聯機分析應用數據源的結構化數據環境。主要側重對機構歷史數據的綜合分析利用，找出對企業發展有價值的信息，以提供決策支持，幫助提高效益。其特徵是面向主題、集成性、穩定性和時變性。新一代資料庫使數據集成和數據倉庫的實施更簡單。數據應用逐步過渡到數據服務，開始注重處理：關系型與非關系型數據的融合、分類、國際化多語言數據。
（3）主數據管理和商務智能
在企事業機構內部業務應用整合和系統互聯中，許多機構具有相同業務語義的數據被多次反復定義和存儲，導致數據大量冗餘成為IT環境發展的障礙，為了有效使用和管理這些數據，主數據管理已經成為一個新的熱點。
商務智能（Business Intelligence）是指利用數據倉庫及數據挖掘技術對業務數據分析處理並提供決策信息和報告，促進企業利用現代信息技術收集、管理和分析商務數據，改善決策水平，提升績效，增強綜合競爭力的智慧和能力。是企業利用現代信息技術收集、管理和分析商務數據和信息，創造和累計商務知識和見解，改善商務決策水平，採取有效的商務行動，完善各種商務流程，提升各方面商務績效，增強綜合競爭力的智慧和能力。融合了先進信息技術與創新管理理念的結合體，集成企業內外的數據，加工並從中提取能夠創造商業價值的信息，面向企業戰略並服務於管理層。
（4）「大數據」促進新型資料庫
進入「大數據時代」，大數據量、高並發、分布式和實時性的需求，由於傳統的資料庫技術的數據模型和預定義的操作模式，時常難以滿足實際需求，致使新型資料庫在大數據的場景下，將取代傳統資料庫成為主導。
（5）基於網路的自動化管理
網路資料庫應用系統的廣泛應用，使資料庫管理更加自動化。如網購、網銀等系統，從企業級Enterprise-class到世界級World-class的轉變，提供更多基於Internet環境的管理工具，完成資料庫管理網路化。應用程序編程介面API(Application ProgrammingInterface)更開放，基於瀏覽器端技術的管理套件，便於分布遠程管理。
（6）PHP將促進資料庫產品應用
隨著新一代Web技術的廣泛應用，在.NET和Java成為數據應用的主體開發平台後，很多廠商為了爭取市場在新版本資料庫產品推出後，提供面向超級文本預處理語言PHP（Hypertext Preprocessor）的專用驅動和應用。
（7）資料庫將與業務語義的數據內容融合
資料庫將更廣泛地為用於「信息服務」。對新一代基於AJAX、MashUp、SNS等技術的創新應用，數據從集中於邏輯中心資料庫，改為分布網路，為了給予技術支持，數據聚集及基於業務語義的數據內容融合也成為資料庫發展的方向，不僅在商務智能領域不斷加強對服務應用的支持，而且注重加強數據集成服務。

⑶ 資料庫架構選型與落地，看這篇就夠了

隨著時間和業務的發展，資料庫中的數據量增長是不可控的，庫和表中的數據會越來越大，隨之帶來的是更高的 磁碟 、 IO 、 系統開銷 ，甚至 性能 上的瓶頸，而單台伺服器的 資源終究是有限 的。

因此在面對業務擴張過程中，應用程序對資料庫系統的 健壯性 ， 安全性 ， 擴展性 提出了更高的要求。

以下，我從資料庫架構、選型與落地來讓大家入門。

資料庫會面臨什麼樣的挑戰呢？

業務剛開始我們只用單機資料庫就夠了，但隨著業務增長，數據規模和用戶規模上升，這個時候資料庫會面臨IO瓶頸、存儲瓶頸、可用性、安全性問題。

為了解決上述的各種問題，資料庫衍生了出不同的架構來解決不同的場景需求。

將資料庫的寫操作和讀操作分離，主庫接收寫請求，使用多個從庫副本負責讀請求，從庫和主庫同步更新數據保持數據一致性，從庫可以水平擴展，用於面對讀請求的增加。

這個模式也就是常說的讀寫分離，針對的是小規模數據，而且存在大量讀操作的場景。

因為主從的數據是相同的，一旦主庫宕機的時候，從庫可以 切換為主庫提供寫入 ，所以這個架構也可以提高資料庫系統的 安全性 和 可用性 ；

優點：

缺點：

在資料庫遇到 IO瓶頸 過程中，如果IO集中在某一塊的業務中，這個時候可以考慮的就是垂直分庫，將熱點業務拆分出去，避免由 熱點業務 的 密集IO請求 影響了其他正常業務，所以垂直分庫也叫 業務分庫 。

優點：

缺點：

在資料庫遇到存儲瓶頸的時候，由於數據量過大造成索引性能下降。

這個時候可以考慮將數據做水平拆分，針對數據量巨大的單張表，按照某種規則，切分到多張表裡面去。

但是這些表還是在同一個庫中，所以庫級別的資料庫操作還是有IO瓶頸（單個伺服器的IO有上限）。

所以水平分表主要還是針對 數據量較大 ，整體業務 請求量較低 的場景。

優點：

缺點：

四、分庫分表

在資料庫遇到存儲瓶頸和IO瓶頸的時候，數據量過大造成索引性能下降，加上同一時間需要處理大規模的業務請求，這個時候單庫的IO上限會限制處理效率。

所以需要將單張表的數據切分到多個伺服器上去，每個伺服器具有相應的庫與表，只是表中數據集合不同。

分庫分表能夠有效地緩解單機和單庫的 性能瓶頸和壓力 ，突破IO、連接數、硬體資源等的瓶頸。

優點：

缺點：

註：分庫還是分表核心關鍵是有沒有IO瓶頸 。

分片方式都有什麼呢？

RANGE（范圍分片）

將業務表中的某個 關鍵欄位排序 後，按照順序從0到10000一個表，10001到20000一個表。最常見的就是 按照時間切分 （月表、年表）。

比如將6個月前，甚至一年前的數據切出去放到另外的一張表，因為隨著時間流逝，這些表的數據被查詢的概率變小，銀行的交易記錄多數是採用這種方式。

優點：

缺點：

HASH（哈希分片）

將訂單作為主表，然後將其相關的業務表作為附表，取用戶id然後 hash取模 ，分配到不同的數據表或者資料庫上。

優點：

缺點：

講到這里，我們已經知道資料庫有哪些架構，解決的是哪些問題，因此， 我們在日常設計中需要根據數據的特點，數據的傾向性，數據的安全性等來選擇不同的架構 。

那麼，我們應該如何選擇資料庫架構呢？

雖然把上面的架構全部組合在一起可以形成一個強大的高可用，高負載的資料庫系統，但是架構選擇合適才是最重要的。

混合架構雖然能夠解決所有的場景的問題，但是也會面臨更多的挑戰，你以為的完美架構，背後其實有著更多的坑。

1、對事務支持

分庫分表後（無論是垂直還是水平拆分），就成了分布式事務了，如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價（XA事務）；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔（TCC、SAGA）。

2、多庫結果集合並 （group by，order by）

由於數據分布於不同的資料庫中，無法直接對其做分頁、分組、排序等操作，一般應對這種多庫結果集合並的查詢業務都需要採用數據清洗、同步等其他手段處理（TIDB、KUDU等）。

3、數據延遲

主從架構下的多副本機制和水平分庫後的聚合庫都會存在主數據和副本數據之間的延遲問題。

4、跨庫join

分庫分表後表之間的關聯操作將受到限制，我們無法join位於不同分庫的表（垂直），也無法join分表粒度不同的表（水平）， 結果原本一次查詢就能夠完成的業務，可能需要多次查詢才能完成。

5、分片擴容

水平分片之後，一旦需要做擴容時。需要將對應的數據做一次遷移，成本代價都極高的。

6、ID生成

分庫分表後由於資料庫獨立，原有的基於資料庫自增ID將無法再使用，這個時候需要採用其他外部的ID生成方案。

一、應用層依賴類（JDBC）

這類分庫分表中間件的特點就是和應用強耦合，需要應用顯示依賴相應的jar包（以Java為例），比如知名的TDDL、當當開源的 sharding-jdbc 、蘑菇街的TSharding等。

此類中間件的基本思路就是重新實現JDBC的API，通過重新實現 DataSource 、 PrepareStatement 等操作資料庫的介面，讓應用層在 基本 不改變業務代碼的情況下透明地實現分庫分表的能力。

中間件給上層應用提供熟悉的JDBC API，內部通過 sql解析 、 sql重寫 、 sql路由 等一系列的准備工作獲取真正可執行的sql，然後底層再按照傳統的方法（比如資料庫連接池）獲取物理連接來執行sql，最後把數據 結果合並 處理成ResultSet返回給應用層。

優點

缺點

二、中間層代理類（Proxy）

這類分庫分表中間件的核心原理是在應用和資料庫的連接之間搭起一個 代理層 ，上層應用以 標準的MySQL協議 來連接代理層，然後代理層負責 轉發請求 到底層的MySQL物理實例，這種方式對應用只有一個要求，就是只要用MySQL協議來通信即可。

所以用MySQL Navicat這種純的客戶端都可以直接連接你的分布式資料庫，自然也天然 支持所有的編程語言 。

在技術實現上除了和應用層依賴類中間件基本相似外，代理類的分庫分表產品必須實現標準的MySQL協議，某種意義上講資料庫代理層轉發的就是MySQL協議請求，就像Nginx轉發的是Http協議請求。

比較有代表性的產品有開創性質的Amoeba、阿里開源的Cobar、社區發展比較好的 Mycat （基於Cobar開發）等。

優點

缺點

JDBC方案 ：無中心化架構，兼容市面上大多數關系型資料庫，適用於開發高性能的輕量級 OLTP 應用（面向前台）。

Proxy方案 ：提供靜態入口以及異構語言的支持，適用於 OLAP 應用（面向後台）以及對分片資料庫進行管理和運維的場景。

混合方案 ：在大型復雜系統中存在面向C端用戶的前台應用，也有面向企業分析的後台應用，這個時候就可以採用混合模式。

JDBC 採用無中心化架構，適用於 Java 開發的高性能的輕量級 OLTP 應用；Proxy 提供靜態入口以及異構語言的支持，適用於 OLAP 應用以及對分片資料庫進行管理和運維的場景。

ShardingSphere是一套開源的分布式資料庫中間件解決方案組成的生態圈，它由 Sharding-JDBC 、 Sharding-Proxy 和 Sharding-Sidecar （計劃中）這3款相互獨立的產品組成，他們均提供標准化的數據分片、分布式事務和資料庫治理功能，可適用於如Java同構、異構語言、容器、雲原生等各種多樣化的應用場景。

ShardingSphere提供的核心功能：

Sharding-Proxy

定位為透明化的 資料庫代理端 ，提供封裝了 資料庫二進制協議的服務端版本 ，用於完成對 異構語言的支持 。

目前已提供MySQL版本，它可以使用 任何兼容MySQL協議的訪問客戶端 (如：MySQL Command Client, MySQL Workbench, Navicat等)操作數據，對DBA更加友好。

向 應用程序完全透明 ，可直接當做MySQL使用。

適用於任何兼容MySQL協議的客戶端。

Sharding-JDBC

定位為 輕量級Java框架 ，在Java的JDBC層提供的額外服務。 它使用客戶端直連資料庫，以jar包形式提供服務，無需額外部署和依賴，可理解為 增強版的JDBC驅動，完全兼容JDBC和各種ORM框架 。

以電商SaaS系統為例，前台應用採用Sharding-JDBC，根據業務場景的差異主要分為三種方案。

分庫（用戶）

問題解析：頭部企業日活高並發高，單獨分庫避免干擾其他企業用戶，用戶數據的增長緩慢可以不分表。

拆分維度：企業ID分庫

拆分策略：頭部企業單獨庫、非頭部企業一個庫

分庫分表（訂單）

問題解析：訂單數據增長速度較快，在分庫之餘需要分表。

拆分維度：企業ID分庫、用戶ID分表

拆分策略：頭部企業單獨庫、非頭部企業一個庫，分庫之後用戶ID取模拆分表

單庫分表（附件）

問題解析：附件數據特點是並發量不大，只需要解決數據增長問題，所以單庫IO足以支撐的情況下分表即可。

拆分維度：用戶ID分表

拆分策略：用戶ID取模分表

問題一：分布式事務

分布式事務過於復雜也是分布式系統最難處理的問題，由於篇幅有限，後續會開篇專講這一塊內容。

問題二：分布式ID

問題三：跨片查詢

舉個例子，以用戶id分片之後，需要根據企業id查詢企業所有用戶信息。

sharding針對跨片查詢也是能夠支持的，本質上sharding的跨片查詢是採用同時查詢多個分片的數據，然後聚合結果返回，這個方式對資源耗費比較大，特別是對資料庫連接資源的消耗。

假設分4個資料庫，8個表，則sharding會同時發出32個SQL去查詢。一下子消耗掉了32個連接；

特別是針對單庫分表的情況要注意，假設單庫分64個表，則要消耗64個連接。如果我們部署了2個節點，這個時候兩個節點同時查詢的話，就會遇到資料庫連接數上限問題（mysql默認100連接數）

問題四：分片擴容

隨著數據增長，每個片區的數據也會達到瓶頸，這個時候需要將原有的分片數量進行增加。由於增加了片區，原先的hash規則也跟著變化，造成了需要將舊數據做遷移。

假設原先1個億的數據，hash分64個表，現在增長到50億的數據，需要擴容到128個表，一旦擴容就需要將這50億的數據做一次遷移，遷移成本是無法想像的。

問題五：一致性哈希

首先，求出每個 伺服器的hash值 ，將其配置到一個 0~2^n 的圓環上 （n通常取32）

其次，用同樣的方法求出待 存儲對象的主鍵 hash值 ，也將其配置到這個圓環上。

然後，從數據映射到的位置開始順時針查找，將數據分布到找到的第一個伺服器節點上。

一致性hash的優點在於加入和刪除節點時只會影響到在哈希環中相鄰的節點，而對其他節點沒有影響。

所以使用一致性哈希在集群擴容過程中可以減少數據的遷移。

好了，這次分享到這里，我們日常的實踐可能只會用到其中一種方案，但它不是資料庫架構的全貌，打開技術視野，才能更好地把存儲工具利用起來。

老規矩，一鍵三連，日入兩千，點贊在看，年薪百萬！

本文作者：Jensen

7年Java老兵，小米主題設計師，手機輸入法設計師，ProcessOn特邀講師。

曾涉獵航空、電信、IoT、垂直電商產品研發，現就職於某知名電商企業。

技術公眾號 【架構師修行錄】 號主，專注於分享日常架構、技術、職場干貨，Java Goals：架構師。

交個朋友，一起成長！

⑷ 企業數據上雲必有一戰，華為雲12.12雲資料庫2折起

每年的Gartner全球資料庫魔力象限都會對未來三年的市場進行預測，而2020年的預測相比於2019年的預測出現一個顯著的變化，那就是全球75%資料庫將被部署或遷移到雲平台的時間表提前了一年——從2023年提前到了2022年。進入2020年底，我們將迎來資料庫行業的世紀之戰，企業數據上雲與治理面臨著重大抉擇：本地資料庫與雲資料庫的PK。特別是受2020全球疫情的影響，越來越多的企業正加速數字化轉型，雲資料庫以及雲上數據治理的時代將很快到來。

2020年12月12日雙十二之際，華為雲打出了雲資料庫2折起的大幅折扣，包括：MySQL等熱門雲資料庫 2折起、遷移上雲再加送6個月；GaussDB系列、數據管理服務DAS企業版等熱銷產品低至5折；數據加速與治理產品中也有Redis 4折的驚喜優惠。2020年又是華為雲推出全場景資料庫雲服務GaussDB的第一年，而在2020年底打出雲資料庫2折起的大力度促銷，彰顯了華為雲開打2021企業數據上雲之戰的決心。

2020年的一場疫情，讓很多企業都將數字化轉型提速，特別是讓本來需要幾年才能下的數字化轉型決心和決定縮短到幾個月；而新基建的推出，更刺激了基於數字技術的融合基礎設施的大規模建設。無論是加速的數字化轉型、急於上線的各種在線和互聯網業務，還是籌建中的融合基礎設施新基建，都為CIO們帶來了頭痛的問題：資料庫的選型。

那麼CIO怎麼解決雲資料庫的選型難題呢？華為雲資料庫業務總裁蘇光牛認為，CIO選型資料庫，最常見的其實沒有變化，就是穩定性和性能，以及雲技術出現之後的擴展性和灰度等能力。但對於很多企業，特別是有 歷史 遺留系統的，都涉及一個古老但無法迴避的問題就是：生態。也就是如果招聘的DBA多是搞PostgreSQL，那麼企業怎麼能選擇MySQL？反之亦然。或者當熟悉某個資料庫的DBA幹了幾十年，又怎麼轉向另外一種資料庫？

轉型是必然的。數字化智能化升級，必然要求資料庫跟上，蘇光牛認為生態必須是開放的，否則就從一個火坑跳入另外一個火坑。選型之後，CIO都普遍擔心，遷移的工作量有多大？CIO都需要有能自動化轉換或者評估的工具，能把非確定的工作量轉化為確定性的計劃。然後就需要考慮遷移是否會中斷或者中斷多久，業務切換需要多久，對於在線遷移來說還要可控制的切換時間；隨之，要考慮數據是否會丟失，因為從一個系統遷移到另一個系統，不可能100%覆蓋所有的功能測試，沒有覆蓋到數據是否就丟失了，當然還要考慮數據安全等問題。

最後，必然要考慮成本以及讓數據「活」起來。蘇光牛認為，控製成本的最好方式是存儲的融合，計算和存儲分離的架構；而讓數據活起來，就是要讓存儲的數據在不同系統之間流動起來，通過大的存儲資源池解決數據孤島問題，當然更好的數據遷移工具也能配合解決問題。

2020年11月，在Gartner發布的2020全球雲資料庫魔力象限中，華為雲憑借GaussDB系列產品首次晉級全球頂級雲資料庫行列。Gartner對華為雲的評價是：華為雲專注於提供全面的混合堆棧，構建了全面、穩健的產品組合，能夠滿足跨雲和本地環境的全方位數據管理用例，其許多產品與雲基礎架構緊密集成，以提供增強的性能和可靠性。Gartner還認為，華為在全球電信和網路行業有很強的影響力，很多為管理華為全球行業業務而構建的數據管理能力，面向政企行業普遍可用。

2020年下半年，華為雲宣布GaussDB資料庫戰略升級為華為雲資料庫全場景服務，以及發布GaussDB雲資料庫服務GaussDB（for MySQL）、GaussDB（openGauss）以及GaussDB NoSQL，而GaussDB NoSQL非關系型資料庫則支持MongoDB、Cassandra、時序InfluxDB、KV資料庫Redis等，具有多模式數據管理能力。

就GaussDB來說，通過計算和存儲分離實現分布式處理，在一套架構下，可以對接MySQL、PostgreSQL、MongoDB、Cassandra等多種開源資料庫引擎，實現這些開源資料庫的良好商用性能。GaussDB以華為雲為底座，保證了良好可擴展性、彈性、安全可靠等性能要求，特別是通過底層統一的智能化DFV分布式存儲架構，滿足企業上雲對於雲資料庫的各種需求。

在數據遷移方面，華為雲推出的資料庫和應用遷移 UGO，是一款專注於異構資料庫對象遷移和應用遷移的專業化工具，而華為雲數據復制服務DRS，支持更大數據量、更長時間等多種復雜遷移場景，支持資料庫上雲和雲上業務數據實時回傳至雲外的混合雲架構。UGO+DRS形成了完整的遷移產品形態。

GaussDB是為政企打造的資料庫一站式上雲解決方案，提供全場景數據管理業務、全開放生態和安全可信，徹底解決政企以及互聯網行業在資料庫選型方面的痛點，真正做到資料庫選型安心、遷移放心、管理省心。

蘇光牛表示：「華為將持續戰略投入資料庫，布局全球7大區域囊括1000+資料庫專家與人才。此次戰略升級是華為雲資料庫積極構建高安全、高可靠、高性能的全場景雲服務，擁抱開源生態的具體舉措，華為雲GaussDB資料庫會持續打造多元生態服務，全方位滿足客戶的需求，加速政企客戶數字化創新發展。」

正如Gartner所觀察到的，如今華為雲資料庫業務在亞太地區，尤其是中國市場實現規模化部署，其中超過一半的客戶來自公共管理、電信、金融保險等行業。華為雲資料庫，特別是GaussDB能夠被廣大政企用戶認可，這首先來自於經歷了華為內部的千錘百煉。從2007年開始，就因為華為的無線、網路、交換機等產品而發展起來了GaussDB，從2009年開始基於存算分離的架構而考慮分布式資料庫的設計，2015年起基於廣泛認知的生態如MySQL或者PostgreSQL等以及NoSQL資料庫，逐步推出了分布式的資料庫，同時還打造華為自己的openGauss生態。

2020年，華為雲資料庫品牌更加清晰，GaussDB是華為自有資料庫品牌，既兼容MySQL、PostgreSQL等廣泛認知的生態，又有自有的生態openGauss，openGauss於2020年6月正式對外開源。蘇光牛強調，華為公司將長期投入GaussDB的開發，基於混合雲和公有雲的方式，聯合ISV等夥伴一起，全方位服務好客戶。

總結下來，GaussDB有四大特色：第一，開放的生態，擁抱開源生態的同時，打造華為自有生態。華為雲認為未來一定是開放的生態，開放的生態才能保護客戶投資，避免從一個封閉體系走向另外一個封閉體系。

第二，存算分離的架構，資料庫的穩定性是第一位的，特別是交易型資料庫，華為雲資料庫最核心的特色是存儲的穩定性。華為雲GaussDB基於與企業存儲相同的分布式存儲架構，經過千行百業的磨煉而不僅僅是單一的某種交易流量，另外各種存儲能力如重刪、壓縮、跨AZ等特性讓快速備份恢復、性價比都具備非常好的優勢。

第三，安全合規，GaussDB經過了ICSL的安全認證，以及很多白盒的代碼層面的認證。特別是隨著歐洲GDPR等標準的實施，以及政企對數據安全性要求的增加，華為雲GaussDB的代碼級、架構級別安全設計，以及多年來在電信級高標准行業的錘煉，經歷了很多實際客戶的嚴苛考驗，讓政企在使用資料庫的時候更加放心。

第四，軟硬體全棧協同。華為雲具備軟硬體全棧研發的實力，無論存儲底座和RDMA高速網路，還是虛擬化和容器之上的性能調優，以及GuestOS上的協議棧優化，特別是基於雲技術之後的全棧優化和雲服務能力，更加是華為雲的優勢。

當然，更為重要的是，雲資料庫採用雲的模式實現了資料庫運維管理的集中化，極大簡化了資料庫的安裝、部署、配置、遷移和優化，大幅提升運維管理效率，讓政企可以投入更多精力聚焦在核心業務創新上。

總結而言： 企業數據上雲和雲上數據治理將成為2021年政企數字化轉型的重中之重，各大技術廠商都在爭奪雲資料庫市場份額。以華為雲全場景資料庫GaussDB為代表的新一代雲資料庫，將滿足政企數字化轉型的全面需求。特別是以華為雲和華為雲Stack為底座，GaussDB可以跨公有雲以及企業本地部署，其技術符合雲及企業本地的要求，同時具有華為雲的高性能、高可用、高安全等保證，可以說政企數字化轉型的全場景保障！（文/寧川）