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的智能化，可对基础设施进行高效的管理，为行业应用开发和迭代赋能，全面帮助企业突破关键应用上云的“雄关漫道”。（文/宁川）