本期目录
DB-Engines数据库排行榜
新闻快讯
第一段：RDBMS家族
第二段：NoSQL家族
第三段：NewSQL家族
第四段：时间序列
第五段：大数据生态圈
第六段：国产数据库概览
第七段：云数据库
第八段：推出dbaplus Newsletter的想法
第九段：感谢名单
RDBMS家族
①.、性能
①.、账户管理
经过配置,修改密码时,必须带上原密码.在之前的版本,用户登录之后,就可以修改自己的密码.这种方式存在一定安全风险.比如用户登录上数据库后,中途离开一段时间,那么非法用户可能会修改密码.由参数password_require_current控制.
Innodb表必须有主键.在用户没有指定主键时,系统会生成一个默认的主键.但是在主从复制的场景下,默认的主键,会对丛库应用速度带来致命的影响.如果设置sql_require_primary_key,那么数据库会强制用户在创建表、修改表时,加上主键.
BLOB、TEXT、GEOMETRY和JSON字段可以指定默认值了.
①.）Skip Scan
非前缀索引也可以用了.
之前版本只能基于某个列或者多个列加索引,但是不允许在上面做计算,如今这个限制消除了.
GROUP BY ASC和GROUP BY DESC语法已经被废弃,要想达到类似的效果,请使用GROUP BY ORDER BY ASC和GROUP BY ORDER BY DESC.
①.）设置用户变量,请使用SET语句
该变量是控制文件刷新到磁盘的速率,防止磁盘在短时间内饱和.
在以往的版本中,当执行SQL时,产生的临时表都在全局表空间ibtmp1中,及时执行结束,临时表被释放,空间不会被回收.新版本中,会为session从临时表空间池中分配一个临时表空间,当连接断开时,临时表空间的磁盘空间被回收.
group_replication_member_expel_timeout让管理员能更好的依据自身的场景,做出最合适的配置（建议配置时间小于一个小时）.
①.）update连表更新,limit语句
参考：
Online DDL从名字上看很容易误导新手,以为不论什么情况,修改表结构都不会锁表,理想很丰满,现实很骨感,注意这个坑！
有以下两种情况执行DDL操作会锁表的,Waiting for table metadata lock（元数据表锁）：
例：
如果线上有某个慢SQL对该表进行操作,可以使用WAIT n（以秒为单位设置等待）或NOWAIT在语句中显式设置锁等待超时,在这种情况下,如果无法获取锁,语句将立即失败. WAIT 0相当于NOWAIT.
①.、安全性和合规性
RocksDB是Facebook在LevelDB基础上用C++写的高效内嵌式K/V存储引擎.相比LevelDB,RocksDB提供了Column-Family,TTL,Transaction,Merge等方面的支持.目前MyRocks,TiKV等底层的存储都是基于RocksDB来构建.
PostgreSQL发布11版本
①.、PostgreSQL 11的重大增强
citus是PostgreSQL的一款sharding插件,目前国内苏宁、铁总、探探有较大量使用案例.
PostGIS是专业的时空数据库插件,在测绘、航天、气象、地震、国土资源、地图等时空专业领域应用广泛.同时在互联网行业也得到了对GIS有性能、功能深度要求的客户青睐,比如共享出行、外卖等客户.
Pipelinedb是PostgreSQL的一款流计算插件,使用这个创建可以对高速写入的数据进行实时根据定义的聚合规则进行聚合（支持概率计算）,实时根据定义的规则触发事件（支持事件处理函数的自定义）.可用于IoT,监控,FEED实时计算等场景.
agensgraph是兼容PostgreSQL、opencypher的专业图数据库,适合图式关系的管理.
gpdb是兼容PostgreSQL的mpp数据库,适合OLAP场景.近两年,gpdb一直在追赶PostgreSQL的社区版本,预计很快会追上10的PostgreSQL,在TP方面的性能也会得到显著提升.
antdb是以Postgres-XC为基础开发的一款PostgreSQL sharding数据库,亚信主导开发,开源,目前主要服务于亚信自有客户.
MTK是EDB提供的可以将Oracle、PostgreSQL、MySQL、MSSQL、Sybase数据库迁移到PostgreSQL, PPAS的产品,迁移速度可以达到100万行/s以上.
NoSQL家族
MongoDB升级更新MongoDB Mobile和MongoDB Stitch
MongoDB 公司日前发布了多项新产品功能,旨在更好地帮助开发人员在世界各地管理数据.通过利用存储在移动设备和后台数据库的数据之间的实时、自动的同步特性,MongoDB Mobile通用版本助力开发人员构建更快捷、反应更迅速的应用程序.此前,这只能通过在移动应用内部安装一个可供选择或限定功能的数据库来实现.
Apache Cassandra是一款开源分布式NoSQL数据库系统,使用了基于Google BigTable的数据模型,与面向行(row)的传统关系型数据库或键值存储key-value数据库不同,Cassandra使用的是宽列存储模型(Wide Column Stores).与BigTable和其模仿者HBase不同,数据并不存储在分布式文件系统如GFS或HDFS中,而是直接存于本地.
NewSQL家族
TiDB 是一款定位于在线事务处理/在线分析处理（ HTAP: Hybrid Transactional/Analytical Processing）的融合型数据库产品.除了底层的 RocksDB 存储引擎之外,分布式SQL层、分布式KV存储引擎（TiKV）完全自主设计和研发.
TiDB 完全开源,兼容MySQL协议和语法,可以简单理解为一个可以无限水平扩展的MySQL,并且提供分布式事务、跨节点 JOIN、吞吐和存储容量水平扩展、故障自恢复、高可用等优异的特性；对业务没有任何侵入性,简化开发,利于维护和平滑迁移.
TiDB：
PD：
TiKV：
Tools：
①.）TiDB-Lightning
新增企业级特性：
新增SQL特性：
新增内核特性：
Admin UI增强：
时间序列
本期新秀：TimescaleDB发布1.0版本
①.0月底,TimescaleDB 1.0宣布正式推出,官方表示该版本已可用于生产环境,支持完整SQL和扩展.
TimescaleDB是基于PostgreSQL数据库开发的一款时序数据库,以插件化的形式打包提供,随着PostgreSQL的版本升级而升级,不会因为另立分支带来麻烦.
TimescaleDB架构：
数据自动按时间和空间分片(chunk)
更新亮点：
大数据生态圈
该版本中的Greenplum Streem Server组件已经集成了Kafka流式加载功能,并通过了Confluent官方的集成认证,其支持的主要功能如下：
国产数据库概览
K-DB发布数据库一体机版
OceanBase迁移服务发布1.0版本
以下内容包含 OceanBase 迁移服务的重要特性和功能：
①.、架构
①.）完整计算存储分离架构,兼容MySQL协议、语法
计算存储分离体系以松耦合的方式将计算与存储层分别部署,通过标准接口或插件对各个模块和组件进行无缝替换,在计算层与存储层均可实现自由的弹性伸缩.
SequoiaDB巨杉数据库"计算-存储分离"架构详细示意
用户可以根据自身业务特征选择面向交易的SQL解析器（例如MySQL或PGSQL）或面向统计分析的执行引擎（例如SparkSQL）.众所周知,使用不同的SQL优化与执行方式,数据库的访问性能可能会存在上千上万倍的差距.计算存储分离的核心思想便是在数据存储层面进行一体化存储,在计算层面则利用每种执行引擎的特点针对不同业务场景进行选择和优化,用户可以在存储层进行逻辑与物理的隔离,将面向高频交易的前端业务与面向高吞吐量的统计分析使用不同的硬件进行存储,确保在多类型数据访问时互不干扰,以真正达到生产环境可用的多租户与HTAP能力.
①.）接口变更：
云数据库
本期新秀：腾讯发布数据库CynosDB,开启公测
①.、News
产品特性：
使用场景：
官网文档：
本期新秀：京东云DRDS发布1.0版本
京东云DRDS产品有以下主要特性
①.）自动分库分表
通过简单的定义即可自动实现分库分表,将数据实际存放在多个MySQL实例的数据库中,但呈现给应用程序的依旧是一张表,对业务透明,应用程序几乎无需改动,实现了对数据库存储和处理能力的水平扩展.
基于分布式架构的集群方案,多个对等节点同时对外提供服务,不但可有效规避服务的单点故障,而且更加容易扩展.
具有极高的处理能力,双节点即可支持数万QPS,满足用户超大规模处理能力的需求.
兼容绝大部分MySQL语法,包括MySQL语法、数据类型、索引、常用函数、排序、关联等DDL,DML语句,使用成本低.
参考链接：
推出dbaplus Newsletter的想法
dbaplus Newsletter旨在向广大技术爱好者提供数据库行业的最新技术发展趋势,为社区的技术发展提供一个统一的发声平台.为此,我们策划了RDBMS、NoSQL、NewSQL、时间序列、大数据生态圈、国产数据库、云数据库等几个版块.
我们不以商业宣传为目的,不接受任何商业广告宣传,严格审查信息源的可信度和准确性,力争为大家提供一个纯净的技术学习环境,欢迎大家监督指正.
感谢名单
最后要感谢那些提供宝贵信息和建议的专家朋友,排名不分先后.
往期回顾：
NoSQL,指的是非关系型的数据库.NoSQL有时也称作Not Only SQL的缩写,是对不同于传统的关系型数据库的数据库管理系统的统称.
NoSQL用于超大规模数据的存储.（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）.这些类型的数据存储不需要固定的模式,无需多余操作就可以横向扩展.
NoSQL的优点/缺点
优点:
- 高可扩展性
- 分布式计算
- 低成本
- 架构的灵活性,半结构化数据
- 没有复杂的关系
缺点:
- 没有标准化
- 有限的查询功能（到目前为止）
- 最终一致是不直观的程序 （BY三人行慕课）
一般将NoSQL数据库分为四大类：键值(Key-Value)存储数据库、列存储数据库、文档型数据库和图形(Graph)数据库.它们的数据模型、优缺点、典型应用场景.
键值(Key-Value)存储数据库Key指向Value的键值对,通常用hash表来实现查找速度快数据无结构化(通常只被当作字符串或者二进制数据)内容缓存,主要用于处理大量数据的高访问负载,也用于一些日志系统等.
列存储数据库,以列簇式存储,将同一列数据存在一起查找速度快,可扩展性强,更容易进行分布式扩展功能相对局限分布式的文件系统.
文档型数据库,Key-Value对应的键值对,Value为结构化数据,数据结构要求不严格,表结构可变(不需要像关系型数据库一样需预先定义表结构),查询性能不高,而且缺乏统一的查询语法,Web应用.
图形(Graph)数据库,图结构,利用图结构相关算法(如最短路径寻址,N度关系查找等),很多时候需要对整个图做计算才能得出需要的信息,而且这种结构不太好做分布式的集群方案,社交网络,推荐系统等.
NoSQL(NoSQL = Not Only SQL ),意即"不仅仅是SQL",
（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）.这些类型的数据存储不需要固定的模式,无需多余操作就可以横向扩展.
MongDB、 Redis、Memcache
高度组织化结构化数据
结构化查询语言（SQL）
数据和关系都存储在单独的表中.
数据操纵语言,数据定义语言
严格的一致性
基础事务
ACID
关系型数据库遵循ACID规则
事务在英文中是transaction,和现实世界中的交易很类似,它有如下四个特性：
A (Atomicity) 原子性
C (Consistency) 一致性
一致性也比较容易理解,也就是说数据库要一直处于一致的状态,事务的运行不会改变数据库原本的一致性约束.
I (Isolation) 独立性
所谓的独立性是指并发的事务之间不会互相影响,如果一个事务要访问的数据正在被另外一个事务修改,只要另外一个事务未提交,它所访问的数据就不受未提交事务的影响.比如现有有个交易是从A账户转100元至B账户,在这个交易还未完成的情况下,如果此时B查询自己的账户,是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事务提交后,它所做的修改将会永久的保存在数据库上,即使出现宕机也不会丢失.
代表着不仅仅是SQL
没有声明性查询语言
没有预定义的模式
键 - 值对存储,列存储,文档存储,图形数据库
最终一致性,而非ACID属性
非结构化和不可预知的数据
CAP定理
高性能,高可用性和可伸缩性
分布式数据库中的CAP原理(了解)
CAP定理：
Consistency(一致性), 数据一致更新,所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容错性) 可靠性
P: 系统中任意信息的丢失或失败不会影响系统的继续运作.
定理：任何分布式系统只可同时满足二点,没法三者兼顾.
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,
所以呢,根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：
CA - 单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大.
CP - 满足一致性,分区容忍性的系统,通常性能不是特别高.
AP - 满足可用性,分区容忍性的系统,通常可能对一致性要求低一些.
CAP理论就是说在分布式存储系统中,最多只能实现上面的两点.
而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的.
所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点.
说明：C：强一致性 A：高可用性 P：分布式容忍性
举例：
CA：传统Oracle数据库
AP：大多数网站架构的选择
CP：Redis、Mongodb
注意：分布式架构的时候必须做出取舍.
一致性和可用性之间取一个平衡.多余大多数web应用,其实并不需要强一致性.
所以呢牺牲C换取P,这是目前分布式数据库产品的方向.
当下的应用是 SQL 与 NoSQL 一起使用的.
代表项目：阿里巴巴商品信息的存放.
去 IOE 化.
ps：I 是指 IBM 的小型机,很贵的,好像好几万一台；O 是指 Oracle 数据库,也很贵的,好几万呢；M 是指 EMC 的存储设备,也很贵的.
难点：
数据类型多样性.
数据源多样性和变化重构.
数据源改造而服务平台不需要大面积重构.
本文以淘宝作为例子,介绍从一百个并发到千万级并发情况下服务端的架构的演进过程,同时列举出每个演进阶段会遇到的相关技术,让大家对架构的演进有一个整体的认知,文章最后汇总了一些架构设计的原则.
在介绍架构之前,为了避免部分读者对架构设计中的一些概念不了解,下面对几个最基础的概念进行介绍：
Tomcat和数据库分别独占服务器资源,显著提高两者各自性能.
在Tomcat同服务器上或同JVM中增加本地缓存,并在外部增加分布式缓存,缓存热门商品信息或热门商品的html页面等.通过缓存能把绝大多数请求在读写数据库前拦截掉,大大降低数据库压力.其中涉及的技术包括：使用memcached作为本地缓存,使用Redis作为分布式缓存,还会涉及缓存一致性、缓存穿透/击穿、缓存雪崩、热点数据集中失效等问题.
把不同业务的数据保存到不同的数据库中,使业务之间的资源竞争降低,对于访问量大的业务,可以部署更多的服务器来支撑.这样同时导致跨业务的表无法直接做关联分析,需要通过其他途径来解决,但这不是本文讨论的重点,有兴趣的可以自行搜索解决方案.
比如针对评论数据,可按照商品ID进行hash,路由到对应的表中存储；针对支付记录,可按照小时创建表,每个小时表继续拆分为小表,使用用户ID或记录编号来路由数据.只要实时操作的表数据量足够小,请求能够足够均匀的分发到多台服务器上的小表,那数据库就能通过水平扩展的方式来提高性能.其中前面提到的Mycat也支持在大表拆分为小表情况下的访问控制.
这种做法显著的增加了数据库运维的难度,对DBA的要求较高.数据库设计到这种结构时,已经可以称为分布式数据库,但是这只是一个逻辑的数据库整体,数据库里不同的组成部分是由不同的组件单独来实现的,如分库分表的管理和请求分发,由Mycat实现,SQL的解析由单机的数据库实现,读写分离可能由网关和消息队列来实现,查询结果的汇总可能由数据库接口层来实现等等,这种架构其实是MPP（大规模并行处理）架构的一类实现.
目前开源和商用都已经有不少MPP数据库,开源中比较流行的有Greenplum、TiDB、Postgresql XC、HAWQ等,商用的如南大通用的GBase、睿帆 科技 的雪球DB、华为的LibrA等等,不同的MPP数据库的侧重点也不一样,如TiDB更侧重于分布式OLTP场景,Greenplum更侧重于分布式OLAP场景,这些MPP数据库基本都提供了类似Postgresql、Oracle、MySQL那样的SQL标准支持能力,能把一个查询解析为分布式的执行计划分发到每台机器上并行执行,最终由数据库本身汇总数据进行返回,也提供了诸如权限管理、分库分表、事务、数据副本等能力,并且大多能够支持100个节点以上的集群,大大降低了数据库运维的成本,并且使数据库也能够实现水平扩展.
此处需要注意的是,上图中从Nginx层到Tomcat层这样画并不代表全部Nginx都转发请求到全部的Tomcat,在实际使用时,可能会是几个Nginx下面接一部分的Tomcat,这些Nginx之间通过keepalived实现高可用,其他的Nginx接另外的Tomcat,这样可接入的Tomcat数量就能成倍的增加.
在DNS服务器中可配置一个域名对应多个IP地址,每个IP地址对应到不同的机房里的虚拟IP.当用户访问时,DNS服务器会使用轮询策略或其他策略,来选择某个IP供用户访问.此方式能实现机房间的负载均衡,至此,系统可做到机房级别的水平扩展,千万级到亿级的并发量都可通过增加机房来解决,系统入口处的请求并发量不再是问题.
当数据库中的数据多到一定规模时,数据库就不适用于复杂的查询了,往往只能满足普通查询的场景.对于统计报表场景,在数据量大时不一定能跑出结果,而且在跑复杂查询时会导致其他查询变慢,对于全文检索、可变数据结构等场景,数据库天生不适用.所以呢需要针对特定的场景,引入合适的解决方案.如对于海量文件存储,可通过分布式文件系统HDFS解决,对于key value类型的数据,可通过HBase和Redis等方案解决,对于全文检索场景,可通过搜索引擎如ElasticSearch解决,对于多维分析场景,可通过Kylin或Druid等方案解决.
当然,引入更多组件同时会提高系统的复杂度,不同的组件保存的数据需要同步,需要考虑一致性的问题,需要有更多的运维手段来管理这些组件等.
按照业务板块来划分应用代码,使单个应用的职责更清晰,相互之间可以做到独立升级迭代.这时候应用之间可能会涉及到一些公共配置,可以通过分布式配置中心Zookeeper来解决.
如用户管理、订单、支付、鉴权等功能在多个应用中都存在,那么可以把这些功能的代码单独抽取出来形成一个单独的服务来管理,这样的服务就是所谓的微服务,应用和服务之间通过HTTP、TCP或RPC请求等多种方式来访问公共服务,每个单独的服务都可以由单独的团队来管理.此外,可以通过Dubbo、SpringCloud等框架实现服务治理、限流、熔断、降级等功能,提高服务的稳定性和可用性.
通过ESB统一进行访问协议转换,应用统一通过ESB来访问后端服务,服务与服务之间也通过ESB来相互调用,以此降低系统的耦合程度.这种单个应用拆分为多个应用,公共服务单独抽取出来来管理,并使用企业消息总线来解除服务之间耦合问题的架构,就是所谓的SOA（面向服务）架构,这种架构与微服务架构容易混淆,因为表现形式十分相似.个人理解,微服务架构更多是指把系统里的公共服务抽取出来单独运维管理的思想,而SOA架构则是指一种拆分服务并使服务接口访问变得统一的架构思想,SOA架构中包含了微服务的思想.
所谓的云平台,就是把海量机器资源,通过统一的资源管理,抽象为一个资源整体,在之上可按需动态申请硬件资源（如CPU、内存、网络等）,并且之上提供通用的操作系统,提供常用的技术组件（如Hadoop技术栈,MPP数据库等）供用户使用,甚至提供开发好的应用,用户不需要关系应用内部使用了什么技术,就能够解决需求（如音视频转码服务、邮件服务、个人博客等）.在云平台中会涉及如下几个概念：