❶ 2019數據架構選型必讀：1月資料庫產品技術解析
本期目錄
DB-Engines資料庫排行榜
新聞快訊
一、RDBMS家族
二、Nosql家族
三、NewSQL家族
四、時間序列
五、大數據生態圈
六、國產資料庫概覽
七、雲資料庫
八、推出dbaplus Newsletter的想法
九、感謝名單
為方便閱讀、重點呈現，本期Newsletter（2019年1月）將對各個板塊的內容進行精簡。需要閱讀全文的同學可點擊文末 【閱讀原文】 或登錄https://pan..com/s/13BgipbaHeMfvm0YPtiYviA
DB-Engines資料庫排行榜
以下取自2019年1月的數據，具體信息可以參考http://db-engines.com/en/ranking/，數據僅供參考。
DB-Engines排名的數據依據5個不同的因素：
新聞快訊
1、2018年9月24日，微軟公布了SQL Server2019預覽版，SQL Server 2019將結合Spark創建統一數據平台。
2、2018年10月5日，ElasticSearch在美國紐約證券交易所上市。
3、亞馬遜放棄甲骨文資料庫軟體，導致最大倉庫之一在黃金時段宕機。受此消息影響，亞馬遜盤前股價小幅跳水，跌超2%。
4、2018年10月31日，Percona發布了Percona Server 8.0 RC版本，發布對MongoDB 4.0的支持，發布對XtraBackup測試第二個版本。
5、2018年10月31日，Gartner陸續發布了2018年的資料庫系列報告，包括《資料庫魔力象限》、《資料庫核心能力》以及《資料庫推薦報告》。
今年的總上榜資料庫產品達到了5家，分別來自：阿里雲，華為，巨杉資料庫，騰訊雲，星環 科技 。其中阿里雲和巨杉資料庫已經連續兩年入選。
6、2018年11月初，Neo4j宣布完成E輪8000萬美元融資。11月15日，Neo4j宣布企業版徹底閉源：
7、2019年1月8日，阿里巴巴以1.033億美元（9000萬歐元）的價格收購了Apache Flink商業公司DataArtisans。
8、2019年1月11日早間消息，亞馬遜宣布推出雲資料庫軟體，亞馬遜和MongoDB將會直接競爭。
RDBMS家族
Oracle 發布18.3版本
2018年7月，Oracle Database 18.3通用版開始提供下載。我們可以將Oracle Database 18c視為採用之前發布模式的Oracle Database 12c第2版的第一個補丁集。未來，客戶將不再需要等待多年才能用上最新版Oracle資料庫，而是每年都可以期待新資料庫特性和增強。Database 19c將於2019年Q1率先在Oracle cloud上發布雲版本。
Oracle Database 18c及19c部分關鍵功能：
1、性能
2、多租戶，大量功能增強及改進，大幅節省成本和提高敏捷性
3、高可用
4、數據倉庫和大數據
MySQL發布8.0.13版本
1、賬戶管理
經過配置，修改密碼時，必須帶上原密碼。在之前的版本，用戶登錄之後，就可以修改自己的密碼。這種方式存在一定安全風險。比如用戶登錄上資料庫後，中途離開一段時間，那麼非法用戶可能會修改密碼。由參數password_require_current控制。
2、配置
Innodb表必須有主鍵。在用戶沒有指定主鍵時，系統會生成一個默認的主鍵。但是在主從復制的場景下，默認的主鍵，會對叢庫應用速度帶來致命的影響。如果設置sql_require_primary_key，那麼資料庫會強制用戶在創建表、修改表時，加上主鍵。
3、欄位默認值
BLOB、TEXT、GEOMETRY和JSON欄位可以指定默認值了。
4、優化器
1）Skip Scan
非前綴索引也可以用了。
之前的版本，任何沒有帶上f1欄位的查詢，都沒法使用索引。在新的版本中，它可以忽略前面的欄位，讓這個查詢使用到索引。其實現原理就是把(f1 = 1 AND f2 > 40) 和(f1 = 2 AND f2 > 40)的查詢結果合並。
2）函數索引
之前版本只能基於某個列或者多個列加索引，但是不允許在上面做計算，如今這個限制消除了。
5、SQL語法
GROUP BY ASC和GROUP BY DESC語法已經被廢棄，要想達到類似的效果，請使用GROUP BY ORDER BY ASC和GROUP BY ORDER BY DESC。
6、功能變化
1）設置用戶變數，請使用SET語句
如下類型語句將要被廢棄SELECT @var, @var:=@var+1。
2）新增innodb_fsync_threshold
該變數是控制文件刷新到磁碟的速率，防止磁碟在短時間內飽和。
3）新增會話級臨時表空間
在以往的版本中，當執行SQL時，產生的臨時表都在全局表空間ibtmp1中，及時執行結束，臨時表被釋放，空間不會被回收。新版本中，會為session從臨時表空間池中分配一個臨時表空間，當連接斷開時，臨時表空間的磁碟空間被回收。
4）在線切換Group Replication的狀態
5）新增了group_replication_member_expel_timeout
之前，如果某個節點被懷疑有問題，在5秒檢測期結束之後，那麼就直接被驅逐出這個集群。即使該節點恢復正常時，也不會再被加入集群。那麼，瞬時的故障，會把某些節點驅逐出集群。
group_replication_member_expel_timeout讓管理員能更好的依據自身的場景，做出最合適的配置（建議配置時間小於一個小時）。
MariaDB 10.3版本功能展示
1、MariaDB 10.3支持update多表ORDER BY and LIMIT
1）update連表更新，limit語句
update t1 join t2 on t1.id=t2.id set t1.name='hechunyang' limit 3;
MySQL 8.0直接報錯
MariaDB 10.3更新成功
2）update連表更新，ORDER BY and LIMIT語句
update t1 join t2 on t1.id=t2.id set t1.name='HEchunyang' order by t1.id DESC limit 3;
MySQL 8.0直接報錯
MariaDB 10.3更新成功
參考：
https://jira.mariadb.org/browse/MDEV-13911
2、MariaDB10.3增補AliSQL補丁——安全執行Online DDL
Online DDL從名字上看很容易誤導新手，以為不論什麼情況，修改表結構都不會鎖表，理想很豐滿，現實很骨感，注意這個坑！
有以下兩種情況執行DDL操作會鎖表的，Waiting for table metadata lock（元數據表鎖）：
針對第二種情況，MariaDB10.3增補AliSQL補丁-DDL FAST FAIL，讓其DDL操作快速失敗。
例：
如果線上有某個慢SQL對該表進行操作，可以使用WAIT n（以秒為單位設置等待）或NOWAIT在語句中顯式設置鎖等待超時，在這種情況下，如果無法獲取鎖，語句將立即失敗。 WAIT 0相當於NOWAIT。
參考：
https://jira.mariadb.org/browse/MDEV-11388
3、MariaDB Window Functions窗口函數分組取TOP N記錄
窗口函數在MariaDB10.2版本里實現，其簡化了復雜SQL的撰寫，提高了可讀性。
參考：
https://mariadb.com/kb/en/library/window-functions-overview/
Percona Server發布8.0 GA版本
2018年12月21日，Percona發布了Percona Server 8.0 GA版本。
在支持MySQL8.0社區的基礎版上，Percona Server for MySQL 8.0版本中帶來了許多新功能：
1、安全性和合規性
2、性能和可擴展性
3、可觀察性和可用性
Percona Server for MySQL 8.0中將要被廢用功能：
Percona Server for MySQL 8.0中刪除的功能：
RocksDB發布V5.17.2版本
2018年10月24日，RocksDB發布V5.17.2版本。
RocksDB是Facebook在LevelDB基礎上用C++寫的高效內嵌式K/V存儲引擎。相比LevelDB，RocksDB提供了Column-Family，TTL，Transaction，Merge等方面的支持。目前MyRocks，TiKV等底層的存儲都是基於RocksDB來構建。
PostgreSQL發布11版本
2018年10月18日，PostgreSQL 11發布。
1、PostgreSQL 11的重大增強
2、PostgreSQL 插件動態
1）分布式插件citus發布 8.1
citus是PostgreSQL的一款sharding插件，目前國內蘇寧、鐵總、探探有較大量使用案例。
https://github.com/citusdata/citus
2）地理信息插件postgis發布2.5.1
PostGIS是專業的時空資料庫插件，在測繪、航天、氣象、地震、國土資源、地圖等時空專業領域應用廣泛。同時在互聯網行業也得到了對GIS有性能、功能深度要求的客戶青睞，比如共享出行、外賣等客戶。
http://postgis.net/
3）時序插件timescale發布1.1.1
timescale是PostgreSQL的一款時序資料庫插件，在IoT行業中有非常好的應用。github star數目前有5000多，是一個非常火爆的插件。
https://github.com/timescale/timescaledb
4）流計算插件 pipelinedb 正式插件化
Pipelinedb是PostgreSQL的一款流計算插件，使用這個創建可以對高速寫入的數據進行實時根據定義的聚合規則進行聚合（支持概率計算），實時根據定義的規則觸發事件（支持事件處理函數的自定義）。可用於IoT，監控，FEED實時計算等場景。
https://github.com/pipelinedb/pipelinedb
3、PostgreSQL衍生開源產品動態
1）agensgraph發布 2.0.0版本
agensgraph是兼容PostgreSQL、opencypher的專業圖資料庫，適合圖式關系的管理。
https://github.com/bitnine-oss/agensgraph
2）gpdb發布5.15
gpdb是兼容PostgreSQL的mpp資料庫，適合OLAP場景。近兩年，gpdb一直在追趕PostgreSQL的社區版本，預計很快會追上10的PostgreSQL，在TP方面的性能也會得到顯著提升。
https://github.com/greenplum-db/gpdb
3）antdb發布3.2
antdb是以Postgres-XC為基礎開發的一款PostgreSQL sharding資料庫，亞信主導開發，開源，目前主要服務於亞信自有客戶。
https://github.com/ADBSQL/AntDB
4）遷移工具MTK發布52版本
MTK是EDB提供的可以將Oracle、PostgreSQL、MySQL、MSSQL、Sybase資料庫遷移到PostgreSQL, PPAS的產品，遷移速度可以達到100萬行/s以上。
https://github.com/digoal/blog/blob/master/201812/20181226_01.md
DB2發布 11.1.4.4版本
DB2最新發布Mod Pack 4 and Fix Pack 4，包含以下幾方面的改動及增強：
1、性能
2、高可用
3、管理視圖
4、應用開發方面
5、聯邦功能
6、pureScale
NoSQL家族
Redis發布5.0.3版本
MongoDB升級更新MongoDB Mobile和MongoDB Stitch
2018年11月21日，MongoDB升級更新MongoDB Mobile和MongoDB Stitch，助力開發人員提升工作效率。
MongoDB 公司日前發布了多項新產品功能，旨在更好地幫助開發人員在世界各地管理數據。通過利用存儲在移動設備和後台資料庫的數據之間的實時、自動的同步特性，MongoDB Mobile通用版本助力開發人員構建更快捷、反應更迅速的應用程序。此前，這只能通過在移動應用內部安裝一個可供選擇或限定功能的資料庫來實現。
MongoDB Mobile在為客戶提供隨處運行的自由度方面更進了一步。用戶在iOS和安卓終端設備上可擁有MongoDB所有功能，將網路邊界擴展到其物聯網資產范疇。應用系統還可以使用MongoDB Stitch的軟體開發包訪問移動客戶端或後台數據，幫助開發人員通過他們希望的任意方式查詢移動終端數據和物聯網數據，包括本地讀寫、本地JSON存儲、索引和聚合。通過Stitch移動同步功能(現可提供beta版)，用戶可以自動對保存在本地的數據以及後台資料庫的數據進行同步。
本期新秀：Cassandra發布3.11.3版本
2018年8月11日，Cassandra發布正式版3.11.3。
Apache Cassandra是一款開源分布式NoSQL資料庫系統，使用了基於Google BigTable的數據模型，與面向行(row)的傳統關系型資料庫或鍵值存儲key-value資料庫不同，Cassandra使用的是寬列存儲模型(Wide Column Stores)。與BigTable和其模仿者HBase不同，數據並不存儲在分布式文件系統如GFS或HDFS中，而是直接存於本地。
Cassandra的系統架構與Amazon DynamoDB類似，是基於一致性哈希的完全P2P架構，每行數據通過哈希來決定應該存在哪個或哪些節點中。集群沒有master的概念，所有節點都是同樣的角色，徹底避免了整個系統的單點問題導致的不穩定性，集群間的狀態同步通過Gossip協議來進行P2P的通信。
3.11.3版本的一些bug fix和改進：
NewSQL家族
TiDB 發布2.1.2版本
2018 年 12 月 22 日，TiDB 發布 2.1.2 版，TiDB-Ansible 相應發布 2.1.2 版本。該版本在 2.1.1 版的基礎上，對系統兼容性、穩定性做出了改進。
TiDB 是一款定位於在線事務處理/在線分析處理（ HTAP: Hybrid Transactional/Analytical Processing）的融合型資料庫產品。除了底層的 RocksDB 存儲引擎之外，分布式SQL層、分布式KV存儲引擎（TiKV）完全自主設計和研發。
TiDB 完全開源，兼容MySQL協議和語法，可以簡單理解為一個可以無限水平擴展的MySQL，並且提供分布式事務、跨節點 JOIN、吞吐和存儲容量水平擴展、故障自恢復、高可用等優異的特性；對業務沒有任何侵入性，簡化開發，利於維護和平滑遷移。
TiDB：
PD：
TiKV：
Tools：
1）TiDB-Lightning
2）TiDB-Binlog
EsgynDB發布R2.5版本
2018年12月22日，EsgynDB R2.5版本正式發布。
作為企業級產品，EsgynDB 2.5向前邁進了一大步，它擁有以下功能和改進：
CockroachDB發布2.1版本
2018年10月30日，CockroachDB正式發布2.1版本，其新增特性如下：
新增企業級特性：
新增SQL特性：
新增內核特性：
Admin UI增強：
時間序列
本期新秀：TimescaleDB發布1.0版本
10月底，TimescaleDB 1.0宣布正式推出，官方表示該版本已可用於生產環境，支持完整SQL和擴展。
TimescaleDB是基於PostgreSQL資料庫開發的一款時序資料庫，以插件化的形式打包提供，隨著PostgreSQL的版本升級而升級，不會因為另立分支帶來麻煩。
TimescaleDB架構：
數據自動按時間和空間分片(chunk)
更新亮點：
https://github.com/timescale/timescaledb/releases/tag/1.0.0
大數據生態圈
Hadoop發布2.9.2版本
2018年11月中旬，Hadoop在2.9分支上發布了新的2.9.2版本，該版本進行了204個大大小小的變更，主要變更如下：
Greenplum 發布5.15版本
Greenplum最新的5.15版本中發布了流式數據載入工具。
該版本中的Greenplum Streem Server組件已經集成了Kafka流式載入功能，並通過了Confluent官方的集成認證，其支持的主要功能如下：
國產資料庫概覽
K-DB發布資料庫一體機版
2018年11月7日，K-DB發布了資料庫一體機版。該版本更新情況如下：
OceanBase遷移服務發布1.0版本
1月4日，OceanBase 正式發布OMS遷移服務1.0版本。
以下內容包含 OceanBase 遷移服務的重要特性和功能：
SequoiaDB發布3.0.1新版本
1、架構
1）完整計算存儲分離架構，兼容MySQL協議、語法
計算存儲分離體系以松耦合的方式將計算與存儲層分別部署，通過標准介面或插件對各個模塊和組件進行無縫替換，在計算層與存儲層均可實現自由的彈性伸縮。
SequoiaDB巨杉資料庫「計算-存儲分離」架構詳細示意
用戶可以根據自身業務特徵選擇面向交易的SQL解析器（例如MySQL或PGSQL）或面向統計分析的執行引擎（例如SparkSQL）。眾所周知，使用不同的SQL優化與執行方式，資料庫的訪問性能可能會存在上千上萬倍的差距。計算存儲分離的核心思想便是在數據存儲層面進行一體化存儲，在計算層面則利用每種執行引擎的特點針對不同業務場景進行選擇和優化，用戶可以在存儲層進行邏輯與物理的隔離，將面向高頻交易的前端業務與面向高吞吐量的統計分析使用不同的硬體進行存儲，確保在多類型數據訪問時互不幹擾，以真正達到生產環境可用的多租戶與HTAP能力。
2、其他更新信息
1）介面變更：
2）主要特性：
雲資料庫
本期新秀：騰訊發布資料庫CynosDB，開啟公測
1、News
1）騰訊雲資料庫MySQL2018年重大更新：
2）騰訊雲資料庫MongoDB2018年重大更新：
3）騰訊雲資料庫Redis/CKV+2018年重大更新：
4）騰訊雲資料庫CTSDB2018年重大更新：
2、Redis 4.0集群版商業化上線
2018年10月，騰訊雲資料庫Redis 4.0集群版完成邀測、公測、商業化三個迭代，在廣州、上海、北京正式全量商業化上線。
產品特性：
使用場景：
官網文檔：
https://cloud.tencent.com/document/proct/239/18336
3、騰訊自研資料庫CynosDB發布，開啟公測
2018年11月22日，騰訊雲召開新一代自研資料庫CynosDB發布會，業界第一款全面兼容市面上兩大最主流的開源資料庫MySQL和PostgreSQL的高性能企業級分布式雲資料庫。
本期新秀：京東雲DRDS發布1.0版本
12月24日，京東雲分布式關系型資料庫DRDS正式發布1.0版本。
DRDS是京東雲精心自研的資料庫中間件產品，獲得了2018年 」可信雲技術創新獎」。DRDS可實現海量數據下的自動分庫分表，具有高性能，分布式，彈性升級，兼容MySQL等優點，適用於高並發、大規模數據的在線交易， 歷史 數據查詢，自動數據分片等業務場景，歷經多次618，雙十一的考驗，已經在京東集團內大規模使用。
京東雲DRDS產品有以下主要特性
1）自動分庫分表
通過簡單的定義即可自動實現分庫分表，將數據實際存放在多個MySQL實例的資料庫中，但呈現給應用程序的依舊是一張表，對業務透明，應用程序幾乎無需改動，實現了對資料庫存儲和處理能力的水平擴展。
2）分布式架構
基於分布式架構的集群方案，多個對等節點同時對外提供服務，不但可有效規避服務的單點故障，而且更加容易擴展。
3）超強性能
具有極高的處理能力，雙節點即可支持數萬QPS，滿足用戶超大規模處理能力的需求。
4）兼容MySQL
兼容絕大部分MySQL語法，包括MySQL語法、數據類型、索引、常用函數、排序、關聯等DDL，DML語句，使用成本低。
參考鏈接：
https://www.jdcloud.com/cn/procts/drds
RadonDB發布1.0.3版本
2018年12月26日，MyNewSQL領域的RadonDB雲資料庫發布1.0.3版本。
推出dbaplus Newsletter的想法
dbaplus Newsletter旨在向廣大技術愛好者提供資料庫行業的最新技術發展趨勢，為社區的技術發展提供一個統一的發聲平台。為此，我們策劃了RDBMS、NoSQL、NewSQL、時間序列、大數據生態圈、國產資料庫、雲資料庫等幾個版塊。
我們不以商業宣傳為目的，不接受任何商業廣告宣傳，嚴格審查信息源的可信度和准確性，力爭為大家提供一個純凈的技術學習環境，歡迎大家監督指正。
至於Newsletter發布的周期，目前計劃是每三個月左右會做一次跟進， 下期計劃時間是2019年4月14日~4月25日， 如果有相關的信息提供請發送至郵箱：[email protected]
感謝名單
最後要感謝那些提供寶貴信息和建議的專家朋友，排名不分先後。
往期回顧：
↓↓別忘了點這里下載 2019年1月 完整版Newsletter 哦~
❷ 對話阿里雲李飛飛：關於雲原生資料庫的五大預判
作者：王慧賢
數據存儲、數據分析、數據安全......如今，圍繞「數據」的話題越來越多，離人們的生活也越來越近。
從陌生到熟悉，數據不僅「出圈」，甚至已然站在了C位。去年，中央發布的《關於構建更加完善的要素市場化配置體制機制的意見》中明確表示，繼土地、勞動力、資本、技術後，數據成為第五大生產要素。
步入信息化時代後，資料庫、操作系統與中間件作為計算機最基礎的三大軟體，支撐著企業的正常運行。
當數據成為生產要素後，必然會迎來爆發式增長，企業的數據存儲和處理需求將進一步釋放。更重要的是，疫情加快了數字化轉型的腳步，更加速了企業的上雲速度。
從信息化到數字化，時代的變革，總會帶來商業世界的變化。如何在雲原生架構下使用資料庫，成為企業的痛點和雲廠商的機會，亞馬遜AWS的CTO Werner Vogels曾多次強調：「資料庫是雲計算的終極之戰。」
在數智化時代，雲原生到底意味著什麼？雲原生資料庫和傳統資料庫相比，核心優勢是什麼？是否把資料庫搬上雲就是雲原生？基於這些問題，雷鋒網與阿里巴巴集團副總裁、阿里雲資料庫產品事業部負責人李飛飛展開一場對話。
國產雲原生資料庫，擺脫「切膚之痛」
如今，資料庫的商業世界，因為雲的出現與發展，分成了兩大派系。
一派是以Oracle為代表的傳統商用資料庫，一派是以國外AWS、國內阿里雲為代表的雲原生資料庫，去「IOE革命」下的產物。
其實，早期較為火熱的資料庫種類有三種，層次式資料庫、網路式資料庫和關系型資料庫。
在《浪潮之巔》一書中，作者吳軍寫下了這樣的觀點：「Oracle 的興起很大程度上靠的是它最早看到關系型資料庫的市場前景，並且在商業模式上優於 IBM。」
因此，在雲原生資料庫「入世」之前，資料庫的天下一直是Oracle的，國內大部分互聯網公司都不得不採用Oracle+IBM小型機+EMC的模式來維持正常運營。
高昂的費用，使得對於資料庫需求較大的互聯網巨頭「忍無可忍」。
2009年，阿里巴巴的Oracle RAC 集群節點數達到了創記錄的20個。可由於Oracle並沒有彈性擴展的功能，只能按照峰值流量購買小型機和資料庫，導致阿里將業務上漲帶來的大部分利潤，都支付給了Oracle。
第二年，阿里便開始走上了去「IOE」之路，根據開源MySQL搭建了AliSQL，並順利經過了淘寶雙11的考驗，國產雲原生資料庫算是正式擺脫了「切膚之痛」，逐漸受到市場的真正認可。
另一邊，國外的AWS在2015年公布了基於雲計算的自研資料庫Amazon Aurora。Aurora是一個關系型資料庫，可以跨3個可用區域復制6份數據，其最大的特性就是高性能和高可用性。
雲計算巨頭的入局，讓雲原生資料庫在國內外一步步成為主流。據Gartner預測，到了2021年，雲資料庫在整個資料庫市場中的佔比將首次達到50%，到2023年，75%的資料庫都要跑在雲平台之上。
關於雲原生資料庫，隨著逐步的出圈，也讓人們關心的焦點從「是啥？」轉變為「還能解決哪些問題？」
但雲原生資料庫存在著數據孤島的問題，無法打通多個數據系統的情況下，企業在數據加工和數據管理上就會「壓力較大」，甚至在數據安全方面還存在隱患。
傳統數據倉庫一般基於T+1數據集成構建離線數倉，以支撐企業各項分析與服務。傳統方案不但會影響線上業務穩定性，且難以支持企業的實時需求。
因此，在李飛飛看來，雲原生資料庫已經走到2.0階段。這個階段要解決的問題，就是上述存在的痛點。
9月26日，在阿里雲資料庫創新上雲峰會上，阿里雲發布了首個一站式敏捷數據倉庫解決方案。該方案結合一站式數據管理平台DMS及雲原生數據倉庫AnalyticDB（簡稱：ADB），實現了庫倉一體的技術架構，提供在線數據實時入倉、T+1周期性快照、按需建倉等能力，數據延時低至秒級，持續賦能業務在線化，使企業的在線數據可以釋放出更大的價值。
相較於傳統方案，阿里雲一站式敏捷數據倉庫解決方案有4大核心優勢：
1、對業務側影響小，不會因為數據匯聚集中和實時加工影響業務側正常運行，CPU、內存佔用低於5%；
2、事務順序和數據准確性有保障，且處理鏈路短，支持在線數據實時處理落倉，效率更高。數據傳輸效率100m/s，數據延時在10秒內；
3、支持復雜實時數據加工、計算邏輯；
4、低代碼操作，能夠大大降低實時數倉的構建難度，提升構建效率的同時，支撐企業數字化轉型過程中的各類實時場景。
除了實時統計分析場景外，企業為滿足周期性數據分析需求，需建設周期性全量快照。
傳統數倉的周期性全量集成方案會對生產業務造成穩定性影響、全量集成時效性差、且無法滿足客戶針對任意時間點進行數據回溯的業務訴求。
針對T+1周期性集成場景，一站式敏捷數據倉庫解決方案支持基於拉鏈表的T+1全量數據快照，用戶通過簡單幾個步驟，即可按需生成各種周期的全量或增量快照。
此外，業務還可按需進行任意時間點的數據回溯，以快速解決數據異常問題。
談起未來資料庫的發展趨勢，李飛飛提到以下五點：
1、雲原生+分布式一定是資料庫的標配，分布式已經是必選項。分布式資料庫由多個相互連接的資料庫組合而成，面向用戶則是以單個資料庫的形態出現。雲原生分布式資料庫具備易用性、高擴展性、快速迭代、節約成本等特徵，從資源池化到彈性擴展，再到智能運維，再到離在線一體化，解決企業用戶的核心訴求。
2、AI for DB（database，指資料庫）和 DB for AI 將是主流趨勢。用AI將資料庫運維管控智能化，尤其在雲原生+分布式這個前提下更重要，因為資料庫不僅是內核的能力彈性高可用、可拓展性，更重要的是部署後應用和運維的復雜度要大大降低。在資料庫里，面對越來越多非結構化的數據，分析能力十分重要。
3、數據的安全可信，在今天這個大環境下變得愈發重要，如何確保整個資料庫系統，在處理數據全鏈路過程中提供加密能力、多方安全計算能力、隱私保護的能力，也是很重要的趨勢。
4、多模數據處理能力將越來越重要。比如，新型資料庫多模態的處理能力，在新能源 汽車 企業打標簽、智能電池化預測等應用場景中，將發揮越來越重要的作用。
5、一份數據，多個數據處理引擎：實現倉庫一體、倉庫聯動、倉庫打通，數據之間無縫流轉。
以上判斷，也從側面反映出阿里雲資料庫的走向，這點毋庸置疑。但除此之外，業界最關心的，還有開源。
近半年，國內很多廠商相繼提出開源戰略，背後緣由顯而易見，為了打造生態。就在今年的阿里雲峰會上，阿里雲智能總裁、達摩院院長張建鋒（花名行癲）將2021年阿里雲的發展關鍵詞歸納為：做好服務、做深基礎、做厚中台、做強生態。
做好服務與生態，成為如今廠商們不約而同的目標，而開源，就是最好的選擇。
當雷鋒網問到：「未來，阿里雲資料庫會不會把所有能力都開源？」這一問題時，李飛飛給到的回答是：「不會。」
之所以有這樣的回答，是因為對於開源，他有著一些判斷和看法。
李飛飛表示，這些部分，本就是阿里雲資料庫的商業化版本。
事實上，業界大多數的資料庫廠商都不會針對自身的核心能力開源，如TiDB的核心管控組件、TiFlash。
與像MongoDB,、Cassandra、CouchDB這些以開源起家的資料庫廠商不同，開源只是阿里雲資料庫的戰略，不是阿里雲資料庫的命脈。
前幾年，有業內人士表示，在面向開源時，國產資料庫首先需要解決信任以及開源知識產權等問題。「開源會讓廠商更加認真思考版權還有專利的問題，事實上，選擇開源後，對於資料庫廠商提出了更高的要求。」
李飛飛認為，開源只是一種選擇，資料庫開源成功並不代表著商業化就能夠成功，不開源也不能代表廠商不先進。
更准確的說，開源只是一種有效手段。
最終，阿里雲資料庫希望客戶能夠通過開源版本把阿里雲資料庫產品技術快速用起來，並能夠參與到技術產品的迭代過程中，在一些高階能力上，借鑒團隊專業能力和阿里雲的服務能力，成為良好的商業合作夥伴，這是李飛飛以及阿里雲資料庫對於開源的一些基本思考。雷鋒網雷鋒網雷鋒網
❸ 從雲原生資料庫服務到新型「數聯網」基礎設施
作者 石默研
新型「數聯網」基礎設施
2020年4月，《中共中央國務院關於構建更加完善的要素市場化配置體制機制的意見》（下稱《2020數據要素意見》）發布以來，數據要素的市場價值日益受到重視。同時，長期的實踐證明，數據要素的威力，大多數情況下源於對多源數據的融合分析，單一組織靠自身積累往往難以聚集足夠價值的數據，因此，只有通過數據跨域流通與共享開放才能真正發揮大數據的應用價值。如銀行、保險、政府、電商等等行行業業，已經有了強烈、廣泛的數據跨域集成與融合的市場需求。另一方面，隨著數字化的深入發展，信息技術已經開始從助力經濟發展的輔助工具向引領經濟發展的核心引擎轉變，大數據資源應該向資產升級，對「數字經濟」新範式產生更加直接的驅動作用。而大數據資源向資產升級的關鍵則是高效、安全的互聯互通、精確的計量計價及數據所有權、使用權的市場化清晰界定。
於是，「數據要素互聯互通網路」數聯網成為國家乃至國際一項重要的新型互聯網基礎設施與創新業態訴求，有著重大的 社會 價值與廣闊的市場空間。
2. 雲原生資料庫服務
雲原生資料庫，是支撐現代數據服務的主體設施，它生於雲上，長於雲上，對外形成按需獲取的DBCloud形態，使用者無需關心數據計算與存儲的具體細節，無需為部署、運維、擴縮等工作付出精力，無需對數據計算的模態（AP，TP，流，圖等）做出額外的規劃與設計，無需區分所選擇雲計算基礎設施IaaS的特性與區別，只需要向雲原生資料庫DBCloud的運營者申請使用相應的服務即可，這是現代資料庫技術與服務發展的必然方向。毫無疑問，在不久的將來，全球越來越多的數據服務將在雲上，包括多雲、跨雲的環境中以平台化的方式實現。由於雲計算環境所帶來的強大算力與各項能力，數據服務平台化必將極大地推動與加速各行業業務數字化轉型升級的進程，而雲原生資料庫也必將成為新數字化時代一項關鍵的公共IT基礎設施。
3. 從資料庫平台服務到新一代互聯網基礎設施「數聯網」
關於數據流通互聯基礎設施「數聯網」，相當長一段時間以來，國內外已經有很多建設與運營的嘗試，在我國主要就是各級政府主導的「大數據交易中心」，從2014年起就開始啟動，經歷了2014-2016年「第一次浪潮」後，於2017-2019年處於「停滯期」，運營實踐看，整體成交量遠低於預期。原因主要在於數據所有權與使用權屬難以界定，隱私、安全與共享之間的矛盾越來越明顯。一方面跨域數據共創需求越來越迫切，另一方面，數據的無序流通，又可能導致隱私保護與數據安全的重大風險，必須加以規范與限制。無論是國際還是國內，日趨嚴格的「數據安全法」「信息保護法案」不斷出台，在客觀上增加了數據流通的成本，降低了數據綜合利用的效率；而大數據價值的精確計量計價也難以實現，不能有效體現數據的資產屬性。如何兼顧發展與安全，平衡效率與風險，准確衡量價值，是全世界在大數據治理中一直面臨的共同課題，也導致規范高效的數據流通市場始終未能形成。
而中央的《2020數據要素意見》，首次明確了培育數據要素市場的目標和定位，隨之有關數據安全、信息保護的法案以及技術系列標准等相繼發布，為促進數據流通規范化運作提供了政策制度基礎；同時，「數據可用不可見、用途可控可計量」的隱私安全計算技術與創新模式也蓬勃發展並成熟起來，為解決隱私安全問題及數據資產化提供了堅實的技術基礎。因此，自2020年至今，以新興技術驅動「數據使用價值流通」新模式的數據要素流通市場迎來「第二次浪潮」，新一輪建設再次啟動，全國一年來共有6家新型數據資產交易中心開始籌備建設，其中北數所等2家新型示範已正式投入運營。隱私安全計算技術採用數據不動、演算法流動的策略，在數據不出域的情況下，安全地達到數據跨域聯合計算的目的。雖然目前該組技術的成熟度與標准化程度還有待提高，在相當范圍內也有炒作的成份，但在強烈需求與趨勢的驅動下，發展很快，前景極為可期。
應該可以看到：採用「數據使用權」而不是「所有權」交易實現跨域流通，對數據訪問按量計價的新模式同時也給雲原生資料庫服務帶來新的商業發展契機，原因很簡單：資料庫本身就是以提供數據使用服務為天職的！
仔細調研與分析還會發現，當前政府主導的新型數據資產交易所對「數據使用權」流通模式的嘗試，基本還在「雷聲大，雨點小」的階段，至今實效依然甚微！這除了可能還需要一定的市場培育周期以外，本文認為一個最重要的原因是：憑空而生的數據交易所，並沒有直接沉澱客戶數據的條件，運營只能靠「借雞生蛋」，而正在發生的事實也正是如此：大都以授權政府數據公開運營為起點，然後大力「邀請」各種數據資源擁有者上平台，培育數據流通生態圈。然而，多數情況下，一是靜態政務數據的實用價值很有限（例如對金融風控），二是真正有價值的產業活數據與公民行為數據擁有者（在其自有資料庫中）上交易平台的程序非常繁雜，意願較低......。同時，現階段在技術體繫上，新型交易所主要依賴隱私計算，對資料庫總體採用鬆散繁雜的集成方案對接，就是說，目前還沒有系統重視資料庫的技術定位。
本文認為，首先，從技術上講，雲原生資料庫融入隱私安全計算甚至更廣泛的跨域安全計算手段，並沒有太大的瓶頸，還可以方便地承擔可信安全中介的角色，卻會賦予數據資源擁有者最便利的「數據使用權」共享能力。更重要的是，當雲計算環境下的數據服務平台化成為全球化趨勢後，全 社會 范圍內大多數的資料庫服務都將由雲原生資料庫平台運營者所承擔，它就自然建立了最廣泛豐富的「數據流通生態圈」，天然擁有提供「數據跨域流通互聯」服務的各種有利條件。而雲原生數據流通顯然是目前數據要素市場化領域需求與商業前景最為強烈的可運營業務之一，如果雲原生資料庫服務運營者借其固有優勢，同時運營數據要素流通業務，必將在技術效能與商業模式上超越現存的各種模式，對政府主導、靠「借雞生蛋」現有市場帶來巨大的挑戰，甚至是終結。
進一步講，這種能力的提供，不僅可以最大限度地挖掘與發揮數據要素的價值與紅利，還可以極大地加速各行業、各組織對雲原生資料庫平台服務的消費需求，兩種因素又會相互促進，從而使雲原生資料庫服務成為將來數據要素市場化的新標准，自然進化為新一代互聯網基礎設施「數聯網」本身。
❹ 雲資料庫的幾種主流雲服務資料庫
Redshift跨一個主節點和多個工作節點實施分布式資料庫。通過使用AW管理控制台，管理員能夠在集群內增加或刪除節點，以及 按實際需要調整資料庫規模。所有的數據都存儲在集群節點或機器實例中。
Redshift集群的實施可通過兩種類型的虛擬機：密集存儲型和密集計算型 。密集存儲型虛擬機是專為大數據倉庫應用而進行優化的，而密集計算型為計算密集型分析應用提供了更多的CPU。 DynamoDB是亞馬遜公司的NoSQL資料庫產品。其資料庫還可與亞馬遜Lambda集成以幫助管理人員對數據和應用的觸發器進行設置。
DynamoDB特別適用於具有大容量讀寫操作的移動應用。用戶可創建存儲JavaScript對象符號（JSON）文檔的表格，而用戶可指定鍵值對 其進行分區。與定義如何分割數據不同，這里無需定義一個正式的架構。
❺ 目前主流的分布式資料庫系統實現方案有哪些
（1）方案一（資料庫保存所有伺服器索引信息）
全對稱結構，沒有中央伺服器
web方案：
只從本地資料庫檢索符合條件的記錄，給出結果
每次檢索都要從本地伺服器的海量數據中進行
資料庫方案：
資料庫保存所有伺服器的索引內容
緩存命中率高的記錄，減少檢索時間
伺服器負載分析：
伺服器負載假設：
一百個結點，每結點一百人同時使用，每個結點一萬條記錄
web伺服器：同時一百線程在本地資料庫伺服器檢索
資料庫伺服器：每次接收一百個查詢請求；每個請求要從一百萬條索引中檢索（最壞的情況）；緩沖機制可以稍微減輕負擔
數據更新操作：
同時更新所有資料庫/只更新本地，伺服器間相互同步
方案二（資料庫保存本地索引及少量緩沖）
每高校作為一個結點
所有結點全對稱結構，網路中沒有一個中央伺服器
web方案：
接收到請求時同時多線程向其它伺服器同時搜索（伺服器壓力問題？）
資料庫方案：
資料庫保存本地數據
資料庫保存一定量緩沖數據，
伺服器負載分析：
伺服器負載假設：
一百個結點，每結點一百人同時使用
則每個web伺服器同時發起一萬個線程向其它數據伺服器搜索（oops!）
每個資料庫伺服器會同時接收到一萬個查詢請求（oops！）
採用學習過程只能少量減少查詢請求和web伺服器搜索線程
數據更新操作：
只更新本地
方案三（中央伺服器方案一）
每高校一個結點
每結點結構相同，連接到同一個中央伺服器
web方案
每個查詢向中央伺服器進行，由中央伺服器實行檢索，中央伺服器返回檢索結果
資料庫方案
中央資料庫保存所有索引信息
每結點可以只用小型資料庫保存本地用戶和其它信息即可
伺服器負載分析：
伺服器負載假設：
一百個結點，每結點一百人同時使用，每結點資料記錄一萬條
web伺服器：同時發起一百個進程向中央資料庫查詢
資料庫伺服器（中央）：同時接收一萬條查詢請求並返回大容量結果
資料庫伺服器（結點）：少量工作
數據更新操作：
只更新中央伺服器
方案四（中央伺服器方案二）
每高校一個結點
每結點結構相同，連接到同一中央伺服器
web方案：
每個查詢向中央伺服器進行，由中央伺服器根據查詢內容進行轉發到結點資料庫，再由結點資料庫返回結果
資料庫方案：
中央伺服器保存各結點分類信息，根據頁面請求的分類轉發查詢到相應伺服器
伺服器負載分析：
伺服器負載假設：
一百個結點，每結點一百人同時使用，每結點資料記錄一萬條，每結點一百個類別
web伺服器：同時一百個進程向中央資料庫查詢
資料庫伺服器（中央）：同時接收一萬條請求並轉發
資料庫伺服器（結點）：從中央伺服器接收查詢請求，最壞情況下每結點接收到一萬條查詢請求
數據更新操作：
只更新本地伺服器
分類變化時更新中央伺服器
❻ 雲原生應用是什麼它的特點有哪些
雲並非把原先在物理伺服器上跑的東西放到虛擬機里跑，真正的雲化不僅是基礎設施和平台的事情，應用也要做出改變，改變傳統的做法，實現雲化的應用——應用的架構、應用的開發方式、應用部署和維護技術都要做出改變，真正的發揮雲的彈性、動態調度、自動伸縮……一些傳統IT所不具備的能力。這里說的「雲化的應用」也就是「雲原生應用」。雲原生架構和雲原生應用所涉及的技術很多，如容器技術、微服務等，
而雲原生應用最大的特點就是可以迅速部署新業務。在企業里，提供新的應用程序環境及部署軟體新版本通常所需時間以日、周甚至以月計算。這種速度嚴重限制了軟體發布所能承受的風險，因為犯錯及改錯也需要花費同樣的時間成本，競爭優勢就會由此產生。
所以雲原生不是一個產品，而是一套技術體系和一套方法論，而數字化轉型是思想先行，從內到外的整體變革。雲原生包括DevOps、持續交付、微服務、敏捷基礎設施、康威定律等，以及根據商業能力對公司進行重組的能力，既包含技術、也包含管理，可以說是一系列雲技術和企業管理方法的集合，通過實踐及與其他工具相結合更好地幫助用戶實現數字化轉型。
CNCF(雲原生計算基金會)認為雲原生系統需包含的屬性：
1、容器化封裝：以容器為基礎，提高整體開發水平，形成代碼和組件重用，簡化雲原生應用程序的維護。在容器中運行應用程序和進程，並作為應用程序部署的獨立單元，實現高水平資源隔離。
2、自動化管理：統一調度和管理中心，從根本上提高系統和資源利用率，同時降低運維成本。
3、面向微服務：通過松耦合方式，提升應用程序的整體敏捷性和可維護性。
❼ 【重識雲原生】第2.3節——主流虛擬化技術之Xen
Xen知識地圖：
Xen是由劍橋大學計算機實驗室開發的一個開源項目，是一個開源的可直接運行於硬體層之上的虛擬化軟體，它屬於type-I型虛擬化系統，支持萬貫虛擬化和超虛擬化，以高性能、佔用資源少著稱，贏得了IBM、AMD、HP、Red Hat和Novell等眾多世界級軟硬體廠商的高度認可和大力支持，已被國內外眾多企事業用戶用來搭建高性能的虛擬化平台。
Xen僅對CPU和Memory直接接管，而其它IO硬體驅動則由其上運行的第一個虛擬機來提供支持，它能夠在計算機硬體上並發的運行多個客戶操作系統（Guest OS）。支持x86、x86-64、安騰( Itanium)、Power PC和ARM多種處理器，因此Xen可以在大量的計算設備上運行，目前Xen支持Linux、NetBSD、FreeBSD、Solaris、 Windows和其他常用的操作系統作為客戶操作系統在其管理程序上運行。
Xen默認認為自己是直接運行於硬體層之上的虛擬化軟體（即Xen Hypervisor層），並且可以直接驅動CPU和內存，需注意CPU和內存是所有想要運行的操作系統必須能直接支持的，但Xen為保證自身的小巧，它並沒有提供虛擬機的管理介面，因此它採用了一種獨特的方式，先運行一台特權虛擬機（即Domain 0），且這台VM必須支持Kernel的修改，因此選擇開源的Linux做為特權VM是最合適的，這樣也可方便採用Linux所支持的方式來開發虛擬機管理介面，實現與Xen Hypervisor層直接交互來完成為VM分配CPU和內存資源及創建、刪除、停止、啟動VM的管理介面。通常這台特權虛擬機一定會採用當前比較流行的Linux發行版，因為它能支持更多IO硬體設備，如：網卡，磁碟，顯卡，音效卡等；到目前為止，NetBSD，GNU/Linux，FreeBSD和Plan 9，OpenSolaris等系統已經支持已半虛擬化方式運行在Xen的DomU中。目前Xen已經支持x86、x86_64和ARM等平台，並正在向IA64、PPC移植。移植到其他平台從技術上是可行的，未來有可能會實現。
Xen虛擬機支持在不停止的情況下在多個物理主機之間實時遷移。在操作過程中，虛擬機在沒有停止工作的情況下內存被反復地復制到目標機器。虛擬機在最終目的地開始執行之前，會有一次60-300毫秒的非常短暫的暫停以執行最終的同步化，給人無縫遷移的感覺。類似的技術被用來暫停一台正在運行的虛擬機到磁碟，並切換到另外一台，第一台虛擬機在以後可以恢復。
如上圖所示，Xen虛擬環境由三部分組件組成：
XEN Hypervisor
Xen Hypervisor 是介於操作系統和硬體之間的一個軟體抽象層。它負責在各個虛擬機之間進行CPU調度和內存分配。Xen Hypervisor不僅抽象出虛擬機的硬體，同時還控制著各個虛擬機的執行。Xen Hypervisor不會處理網路、存儲設備、視頻以及其他 I/O。
Domain 0 Guest
Domain 0是特權域，是一個修改過的Linux kernel，是唯一運行在 Xen Hypervisor之上的虛擬機，它擁有訪問物理 I/O 資源的許可權，同時和系統上運行的其他虛擬機（Domain U: PV and HVM Guest）進行交互。Domain 0需要在其它Domain啟動之前啟動。
Domain 0 中有兩個驅動 Network Backend Driver 和 Block Backend Driver，它們分別用來處理來自 Domain U 的網路和本地磁碟請求。 Network Backend Driver與本地網路硬體直接通信，以此來處理來自於Domain U所有虛擬機訪問網路設備的請求；Block Backend Drive與本地存儲設備進行通信，以此來處理來自於Domain U的磁碟數據讀寫的請求。
Domain U Guest(Dom U)
Domain U沒有直接訪問物理硬體的許可權（Domain U的"U"是來自於英文單詞 unprivileged，是指沒有許可權的），但Domain 0有。
運行在 Xen Hypervisor 上的所有半虛擬化（paravirtualized）虛擬機被稱為「Domain U PV Guests」，其上運行著被修改過內核的操作系統，如 Linux、Solaris、FreeBSD 等其它 UNIX 操作系統。
所有的全虛擬化虛擬機被稱為「Domain U HVM Guests」，其上運行著不用修改內核的操作系統，如 Windows 等。
Domain U PV Guest 中也包括兩個驅動「PV Network Driver」和「PV Block Driver」，它們分別也是用來處理發送網路和本地磁碟請求用的，這與 Domain 0 中的兩個驅動是相對應的。
Xen對虛擬機的虛擬化分為兩大類，半虛擬化（Para virtualization）和完全虛擬化（Hardware VirtualMachine）。
半虛擬化（Paravirtualization）有些資料稱為「超虛擬化」，簡稱為PV，是Xen主導的虛擬化技術。這種技術允許虛擬機操作系統感知到自己運行在Xen Hypervisor上而不是直接運行在硬體上，同時也可以識別出其他運行在相同環境中的客戶虛擬機。
在Xen Hypervisor上運行的半虛擬化的操作系統，為了調用系統管理程序（Xen Hypervisor），要有選擇地修改操作系統，然而卻不需要修改操作系統上運行的應用程序。由於 Xen 需要修改操作系統內核，所以您不能直接讓當前的 Linux 內核在 Xen 系統管理程序中運行，除非它已經移植到了Xen 架構。不過，如果當前系統可以使用新的已經移植到 Xen 架構的Linux 內核，那麼您就可以不加修改地運行現有的系統。
完全虛擬化（Hardware Virtual Machine）又稱「硬體虛擬化」，簡稱HVM，是指運行在虛擬環境上的虛擬機在運行過程中始終感覺自己是直接運行在硬體之上的，並且感知不到在相同硬體環境下運行著其他虛擬機的虛擬技術。此種虛擬化需要藉助於Intel的VT-x 或 AMD的AMD-v 等硬體輔助虛擬化技術（詳細技術原理參見1.5.1節）及Qemu的IO硬體模擬技術，才能支持GuestOS的kernel不修改,就可直接被DomU支持。
在Xen Hypervisor運行的完全虛擬化虛擬機，所運行的操作系統都是標準的操作系統，即：無需任何修改的操作系統版本。同時也需要提供特殊的硬體設備。
值的注意的是，在Xen上虛擬的Windows虛擬機必須採用完全虛擬化技術。
為了提高性能，完全虛擬化的Guests可以使用特殊的半虛擬設備驅動程序（PVHVM或PV-on-HVM驅動）。這些驅動程序在HVM環境下優化你的 PV驅動，模擬的磁碟和網路IO旁路運行，從而讓你的PV在HVM中有更好的性能。這意味著你在用戶窗口操作方面可以得到最佳的性能。
注意，Xen項目PV（半虛擬化）的Guest自動使用PV驅動，因此不需要這些驅動程序，因為你已經自動使用優化的驅動程序。PVHVM只會在HVM（全虛擬化）guest虛擬機中需要。
Xen 的 VMM ( Xen Hypervisor ) 位於操作系統和硬體之間，負責為上層運行的操作系統內核提供虛擬化的硬體資源，負責管理和分配這些資源，並確保上層虛擬機（稱為域 Domain）之間的相互隔離。Xen採用混合模式，因而設定了一個特權域用以輔助Xen管理其他的域，並提供虛擬的資源服務，該特權域稱為Domain 0，而其餘的域則稱為Domain U。
Xen向Domain提供了一個抽象層，其中包含了管理和虛擬硬體的API。Domain 0內部包含了真實的設備驅動（原生設備驅動），可直接訪問物理硬體，負責與 Xen 提供的管理 API 交互，並通過用戶模式下的管理工具來管理 Xen 的虛擬機環境。
Xen2.0之後，引入了分離設備驅動模式。該模式在每個用戶域中建立前端（front end）設備，在特權域(Dom0)中建立後端(back end)設備。所有的用戶域操作系統像使用普通設備一樣向前端設備發送請求，而前端設備通過IO請求描述符(IO descripror ring)和設備通道（device channel）將這些請求以及用戶域的身份信息發送到處於特權域中的後端設備。這種體系將控制信息傳遞和數據傳遞分開處理。
在Xen體系結構設計中，後端設備運行的特權域被賦予一個特有的名字---隔離設備域(Isolation Device Domain, IDD)，而在實際設計中，IDD 就處在Dom0中。所有的真實硬體訪問都由特權域的後端設備調用本地設備驅動 (native device driver)發起。前端設備的設計十分簡單，只需要完成數據的轉發操作，由於它們不是真實的設備驅動程序，所以也不用進行請求調度操作。而運行在IDD中的後端設備，可以利用Linux的現有設備驅動來完成硬體訪問，需要增加的只是IO請求的橋接功能---能完成任務的分發和回送。
1）半虛擬化技術實現原理
採用半虛擬化技術的虛擬機操作系統能夠識別到自己是運行在Xen Hypervisor而非直接運行於硬體之上，並且也可以識別到在相同的機器上運行的其他虛擬機系統。而且運行的操作系統都需要進行相應的修改。
半虛擬化客戶機（Domain U PV Guests）包含兩個用於操作網路和磁碟的驅動程序，PV Network Driver 和PV Block Driver。
PV Network Driver負責為Domain U提供網路訪問功能。PV Block Driver負責為Domain U提供磁碟操作功能。
2）完全虛擬化技術實現原理
完全虛擬化客戶機（Domain U HVM Guests）運行的是標准版本的操作系統，因此其操作系統中不存在半虛擬化驅動程序（PV Driver），但是在每個完全虛擬化客戶機都會在Domain 0中存在一個特殊的精靈程序，稱作：Qemu-DM，Qemu-DM幫助完全虛擬化客戶機（Domain U HVM Guest）獲取網路和磁碟的訪問操作。
完全虛擬化客戶機必須和在普通硬體環境下一樣進行初始化，所以需要在其中加入一個特殊的軟體Xen virtual firmware，來模擬操作系統啟動時所需要的BIOS。
開源社區中將一系列的Linux精靈程序分類為「管理」和「控制」兩大類。這些服務支撐著整個虛擬環境的管理和控制操作，並且存在於Domain 0虛擬機中。
下面將對直接服務進行詳細的描述。
註：為了清晰的描述Xen的運行流程，畫圖時將精靈程序放在Domain 0外部來描述，但事實上所有精靈程序都存在於Domain 0 之中。
1）Xend
Xend精靈線程是一個Python應用程序，它作為Xen環境的系統管理員。它利用Libxenctrl類庫向Xen Hypervisor發出請求。
所有Xend處理的請求都是由XM工具使用XML RPC介面發送過來的。
2）Xm
用於將用戶輸入通過XML RPC介面傳遞到Xend中的命令行工具。
3）Xenstored
Xenstored精靈程序用於維護注冊信息，這些信息包括內存和在連接Domain 0和所有其他Domain U之間的事件通道。Domain 0虛擬機利用這些注冊信息來與系統中其他虛擬機建立設備通道，即幫助Domain U虛擬機訪問硬體資源。
4）Libxenctrl
Libxenctrl是C程序類庫，用於讓Xend具有通過Domain 0與Xen Hypervisor進行交互的能力。在Domain 0中存在一個特殊的驅動程序稱作privcmd，它將請求發送給Hypervisor。
5）Qemu-DM
在Xen環境下，每個完全虛擬化虛擬機都需要擁有自己的Qemu精靈程序。Qemu-DM處理在Xen環境下完全虛擬化客戶機所能允許執行的所有關於網路 和磁碟請求和操作。Qemu程序必須存在於Hypervisor之外同時又需要訪問網路和I/O，所以Qemu-DM必須存在於Domain 0 中（參見前面章節對Domain 0 的描述）。
未來版本的Xen中，一種新的工具Stub-DM將會提供一系列對所有完全虛擬化客戶機都可用的服務，以此來替代需要在每個虛擬機上都生成一個Qemu的邏輯。
6）Xen Virtual Firmware
Xen Virtual Firmware是被嵌入到所有完全虛擬化客戶機中的虛擬BIOS系統，來確保所有客戶操作系統在正常啟動操作中接收到標準的啟動指令集並提供標準的軟體兼容環境。
根據前幾章節所述，Xen Hypervisor不負責處理網路和磁碟請求，因此半虛擬化客戶機（Domain U PV）必須通過Domain 0 與Xen Hypervisor進行通信，從而完成網路和磁碟的操作請求。下面以半虛擬化客戶機（Domain U PV）執行向本地磁碟寫入數據為例描述Domain 0與Domain U PV的交互過程。
半虛擬化客戶機（Domain U PV）的PV Block Driver接收到要向本地磁碟寫入數據的請求，然後通過Xen Hypervisor將與Domain 0共享的本地內存中的數據寫入到本地磁碟中。在Domain 0 和半虛擬化Domain U之間存在事件通道，這個通道允許它們之間通過存在於Xen Hypervisor內的非同步中斷來進行通信。Domain 0將會接收到一個來自於Xen Hypervisor的系統中斷，並觸發Domain 0中的Block Backend驅動程序去訪問本地系統內容，並從與半虛擬化客戶機的共享內存中讀取適合的數據塊。從共享內存中讀取的數據隨後被寫入到本地磁碟的指定位置中。
上圖中所顯示的事件通道是直接連接Domain 0 和Domain U PV是為了清晰和簡單的描述系統是如何運行的。但事實上，事件通道（Event Channel）運行於Xen Hypervisor中，並在Xenstored中注冊特定的系統中斷，以此來讓Domain 0 和Domain U PV能夠通過本地內存快速的共享信息。
Xen在給VM提供CPU的虛擬化時，它採用的也是在Xen hypervisor層啟動一個線程，並將這些線程映射到某個物理核心上，當然通過DomU的配置文件中的cpus可以指定將這些模擬CPU的線程綁定到某幾個物理核心上；而內存的虛擬化則是內存頁的映射，將物理內存上多個連續或不連續的內存頁映射給VM，讓VM看來這就是一個完整的連續的內存空間。
當啟動一個用戶VM(DomU)時，該VM所需的CPU和內存都由Xen Hypervisor提供，而它若需要使用IO設備時，則向特權VM(即Dom0)發起請求，特權VM會為該用戶VM創建一個模擬的硬體設備線程，並運行於特權VM的用戶空間，當用戶VM向該IO硬體發起調用時，特權VM上相應的模擬設備接收請求並將其轉化為特權VM對IO硬體的操作，交給特權VM的內核來代為完成其操作。這里需注意這些虛擬IO硬體需要由Qemu來模擬，Xen本身並沒有提供相應的模擬功能。（註：特權VM的CPU和內存也是有Xen Hypervisor提供）
1）Qemu模擬IO設備(完全虛擬化方式)
Qemu模擬IO設備(完全虛擬化方式)：假如用戶VM向特權VM請求磁碟，特權VM可以將一個分區、文件等，通過Qemu將其模擬成一個磁碟設備，就拿文件來說，特權VM先創建一個映像文件，再通過Qemu為該文件模擬一個磁碟控制器晶元；然後，將其映射到用戶VM上，當然模擬的這個磁碟控制器晶元一定是一個最常見的，用戶VM的Kernel一定支持的，但需注意：模擬的磁碟可能會與實際的物理磁碟不同，因為要盡可能兼容。這樣一來用戶VM假如要寫數據到磁碟的過程如下：
用戶VM-APP--->用戶VM-Kernel調用虛擬磁碟的驅動進行寫數據前的准備(如：數據寫入到磁碟中的扇區位置/數據編碼等)--->
用戶VM-Kernel將編碼後的信息發給特權VM的模擬磁碟進程--->
特權VM的模擬磁碟進程再將編號信息還原後發給特權VM-kernel--->
特權VM-kernel調用真實物理磁碟的驅動對數據進行寫前准備--->最後磁碟驅動調度磁碟完成寫入
摘錄補充:（ http://my.oschina.net/davehe/blog/94039?fromerr=mOuCyx6W ）
Xen向Domain提供了一個抽象層，其中包含了管理和虛擬硬體的API。Domain 0內部包含了真實的設備驅動（原生設備驅動），可直接訪問物理硬體，Xen 提供的管理 API 可與其交互，並通過用戶模式下的管理工具(如：xm/xend、xl等)來管理 Xen 的虛擬機環境。
2）半虛擬化IO設備
半虛擬化的IO設備：它與模擬最大不同是DomU知道自己是運行在虛擬化環境中的，並且知道這個磁碟不是真正的磁碟，它只是Xen模擬的一個磁碟前端驅動(Disk Frontend)，它要寫數據時，直接將數據交給Disk Frontend，而不再去調用磁碟驅動進行數據編碼，當特權VM端的Disk backend收到來自DomU的數據時，也是直接轉給特權VM-Kernel，由其直接調用物理磁碟驅動來對這些原始數據進行處理並寫入磁碟。
摘錄補充：（ http://my.oschina.net/davehe/blog/94039?fromerr=mOuCyx6W ）
Xen2.0之後，引入了分離設備驅動模式。該模式在每個用戶域中建立前端（front end）設備，在特權域(Dom0)中建立後端(back end)設備。所有的用戶域操作系統像使用普通設備一樣向前端設備發送請求，而前端設備通過IO請求描述符(IO descripror ring)和設備通道（device channel）將這些請求以及用戶域的身份信息發送到處於特權域中的後端設備。這種體系將控制信息傳遞和數據傳遞分開處理（類似雲計算中常說的控制面與數據面分離設計）。
半虛擬化客戶機（Domain U PV）的PV Block Driver接收到要向本地磁碟寫入數據的請求，然後通過Xen Hypervisor將自己與Domain 0共享的本地內存中的數據寫入到本地磁碟中。在Domain 0 和半虛擬化Domain U之間存在事件通道，這個通道允許它們之間通過存在於Xen Hypervisor內的非同步中斷來進行通信。Domain 0將會接收到一個來自於Xen Hypervisor的系統中斷，並觸發Domain 0中的Block Backend驅動程序去訪問本地系統內容，並從自己與半虛擬化客戶機的共享內存中讀取適合的數據塊後，隨即被寫入到本地磁碟的指定位置中。
但無論採用模擬或半虛擬化最終都是對物理磁碟的操作，假如當前只有一個物理磁碟，眾多用戶VM都在進行大量的讀寫請求，此時，為了避免用戶VM無限制的向特權VM發起請求，特權VM中採用一個環狀緩存區，每到一個IO請求，就先將其塞入這個環狀緩沖區的槽位中，若緩沖區滿了，就會告訴用戶VM IO設備繁忙。當然其它各種IO設備大致都採用這種機制來控制。
在虛擬化環境中虛擬網路是十分重要但又比較難,需要特別注意；
在Linux中實現虛擬網路的方法中比較常用的工具有兩個：bridge-utils 和 openvswitch，它們創建的虛擬網路設備是不能相互使用的，比如：bridge-utils創建的橋設備，openvswitch是無法識別的。
用下圖來做簡單說明：
1）Bridge模式
Xend啟動時流程：
1、創建虛擬網橋 xenbr0；
2、停止物理網卡 eth0；
3、物理網卡 eth0 的 MAC 地址和 IP 地址被復制到虛擬網卡 veth0；
4、物理網卡 eth0 重命名為 peth0；
5、Veth0 重命名為 eth0；
6、Peth0 的 MAC 地址更改（ FE:FF:FF:FF:FF:FF ），ARP 功能關閉；
7、連接 peth0、vif0.0 到網橋 xenbr0
8、啟動 peth0、vif0.0、xenbr0
Domain U 啟動時的流程：
1、vif<domainID>.0 連接到 xenbr0
2、啟動vif<domainID>.0
2）Route 模式
Xend啟動時的流程：
1、開啟Domain 0的IP Forward。
Domain U啟動時的流程：
1、創建 vif<domainID>.0 ，dom U eth0的IP地址被拷貝到vif<domainID>。
2、啟動 vif<domainID>.0。
3、為domU的配置文件中指向虛擬介面vif.0分配的IP地址增加靜態路由。
3）NAT模式
NAT 模式會使用虛擬區域網 virbr0
安裝了Xen的Linux機器，在Dom 0中能看到以下幾類網卡（網路介面設備 ）：
(X ，Y都為數字)
pethY
ethY
xenbrY
virbrY
vifX.Y（X為DomaiID，Y表示該虛擬網卡是該Domain的第幾塊虛擬網卡）
vethY （一般在Xend啟動完成以後就不存在了）
xend : 這是Xen Hypervisor的Dom0上運行的服務,此服務用來監控xm命令發來的指令,並完成相應的動作。
xm : Xen Management,用來管理VM的創建、刪除、啟動、快照、刪除、停止等的管理工具。
xl : 這是一個基於libxenlight庫的一個輕量級VM管理工具，它從Xen4.1開始出現,從4.3以後,它被作為主要的VM管理工具,而xm這個重量級管理工具開始被提示廢棄.以下為xm、xl的對比圖:
xl 和 xm都需要調用libxenlight，但xl不需要運行任何服務,它可直接調用libxenlight完成相關操作。
xe/XAPI，是xend的一個API管理介面,通常用於Xen Cloud環境中：Xen Server, XCP
virsh/ libvirt : 這是Redhat發起開發的一套用於管理眾多不同類別的VM的管理工具。
virsh : 這是一個命令行工具
libvirt: 則是一個lib庫, libvirtd守護進程用於監聽virsh命令操作,並調用lbvirt完成相關操作.
10年4月Xen4.0.0發布，改進後Xen的DomU最大可支持虛擬CPU 64顆，Xen主機可支持1TB內存和128顆物理CPU，磁碟可支持快照和克隆；HVM客戶機支持虛擬內存頁共享；
11年4月發布的Xen4.1版後，xm/xend開始被提示廢棄，xl這個更輕量級的Xen VM管理工具逐漸成為主流。
15年為止已經發布Xen4.5版本，目前yum源可用的最新版Xen是4.6.1版的(http://mirrors.skyshe.cn/centos/6.7/virt/x86_64/xen-46/)。
Linux2.6.37：kernel開始對Xen進行支持,並加其加入到Kernel中。
Linux3.0：Kernel開始對Xen的關鍵部分進行優化。
RHEL對Xen的支持概況：
Redhat系列對Xen的支持情況：
RHEL5.7 ~ 及以前版本：默認的企業虛擬化技術為Xen。
但Redhat提供了兩種內核：
kernel-... ：這是僅允許RHEL系統的內核，不能運行在DomU中。
kernel-xen.. ：這是需要部署XenServer時,使用的Kernel版本。
RHEL6 ~ 及以後版本：默認支持KVM(收購自以色列的一款虛擬化工具)，並且不在對Xen做任何支持，但允許自己運行在DomU中。
Linux內核態、用戶態簡介與IntelCPU特權級別--Ring0-3_weixin_30784501的博客-CSDN博客
雲計算技術 — 雲計算技術發展編年史_煙雲的計算-CSDN博客_雲計算編年史
虛擬化技術原理（CPU、內存、IO）_joneslee的博客-CSDN博客_虛擬化原理
五種主流的虛擬化技術_遠有青山-CSDN博客_虛擬化技術
Xen原理
Xen原理 - 張朝鋒 - 博客園
Xen虛擬化技術原理_IT人生活的技術博客_51CTO博客
Xen虛擬化基本原理詳解
Xen虛擬化基本原理詳解 - stardsd - 博客園
Xen工作原理_為幸福寫歌的博客-CSDN博客_xen原理
Xen_網路
❽ 雲原生有哪些熱門發展方向
雲原生熱門發展方向：
1. 容器（Containers）容器是一種輕量級的虛擬化技術，通過容器可以簡化應用的部署、管理和交付。目前各大IT廠商已經投入了大量的資源進行容器產品和服務的研發，可以預見，未來容器將會是一種主流的應用交互手段，非常有前景。
2. 微服務（Microservices）微服務倡導運用化整為零，實現各個功能的獨立開發與部署、提升應用架構的靈活性，從而提升對業務的響應速度。在提倡敏捷的今天，微服務已經成為應用架構的一種默認的選擇。
3. 無服務（Serverless）無伺服器架構並不是說，未來不再需要伺服器，而是不再著重關注底層的基礎架構，更多的注意力可以放在和業務更相關的一些邏輯實現上，例如一些函數的代碼片段，平台自動根據負載按需部署和啟動，以及自動伸縮代碼邏輯來滿足業務處理的需求。
4. DevOpsDevOps這個框什麼都可以往裡裝，提供了指導思想、流程和工具，為應用的迭代更新保駕護航，運維行業的未來之路。
5. Service Mesh(服務網格)Service Mesh是近年興起的一個話題，在容器微服務的基礎上，通過Service Mesh可以讓用戶更精細、更智能的去管理服務之間的通訊。ServiceMesh社區的旗艦項目Istio，當前的熱度正在迅速的飆升。
6. 雲（Cloud）雲是雲原生的基礎，沒有雲也就沒有雲原生。沒有對雲正確地理解，也不可能對雲原生有正確的打開方式。對於非技術人員來說，至少要理解雲的多種不同的服務模型，比方IaaS、PaaS、SaaS以及各種服務模型的應用場景和價值。
雲原生熱門發展方向容器（Containers）、微服務（Microservices）、無服務（Serverless）、DevOps、ServiceMesh(服務網格)、雲（Cloud）這6個方面，並不是孤立的，而是相互聯 系的。雲是一切的基礎，為上層應用的運行提供了計算、網路、存儲等基礎架構資源；容器在雲的基礎架構和應用之間，集有了應用和基礎架構資源；應用層面，用戶可以根據場景來選擇微服務架構或者是無伺服器架構；在復雜的交互場景當中，通過服務網格，可以對服務組建的通訊進行管控；通過DevOps構建一個應用架構不斷迭代更新的正向循環。時速雲是一家全棧雲原生技術服務提供商，提供雲原生應用及數據平台產品，其中涵蓋容器雲PaaS、DevOps、微服務治理、服務網格、API網關等。大家可以去體驗一下。
3、雲原生有哪些發展方向？
4、雲原生相關知識
5、未來雲原生如何發展？
雲原生熱門發展方向：一站式雲原生研發平台我們現在講雲原生技術、雲原生應用，其實最有切身感受的是開發，容器、DevOps等都是屬於開發、運維層面的應用。未來企業，誰能抓住快速上新、迭代、變幻的互聯網需求，誰就能抓住時代的機會。因此，研發工具的改革將會是未來非常熱門的一個方向。什麼是一站式的雲原生研發平台？即，包含雲原生應用架構設計、在線協同編碼開發、基於雲原生的API管理和介面測試、多雲交付和應用調度、灰度發布、流水線、應用運維、服務治理、多容器集群管理、雲邊一體化業務交付等能力。目標是提升應用架構敏捷度，大大加快軟體開發迭代速度，提高IT資源的彈性和利用率，幫助企業客戶加速實現業務價值。時速雲是一家全棧雲原生技術服務提供商，提供雲原生應用及數據平台產品，其中涵蓋容器雲PaaS、DevOps、微服務治理、服務網格、API網關等。大家可以去體驗一下。
❾ 現在主流資料庫
主流的資料庫有：
1、MySQL
MySQL是一個關系型資料庫管理系統，由瑞典MySQL AB 公司開發，屬於Oracle旗下產品。
MySQL 是最流行的關系型資料庫管理系統之一，在 WEB 應用方面，MySQL是最好的RDBMS(Relational Database Management System，關系資料庫管理系統) 應用軟體之一。
2、SQL Server
SQL Server是Microsoft 公司推出的關系型資料庫管理系統。
具有使用方便可伸縮性好與相關軟體集成程度高等優點，可跨越從運行Microsoft Windows 98 的膝上型電腦到運行Microsoft Windows 2012 的大型多處理器的伺服器等多種平台使用。
3、Oracle Database
Oracle Database，是甲骨文公司的一款關系資料庫管理系統。
它是在資料庫領域一直處於領先地位的產品。系統可移植性好、使用方便、功能強，適用於各類大、中、小、微機環境。它是一種高效率、可靠性好的、適應高吞吐量的資料庫方案。
(9)盤點主流雲原生資料庫技術方案擴展閱讀
資料庫的類型
1、關系資料庫
關系型資料庫，存儲的格式可以直觀地反映實體間的關系。關系型資料庫和常見的表格比較相似，關系型資料庫中表與表之間是有很多復雜的關聯關系的。 常見的關系型資料庫有Mysql，SqlServer等。
在輕量或者小型的應用中，使用不同的關系型資料庫對系統的性能影響不大，但是在構建大型應用時，則需要根據應用的業務需求和性能需求，選擇合適的關系型資料庫。
2、非關系型資料庫
非關系型資料庫，指的是分布式的、非關系型的、不保證遵循ACID原則的數據存儲系統。非關系型資料庫技術與CAP理論、一致性哈希演算法有密切關系。
所謂CAP理論，簡單來說就是一個分布式系統不可能滿足可用性、一致性與分區容錯性這三個要求，一次性滿足兩種要求是該系統的上限。
而一致性哈希算則指的是非關系型資料庫在應用過程中，為滿足工作需求而在通常情況下產生的一種數據演算法，該演算法能有效解決工作方面的諸多問題但也存在弊端，即工作完成質量會隨著節點的變化而產生波動，當節點過多時，相關工作結果就無法那麼准確。
❿ 創原會：保險行業精英齊聚，共論雲原生創新之道
1月15日，由創原會發起的「雲原生技術精英沙龍（保險行業專場）」成功舉辦，來自中國信通院、華為雲以及保險行業的技術精英，就「雲原生提速保險行業數字化轉型」以及「保險行業雲原生典型應用場景」進行了深入探討。
創原會是華為雲聯合CNCF、中國信通院及業界雲原生技術精英們，構建的全球化雲原生交流平台，旨在通過 探索 前沿雲原生技術、共享產業落地實踐，共創雲原生與業務融合的無限可能。
雲原生：保險行業數字化升級的必由之路
隨著百姓保險意識的增強、「互聯網+保險」對傳統業務的顛覆創新，保險行業正經歷一場產品、運營、業務模式全面升級的變革。
合眾人壽信息技術總監頊頌表示：「我們希望擴大外部交流，引入新的技術，並通過平台化戰略實現開放生態、跨界融合，進而與上下游渠道對接，建立一個整合了保險業務、數據、產品的體系，提高業務系統的靈活性和創新的敏捷性，實現以客戶為中心，數字化驅動、智慧經營的 科技 發展目標。」
中國信通院雲大所雲計算部副主任陳屹力，在會上分享了雲原生技術與保險業務融合的趨勢洞察。他認為：「 雲原生是保險行業新一輪數字化升級的必由之路， 其開放、敏捷、標準的特點，能快速幫助企業構建開放的平台，更好地支撐業務的快速發展和創新，實現降本增效。未來的1至3年，保險行業將迎來全面雲原生化的時代。」
雲原生基礎設施：為保險業務構建高效的雲原生底座
互聯網加持下的保險業務，呈現出交易頻次高、流量大等特點。同時，保險業務與不同行業的融合，也對業務敏捷創新提出了更高的要求。
華為雲雲原生解決方案資深架構師吉碩在會上介紹：「華為作為全球領先的ICT基礎設施和智能終端提供商，在自有業務升級、服務全球客戶的過程中，已實現超大規模企業雲原生實踐。我們將這些經驗與華為雲服務相結合，打造了更適合傳統行業客戶大規模落地雲原生的解決方案。」
華為雲基於擎天架構打造 「以應用為中心」的雲原生基礎設施，為客戶構建全棧雲原生業務，提供了高效、敏捷的雲原生基礎設施平台。
通過提供x86、GPU、鯤鵬、升騰等多樣性算力，華為雲滿足保險行業核心交易、互聯網業務、AI及大數據業務對算力的差異化訴求，並基於擎天架構的軟硬協同能力，充分發揮出雲原生基礎設施性能，滿足業務大規模部署、大業務量並發的需求；同時，雲原生多雲平台幫助客戶快速構建多地多中心業務治理能力，實現跨地域的資源調度、業務擴容、流量治理；此外，標准、開放的應用管理平台，實現各類雲原生應用共平台部署，提升了業務的開發、運行、運維效率。
雲原生資料庫：保障保險業務數據的高效與安全
保險業務的快速發展，各企業資料庫數據量可高達幾十、數百TB，資料庫如何擴展、如何最大限度的發揮這些數據的業務價值，是困擾保險行業的難題。
華為雲資料庫聚焦全場景雲服務，推出了雲原生資料庫GaussDB，其基於統一的存算分離架構，兼容openGauss及主流開源資料庫生態，支持關系型與非關系型資料庫，並構建了多生態兼容、層次解耦、多副本強一致、數據融合、運算元下推等雲原生能力。GaussDB的極致性能解決了企業海量數據讀寫帶來的壓力。同時，數據跨AZ高可用、RPO=0、RTO秒級，滿足了保險行業監管的要求，且完整的工具鏈，可幫助企業快速完成數據的平滑遷移，確保業務數據0丟失。
目前，華為雲雲原生解決方案已廣泛應用在永安保險、眾惠保險等多家保險行業的標桿企業，幫助企業重塑雲原生業務架構，加速企業數字化升級。
聚八方領航者，論雲原生之道。未來，創原會成員將繼續與各行業的雲原生技術精英一起，持續賦能「新雲原生企業」，加速雲原生技術落地與產業繁榮。
視頻載入中...