❶ 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丢失。
目前，华为云云原生解决方案已广泛应用在永安保险、众惠保险等多家保险行业的标杆企业，帮助企业重塑云原生业务架构，加速企业数字化升级。
聚八方领航者，论云原生之道。未来，创原会成员将继续与各行业的云原生技术精英一起，持续赋能“新云原生企业”，加速云原生技术落地与产业繁荣。
视频加载中...