htap資料庫
PostgreSQL的穩定性極強，Innodb等索引在崩潰，斷電之類的災難場景下 抗擊打能力有了長足進步，然而很多 MqSQL用戶 都遇到過 Server級的資料庫丟失的場景 -- MySQL系統庫是 MyISAM，相比之下，PG資料庫這方面要更好一些。
任何系統都有它的性能極限，在高並發讀寫，負載逼近極限下，PG的性能指標仍可以位置雙曲線甚至對數曲線，到 頂峰之後不在下降，而MySQL明顯出現一個波峰後下滑（5.5版本 之後，在企業級版本中有個插件可以改善很多，不過需要付費）。
PG多年來在 GIS（地理信息）領域處於優勢地位，因為它有豐富的幾何類型，PG有大量字典，數組，bitmap等數據類型，相比之下 MySQL就差很多， Instagram就是因為 PG的空間資料庫 擴展 POSTGIS遠遠強於 MySQL的 my spatial 而採用 PgSQL的。
PG的「無鎖定」特性非常突出，甚至包括 vacuum這樣的整理數據空間的操作，這個和PGSQL的MVCC實現有關系。
PG可以使用函數 和 條件索引，這使得 PG資料庫的調優非常靈活， MySQL就沒有這個功能，條件索引在 web應用中 很重要。
PG有極其強悍的 SQL編程能力（9.x 圖靈完備，支持遞歸！），有非常豐富的統計函數和統計語法支持，比如分析函數（Oracle的叫法，PG里叫Window函數），還可以用多種語言來寫存儲過程，對於 R的支持也很好。這一點MySQL就差很多，很多分析功能都不支持，騰訊內部的存儲主要是 MySQL，但是數據分析主要是 Hadoop+ PgSQL。
PG的有多種集群架構可以選擇，plproxy可以之hi語句級的鏡像或分片，slony可以進行欄位級的同步配置，standby 可以構建 WAL文件級或流式的讀寫分離集群，同步頻率和集群策略調整方便。
一般關系型資料庫字元串有長度限制 8k 左右，無限長 TEXT類型的功能受限，只能作為外部大數據訪問。而 PG 的 TEXT 類型 可以直接訪問且無長度限制， SQL語法內置 正則表達式，可以索引，還可以全文檢索，或使用 xml xpath。用 PG的話，文檔資料庫都可以省了。
PgSQL對於 numa 架構的支持比 MySQL強一些，比 MySQL對於讀的性能更好一些， PgSQL提交可以完全非同步提交，而 MySQL的內存表不夠實用（因為表鎖的原因）。
pgsql除了存儲正常的數據類型外，還支持存儲
array，不管是一維數組還是多維數組均支持。
json和jsonb，相比使用 text存儲要高效很多。
json和 jsonb在更高的層面上看起來幾乎是一樣的，但是存儲實現上是不同的。
json存儲完的文本，json列會每次都解析存儲的值，它不支持索引，但 可以為創建表達式索引。
jsonb存儲的二進制格式，避免了重新解析數據結構。它支持索引，這意味著 可以不使用指定索引就能查詢任何路徑。
當我們比較寫入數據速度時，由於數據存儲 的方式的原因，jsonb會比 json 稍微的慢一點。json列會每次都 解析存儲的值，這意味著鍵的順序要和輸入的 時候一樣。但是 jsonb不同，以二進制格式存儲且不保證鍵的順序。因此如果有軟體需要依賴鍵的順序，jsonb可能不是最佳選擇。使用 jsonb的優勢還在於可以輕易的整合關系型數據和非關系型 數據 ，PostgreSQL對於 mongodb這類資料庫是一個不小的威脅，畢竟如果一個表中只有一列數據的類型是半結構化的，沒有必要為了遷就它而整個表的設計都採用 schemaless的結構。
1. CPU限制
PGSQL
沒有CPU核心數限制，有多少CPU核就用多少
MySQL
能用128核CPU，超過128核用不上
2. 配置文件參數
PGSQL
一共有255個參數，用到的大概是80個，參數比較穩定，用上個大版本配置文件也可以啟動當前大版本資料庫
MySQL
一共有707個參數，用到的大概是180個，參數不斷增加，就算小版本也會增加參數，大版本之間會有部分參數不兼容情況
3. 第三方工具依賴情況
PGSQL
只有高可用集群需要依靠第三方中間件，例如：patroni+etcd、repmgr
MySQL
大部分操作都要依靠percona公司的第三方工具（percona-toolkit，XtraBackup），工具命令太多，學習成本高，高可用集群也需要第三方中間件，官方MGR集群還沒成熟
4. 高可用主從復制底層原理
PGSQL
物理流復制，屬於物理復制，跟SQL Server鏡像/AlwaysOn一樣，嚴格一致，沒有任何可能導致不一致，性能和可靠性上，物理復制完勝邏輯復制，維護簡單
MySQL
主從復制，屬於邏輯復制，（sql_log_bin、binlog_format等參數設置不正確都會導致主從不一致）
大事務並行復制效率低，對於重要業務，需要依賴 percona-toolkit的pt-table-checksum和pt-table-sync工具定期比較和修復主從一致
主從復制出錯嚴重時候需要重搭主從
MySQL的邏輯復制並不阻止兩個不一致的資料庫建立復制關系
5. 從庫只讀狀態
PGSQL
系統自動設置從庫默認只讀，不需要人工介入，維護簡單
MySQL
從庫需要手動設置參數super_read_only=on，讓從庫設置為只讀，super_read_only參數有bug，鏈接：https://jiahao..com/s?id=1636644783594388753&wfr=spider&for=pc
6. 版本分支
PGSQL
只有社區版，沒有其他任何分支版本，PGSQL官方統一開發，統一維護，社區版有所有功能，不像SQL Server和MySQL有標准版、企業版、經典版、社區版、開發版、web版之分
國內外還有一些基於PGSQL做二次開發的資料庫廠商，例如：Enterprise DB、瀚高資料庫等等，當然這些只是二次開發並不算獨立分支
MySQL
由於歷史原因，分裂為三個分支版本，MariaDB分支、Percona分支 、Oracle官方分支，發展到目前為止各個分支基本互相不兼容
Oracle官方分支還有版本之分，分為標准版、企業版、經典版、社區版
7. SQL特性支持
PGSQL
SQL特性支持情況支持94種，SQL語法支持最完善，例如：支持公用表表達式（WITH查詢）
MySQL
SQL特性支持情況支持36種，SQL語法支持比較弱，例如：不支持公用表表達式（WITH查詢）
關於SQL特性支持情況的對比，可以參考：http://www.sql-workbench.net/dbms_comparison.html
8. 主從復制安全性
PGSQL
同步流復制、強同步（remote apply)、高安全，不會丟數據
PGSQL同步流復制：所有從庫宕機，主庫會罷工，主庫無法自動切換為非同步流復制（非同步模式），需要通過增加從庫數量來解決，一般生產環境至少有兩個從庫
手動解決：在PG主庫修改參數synchronous_standby_names =''，並執行命令： pgctl reload ，把主庫切換為非同步模式
主從數據完全一致是高可用切換的第一前提，所以PGSQL選擇主庫罷工也是可以理解
MySQL
增強半同步復制 ，mysql5.7版本增強半同步才能保證主從復制時候不丟數據
mysql5.7半同步復制相關參數：
參數rpl_semi_sync_master_wait_for_slave_count 等待至少多少個從庫接收到binlog，主庫才提交事務，一般設置為1，性能最高
參數rpl_semi_sync_master_timeout 等待多少毫秒，從庫無回應自動切換為非同步模式，一般設置為無限大，不讓主庫自動切換為非同步模式
所有從庫宕機，主庫會罷工，因為無法收到任何從庫的應答包
手動解決：在MySQL主庫修改參數rpl_semi_sync_master_wait_for_slave_count=0
9. 多欄位統計信息
PGSQL
支持多欄位統計信息
MySQL
不支持多欄位統計信息
10. 索引類型
PGSQL
多種索引類型（btree , hash , gin , gist , sp-gist , brin , bloom , rum , zombodb , bitmap，部分索引，表達式索引）
MySQL
btree 索引，全文索引（低效），表達式索引(需要建虛擬列)，hash 索引只在內存表
11. 物理表連接演算法
PGSQL
支持 nested-loop join 、hash join 、merge join
MySQL
只支持 nested-loop join
12. 子查詢和視圖性能
PGSQL
子查詢，視圖優化，性能比較高
MySQL
視圖謂詞條件下推限制多，子查詢上拉限制多
13. 執行計劃即時編譯
PGSQL
支持 JIT 執行計劃即時編譯，使用LLVM編譯器
MySQL
不支持執行計劃即時編譯
14. 並行查詢
PGSQL
並行查詢（多種並行查詢優化方法），並行查詢一般多見於商業資料庫，是重量級功能
MySQL
有限，只支持主鍵並行查詢
15. 物化視圖
PGSQL
支持物化視圖
MySQL
不支持物化視圖
16. 插件功能
PGSQL
支持插件功能，可以豐富PGSQL的功能，GIS地理插件，時序資料庫插件， 向量化執行插件等等
MySQL
不支持插件功能
17. check約束
PGSQL
支持check約束
MySQL
不支持check約束，可以寫check約束，但存儲引擎會忽略它的作用，因此check約束並不起作用（mariadb 支持）
18. gpu 加速SQL
PGSQL
可以使用gpu 加速SQL的執行速度
MySQL
不支持gpu 加速SQL 的執行速度
19. 數據類型
PGSQL
數據類型豐富，如 ltree，hstore，數組類型，ip類型，text類型，有了text類型不再需要varchar，text類型欄位最大存儲1GB
MySQL
數據類型不夠豐富
20. 跨庫查詢
PGSQL
不支持跨庫查詢，這個跟Oracle 12C以前一樣
MySQL
可以跨庫查詢
21. 備份還原
PGSQL
備份還原非常簡單，時點還原操作比SQL Server還要簡單，完整備份+wal歸檔備份（增量）
假如有一個三節點的PGSQL主從集群，可以隨便在其中一個節點做完整備份和wal歸檔備份
MySQL
備份還原相對不太簡單，完整備份+binlog備份（增量）
完整備份需要percona的XtraBackup工具做物理備份，MySQL本身不支持物理備份
時點還原操作步驟繁瑣復雜
22. 性能視圖
PGSQL
需要安裝pg_stat_statements插件，pg_stat_statements插件提供了豐富的性能視圖：如：等待事件，系統統計信息等
不好的地方是，安裝插件需要重啟資料庫，並且需要收集性能信息的資料庫需要執行一個命令：create extension pg_stat_statements命令
否則不會收集任何性能信息，比較麻煩
MySQL
自帶PS庫，默認很多功能沒有打開，而且打開PS庫的性能視圖功能對性能有影響（如：內存佔用導致OOM bug）
23. 安裝方式
PGSQL
有各個平台的包rpm包，deb包等等，相比MySQL缺少了二進制包，一般用源碼編譯安裝，安裝時間會長一些，執行命令多一些
MySQL
有各個平台的包rpm包，deb包等等，源碼編譯安裝、二進制包安裝，一般用二進制包安裝，方便快捷
24. DDL操作
PGSQL
加欄位、可變長欄位類型長度改大不會鎖表，所有的DDL操作都不需要藉助第三方工具，並且跟商業資料庫一樣，DDL操作可以回滾，保證事務一致性
MySQL
由於大部分DDL操作都會鎖表，例如加欄位、可變長欄位類型長度改大，所以需要藉助percona-toolkit裡面的pt-online-schema-change工具去完成操作
將影響減少到最低，特別是對大表進行DDL操作
DDL操作不能回滾
25. 大版本發布速度
PGSQL
PGSQL每年一個大版本發布，大版本發布的第二年就可以上生產環境，版本迭代速度很快
PGSQL 9.6正式版推出時間：2016年
PGSQL 10 正式版推出時間：2017年
PGSQL 11 正式版推出時間：2018年
PGSQL 12 正式版推出時間：2019年
MySQL
MySQL的大版本發布一般是2年~3年，一般大版本發布後的第二年才可以上生產環境，避免有坑，版本發布速度比較慢
MySQL5.5正式版推出時間：2010年
MySQL5.6正式版推出時間：2013年
MySQL5.7正式版推出時間：2015年
MySQL8.0正式版推出時間：2018年
26. returning語法
PGSQL
支持returning語法，returning clause 支持 DML 返回 Resultset，減少一次 Client <-> DB Server 交互
MySQL
不支持returning語法
27. 內部架構
PGSQL
多進程架構，並發連接數不能太多，跟Oracle一樣，既然跟Oracle一樣，那麼很多優化方法也是相通的，例如：開啟大頁內存
MySQL
多線程架構，雖然多線程架構，但是官方有限制連接數，原因是系統的並發度是有限的，線程數太多，反而系統的處理能力下降，隨著連接數上升，反而性能下降
一般同時只能處理200 ~300個資料庫連接
28. 聚集索引
PGSQL
不支持聚集索引，PGSQL本身的MVCC的實現機制所導致
MySQL
支持聚集索引
29. 空閑事務終結功能
PGSQL
通過設置 idle_in_transaction_session_timeout 參數來終止空閑事務，比如：應用代碼中忘記關閉已開啟的事務，PGSQL會自動查殺這種類型的會話事務
MySQL
不支持終止空閑事務功能
30. 應付超大數據量
PGSQL
不能應付超大數據量，由於PGSQL本身的MVCC設計問題，需要垃圾回收，只能期待後面的大版本做優化
MySQL
不能應付超大數據量，MySQL自身架構的問題
31. 分布式演進
PGSQL
HTAP資料庫：cockroachDB、騰訊Tbase
分片集群： Postgres-XC、Postgres-XL
MySQL
HTAP資料庫：TiDB
分片集群： 各種各樣的中間件，不一一列舉
32. 資料庫的文件名和命名規律
PGSQL
PGSQL在這方面做的比較不好，DBA不能在操作系統層面（停庫狀態下）看清楚資料庫的文件名和命名規律，文件的數量，文件的大小
一旦操作系統發生文件丟失或硬碟損壞，非常不利於恢復，因為連名字都不知道
PGSQL表數據物理文件的命名/存放規律是： 在一個表空間下面，如果沒有建表空間默認在默認表空間也就是base文件夾下，例如：/data/base/16454/3599
base：默認表空間pg_default所在的物理文件夾
16454：表所在資料庫的oid
3599：就是表對象的oid，當然，一個表的大小超出1GB之後會再生成多個物理文件，還有表的fsm文件和vm文件，所以一個大表實際會有多個物理文件
由於PGSQL的數據文件布局內容太多，大家可以查閱相關資料
當然這也不能全怪PGSQL，作為一個DBA，時刻做好資料庫備份和容災才是正道，做介質恢復一般是萬不得已的情況下才會做
MySQL
資料庫名就是文件夾名，資料庫文件夾下就是表數據文件，但是要注意表名和資料庫名不能有特殊字元或使用中文名，每個表都有對應的frm文件和ibd文件，存儲元數據和表/索引數據，清晰明了，做介質恢復或者表空間傳輸都很方便
33. 許可權設計
PGSQL
PGSQL在許可權設計這塊是比較坑爹，拋開實例許可權和表空間許可權，PGSQL的許可權層次有點像SQL Server，db=》schema=》object
要說許可權，這里要說一下Oracle，用Oracle來類比
在ORACLE 12C之前，實例與資料庫是一對一，也就是說一個實例只能有一個資料庫，不像MySQL和SQL Server一個實例可以有多個資料庫，並且可以隨意跨庫查詢
而PGSQL不能跨庫查詢的原因也是這樣，PGSQL允許建多個資料庫，跟ORACLE類比就是有多個實例（之前說的實例與資料庫是一對一）
一個資料庫相當於一個實例，因為PGSQL允許有多個實例，所以PGSQL單實例不叫一個實例，叫集簇（cluster），集簇這個概念可以查閱PGSQL的相關資料
PGSQL裡面一個實例/資料庫下面的schema相當於資料庫，所以這個schema的概念對應MySQL的database
注意點：正因為是一個資料庫相當於一個實例，PGSQL允許有多個實例/資料庫，所以資料庫之間是互相邏輯隔離的，導致的問題是，不能一次對一個PGSQL集簇下面的所有資料庫做操作
必須要逐個逐個資料庫去操作，例如上面說到的安裝pg_stat_statements插件，如果您需要在PGSQL集簇下面的所有資料庫都做性能收集的話，需要逐個資料庫去執行載入命令
又例如跨庫查詢需要dblink插件或fdw插件，兩個資料庫之間做查詢相當於兩個實例之間做查詢，已經跨越了實例了，所以需要dblink插件或fdw插件，所以道理非常簡單
許可權操作也是一樣逐個資料庫去操作，還有一個就是PGSQL雖然像SQL Server的許可權層次結構db=》schema=》object，但是實際會比SQL Server要復雜一些，還有就是新建的表還要另外授權
在PGSQL裡面，角色和用戶是一樣的，對新手用戶來說有時候會傻傻分不清，也不知道怎麼去用角色，所以PGSQL在許可權設計這一塊確實比較坑爹
MySQL
使用mysql庫下面的5個許可權表去做許可權映射，簡單清晰，唯一問題是缺少許可權角色
user表
db表
host表
tables_priv表
columns_priv表
1. 架構對比
Mysql：多線程
PostgreSql：多進程
多線程架構和多進程架構之間沒有絕對的好壞，例如oracle在unix上是多進程架構，在windows上是多線程架構。
2. 對存儲過程及事務的支持能力
MySql對於無事務的MyISAM表，採用表鎖定，一個長時間運行的查詢很可能會長時間的阻礙，而PostgreSQL不會尊在這種問題。
PostgreSQL支持存儲過程，要比MySql好，具備本地緩存執行計劃的能力。
3. 穩定性及性能
高並發讀寫，負載逼近極限下，PG的性能指標仍可以維持雙曲線甚至對數曲線，到頂峰之後不再下降，而 MySql 明顯出現一個波峰後下滑（5.5版本後Mysql企業版有優化，需要付費）
MySql的InnoDB引擎，可以充分優化利用系統的所有內存，超大內存下PG對內存使用的不那麼充分（需要根據內存情況合理分配）。
4. 高可用
InnoDB的基於回滾實現的 MVCC 機制，對於 PG 新老數據一起放的基於 XID 的 MVCC機制，是占優的。新老數據一起存放，需要定時觸發 VACUUM，會帶來多餘的 IO 和資料庫對象加鎖開銷，引起資料庫整理的並發能力下降。而且 VACUUM 清理不及時，還可能會引發數據膨脹
5. 數據同步方式：
Mysql到現在也是非同步復制，pgsql可以做到同步、非同步、半同步復制。
Mysql同步是基於binlog復制，屬於邏輯復制，類似於oracle golden gate，是基於stream的復制，做到同步很困難，這種方式更加適合非同步復制；
Pgsql的同是基於wal，屬於物理復制，可以做到同步復制。同時，pgsql還提供stream復制。
Mysql的復制可以用多級從庫，但是在9.2之前，PgSql不能用從庫帶從庫。
Pgsql的主從復制屬於物理復制，相對於Mysql基於binlog的邏輯復制，數據的一致性更加可靠，復制性能更高，對主機性能的影響也更小。
6. 許可權控制對比
MySql允許自定義一套不同的數據級、表級和列的許可權，運行指定基於主機的許可權
Mysql的merge表提供了 一個獨特管理多個表的方法。myisampack可以對只讀表進行壓縮，以後仍然可以直接訪問該表中的行。
7. SQL語句支持能力
PG有極其強悍的 SQL 編程能力（9.x 圖靈完備，支持遞歸！），有非常豐富的統計函數和統計語法支持，例如分析函數（Oracle的叫法，PG里叫window函數）
支持用多種語言來寫存儲過程，對於R的支持也很好。這一點上Mysql就差的很遠，很多分析功能都不支持。
PgSql對表名大小寫的處理，只有在Sql語句中，表明加雙引號，才區分大小寫。
在Sql的標准實現上要比Mysql完善，而且功能實現比較嚴謹。
對表連接支持比較完整，優化器的功能比較完整，支持的索引類型很多，復雜查詢能力較強。
Mysql採用索引組織表，這種存儲方式非常適合基於主鍵匹配的查詢、刪改操作，但是對表結果設計存在約束；
Mysql的Join操作的性能非常的差，只支持Nest Join，所以一旦數據量大，性能就非常的差。PostgresSQL除了支持 Nest Join 和 Sort Merge Join，PostgreSQL還支持正則表達式查詢，MySql不支持。
8. 數據類型支持能力
PostgreSQL可以更方便的使用UDF（用戶定義函數）進行擴展。
有豐富的幾何類型，實際上不止集合類型，PG有大量的字典、數組、bitmap等數據類型，因此PG多年來在 GIS 領域處於優勢地位。相比之下Mysql就差很多，instagram就是因為PG的空間數據擴展 PostGIS遠遠強於 MySql的 my spatial 而採用 PgSql的。Mysql中的空間數據類型有4種，分別是 CEOMETRY、POINT、LINESTRING、POLYGON，其空間索引只能在存儲引擎為 MyiSam的表中創建，用SPATIAL關鍵字進行擴展，使得能夠用於創建正規索引類型的語法創建空間索引。創建空間索引的列，必須將其聲明為NOT NULL。不同的存儲親情有差別。MyISAM和InnoDB 都支持 spatial extensions，但差別在於：如果使用MyISAM，可以建立 spatial index，而 InnoDB是不支持的。
pgsql對json支持比較好，還有很逆天的fdw功能，就是把別的資料庫中的表當自己的用。
pgsql的欄位類型支持的多，有很多mysql沒有的類型，但是實際中有時候用到。
一半關系型資料庫的字元串長度8k左右，無限長的 TEXT 類型的功能受限，只能作為外部帶數據訪問。而 PG 的 TEXT 類型可以直接訪問，SQL 語法內置正則表達式，可以索引，還可以全文檢索，或使用 xml xpath。用 PG 的話，文檔資料庫都可以省了。
postgresql 有函數，用於報表、統計很方便
PG支持 R-Trees這樣可擴展的索引類型，可以方便的處理一些特殊數據。
PG可以使用函數和條件所以，使得資料庫的調優非常靈活，mysql就沒有這個功能，條件索引在web應用中很重要。
9. 如可過程容錯能力
大批量數據入庫，PostgreSql要求所有的數據必須完全滿足要求，有一條錯誤，整個數據入庫過程失敗。MySql無此問題。
10. 表組織方式
pgsql用繼承的方式實現分區表，讓分區表的使用不方便且性能差，這點比不上mysql。
pg主表採用堆表存放，MySQL採用索引組織表，能夠支持比MySql更大的數據量。
MySql分區表的實現要優於PG的基於繼承表的分區實現，主要體現在分區個數達到成千上萬後的處理性能差異很大。
11. 開發結構
對於web應用來所，mysql 5.6 的內置 MC API 功能很好用，PgSQL差一些。
PG的「無鎖定」特性非常突出，甚至包括 vacuum 這樣的整理數據空間的操作，這個和 PGSQL的 MVCC 實現有關系。
好文要頂 關注我 收藏該文
茄子777
粉絲 - 0 關注 - 0
+加關注
00
« 上一篇： 多線程中的wait與join
» 下一篇： 負載均衡相關
posted @ 2022-11-02 16:20 茄子777 閱讀(55) 評論(0) 編輯 收藏 舉報
刷新評論刷新頁面返回頂部
登錄後才能查看或發表評論，立即 登錄 或者 逛逛 博客園首頁
【推薦】阿里雲新人特惠，爆款雲伺服器2核4G低至0.46元/天
【推薦】雙十一同價！騰訊雲雲伺服器搶先購，低至4.2元/月
編輯推薦：
· 一個有趣的 nginx HTTP 400 響應問題分析
· 誰說.NET沒有GC調優？只改一行代碼就讓程序不再佔用內存
· 為什麼標准庫的模板變數都是 inline 的
· .net 如何優雅的使用 EFCore
· 在 C# 中使用 Halcon 開發視覺檢測程序
閱讀排行：
· Entity Framework Core 7中高效地進行批量數據插入
· 除了 filter 還有什麼置灰網站的方式？
· 快速繪制流程圖「GitHub 熱點速覽 v.22.47」
· 使用.NET7和C#11打造最快的序列化程序-以MemoryPack為例
· 私藏！資深數據專家SQL效率優化技巧 ⛵
❷ 它用分布式資料庫替代Oracle、SAS，讓銀行告別西方軟體「霸凌」
WPS成功上市代表了信息化企業軟體國產化的趨勢。在雷濤看來，WPS不是簡單復制後替代Windows office，而是找到了下一代產品需求。
以往無論是運營商還是銀行核心系統，大架構都壟斷在西方的 IOE（IBM、Oracle、EMC）這三座大山裡。直到2008年阿里提出去「IOE」運動，開始助推信息化軟體國產化浪潮。
天雲數據就是其中最早一批入場者。2010年為了建立中國完整的雲計算產業鏈，中國寬頻之父田溯寧投資建設雲基地昌燃，天雲數據便由此孵化，初備雛形。
2015年，雷濤帶領創始團隊們正式成立天雲數據，率先切入金融領域。天雲提供了國內領先的國產HTAP資料庫Hubble，完成了「去IOE」中最困難的部分，替代金融A類核心系統慣用的西方IOE架構，在銀行的聯機事務中解決A類核心系統減負問題。此外，為了降低AI使用門檻，天雲數據還推出AI PaaS平台MaximAI，逐步將數據價值逐漸擴展到能源、醫葯、軍事等其它行業。
目前天雲數據有70多家行業內大企業客戶，單筆合同200-500萬，純軟體年營收過億。
融資方面，天雲數據2018年曾獲得曦域資本、華映資本B輪1億人民幣投資。
作為行業老兵，雷濤在北美跨國公司有20多年的技術管理經驗， 2005年便入席SNIA存儲游槐工業協會中國區技術委員會聯合主席，CCF中國計算機學會大數據專委會委員。
2011年在雲基地時期，雷濤和創始團隊通過BDP大數據平台負責了眾多運營商業務，如聯通的數據魔方、移動總部、南方基地等，2015年天雲數據正式獨立後，雷濤為了避免同業競爭，選擇先聚焦在金融領域。
「天雲數據的目標是替代 Oracle 和 SAS 」。雲基地時期的積累讓天雲數據一開始就有高起點，首單就接下了光大銀行的核心系統——OLTP線交易系統。比如銀行能在全國所有營業廳實時實現OOTD交易，實時查詢存錢取錢數額，整個環節涉及的技術都是天雲數據早期對Oracle的一些替代。
但之後在多次的項目操作過程中雷濤發現，在幾百萬條交易規格的強一致性下，數據的移動性、計算框架的變化、聯機事務同時要做大規模並行計算，這對計算場景的神迅友通用性、即時性和全量數據要求極高，傳統 Oracle架構根本無法適應。
「在Oracle架構之上，還需要升級滿足新需求」。
於是天雲數據自主研發HTAP國產分布式資料庫Hubble。與傳統 IT 架構處理失誤需要聯機分析和分開處理不同，HTAP 資料庫能夠在一份數據上同時支撐業務系統運行並做 OLAP 場景，避免在線與離線資料庫之間大量的數據交互，為系統減負。
HTAP國產分布式資料庫Hubble替代了Oracle一體機,核心表2000餘張80T左右、400億條交易數據、提供56隻服務應用交易、滿足500個用戶並發、500ms交易服務響應、每天在線交易量超200萬、占整個銀行核心交易量的10%，讓銀行面向櫃面系統可提供7*8小時A類實時核心交易，面向手機網銀系統可提供7*24小時A類實時核心交易。
從集中式Oracle切換到分布式HTAP，也解決了資料庫擴展性的問題。比如天雲數據讓光大銀行解決了 歷史 數據查詢問題，以往 歷史 查詢只能查到2年前，但在分布式技術上線後，可以查詢15年前所有交易數據，同時讓銀行櫃面系統以及手機APP可以無數人同時查詢。
而在BI逐步轉向AI的過程中，復雜的商業流程經演算法重構。過去要把數據拿到SAS平台先分析，一層一層地把數據提出來搭建。但現在通過分布式技術，流程趨於扁平化，可以實現毫秒級的服務響應。
天雲數據一開始就撬動的是行業頭部資源。目前天雲數據有光大銀行、興業銀行、中信銀行、中泰證券、中國石油、國家統計局等70餘家行業內大企業客戶，分布在金融、能源、醫葯、政府軍事等領域，單筆合同級別超百萬
針對每個垂直行業，天雲數據都會成立一個子公司來專注賽道。目前天雲數據有160人，技術人員超六成。
在雷濤看來，如果一年600個項目，全是5萬、15萬等碎片化的訂單，公司總是重復滿足初級客戶的簡單需求，技術很難沉澱和深入。「在當下成長階段，打造產品需要在用戶想要什麼和你想做什麼中找到平衡」。
對於雷濤而言，專注頭部大B發展有兩大發展潛力。一方面，大B擁有機器學習的普遍能力和實驗室，更容易接受新產品。另一方面，天雲數據交付產品和交付服務的同時也在轉移大B客戶的數據價值。
「AI本身是一個知識生產過程，它能把大型企業規則、流程的經驗價值快速地抽樣出來進行復制，賦能行業內其它客戶甚至類似的其它行業。」
但在頭部客戶更定製化、個性化的情況下，天雲數據是否失去了很強的復制能力？
雷濤解釋到，雖然每個企業要求不盡相同，但都在不大的池子里找資料庫。企業從海量數據中對數據進行遷徙、清洗、去重，可以去找合適的AI方法讓它產生業務的價值，此過程具有通用性。
談到核心壁壘，雷濤認為天雲數據壁壘就是數據的復制價值。
壁壘的構建可分為兩個階段。第一個階段是前沿 科技 本身的壁壘，比的是效率和產品核心價值，誰能夠扎得深和更好的交付，誰就能拔得頭籌。而作為國內最早研發大數據和人工智慧的團隊，天雲數據有一定的技術先發優勢。
第二個階段是推理端的服務。數據資源的價值需要通過機器學習進行提煉，形成知識，進而封裝成推理服務服務於行業。比如某保險公司20年長周期發生的重疾賠付定價上學習出來的特徵和內容能夠快速地移植到保險行業，而頭部大企業客戶給天雲數據帶來很優質的訓練資料庫。
未來AI將引爆萬億級大市場，但目前滲透率不到1%，這給各企業留有眾多機會和想像空間。但無論哪種圈地方式，最終比的是速度、服務的穩定性以及產品化的能力。
❸ 新一代HTAP資料庫崛起，MySQL生態的最佳歸宿
俗話說，天下大勢，合久必分、分久必合。
資料庫領域同樣如此。過去五十餘年，資料庫經歷OLTP和OLAP兩種需求漫長的融合-分離-再融合的過程。究其原因，資料庫的發展始終與用戶場景需求變遷緊密相關。如今，隨著雲計算和大數據的興起，業務場景正在經歷前所未有的變革，資料庫領域也掀起了一股HTAP浪潮。
Gartner在多次報告中強調，HTAP是資料庫領域最重要的發展趨勢之一，也是用戶數字化轉型中重要的數據平台。業界甚至認為，HTAP的興起代表著資料庫大融合時代的開啟。
那麼，為什麼資料庫大廠和雲服務巨頭們均紛紛押寶HTAP？開源+多雲為何是HTAP普及的助推劑？面對新一代HTAP數據的崛起，多年積累形成的MySQL生態終於找到最佳歸宿？
放在幾年前，HTAP可能還會被認為是資料庫領域的小眾產品，是否成氣候還有待觀察。
而隨著數據資源、數據消費習慣和數據驅動型場景發生巨大變化，用戶需求與傳統資料庫之間的供需矛盾日漸突出，使得HTAP這種具備「同時支持OLTP和OLAP、創新計算存儲框架、去ETL」等特徵的新時代資料庫成為不可阻擋的趨勢。
如今，幾乎所有資料庫大廠和雲服務巨頭都在布局HTAP。例如，OceanBase去年推出的 3.0版本中就正式宣布向HTAP資料庫進軍；今年5月，Google Cloud發布HTAP雲端資料庫AlloyDB，為PG用戶提供了HTAP資料庫服務；再加上Oracle MySQL Heatwave，甚至連SnowFlake也發布Unistore來「蹭」HTAP的熱點。
如果細數近一年以來的HTAP新品，會發現幾乎全部都建立在雲端之上。新一代HTAP+雲正在成為資料庫市場重要的潮流。例如，PingCAP近日發布的TiDB 6.0，也是與雲端緊密聯系的新一代HTAP資料庫。
事實上，PingCAP是HTAP資料庫領域非常重要的一個引領者。早在TiDB 3.0起，PingCAP就正式轉向HTAP，從OLTP主引擎+OLAP輔助能力，到OLTP引擎+外接分析引擎，再到OLTP引擎+融合分析引擎，PingCAP在HTAP領域穩打穩扎，一個版本上一個台階。
如今，隨著TiDB 6.0的發布，針對HTAP進行了更多成熟性改進，TPC-C 性能也較 5.0 版本提升達到 76.32%，TiDB 6.0還增強了多個企業級特性，以更好適合雲時代用戶對於HTAP資料庫的需求。
固然，有人質疑當前HTAP是新瓶裝舊酒，並無太多新意。但業界普遍形成共識：新一代HTAP與過去完全不同，開源+雲孕育而出，很多都有AI加持，而且是為數據敏捷而生，擁有過去前所未有的創新活力與迭代速度，並逐漸形成資料庫技術變革的新潮流。
PingCAP CTO 黃東旭也直言：「TiDB近年來的快速進化與迭代，得益於開源和雲的助力。」
HTAP之所受到用戶青睞，某種程度是因為用戶對於數據敏捷性的極度渴求。
「在數字化時代，客戶最為在乎的是如何快速走向市場。這需要數據敏捷性，而HTAP恰恰是數據敏捷的核心能力。」黃東旭如是說。
最近幾年，「海量、實時、在線」的需求越來越廣泛，大量採用 MySQL 和 PostgreSQL 開源資料庫的新一代企業需要提升對於熱數據的實時在線分析能力，這類需求遍布幾乎所有的互聯網企業以及從事線上業務的數字化轉型企業。對於新鮮數據的實時分析能力直接決定了這些業務的生死存亡，傳統的 OLTP+OLAP+ETL 的數據架構已經嚴重阻礙了消費者體驗，這種訴求催生了 HTAP 的技術變革。
而真正幫助HTAP與用戶需求完成對接的則是開源+雲。眾所周知，開源近年來在資料庫領域的流行和影響力與日俱增，DB-Engines數據顯示，全球383款資料庫中開源資料庫占據51.7%，六款開源資料庫進入到前十，開源正在成為像HTAP這種新時代資料庫的創新源泉。
以PingCAP的TiDB為例，其產品研發體系建立在開源體系和開源社區的基礎上，實現了一年一個大版本、一個月一個小版本的迭代速度。黃東旭透露道：「開源是TiDB的第一個增長引擎，通過開源體系，開發者、貢獻者、佈道者和用戶能夠很好串聯起來，形成飛輪效應，讓產品能夠走向加速迭代和創新的正向循環。」
據悉，TiDB每年會有超過 40% 的代碼更新，而這些代碼有很大一部分由外部貢獻者所共享。TiDB開源項目一直在全球和中國開源項目活躍度中名列前茅。
如果說開源改變了HTAP產品的開發模式和迭代速度，那麼雲則能夠為HTAP產品提供用戶最為直接的需求反饋。眾所周知，雲資料庫一改以往傳統資料庫部署、運維、擴展等難題，以雲服務的方式讓資料庫使用更加簡單；更加關鍵的是，隨著雲計算的普及，雲上用戶群體持續增加，來自雲上用戶群體的需求反饋無時無刻都在發生，對於資料庫產品的進化與迭代至關重要。
「真正的產品迭代是如何縮短用戶問題/需求的反饋時間。雲無疑為資料庫等基礎軟體提供了這樣的價值，讓產品可以更好地迭代。」黃東旭如是說。以TiDB為例，自去年五月全託管的資料庫即服務（DBaaS）產品 TiDB Cloud 公測版發布以來，已經陸續登陸亞馬遜雲 科技 、谷歌雲等全球知名雲服務商的Marketplace，並在今年5月份正式全球商用；今年 6 月與阿里雲合作上線阿里雲雲市場，成為為數不多的跨全球三朵雲的資料庫服務。
在眾多資料庫產品之中，MySQL憑借著開源、免費、適合互聯網場景等優勢，常年位居全球最受歡迎資料庫的前三。根據Slintel網站的統計數據，在全球關系型資料庫市場中，MySQL市場份額最高，達到43.04%。
過去二十年裡，開源MySQL資料庫對於各行各業影響至深，捕獲了來自互聯網、金融、零售、交通等多個行業用戶的心，堪稱「萬人迷」。例如，在中國就有超過9成的金融機構都應用了MySQL資料庫。
但任何資料庫潮流都是「需求變化+技術變革+架構創新」融合的產物，MySQL是如此，HTAP亦不例外。如今，場景的數據規模、業務並發量、處理速度要求跟以往相比早已不是一個數量級。此時，MySQL資料庫的局限性愈發突出，擴展性很難滿足用戶需求，想繼續獲得增長的企業不得不使用分庫分表方案，但這又會造成數據架構的復雜性。
新一代HTAP資料庫無需分庫分表，且具備實時海量規模的OLTP和實時數據分析能力，還擁有極為出色的擴展性，與很多業務場景的海量交易實時數據展現、平穩運行的需求高度契合，HTAP憑借技術架構優勢崛起已成必然。
「用戶需求側最大的變化就是很多用戶需要藉助熱數據實現運營級別的實時分析，獲得實時洞察以支持決策，這極大推動了新一代HTAP資料庫的需求。」PingCAP副總裁劉松補充道。
雖然MySQL已經增加列存引擎Heatwave來獲得HTAP能力，但主要解決規模化查詢的問題，系統本身架構並未產生革命性變化，擴展能力、OLTP吞吐量依然有著很大局限。「智能新能源 汽車 跟傳統燃油車在外表看幾乎沒區別。資料庫也類似，像TiDB這種新一代HTAP資料庫，從架構設計、應對場景和使用體驗等角度，都與傳統資料庫有著極大的區別。」劉松形象比喻道。
事實上，與過去SAP HANA這種小眾、昂貴的HTAP不同，新一代HTAP擁有極強的兼容性，像Google Cloud、PingCAP這些資料庫廠商都藉助新一代HTAP架構為採用 MySQL或者PG開源資料庫的企業拓展 OLTP和OLAP的能力范圍。
例如，Google Cloud發布的HTAP雲端資料庫AlloyDB，為單機版PG生態用戶提供了最好選擇，TiDB則成為MySQL生態的最佳歸宿。PingCAP大量用戶中有很多TiDB與MySQL混合部署的成功案例；得益於 TiDB 的開放性，TiDB 也可通過和其他數據服務產品「混搭」形成新的數據服務解決方案， 如通過同樣是開源的大數據計算引擎 Flink 混搭形成實時數倉解決方案，擴展 HTAP 資料庫的能力邊界。
黃東旭則直言，HTAP資料庫除了產品、技術之外，尤為需要關心用戶體驗，「HTAP應該讓用戶覺得好用，屏蔽掉資料庫的復雜性。」據悉，PingCAP是2022 Gartner Peer Insights「Voice of the Customer」 雲資料庫領域唯一入選的中國資料庫公司，客戶總體評分達到 4.7 分（滿分 5 分），在所有入選企業中位列第一。在參與Gartner Peer Insights評分的PingCAP用戶中，像互聯網、金融等重點行業用戶均高度認可HTAP現代資料庫理念。
總體來看，今年是HTAP的大年，各大廠商紛紛在市場中上新。隨著新一代HTAP資料庫產品的增多，整個市場對於HTAP資料庫理念和產品的接受與採用將會提速。而隨著新一代HTAP資料庫持續完善，讓廣大MySQL生態用戶群真正看到了大數據時代一條絕佳的遷移路徑。
❹ 華為突破分布式資料庫和存儲技術，打通數字化轉型「雄關漫道」
2019年，我們將進入數字化轉型的攻關期。所謂「攻關期」即數字化轉型2.0階段，需要攻堅企業關鍵業務上雲和數字化轉型改造的課題。在一份市場調查公司IDC的報告中指出：IDC自2014年提出數字化轉型以來，看到企業在數字化轉型層面已經投入了大量人力物力，但是效果並不理想，有一些企業已經成功屹立在潮頭，有一些企業在向上游進發，還有一些企業只能在浪潮的挾裹中被動前行。
對於企業來說，數字化轉型是「雄關漫道」。IDC認為，目前階段來看，企業亟待解決的是數字化能力提升，包括：與業務的深入結合能力；數據處理和挖掘能力；以及IT技術運營和管理能力。特別是數據處理和挖掘能力，因為數字化轉型推進企業從以流程為核心向以數據為核心轉型，對海量、異構、多類型的數據處理和挖掘能力是釋放數據價值的前提，對數據全生命周期的管控治理是釋放數據價值的保障。而隨著數字化轉型引入大量新技術而導致IT復雜度變高，企業IT技術運營和管理能力是提升企業「IT生產力」的關鍵。
攻關數字化轉型的「雄關漫道」，需要一個具備融合、智能、可傳承三大特性的數字平台。這是2019年3月華為與IDC聯合推出的《擁抱變化，智勝未來—數字平台破局企業數字化轉型》白皮書所提出的觀點。融合主要指把傳統技術和創新技術相結合；智能主要指平台智能化和智能化能力輸出；可傳承主要指解耦、功能復用、可配置等理念打造的架構。而承載這三大觀點的，就是新一代分布式企業級技術。
2019年5月15日，華為發布了業界首款支持ARM架構的新一代智能分布式資料庫GaussDB以及分布式存儲FusionStorage 8.0，作為新一代數據基礎設施，詮釋了具備融合、智能、可傳承三大特性的數字平台。華為常務董事、ICT戰略與Marketing總裁汪濤在發布會上表示，千行百業正在加速智能化進程，越來越多的企業已經意識到數據基礎設施是智能化成功的關鍵。華為圍繞計算、存儲和數據處理三個領域重定義數據基礎設施，加速邁向智能時代。
今天所討論雲和工業互聯網等概念的背後是一個新時代的到來，這就是體系架構大遷徙。傳統企業級技術是在單體應用和單機環境中，保證數據存儲、調用等操作的高可靠、高可用、高穩定，特別是滿足金融級事物處理的ACID（原子性、一致性、隔離性和耐久性）要求，為企業關鍵業務提供數據管理支撐。隨著企業技術向雲架構遷移，資料庫技術也面臨轉型。
2018年，基於雲計算技術的分布式資料庫成為了業界的熱點。簡單理解，雲計算技術就是把「單機」環境替換為由X86伺服器機群所組成的分布式計算環境。原先由幾台小型機完成的計算任務，要分散到上百甚至上千台X86伺服器上，而且還可能跨數據中心操作，挑戰可想而之。特別是在線支付等金融級業務，不能在斷網或網路連接有問題時出錯，也不能因響應速度慢而影響用戶體驗。
2018年8月，中國支付清算協會與中國信息通信研究院聯合舉辦了「金融分布式事務資料庫研討會」，與業界廠商和用戶共商核心資料庫分布式轉型之路，同時發布了《金融分布式事務資料庫》白皮書。金融分布式事務資料庫的工作推進，為分布式資料庫進入企業關鍵業務系統，提供了產業化支撐。而華為作為企業ICT解決方案供應商，早在2012年就開始研發面向大數據分析的數據倉庫，在基於傳統關系型資料庫SQL引擎和事務強一致性等基礎上，進行了分布式、並行計算的改造，歷時6年打造了面向PB級海量數據分析的分布式資料庫。
在OLAP數據倉庫之外，華為與行業用戶合作了面向OLTP的分布式事務型資料庫研發。2017年，華為與招商銀行合作成立了分布式資料庫聯合創新實驗室，研發具有高性能企業級內核、完整支持分布式事物、滿足金融行業對數據強一致要求、單機事物處理能力要達到每分鍾百萬級別等的OLTP分布式資料庫。
本次發布的GaussDB資料庫新品包括：聯機事務處理OLTP資料庫、聯機分析處理OLAP資料庫、事務和分析混合處理HTAP資料庫。而華為GaussDB資料庫將AI技術融入資料庫設計、開發、驗證、調優、運維等環節，可實現基於AI的自調優、自診斷自愈、自運維，讓資料庫更高效、更智能，引領資料庫架構的發展。
更進一步，本次發布的GaussDB系列資料庫是業界首款支持ARM晶元的分布式資料庫。華為推動計算架構從以X86+GPU為主的單一計算架構到以X86+GPU+ARM64+NPU為主的異構計算架構快速發展。基於X86架構，華為引入AI管理和智能加速能力，率先推出了智能伺服器FusionServer Pro；基於ARM64打造了業界性能最強的TaiShan伺服器；基於Ascend晶元的Atlas智能計算，實現了業界首個端邊雲協同的人工智慧平台。而GaussDB可充分利用並融合ARM、X86、GPU、NPU等多種異構算力組合，大幅提升資料庫性能。
汪濤強調，作為全球首款AI-Native資料庫，GaussDB有兩大革命性突破：第一，首次將人工智慧技術引入資料庫的全生命周期流程，實現自運維、自管理、自調優和故障自診斷。在交易、分析和混合負載場景下，基於最優化理論，首創深度強化學習自調優演算法，把業界平均性能提升60%。第二，支持異構計算，充分發揮X86/ARM/GPU/NPU多樣性算力優勢，最大化資料庫性能，在權威標准測試集TPC-DS上，華為GaussDB排名第一。GaussDB還支持本地部署、私有雲、公有雲等多種場景。
在以雲計算為代表的分布式計算環境中，數據管理解決方案除了需要分布式資料庫外，為了更好的擴縮容以及滿足多樣化數據存儲需求，計算與存儲分離已經成為分布式資料庫設計的主要架構。分布式雲化架構，就是要支持計算、存儲分離和多租戶等架構設計要求。
GaussDB已經從資料庫層面實現了高可用、高可靠、高穩定的分布式資料庫，本次發布的FusionStorage 8.0則是分布式存儲架構，創新地實現一套系統同時支持塊、文件、對象、HDFS協議，1套存儲支持4類存儲能力，適用於全業務場景混合負載，最終讓「一個數據中心一套存儲」成為可能。
IDC發布的《中國軟體定義存儲（SDS）及超融合存儲（HCI）系統市場季度跟蹤報告，2018年第四季度》顯示，2018年，軟體定義存儲市場達到了54.9%的同比增長。軟體定義存儲在中國整體存儲市場的佔有率穩步上升，分別達到了22.1%的市場佔有率。華為憑借文件解決方案在政府、廣電和電信等行業得到認可，在2018年中國軟體定義存儲市場排名第一。
FusionStorage 8.0採用華為ARM-based處理器鯤鵬920加速，使IOPS提升 20%，結合華為AI Fabric無損網路，時延進一步降低15%。基於華為在計算、網路和存儲領域多年的晶元和演算法積累，FusionStorage 8.0在SPC-1的性能測試中，單節點性能達到了16.8萬IOPS以及1ms以內時延，成為承載企業關鍵應用的新選擇。
此外，通過華為雲的雲上訓練及本地AI晶元，FusionStorage 8.0將智能管理貫穿業務使用的全生命周期，如業務上線前對存儲資源的規劃，使用過程中的風險預判及故障定位，大幅提升存儲效率，幫助行業客戶應對智能時代的數據新挑戰。
汪濤在發布會上強調，新一代智能分布式存儲FusionStorage 8.0通過重定義存儲架構，從「Storage for AI」和「AI in Storage」兩個維度實現效率大幅提升，引領存儲智能化。首先，「Storage for AI」通過融合共享，讓AI分析更高效。其次，「AI in Storage」率先將AI融入存儲全生命周期管理，從資源規劃、業務發放、系統調優、風險預測、故障定位等方面實現智能運維。
遼寧移動就採用了華為FusionStorage。作為遼寧省內最大的移動通信運營商，遼寧移動一直在 探索 先進的存儲方案在自身IT系統的應用。由於5G的快速發展，遼寧移動關鍵資料庫的應用也向雲化方向發展，分布式存儲也要滿足其可靠性和高性能要求。華為在深入分析遼寧移動需求後，首先在邊緣開發測試業務小規模試點分布式存儲，進行了大量的實驗和測試後性能和可靠性都達到了預期，最終決定將全部業務遷移至FusionStorage。該方案通過採用雙活、可寫快照、端到端DIF等特性，順利完成Billing、經營分析、B2B等系統從老舊存儲至FusionStorage的搬遷工作，助力遼寧移動的存儲架構邁入新的 歷史 階段。
值得一提的是，華為分布式資料庫與華為分布式存儲深度結合，把資料庫的操作下沉到存儲節點，極大提升了分布式資料庫的性能。利用新的網路技術和人工智慧技術，華為幫助用戶提升數據中心的吞吐量，提升網路應用的可伸縮性，並且能自動調優。
除了推出新一代突破性的分布式資料庫和存儲技術外，華為也積極與客戶、夥伴在資料庫與存儲領域，從行業應用、平台工具、標准組織和社區等多個層面共建開放、合作、共贏的產業生態。在行業應用層面，華為與軟通智慧、神州信息、東華軟體、易華錄、用友政務、亞信國際等獨立軟體開發商長期合作；在平台和工具層面，華為與Tableau、帆軟、ARM、Veritas等合作夥伴聯合創新；在標准組織和社區層面，華為深度參與OpenSDS、中國人工智慧產業聯盟、OCP、OpenStack、CNCF基金會等組織和社區的建設。
總結來說，華為全線分布式資料庫和分布式存儲產品的發布，是華為具備融合、智能、可傳承三大特性數字平台的最新成果。華為分布式資料庫與分布式存儲結合，能消除企業各業務系統數據孤島，構建面向行業場景的數據建模、分析和價值挖掘能力，對多源異構的數據進行匯聚、整合和分析，形成統一的全量數據和數據底座，實現數據價值挖掘和共享。而基於AI的智能化，可對基礎設施進行高效的管理，為行業應用開發和迭代賦能，全面幫助企業突破關鍵應用上雲的「雄關漫道」。（文/寧川）