精华内容
下载资源
问答
  • 史上最强的MySQL数据库设计规范(互联网大厂都使用的2021年最新版本)
    千次阅读 多人点赞
    2021-03-26 09:47:09

    原创超级全面的Java技术知识体系思维导图,欢迎浏览下载

    目录

    第一章 概述 1

    1.1. 目的 1

    1.2. 读者对象 1

    1.3. 参考文档 1

    1.4. 术语定义 1

    第二章 数据库设计规范 3

    2.1. 整体规范 3

    2.1.1. 注释 3

    2.1.2. 字符集 3

    2.1.3. 存储引擎 3

    2.1.4. 不依赖数据库特性 3

    2.1.5. 平衡范式与冗余 3

    2.2. 数据库对象规范 4

    2.2.1. 表设计规范 4

    2.2.2. 字段设计规范 7

    2.2.3. 索引设计规范 9

    2.2.4. 主键设计规范 10

    2.2.5. 其他规范 11

    2.3. 命名规范 12

    2.3.1. 基本规范 12

    2.3.2. 库命名规范 12

    2.3.3. 表命名规范 13

    2.3.4. 字段命名规范 14

    2.3.5. 索引命名规范 15

    2.3.6. MySQL关键字 16

    2.4. SQL规范 19

    2.4.1. in/or 19

    2.4.2. select * 19

    2.4.3. union all 19

    2.4.4. 模糊查询 19

    2.4.5. 反向查询 19

    2.4.6. 隐式类型转换 19

    2.4.7. Join 19

    2.4.8. SQL解析 19

    2.4.9. SQL表达式 20

    2.4.10. 多表更新 20

    2.4.11. 交互 20

    2.4.12. Load data 20

    2.4.13. 避免大SQL 20

    2.4.14. 避免大批量 20

    2.4.15. 避免大事务 20

    2.4.16. 索引字段的顺序 20

    2.4.17. insert into必须指定插入列 21

    2.4.18. DDL操作 21

    2.4.19. sysdate() 21

    2.4.20. 避免多余的排序 21

    2.4.21. 聚合函数 21

    2.4.22. 最有效的过滤字段 21

    2.5. 数据库域名规范 22

    2.6. 行为规范 23

    第三章 高并发高可用 24

    3.1. 主从部署 24

    3.1.1. 主从复制 24

    3.1.2. 读写分离 24

    3.1.3. 负载均衡 24

    3.2. 分库分表 25

    3.3. 数据分级 25

    3.4. 其他 25

    概述

    目的

    本文档主要目的是对所有数据库对象(包括库、表、字段、索引、主键、外键、约束、表分区、触发器、存储过程等)的使用场景及使用规范,进行相关的约定,供日后应用开发、数据库设计、数据库维护提供规范性依据。

    读者对象

    参考文档

    无。

    术语定义

    术语解释
    字符集字符集(Character set)是多个字符的集合,字符集种类较多,每个字符集包含的字符个数不同,常见字符集名称:UTF-8字符集,UTF-8-MB4字符集,ASCII字符集、GB2312字符集、BIG5字符集、 GB18030字符集、Unicode字符集等。
    存储引擎用各种不同的技术将数据存储在文件(或者内存)中的机制。每一种技术都使用不同的存储机制、索引技巧、锁定水平并且最终提供广泛的不同的功能和能力。
    数据库特性跟数据自身相关,但区别于其他类型数据库的功能或者特征。
    范式范式,特指数据库设计范式,是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中,这种规则就是范式。关系数据库中的关系必须满足一定的要求,即满足不同的范式。
    冗余特指在数据库设计中,本不属于表实体的属性,但因性能或者其他要求,将这些属性也在本表中存储,定义为冗余。
    索引在关系数据库中,索引是一种单独的、物理的对数据库表中一列或多列的值进行排序的一种存储结构。
    前缀索引在数据库设计中,特指对某个字段前部分内容建立索引,称为前缀索引。
    联合索引联合索引是由多个字段组成的索引。
    主键也称主关键字(primary key),是表中的一个或多个字段,它的值用于唯一地标识表中的某一条记录。
    稠密度特指经过索引后得到的数据占整个表数据的比值。
    聚合函数SQL的基本函数,主要作用是对一组值执行计算,并返回单个值。
    DDL数据定义语言(Data Definition Language),是用于描述数据库中要存储的现实世界实体的语言。
    DML数据操纵语言(Data Manipulation Language, DML)是SQL语言中,负责对数据库对象运行数据访问工作的指令集。
    负载均衡负载均衡(Load Balance)其意思就是分摊到多个操作单元上进行执行,从而共同完成工作任务。
    主从复制特指实现两个数据库数据同步的一种机制。

    数据库设计规范

    数据库对象,包括库、表、字段、索引、主键、外键、约束、表分区、触发器、存储过程等,每种对象都会有它的使用场景及规范。为提高数据库的稳定性、高效性、安全性,降低数据库故障率,对数据库的对象制定以下规范,供日后应用开发、数据库设计和操作提供依据。

    整体规范

    注释

    • 数据库所有对象必须要有注释,包括:表、字段、索引等,并且要保持最新。

    字符集

    • 默认使用utf8mb4字符集,无乱码风险。utf8mb4是utf8的超集,可以获得比utf8更好的兼容性。

    存储引擎

    • 默认使用INNODB存储引擎。 MyISAM引擎从MYSQL 5.5
      版本后查询性能已经没InnoDB高,另外InnoDB的以主键为条件的查询性能是非常高的,且支持事务、行级锁、高并发性能更好、对多核CPU、大内存、SSD等硬件资源支持更好,利用率更高。

    • 如需要使用基他类型的存储引擎,请在DBA的建议下使用。

    不依赖数据库特性

    • 降低对数据库功能的依赖,如在业务上使用了MySQL特性,且这个特性是只有MySQL存在的,对以后的数据库迁移会带来麻烦。

    平衡范式与冗余

    • 并非一定要遵守范式理论,适度的冗余设计,字段长度短而且频繁查询的字段可以冗余到其他表,避免表连接查询,可以极大提升查询效率。

    数据库对象规范

    表设计规范

    控制单库表数量

    • 单库表数量建议控制在500以内。

    控制单表数据量

    • 单表数据量建议控制在1000万以内(参考值)。表的记录数多少合适不能死搬硬套,需要根据服务器的CPU、内存、磁盘IO能力综合评估。比如服务器总内存有168G,数据库总数据文件大小100G,innodb
      缓存池设置为120G,这个时候即便大表有3000万条,也可以全部加载到内存中,性能上完全不会有磁盘IO压力。根据经验值一般热数据占数据总量的10%左右,热数据都能缓存到内存中性能上就不会有磁盘IO压力。

    控制单表字段数量

    • 控制单表单字段数量的目的是为了控制数据行的长度避免出现行迁移和行链接。如果计算行长度避免出现行链接或行迁移呢?MYSQL
      的数据行是存储在数据页中,数据页的大小是16KB(默认16KB),file header、Page
      Header、File Trailer 占用了102字节,Page Directory
      记录数据行在数据页的位置也需要消耗数据页空间,建议把总消耗空间按1KB算,也就是说数据页可以空间还剩15KB。15KB除去行长度可以整除就可以避免行链接,尽量少使用可变长度的大字段可以有效减少行迁移。表列数量建议控制在30个以内。

    冷热数据分离

    • 访问频率较低的大字段拆分出数据表,以免造成IO资源、缓存资源的浪费。经常一起使用的列应该放到一个表中,允许适当冗余,避免更多的关联操作。

    采用合适的分库分表策略

    大表查询效率很低,需要考虑水平拆分。根据业务特性有很多拆分方式。符合时间递增的表,可以根据时间来分,也可以ID的HASH方式来拆分。

    • 如果按HASH散表,表名后缀使用十进制,下标从0开始。考虑后续的扩容,建议使用二叉树分库分表策略。

    • 如果按日期时间散表,表名需要符合YYYY[MM][DD][HH][mm][sss]的格式。

    根据需要设计汇总表

    • 多表关联查询会很慢,可以根据实际情况,考虑在业务上汇总,记录到汇总表。

    字段设计规范

    基本规范

    • 存储相同数据的列名和列类型必须一致,否则会导致隐式转换,造成索引失效,降低查询效率。

    • 在最大限度的满足可能的需要的前提下,字段应该尽可能的设计得短一些,以提高查询的效率,且降低索引对资源的消耗。

    • 数据行的长度不要超过8020字节,如果超过这个长度的话在物理页中插入两行数据就会出现行链接从而造成存储碎片,降低查询效率。

    • 单表列数量建议控制在30个以内。

    • 尽量使用整型字段,代替IP、枚举类型、字符类型、浮点数类型。

    • 所有字段都需要默认值,如有特殊情况,另作讨论决定。

    字符字段

    • 用户名、密码等长度变化不大的字段选择CHAR类型。

    • 其他不确定长度的字段,统一使用varchar相关的类型。

    整型字段

    • 明确无符号的数值,使用 unsigned的整型。

    • 能够用整型的字段尽量整型,提高查询和连接的性能,降低存储开销、CPU计算开销。如enum、ip、小额货币等。

    Enum字段

    • 禁止使用enum,可使用tinyint代替。
      因为修改ENUM需要使用ALTER语句,需要进行DDL操作, ENUM类型的ORDER
      BY操作效率低,需要额外操作

    默认值

    • 所有字段都需要默认值,不允许为null,避免无法使用索引或null值引发BUG,如有特殊情况,可以存储空白字符代替null。

    Null字段难以进行查询优化,索引需要额外的空间,复合索引无效,整体降低数据库处理的性能,也容易导致应用层程序报空指针异常。

    二进制数据

    • 禁止在数据库上存储图片、二进制文件等静态资源,应该使用合适的文件系统,数据库仅存储URL对于二进制多媒体数据、超大文本数据也不要放在数据库字段中。

    Text/Blob字段

    • 一般避免使用text、blob等类型字段,会浪费更多的磁盘和内存空间,非必要的大量的大字段查询会淘汰掉热数据,导致内存命中率急剧降低,影响数据库性能。

    • 考虑使用varchar来代替,如果一定要使用text/blob,要离到单独的扩展表中,如果要用到索引,只能使用前缀索引。

    日期时间字段

    • timestamp类型比较精简,可以提高查询效率,减少磁盘空间及IO,但范围是1970年-2038年,考虑企业的历史及将来,建议使用datetime类型存储日期时间。

    金额字段

    • 禁止使用float、double来定义金额字段,建议使用decimal类型或者bigint类型。

    • 金额字段使用decimal类型,并给予足够的长度及精度。在性能要求比较苛刻的情况下,使用bigint类型,单位是分(如果是其他货币,需要定义其他单位)。

    其他业务字段

    电话字段
    • 考虑到区号或者国家代号可能会涉及到±()等符号,并且需要支持模糊查询,所以应该使用字符类型,如varchar等
    坐标字段
    • 表示坐标(0,0),应该使用两列表示,而不是将“0,0”放在1个列中。

    不建议使用预留字段

    • 预留字段的命名很难做到见名识义。

    • 预留字段无法确认存储的数据类型,所以无法选择合适的类型。

    • 预留字段是一种“过度设计”,我们应该做的就是“按需设计”,在经过详细有效的分析之后,在数据表中只放置必要的字段,而不要留出大量的备用字段。

    索引设计规范

    索引可以提高查询效率,但会降低更新效率,所以索引不是越多越好,原则是能不加就不加,要加的一定得加。

    控制单表索引数量

    • 单表索引数量不超过5个。

    控制单个索引的字段数量

    • 单个索引中的字段数不超过5个。

    对于更新频繁的字段要评估读写比例和创建索引后的性能收益和醒脑静损坏比例再决定是否创建索引

    • 对于频繁更新的字段是否适合创建索引要评估该字段读写比例再决定是否创建索引。比如一个字段每秒更新20次,但每秒查询达到100次,而且是直接通过该字段来定位数据行的,如果该字段没有索引就会导致全表扫描,如果更新也是需要使用该字段定位数据行也会导致更新出现全表扫描,这种情况就是一定要创建索引的。(相对应的一种情况是通过数据行的ID可以定位到数据行,不需要使用被更新字段定位数据行,这种情况就不适合创建索引)。

    禁止在区分度不高的属性上建立索引

    • 如“性别”这种区分度不大的字段,建立索引对查询性能的提升有限,与全表扫描差别不大。

    建立组合索引字段顺序优先级

    • 使用频率高(大量SQL 过滤条件都使用了这个字段)

    • 使用频率高

    • 区分度高范围查询

    建立长字符串字段的前缀索引

    • 保证快速有效过滤数据的同时,节省维护索引的开销。

    避免冗余重复索引

    • 已经建立唯一索引的字段,没有必要再建立与该字段有关的联合索引。

    • 不要建立查询条件里根本不会出现的字段的索引或者联合索引。

    选择合适的索引类型

    • 唯一确定一条记录的一个字段或多个字段要建立主键或者唯一索引,不能唯一确定一条记录,为了提高查询效率建立普通索引。

    建立索引时必须考虑索引返回的记录稠密度

    • 业务通过不唯一索引访问数据时,需要考虑通过该索引值返回的记录稠密度,原则上稠密度最大不能高于0.2,如果稠密度太大,则不合适建立索引了。

    当通过这个索引查找得到的数据量占到表内所有数据的20%以上时,则需要考虑建立该索引的代价,同时由于索引扫描产生的都是随机I/O,其效率比全表顺序扫描的顺序I/O低很多。数据库系统优化query的时候有可能不会用到这个索引。

    注意联合索引的顺序

    • 联合索引中各字段的顺序,要与查询语句的字段顺序保持一致,否则可能无法应用索引。

    • 区分度最高的放在联合索引的最左侧。

    • 使用最频繁的列放到联合索引的左侧。

    • 尽量把字段长度小的列放在联合索引的最左侧。

    主键设计规范

    • 一般不使用联合主键。

    • 必须指定主键,建议使用内存型、数值型字段做主建,以应对大数据高并发的业务场景。如果使用自增列,在一定程度上依赖了数据库自身的特性,同时也要考虑分布式环境的全局唯一性。UUID是字符类型,增加索引磁盘空间及CPU开销,且不具备自增特性。

    其他规范

    在大数据、高并发的互联网业务,架构设计的思路是解放数据库,让应用层承担更到的责任。一般禁止使用与数据库自身特性相关的对象,如存储过程、触发器、视图等,降低业务耦合度,让数据库做最擅长的事情。

    触发器设计规范

    • 禁止使用数据库的触发器特性,请在应用层寻求对应的解决方案。

    • 如有特殊需求,另行研究决定。

    存储过程设计规范

    • 禁止使用数据库的存储过程特性,请在应用层寻求对应的解决方案。

    • 如有特殊需求,另行研究决定。

    函数设计规范

    • 禁止使用数据库的函数特性,请在应用层寻求对应的解决方案。

    • 如有特殊需求,另行研究决定。

    外键设计规范

    • 禁止使用数据库的外键特性,请在应用层寻求对应的解决方案。如有特殊需求,另行研究决定。

    注意:外键会导致表与表之间耦合,update与delete操作都会涉及相关联的表,影响sql 的性能,甚至会造成死锁,大数据高并发业务场景下容易造成数据库性能大幅下降。

    约束设计规范

    • 本规范禁止使用数据库的约束特性,请在应用层寻求对应的解决方案。如有特殊需求,另行研究决定。

    注意:主键自身会有唯一性约束,其他约束如check、外键等,建议在应用层实现。

    表分区设计规范

    • 本规范禁止使用数据库的表分区特性,请在应用层寻求对应的解决方案。如有特殊需求,另行研究决定。

    注:分区表在物理上表现为多个文件,在逻辑上表现为一个表,实际性能不是非常好,且管理维护成本较高,建议采用物理分表的方式管理大数据,请参考分库分表策略相关的文档。

    命名规范

    基本规范

    对数据库所有对象的命名,进行以下约定:

    • 统一小写格式。

    • 统一使用英文字母,数字和下划线来命名,禁止使用其他字符,如中横线等。

    • 不超过32个字符,须见名知意,易于辨识。

    • 禁止使用拼音来命名,禁止拼音英文混用。

    • 禁止使用关键字,可以加上前缀区别关键字。

    • 临时库、临时表名必须以tmp为前缀并以时间戳为后缀。

    • 备份库、备份表名必须以bak为前缀并以时间戳为后缀。

    • 不同表中,存储相同数据的列名要保持一致。

    库命名规范

    参考格式:<前缀>[_业务类型/产品类型/其他类型]_<库名>。

    • 前缀:必选项,如gtmc。

    • 类型:非必选,但需要所有库要统一选还是不选。参考类型:产品类型/业务类型/其他类型。

    • 库名:应尽可能和所服务的业务模块名一致。

    参考命名:

    <前缀>_<库名><前缀>_<类型>_<库名>
    项目缩写_order项目缩写_ssp_order
    项目缩写_goods项目缩写_ssp_goods
    项目缩写_payment项目缩写_ssp_payment
    项目缩写_member项目缩写_ssp_member
    项目缩写_merchant项目缩写_ssp_merchant
    项目缩写_marketing项目缩写_ ssp_marketing
    项目缩写_asset项目缩写_ssp_asset
    项目缩写_cms项目缩写_ssp_cms
    …………

    表命名规范

    常规表命名

    参考格式:<库名/库名缩写>_<表名/表名缩写>。

    • 表名应尽可能和所服务的业务模块名一致。

    • 表名应尽量包含与所存放数据对应的单词或者缩写。

    • 同一个模块的表应尽量以模块名(或缩写)为前缀。

    参考命名:

    <库名缩写>_<表名/表名缩写>
    ast_account
    ast_account_recharge
    ast_account_withdraw
    ast_account_consume
    ……

    主从表命名

    主表参考格式:请参考上一节描述。

    从表参考格式:<主表名>_<从表关键字>。

    • 从表关键字:优先选从表实体名,如果从表的对象类型不唯一,可以选择item类似的词汇来表达,需要全局统一,形成规范。

    参考命名:

    <主表名>_<从表实体><主表名>_<其他词汇>
    ord_orderord_order
    ord_order_goodsord_order_item
    ord_member
    ord_member_address
    …………

    关联表命名

    参考格式: <表名1>_<表名2>_rel。

    参考命名:

    表名1表名2<表名1>_<表名2>_rel
    bas_categorybas_attributebas_category_attr_rel

    字段命名规范

    参考格式:[前缀_]<字段名>。

    • 一般不用前缀(当和关键词冲突的可以考虑加前缀区别)。

    • 字段名称也应尽量保持和实际数据相对应。

    参考命名:

    [前缀_]<字段名>
    account_id
    account_name
    account_type
    owner_id
    owner_type
    mobile
    ……

    索引命名规范

    普通索引:idx_<表名/表名缩写>_<列名/列名缩写[_列名/列名缩写]>。

    唯一索引:uidx_<表名/表名缩写>_<列名/列名缩写[_列名/列名缩写]>。

    备注:

    • 【idx】:表示索引,英文index。

    • 【uidx】:表示唯一索引,英文unique index。

    • 联合索引名称应尽量包含所有索引键字段名或缩写,且各字段名在索引名中的顺序应与索引键在索引中的索引顺序一致。

    参考命名:

    普通索引唯一索引
    idx_ord_order_numuidx_account_oid_otype:(ownerId,ownerType)
    …………

    MySQL关键字

    MySQL关键字
    ADDALLALTER
    ANALYZEANDAS
    ASCASENSITIVEBEFORE
    BETWEENBIGINTBINARY
    BLOBBOTHBY
    CALLCASCADECASE
    CHANGECHARCHARACTER
    CHECKCOLLATECOLUMN
    CONDITIONCONNECTIONCONSTRAINT
    CONTINUECONVERTCREATE
    CROSSCURRENT_DATECURRENT_TIME
    CURRENT_TIMESTAMPCURRENT_USERCURSOR
    DATABASEDATABASESDAY_HOUR
    DAY_MICROSECONDDAY_MINUTEDAY_SECOND
    DECDECIMALDECLARE
    DEFAULTDELAYEDDELETE
    DESCDESCRIBEDETERMINISTIC
    DISTINCTDISTINCTROWDIV
    DOUBLEDROPDUAL
    EACHELSEELSEIF
    ENCLOSEDESCAPEDEXISTS
    EXITEXPLAINFALSE
    FETCHFLOATFLOAT4
    FLOAT8FORFORCE
    FOREIGNFROMFULLTEXT
    GOTOGRANTGROUP
    HAVINGHIGH_PRIORITYHOUR_MICROSECOND
    HOUR_MINUTEHOUR_SECONDIF
    IGNOREININDEX
    INFILEINNERINOUT
    INSENSITIVEINSERTINT
    INT1INT2INT3
    INT4INT8INTEGER
    INTERVALINTOIS
    ITERATEJOINKEY
    KEYSKILLLABEL
    LEADINGLEAVELEFT
    LIKELIMITLINEAR
    LINESLOADLOCALTIME
    LOCALTIMESTAMPLOCKLONG
    LONGBLOBLONGTEXTLOOP
    LOW_PRIORITYMATCHMEDIUMBLOB
    MEDIUMINTMEDIUMTEXTMIDDLEINT
    MINUTE_MICROSECONDMINUTE_SECONDMOD
    MODIFIESNATURALNOT
    NO_WRITE_TO_BINLOGNULLNUMERIC
    ONOPTIMIZEOPTION
    OPTIONALLYORORDER
    OUTOUTEROUTFILE
    PRECISIONPRIMARYPROCEDURE
    PURGERAID0RANGE
    READREADSREAL
    REFERENCESREGEXPRELEASE
    RENAMEREPEATREPLACE
    REQUIRERESTRICTRETURN
    REVOKERIGHTRLIKE
    SCHEMASCHEMASSECOND_MICROSECOND
    SELECTSENSITIVESEPARATOR
    SETSHOWSMALLINT
    SPATIALSPECIFICSQL
    SQLEXCEPTIONSQLSTATESQLWARNING
    SQL_BIG_RESULTSQL_CALC_FOUND_ROWSSQL_SMALL_RESULT
    SSLSTARTINGSTRAIGHT_JOIN
    TABLETERMINATEDTHEN
    TINYBLOBTINYINTTINYTEXT
    TOTRAILINGTRIGGER
    TRUEUNDOUNION
    UNIQUEUNLOCKUNSIGNED
    UPDATEUSAGEUSE
    USINGUTC_DATEUTC_TIME
    UTC_TIMESTAMPVALUESVARBINARY
    VARCHARVARCHARACTERVARYING
    WHENWHEREWHILE
    WITHWRITEX509
    XORYEAR_MONTHZEROFILL

    具体版本的关键字,请参考以下地址:

    https://dev.mysql.com/doc/refman/8.0/en/keywords.html

    https://dev.mysql.com/doc/refman/5.7/en/keywords.html

    https://dev.mysql.com/doc/refman/5.6/en/keywords.html

    SQL规范

    in/or

    • or的效率是n级别,in的效率是log(n)级别。

    • 应尽量避免在 where 子句中使用 or
      来连接条件,否则将导致引擎放弃使用索引而进行全表扫描。

    • in的个数建议控制在1000以内,避免使用在大集合中使用in。

    select *

    • 禁止使用SELECT
      *,应用层应指定所要的字段,避免消耗不必要的CPU、硬盘IO及网络带宽。

    union all

    • 使用union all替代union,union有去重开销,尽量由应用层实现去重。

    模糊查询

    • 禁止使用全模糊查询,无法使用索引,导致全表扫描。

    • 可以使用右模糊查询,如like‘xxx%’,可以正常应用索引。

    反向查询

    • 禁止使用反向查询,如NOT、!=、<>、!<、!>、NOT IN、NOT
      LIKE等,会导致全表扫描。

    隐式类型转换

    • 禁止使用隐式转换,会导致索引失效。

    Join

    • 大表连接字段和其他过滤条件字段没有合适的索引,禁止大表使用JOIN查询。

    注意:大表join查询如果全表扫描,会产生临时表,消耗较多内存与CPU,极大影响数据库性能。

    SQL解析

    • 尽量避免相同功能的语句由于格式的不同,而导致多次解析。

    SQL表达式

    • 避免在数据库中使用数学运算、函数等,容易将业务逻辑和DB耦合在一起,且容易导致索引失效。

    多表更新

    • 禁止单SQL语句同时更新多个表。

    交互

    • 减少与数据库的交互次数。

    Load data

    • 使用load data导数据,load data比insert快约20倍。

    避免大SQL

    • 一条sql只能在一个cpu运算,大语句拆小语句,减少锁时间。

    • 大sql需要拆分成小sql,充分利用多核CPU。

    避免大批量

    • 大批量写操作会产生大量日志,日志传输和恢复所需要的时间过长,造成主从环境数据同步严重延迟。

    • Insert语句中,根据测试,批量一次插入1000条时效率最高,多于1000条时,要拆分,多次进行同样的插入,应该合并批量进行。

    避免大事务

    • 遵循事务相关性最小原则。

    • 事务尽量简单,事务时间尽可能短。大批量修改数据,一定是在一个事务中进行的,这就会造成表中大批量数据进行锁定,从而导致大量的阻塞,阻塞会对数据库的性能产生非常大的影响。

    索引字段的顺序

    • 查询条件中的字段,要把最有效的索引字段写在前面,同时要注意联合索引中的字段顺序。

    insert into必须指定插入列

    • 禁止使用INSERT INTO t_xxx VALUES(xxx),必须显示指定插入的列属性。

    DDL操作

    • 应用程序里的 SQL 语句,禁止一切 DDL 操作。

    • 如有特殊需要,必需与 DBA 协商同意方可使用。

    sysdate()

    • sysdate取的是系统主机时间,在
      binlog为语句模式时会原文传输,导致主从库数据产生差异。所以 binlog
      强烈建议使用行(row)模式。

    避免多余的排序

    • 使用 GROUP BY 时,默认会进行排序,当你不需要排序时,可以使用order by null。

    聚合函数

    注意以下事项:

    • 使用count(column_name)代替count(1)和count(*)。

    • count(column_name)计算该列不为 NULL 的记录条数。

    • count(distinct column_name)计算该列不为 NULL 的不重复值数量。

    • count()函数不会返回 NULL,但 sum()函数可能返回 NULL。

    最有效的过滤字段

    • 使用最有效的过滤字段,where 字句中的过滤条件返回的记录数以少为好。

    数据库域名规范

    • 禁止使用IP连接数据库。
    各个环境域名规范(xxx业务模块)
    开发环境d.xxx.db
    测试环境t.xxx.db
    生产环境p.xxx.db
    …………
    主从库域名命令规范
    生产环境主库p.xxx.db
    生产环境从库01ps-01.xxx.db
    生产环境从库02Ps-02.xxx.db
    …………

    备注:

    • 生产环境,英文取Production,缩写p。

    • 开发环境,英文取Development,缩写d。

    • 测试环境,英文取Test,缩写t。

    • 从库,英文取Slave,缩写s。

    • 主库,英文取Master,缩写m。

    行为规范

    行为规范
    禁止禁止分配super权限的账号给应用程序使用,super权限只能留给DBA处理问题的账号使用。
    禁止禁止在数据库中存储明文密码。
    禁止禁止从开发环境、测试环境直连线上数据库。
    禁止禁止在线上做数据库压力测试。
    禁止禁止使用IP连接数据库,应该使用内网域名。
    禁止禁止在生产环境创建test库。
    禁止合理分配数据库账号所拥有的权限,如应用程序账号原则上不准有drop权限。
    注意导入导出数据必须提前通知DBA,并让DBA协助观察。
    注意促销活动或者上线新功能必须提前通知DBA进行流量评估。
    注意不在业务高峰期批量更新,查询数据库。
    注意进行DDL/DML操作时,需要DBA进行审查,并在执行过程中观察服务负载等各种指标。
    注意对特别重要的库表,提前与DBA沟通确定维护和备份优先级。

    高并发高可用

    在大数据高并发的场景之下,数据库最终会成为性能的瓶颈,如何在巨量的数据请求之下,提供稳定可靠的数据服务,将是对数据库设计终极考验,设计者应该未雨绸缪,及早策划应对。

    以下是对数据库高并发、高可用设计的一些基本概括,仅供数据库设计者参考。

    主从部署

    数据库采用主从部署方式,这是目前最简单的高可用方式。主从部署,主写从读,读写分离。当读操作大于写操作的时候,这种方案带来的性能提升是很明显的。

    主从复制

    几乎所有的主流数据库都支持复制,这是进行数据库简单扩展的基本手段。下面以Mysql为例来说明,它支持主从复制,配置也并不复杂,只需要开启主服务器上的二进制日志以及在主服务器和从服务器上分别进行简单的配置和授权。Mysql的主从复制是依据主服务器的二进制日志文件进行的,主服务器日志中记录的操作会在从服务器上重放,从而实现复制,所以主服务器必须开启二进制日志,自动记录所有对于主数据库的更新操作,从服务器再定时到主服务器取得二进制日志文件进行重放则完成了数据的复制。主从复制也用于自动备份。

    读写分离

    为保证数据库数据的一致性,我们要求所有对于数据库的更新操作都是针对主数据库的,但是读操作是可以针对从数据库来进行。大多数站点的数据库读操作比写操作更加密集,而且查询条件相对复杂,数据库的大部分性能消耗在查询操作上了。
    主从复制数据是异步完成的,这就导致主从数据库中的数据有一定的延迟,在读写分离的设计中必须要考虑这一点。对于当前用户就需要读主数据库,对于其他访问量更大的外部用户就可以读从数据库。

    负载均衡

    在读写分离的方式使用主从部署方式的数据库的时候,会遇到一个问题,一个主数据库对应多台从服务器,对于写操作是针对主数据库的,数据库个数是唯一的,但是对于从服务器的读操作就需要使用适当的算法来分配请求啦,尤其对于多个从服务器的配置不一样的时候甚至需要读操作按照权重来分配。
    对于上述问题可以使用数据库方向代理来实现。就像WEB反向代理服务器一样,Mysql
    Proxy同样可以在SQL语句转发到后端的Mysql服务器之前对它进行修改。

    分库分表

    随着时间增长,主要的业务表数据会急剧增长,如果是单库单表的形式,就目前的硬件水平,很容易就会达到性能瓶颈,对主要的业务进行分库分表是最终的解决方案。

    分库策略建议选择了“二叉树分库”策略,主要是方便日后扩容,降低数据迁移的成本及出错风险。所谓“二叉树分库”指的是:在进行数据库扩容时,都是以2的倍数进行扩容。比如:1台扩容到2台,2台扩容到4台,4台扩容到8台,以此类推。这种方式扩容时,只需DBA进行表级的数据同步,而不需要进行行级数据同步。

    光有分库依然不够的,在同一数据库中,对多个表进行并发更新的效率要远远大于对一个表进行并发更新,所以在每个分库中都可以再分表。

    数据分级

    根据数据的读写频率、实时性要求可以对数据进行分级处理。

    第1级:如订单数据和支付数据,对实时性和精确性要求很高,所以不添加任何缓存,读写操作将直接操作数据库。

    第2级:用户相关数据,具有读多写少的特征,所以我们使用一些缓存机制,如redis等。

    第3级:配置信息,这些数据和用户无关,具有数据量小,频繁读,几乎不修改的特征,所以我们使用本地内存进行缓存。

    其他

    主数据库的,数据库个数是唯一的,但是对于从服务器的读操作就需要使用适当的算法来分配请求啦,尤其对于多个从服务器的配置不一样的时候甚至需要读操作按照权重来分配。
    对于上述问题可以使用数据库方向代理来实现。就像WEB反向代理服务器一样,Mysql
    Proxy同样可以在SQL语句转发到后端的Mysql服务器之前对它进行修改。

    分库分表

    随着时间增长,主要的业务表数据会急剧增长,如果是单库单表的形式,就目前的硬件水平,很容易就会达到性能瓶颈,对主要的业务进行分库分表是最终的解决方案。

    分库策略建议选择了“二叉树分库”策略,主要是方便日后扩容,降低数据迁移的成本及出错风险。所谓“二叉树分库”指的是:在进行数据库扩容时,都是以2的倍数进行扩容。比如:1台扩容到2台,2台扩容到4台,4台扩容到8台,以此类推。这种方式扩容时,只需DBA进行表级的数据同步,而不需要进行行级数据同步。

    光有分库依然不够的,在同一数据库中,对多个表进行并发更新的效率要远远大于对一个表进行并发更新,所以在每个分库中都可以再分表。

    数据分级

    根据数据的读写频率、实时性要求可以对数据进行分级处理。

    第1级:如订单数据和支付数据,对实时性和精确性要求很高,所以不添加任何缓存,读写操作将直接操作数据库。

    第2级:用户相关数据,具有读多写少的特征,所以我们使用一些缓存机制,如redis等。

    第3级:配置信息,这些数据和用户无关,具有数据量小,频繁读,几乎不修改的特征,所以我们使用本地内存进行缓存。

    其他

    数据库在系统中的定位极为重要,需要精细化设计部署,同时需要应用层架构的配合,方能实现良好的水平扩展,最终实现高并发高可用。

    更多相关内容
  • 最强数据库工具——IDEA

    千次阅读 2019-06-15 11:25:19
    本文介绍了 IDEA 自带的数据库工具,功能强大、操作便捷、主题美观,编程与数据库操作无缝切换,非常高效,赶紧来看看吧!

    先来说说其他一些非常有名的数据库工具,比如Navicat、Sqlyong、PL/SQL等。它们有非常多的优点,有一些功能让我们喜欢使用。然后我觉得有这些不足:

    • Navicat 提供了每一种数据库工具,MySQL、PostgreSQL、MongoDB、MariaDB、SQL Server、Oracle、SQLite, 收费都很贵。Navicat Premium 支持各种数据,更贵;
    • Navicat 快捷键比较少;
    • SQLyog 只支持 MySQL,只支持 Windows;
    • PL/SQL 是 Oracle 数据库工具,感觉有点丑陋啊;
    • 都不能自定义主题,不够美观!

    另外,我觉得编程的过程,同时需要频繁地与数据库交互,因此总是需要在编程工具与数据库工具来回切换,费时费力。

    接下来就看看今天介绍的主角——IntelliJ IDEA。IDEA 自带的数据库工具,完全能满足上面所说的各种功能。

    IDEA 集成编程和数据库与一身,编程和数据库操作可以无缝切换,简直太完美了。

    IDEA 支持各种各样的数据库。IDEA 在手,操作所有!
    支持各种数据库

    支持非常多的快捷键操作。只要是频繁的操作,都有对应的快捷键,操作起来不要太溜了!

    • 修改数据库表名 Shift + F6(同修改文件);
    • 修改表结构 Command + F6;
    • 运行 SQL 命令 Command + Enter;
    • 查看表结构 Command + B;
    • ……
      在这里插入图片描述

    不仅如此,IDEA 自带的数据库工具也有强大的功能。

    • SQL 命令自动补全肯定是支持的;
    • 使用 Command + Enter 运行 SQL 的时候,会提示你运行编辑器的哪个 SQL,可以运行单个,可以运行所有,甚至可以运行子语句;
      提示运行哪个sql
    • 打开多个 Console 在里面写命令(也就是建了多个连接),下次打开的时候,命令依然在,根本不需要手动保存常用的 SQL;
    • 有历史命令记录,之前运行的 SQL 删除了也没有关系;
      历史命令记录
    • 查询结果可以导出各种格式:Insert 语句、Update 语句、表格等,可以导出文件或者导出到剪切板;
      导出结果
    • 每个数据库、表都可以设置 Color,标注重点;
      标注颜色
    • 查看表的引用(就像查看类/类的方法在哪使用一样),可以快速定位到使用该表的外键、存储过程等;
      查找引用
    • 在 mybatis mapper 文件中,点击查询的表,可以快速在数据库工具定位到该表。还可以直接运行 mapper 中的 sql 语句,真的是无缝连接啊!
    • 修改主题,哪个顺眼用哪个(就是修改 IDEA 的主题);

    你可能说 IDEA 正版也挺贵的啊,可以它支持 Java 编程,Python编程,Go编程,支持各种数据库连接……简直是一个 IDEA就是 jetbrains 的全家桶啊。

    你要是不编程,只是操作数据库,可以使用 DataGrip,可以说 IDEA 的数据库工具就是 DataGrip。

    我见过很多人使用 IDEA 来编程,但是竟然不知道 IDEA 有这个强大的数据库工具,真是太可惜了!

    我不喜欢在电脑上安装太多的软件,喜欢把一个软件用好。IDEA 的功能太强大了,虽说我们 80% 的时间只用了 20% 的功能,那就赶紧扩展一下 IDEA 的 "20%"吧。

    另外,如果你只喜欢使用命令行操作数据库,可以试试 MyCLI,它支持命令补全和语法高亮,让你的操作更溜!

    展开全文
  • 来看 Databasir 是如何颠覆数据库文档管理这一细分场景的!

    背景

    在软件行业,API 文档的自动化有着非常广泛而成熟的方案,但数据库模型文档的自动化却还是一片蓝海,我曾在网上搜寻良久,但并没有找到一款能同时满足我以下需求点的产品

    1. 自动化:基于数据库自动生成文档
    2. 版本化:文档历史版本回溯,版本差异对比
    3. 团队化:适应不同团队结构,多样性功能为跨团队协作赋能
    4. 个性化:给予使用者一定的文档定制能力

    鉴于此,我利用业余的时间开发并开源了 在这里插入图片描述
    这个项目,它专注于数据库文档的管理,核心能力就是上面提到的自动化、版本化、团队化和个性化四点。

    如题,如果有更好的产品欢迎留言指出,给我一个奋斗的目标,当然这里也别忘点赞收藏一气呵成 !

    项目地址:https://github.com/vran-dev/databasir

    文档地址:https://doc.databasir.com

    问题

    在进入正题之前,我想先聊一聊在数据库文档维护这个细分场景下,我们平时遇到的一些问题。

    一、没有文档

    这是最普遍的一个问题,没有人会否认文档对一个团队的价值,但文档的维护成本也经常让人望而却步

    二、时间有限,这次就不写文档了

    在人力、时间等资源都有限的情况下我们通常会暂时放弃文档的维护而优先完成业务目标(这本无可厚非),长此以往就会导致文档内容与业务模型之间的差异越来越大,即文档失真了。

    三、百家齐放,格式标准不统一

    每个人对文档的格式标准都有自己的想法,只是团队内部消化的话,大家的容忍度还是很高的,如果涉及跨团队协作的话,一个统一的格式标准能提高内容质量的最低下限。

    四、失忆症,忘记补充文档

    模型的变更 80% 的场景都是增量变化,比如加个字段、加一张表等,加了字段和表以后如果忘了更新文档就会造成前面提到的文档失真,但这非刻意为之,更类似于失忆症,根本原因与第二点不同。

    现实中的问题远不止这些,但我们可以看看 Databasir 面对这些场景给出的答案,下面就进入 Show time 吧。

    自动化,文档的事儿你不用操心

    Databasir 基于 JDBC 实现了对数据库表、列、索引、外键等结构的解析,通过解析后的元数据再自动生成标准化的文档内容,从而替代了人工输出文档这种传统方式,节省人力的同时又降低了错误率。

    目前 Databasir 生成的文档内容包含以下信息

    • 表信息
    • 列信息
    • 索引信息
    • 外键信息
    • 触发器信息(仅 Mysql 支持)

    文档页面的布局采用了经典的两栏布局,左侧显示所有的表信息,右侧显示文档的详细内容,如下图所示

    在这里插入图片描述

    到这儿还算不上自动化,只能算是半自动化,因为每次模型结构有变更的话还需要手动再同步一下,如果忘了同步就会造成前面提到的文档失真问题。

    为了完全的自动化,Databasir 提供了定时自动同步机制,用户可以通过 cron 表达式设置同步时间。

    下图展示了定时同步的配置页面

    在这里插入图片描述

    系统会根据配置的时间定时检查模型是否有变更,如果有变更的话就会更新并生成一个新的文档版本,并通过邮件的形式将变更内容通知到相关方。

    在这里插入图片描述

    除了标准的文档内容以外,Databasir 还支持 UML 格式文档生成,如果业务模型有使用到外键,那 UML 之间还能自动根据外键关系生成关联箭头。

    在这里插入图片描述

    版本化,内容变更一目了然

    文档版本化可以让我们将文档轻松的回溯到任意指定存档点,在 Databasir 中版本号目前是一个递增的数字,数字越大代表版本越新。

    在同步文档时检测到模型有变更才会创建新的版本号,这里的检测使用到了自研的 DIFF 引擎,目前支持以下内容的变更检测

    1. 数据库信息,比如版本号、产品切换
    2. 表信息,基于名称比对其他字段的变更,比如注释变更
    3. 列信息,基于名称比对其他字段的变更,比如类型变更,注释变更
    4. 索引信息,基于名称比对其他字段的变更,比如关联列变更
    5. 触发器信息,基于名称比对其他字段的变更
    6. 外键信息,基于名称比对其他字段的变更,比如关联列变更

    下图展示了版本的切换功能
    在这里插入图片描述

    得益于自研的 DIFF 引擎,Databasir 的文档内容可以实现任意版本的差异对比。

    在文档页面启用显示版本差异开关,然后选择要对比的旧版本

    在这里插入图片描述

    再看一眼上图,文档内容通过三个高亮颜色来区分差异类型

    • 绿色:表示新增的内容
    • 红色:表示被删除的内容
    • 黄色:表示被修改的内容

    比如下图我选择了一个版本号为 18 的内容与当前版本做对比,系统提示有以下变更内容

    • dept_emp 表被修改
    • document_description 被修改
    • oauth_app 是新增的表

    在这里插入图片描述

    表具体的修改内容,可以在表内容展示位置查看,如下图就展示了 document_description 的具体变更内容

    注意黄色的 content 字段由两行组成,其中高亮黄色标识是当前版本的信息,灰色的是旧版本的信息。

    团队化,该有的都有了

    既然是面向团队的文档管理产品,那么自然就得考虑团队通常需要的功能

    • 权限
    • 协作
    • 系统集成
    • 审计

    先说权限, Databasir 的基本理念是开放,即所有合法的用户都应该有权限查看团队的文档,这样做可以保证信息的价值最大化,避免孤岛效应。

    为此,在 Databasir 中将用户分为四种角色

    • 普通用户:即能登录系统的用户,能查看所有分组和所有文档
    • 组员:某个分组的普通成员,拥有所属分组的所有读权限,部分写权限
    • 组长:分组的负责人,拥有所属分组的所有权限
    • 系统管理员:拥有系统最高权限

    在这里插入图片描述

    在这里插入图片描述

    而在协作方面,文档内容支持针对表、列、索引进行跨团队的讨论

    在这里插入图片描述

    系统集成方面,Databasir 支持 Github / Gitlab 的 OAuth2 登录配置,仅需简单的配置即可

    操作审计方面,Databasir 支持完整的系统日志查看

    在这里插入图片描述

    个性化,20% 的需求也满足

    程序员对功能的要求是最为挑剔的,既要简单又不能复杂,在这方面 Databasir 尽管不能做到 100% 满意,那也是为这 20% 的需求付出了 80% 的努力。

    第一个个性化的能力就是数据库类型的扩展。

    Databasir 为 Mysql 和 Postgresql 两款数据库提供了开箱即用的配置,但这并不代表其他数据库就不能用了,理论上 Databasir 是支持所有拥有 JDBC 驱动的数据库类型的,比如常见的

    • sqlserver
    • oracle
    • h2

    扩展它们只需要简单的图形化配置即可,如下图所示

    在这里插入图片描述

    用户可以在 Maven 仓库找到对应的数据库 JDBC 驱动地址填进表单,Databasir 负责下载并动态加载驱动去连接数据库。

    注意哦,由于某些众所周知的原因,驱动的下载地址请尽量选择国内的公共镜像仓库,比如阿里云或企业自建的私库。

    除了数据库的扩展外,Databasir 也努力支持为文档内容进行自定义,比如文档内容中的表格头默认都是英文字段显示,如下

    在这里插入图片描述

    这些你都可以通过模板进行编辑,下图就展示了将表头的英文替换成了中文,未来将还会支持字段的隐藏与展示

    在这里插入图片描述

    保存以后再次查看文档,所有的表头就是我们自己设置的中文名称了,而且导出的文档文件也同样生效

    在这里插入图片描述

    未来规划

    由于时间和精力有限,Databasir 目前尚有许多功能正在规划之中,短期内会着重关注以下几点

    • 提供更多的事件通知,比如被加入分组、成为组长等
    • 提供文档内容自定义程度,比如字段的展示与隐藏,字段值自定义等
    • 丰富文档文件导出格式,比如 Excel、DOC、PDF 等
    • 项目质量,补充足够的单元测试

    结语

    文档的重要性是毋庸置疑的,随着时间线的拉长,它的价值回报会越来越高,但对于初创团队来说生存才是第一要务,短期的高成本与低收益让团队不得不做出暂时放弃维护文档的决策,而 Databasir 的目标就是要解决这个矛盾点,在占用极低资源的情况下让团队不仅能活在当下,还能立足未来。

    如果你对这个产品有兴趣,请在 Github 点击 star 持续关注发展

    Github:https://github.com/vran-dev/databasir

    文档地址:https://doc.databasir.com

    项目反馈:https://github.com/vran-dev/databasir/issues

    如果你有更好的建议,也可以通过公众号(vran)私信反馈

    展开全文
  • 数据库排名年度盘点 说到盘点,首先肯定得看看DB-Engines的全球数据库排名。下表是2017年1月份前20名数据库引擎最新排名。 DB-Engines 2017-01数据库前20名列表DB-Engines 2017-01数据库前20名列表 ​DB-Engines...

    数据库排名年度盘点

    说到盘点,首先肯定得看看DB-Engines的全球数据库排名。下表是2017年1月份前20名数据库引擎最新排名。

    16b45770de8386a52cc92dd2e87abf0f713d72da

    DB-Engines 2017-01数据库前20名列表DB-Engines 2017-01数据库前20名列表

    ​DB-Engines这个排名在业界引用得非常多,权威性也很高,总体来说比较客观,它不像很多咨询机构采用市场调查,或者某个数据库厂商发布的数据,而是通过以下6个方面的统计数据来综合评估各个数据库产品得分并给出综合排名:

    1. 数据库相关网站数量(当前通过google、bing、yandex搜索引擎统计)
    2. 公众关注度(通过Google trends计算)
    3. 技术讨论活跃度(通过Stack Overflow、DBA Stack Exchange问答及用户统计)
    4. 招聘职位(通过Indeed、Simply Hired统计)
    5. 专业档案(通过LinkedIn、Upwork统计)
    6. 社交网络信息(通过Twitter统计)

    DB-Engines这个方法我认为比较科学,我个人也比较喜欢用这种方式来快速分析事物活跃情况与趋势。当然,这个排名只是反应全球流行程度,不能反应出产品营收情况,也不代表国内流行度排名。下图上各数据库产品的竞争关系及客户流向示意图:

    dcd35a82978a2db3d81ec3c2b138f99b1075efc9

    各数据库产品的竞争关系及客户流向示意图各数据库产品的竞争关系及客户流向示意图

    从排名来看Oracle、MySQL、SQL Server三大数据库产品是绝对遥遥领先,呈三足鼎立局面。PostgreSQL、MongoDB比较稳的站在前五,得分也不相上下,两家一直在争夺老四的位置。DB2曾经是数据库的领导者,但近几年发展乏力,在持续下滑,特别是互联网行业及中小企业IT里基本没有DB2的身影,在金融等领域也受到非常大的挑战,估计明年老六的位置也危险。MongoDB、Redis、Elasticsearch、Neo4j在自己的领域取得了领导地位。

    总体来说,去年MySQL、SQLServer、PostgreSQL、MongoDB、Redis、 Elasticsearch 都是市场大赢家,在自家的地盘都发展得非常不错。而Oracle、DB2、Access、Sybase几家都比较悲催,活跃度在不停下滑。

    93c870f6851f53733586bd7b9e7474fb7deaea82

    2013年以来几大主流数据库排名变化整体趋势2013年以来几大主流数据库排名变化整体趋势

    ​上图是2013年以来几大主流数据库排名变化整体趋势。

    62dd6bfeec86f38063c132fa465ac23a13c02209

    2013年以来开源数据库与商业数据库的发展趋势分析

    上图是2013年以来开源数据库与商业数据库的发展趋势分析,整体大家能明显感受到开源数据库都呈良好的发展势头,而商业数据库的市场被慢慢吞食,但从近一年发展趋势来看,开源数据库并没有完全打败商业数据库的势头,未来很长时间还会是激烈竞争状态,目前商业数据库主要是靠Oracle、SQLServer在支撑。

    3ff6853b382586dec8ef8b800dc87bdd96de407f

    ​各种数据库类型市场百分比各种数据库类型市场百分比

    NoSQL发展一直很快,几年前有些人会说NoSQL要代替关系型数据库,但最近大家都开始冷静一点了,从上图可以看出,NoSQL虽然发展很好,但是目前RDBMS仍是占据了80%的活跃度,处于统治地位。

    2016十大数据库点评

    一、Oracle(老大,最挣钱的数据库)

    Oracle一直是数据库市场占有率最高的产品,但2016年很不好受,一直被老二MySQL威胁,虽然Oracle与MySQL都是Oracle公司的产品,但是MySQL带给Oracle的营收可以忽略不计,这样就间接导致Oracle市场受到影响。那Oracle为什么不直接砍掉MySQL或者减缓MySQL的更新步伐呢,这里很可能是考虑到MariaDB这个分支也在持续快速发展,如果官方的MySQL更新缓慢,那估计很多公司就会选择MariaDB了。所以Oracle也没有办法,既没法让MySQL迁移到Oracle,也没法不搞MySQL,所以只能拼命发展MySQL,争取把用户守住。当然Oracle也在全力投入发展云服务,如果云计算领域搞起来,MySQL可能带来不错的营收。

    0cd4c585eede8493ec42aa1d5d19fbda3b26ed54

    Oracle12c

    ​Oracle12c是一个非常重要的版本,相比11g,在设计理念上有了全新的变化,全面拥抱云计算,多租户是12c的最大特性。按Oracle以前产品的发布来看,大版本的第一个版本更多是布道,而第二个版本更具有大规模生产使用价值。2016年发布了12.2版本,12c可以说能进入生产使用阶段。Oracle12.2在云计算多租户方面有了非常大的增强,我简单列了几个重要的点如下,这些点也许普通用数据库的人看起来不太眼,但是对于云计算多租户是非常重要的特性 :

    1. I/O Rate Limits for PDBs(PDB可以按IOPS或Mbps隔离)
    2. Support for PDBs with Different Character Sets, Time Zone File Versions, and Database Time Zones in a CDB
    3. Proxy PDB(PDB代理服务,可以用一个链接指向远程的一个PDB)
    4. Service-Level ACLs for TCP Protocol(每个PDB可以指定ACL安全策略)
    5. Flashback Pluggable Database
    6. PDB Archive Files (.pdb Files)(可以导出PDB为离线文件,然后迁移到其它的CDB上,用于容器迁移)
    7. PDB Refresh,clone PDB and autorefresh,(可用于单PDB的镜像实例灾备、同步、分析)
    8. 一个CDB可以包括4000个PDB(以前最大是252个)

    Oracle12.2增加了原生Sharding支持,这与以前的partition及rac不同,sharding可以将数据放在完全不同的主机,属于share nothing的架构,可以说这个特性是专门为那边业务非常大的OLTP系统准备的,相当于内置实现了自动分库分表管理功能。

    另外新增了数据生命周期管理功能,大家都清楚,数据库有冷热之分,往往近期的数据经常使用,几年前的数据是偶尔使用,通常好的做法是对经常使用的数据采用行式存储,对不经常使用的数据采用压缩存储或列式存储,这样总体成本更优,当然,要做这样的效果需要付出不小的设计与运维成本,还可能会影响业务体验,所以能做好的人不多。在Oracle12.2里,你可以指定数据的生命周期,让数据库自动帮你管理,就像下面这两条指令:

    c51e5837427224e37813f0071f7b25983a5feac3

    二、MySQL(最流行的开源数据库)

    MySQL在2016年是最大赢家,市场占有率不断攀升,很大一部份原因是互联网行业快速发展,因为开源免费易用,MySQL成为互联网公司最受欢迎的数据库。MySQL最新稳定版本是5.7.17 GA。

    f5dc678185e4a98014cb2c22bf0fff755f3595d1

    MySQL5.7

    ​MySQL5.7号称性能是MySQL5.6的3倍,而MySQL5.6号称性能是MySQL5.5的2倍,你信吗?这个问题还是要辩证的理解,首先性能肯定是改进了,但为什么大部份人升级后也没有感觉?这就要从测试方法说起,大部份厂商发布新版本都会说性能提升了多少多少,因为这是最能吸引客户的数据。从官方的测试数据来看,首先是32个并发以上的简单查询,并且超过10万QPS才有区别,如果你的系统没有达到这个并发度那肯定没有体会的。另外是纯内存与CPU计算,如果你的系统瓶颈在磁盘或网络IO那也不会有明显的效率提升。当然,我认为MySQL5.6的ICP这种特性其实对于业务来说更有意义,说不定刚好你的慢SQL可以解决掉。

    2016年MySQL5.7也发布了Group Replication特性,应用于要求强高可用的场景,这个特性让MySQL开始有基础与现代新的分布式数据库去竞争,目前只是刚推出,估计离能生产使用还有差距。

    MySQL5.7对很多代码进行了优化,特别是高并发下锁的争用,所以在高并发简单SQL性能会有大的提升,另外很值得升级的就是带来了不少新功能,比如原生支持JSON了,原生支持full text search等等,如果你的业务要用上那就不要犹豫了,赶紧升级到5.7吧。

    a31d328398e4234e9e2733fca4e2c41369cfb629

    MySQL 8.0 DMR

    ​2016.9月MySQL8.0(原计划是MySQL5.8)刚发了一个DMR版本(开发者版),可以说是有非常大的改进,下面是发出来的几个大特性:

    1. 支持role
    2. 数据字典存储由myisam引擎变为innodb
    3. 支持 invisible indexes,这个对DBA索引调优比较有帮助
    4. 增加column_stats ,相当于Oracle的直方图
    5. Performance schema持续加强,增加了很多error信息采集与展示
    6. 支持SET参数持久化保存

    2016年Facebook的RocksDB引擎也火了一把,它本身可以做为一个KV引擎直接使用,也可以和InnoDB或MyISAM一样,做为存储引擎直接用于MySQL,还可以用于MongoDB,非常灵活。RocksDB是基于Google LevelDB上发展进来的,采用LSM Tree的数据结构管理数据,Key Value操作高性能且拥有非常高的数据压缩比,Percona与MariaDB都在跟进,RocksDB的普及对于InnoDB有一定竞争与互补,但对于TokuDB来讲就非常难受,因为RocksDB基本覆盖了TokuDB的应用场景,并且有各大主流公司在支持。

    三、SQLServer(Windows上最好的数据库)

    5775f424a7de960a75eb0c47ebbe21387f76aae6

    SQLServer2016

    ​SQL Server一直不被很多人看重,认为数据库就是Oracle与MySQL的天下,但是实际上SQLServer的用户非常多,SQLServer发展非常迅猛,微软也网罗了大量数据库的顶级人才。今年微软正式发布了SQL Server 2016及SP1。可以说有很多亮眼的功能,也能看到SQLServer有自己独特的数据库发展规划。列几个SQLServer2016的重磅特性:

    1. PolyBase——PolyBase支持查询分布式数据集。有了PolyBase,你可以使用Transact SQL语句查询Hadoop或者SQL Azure blob存储。你现在可以使用PolyBase写临时查询,实现SQL Server关系型数据与Hadoop或者SQL Azure blog存储中的半结构化数据之间的关联查询。此外,你还可以利用SQL Server的动态列存储索引针对半结构化数据来优化查询。如果组织跨多个分布式位置传递数据,PolyBase就成了利用SQL Server技术访问这些位置的半结构化数据的便捷解决方案了。
    2. 全程加密——支持在SQL Server中保持数据加密,只有调用SQL Server的应用才能访问加密数据。使用该功能,你可以避免数据库或者操作系统管理员接触客户应用程序敏感数据(包括静态数据和动态数据)。该功能现在支持敏感数据存储在云端管理数据库中,并且永远保持加密。即便是云供应商也看不到数据。
    3. 动态数据屏蔽——这个特性可以很好的保护一个表中的敏感信息(如会员表的注册时间不是太机密的信息,但是像手机号码这种信息并不希望普通账号可以查看,动态数据屏蔽可以有效的解决这个问题,它能让普通账号看不到完整的手机号信息,比如138-1234-5678手机号可能会显示为138-****-****)
    4. Stretch Database——Stretch Database功能提供了把内部部署数据库扩展到Azure SQL 数据库的途径。有了Stretch Database功能,访问频率最高的数据会存储在内部数据库,而访问较少的数据会离线存储在Azure SQL 数据库中,最重要的是这可以通过配置规则后由数据库自动完成,对应用没有影响,可以说是混合云的专业数据解决方案。
    5. 支持JSON
    6. 支持R语言做数据分析
    f3dc9632a5fe03c504f1bd9ab378aed5c8cef67c

    SQLServer for Linux

    ​除了发布SQL Server 2016外,今年另一个最重大的事情是微软宣称SQLServer要支持Linux了,并且发布了第一个预览版。这可以说是微软一次艰难的决定,Linux现在是越来越好,Windows是不可能干了Linux,更重要的是微软也是大力搞云计算服务的,SQLServer支持Linux也是顺势而为了。

    四、PostgreSQL(功能最强大的开源数据库)

    PostgreSQL可以说是一个历史非常悠久的开源数据库,从关系型数据库理论提出以来,它一直非常活跃,PostgreSQL的功能非常强大,很多功能可以与Oracle相当。PostgreSQL的代码可读性非常好,又是开源,并且功能强大,所以是学术界非常喜欢研究的数据库。当然,因为工业界应用得不多,也有时会被人理解为学术型数据库。不过PostgreSQL在国外的活跃度比中国高很多,也有许多非常成功的工业界案例。国内很多人也不太了解PostgreSQL,人才方面是非常大的短板,国内缺少非常有影响力的成功案例,也没有很强的商业领导者,所以导致在国内发展得没有MySQL迅速。

    f93eee56fb28aea456588072eef3a78d508c227c

    PostgreSQL

    ​PostgreSQL在2016年发布了9.6版本,主要有以下大的更新:

    1. Parallel execution of sequential scans, joins and aggregates——单条SQL支持并行访问可以说是非常有挑战的功能,这个功能曾经也是商业数据库与开源数据库的重大区别,因为Oracle、SQLServer、DB2都支持单SQL并行计算,但是开源数据库基本不支持,PostgreSQL9.6是第一个支持的开源数据库。
    2. Avoid scanning pages unnecessarily during vacuum freeze operations
    3. Synchronous replication now allows multiple standby servers for increased reliability
    4. Full-text search can now search for phrases (multiple adjacent words)
    5. postgres_fdw now supports remote joins, sorts, UPDATEs, and DELETEs——Fdw在PostgeSQL9.6中有了更大的增强,这个功能有点类似Oracle的DBLink,或者是SQLServer的链接服务器概念,也是一个非常实用的组件,可以非常方便的访问远程数据库,还可以访问远程非PostgreSQL数据库,这对于一些数据迁移与异构关联计算非常有价值。
    6. Substantial performance improvements, especially in the area of scalability on multi-CPU-socket servers

    五、MongoDB(最好的文档型数据库)

    MongoDB是文档型数据库,NoSQL领域的领导者之一,也可以说是当前最成功的NoSQL数据库。能在众多NoSQL中脱颖而出,说明MongoDB一定有不少过人之处 ,我也一直非常看好,因为MongoDB的出现很好的弥补了关系型数据库的很多问题,比如支持Schema Free,在关系型数据库没有支持JSON之前,就是一个典型的难题,曾经有很多开发同学向我咨询对于一个动态属性的表该如何设计表结构,比如商品的属性、游戏装备属性等等?说实话,当时关系型数据库除了预留字段、行转列模式、大字段文本几种方案外,没有什么好的解决方案。MongoDB可以说在这方面非常擅长,因为它的数据交互及存储都采用类似JSON格式,非常灵活,并且可以对JSON数据创建非常灵活的索引,如子属性、数组都能支持索引。新关系型数据库虽然也支持JSON格式,但是与MongoDB还是有较大的差距。

    c53d497ea88c2c355e66b996cf51da1e8c2aa9d2

    NodeJS+MongoDB

    因为是JSON,MongoDB也天然支持js的语法交互,所以又吸引了很多NodeJS服务端同学,甚至有人宣传说NodeJS+MongoDB组合要代替PHP+MySQL的组合了,当然,这更多是给搞js的同学一种方案选择。

    MongoDB在很早就有自己的查询语言,与SQL一样强大,不过语法是js格式,下图是MongoDB查询语言与SQL的一个简单对比:

    18a33bc21c759deb056ae80fa5d7d732f62fc990

    Mongo Query Language and SQL

    是不是和SQL很像,这也是MongoDB过人之处,它第一天就知道客户需求并不只是要高性能,要俘获程序员的心,必须要提供强大高效的访问接口语言,由于是文档型数据库,SQL主要是为了面向关系型数据库设计的语言,但是SQL确实非常牛逼,所以提供一个面向文档型数据库类似SQL的语言非常有价值。

    MongoDB 也是一个天生支持分布式的数据库,数据自动分片,还支持MapReduce,也内置了一个分布式文件系统GridFS,另外可以挂接多种存储引擎,这些都是非常诱人的功能。

    a9f5c5f57e9d35f44832e20f4a6368384abb9add

    MongoDB3.4

    2016年MongoDB发布了3.4版本,也有一些大的更新,主要的新特性有:

    1. 支持View
    2. 新增对decimal支持,最多支持34位小数位。
    3. 新增支持collation,也就是字符串校验集,校验集会影响字符对比与排序,3.4以前字符串是按字节严格对比,通过设置collation后可以指定校验方式,比如忽略大小写等等,汉字按拼音排序(官方文档特意举了拼音排序这个例子,说明中国用户在MongoDB中份量不小)等等。
    4. 集群管理与日志复制方面也有了进一步增强

    Mongo 公司也推出了自己的数据库云服务,MongoDB Atlas,支持AWS上部署,我认为这也是更好的一种云计算服务模式。

    六、Redis(最好的缓存数据库)

    54caf8369fcd1f601b1dd72fe7420cb645189d6c

    Redis

    说Redis是缓存服务,估计有些人会不开心,因为Redis也可以把数据库持久化,但是在大多数情况Redis的竞争力是提供缓存服务。说到缓存服务必然会想到Memcached,因为几年前Memcached是最流行的缓存服务,但随着Redis的发展,Redis在很多方面比Memcached更好用,比如,Redis支持更多种数据类型,包括hash、set、list等等。Redis也支持数据持久化,另外2015年发布的Redis 3.0开始支持集群服务。Redis还支持subscribe/publish命令,可以用于简单的消息发送与订阅,总体而言95%的情况,如果是缓存服务,我们都可以选择Redis。

    Redis在2016年发布了3.2版本,最重要的是支持GEO地理信息存储支持。Redis原计划下个版本是3.4,后来计划重命令为Redis 4.0,今年已经推出了RC1,Redis4.0有许多大的变化,最重要的是模块化特性,官方希望Redis是一个底层基础设施,开发者可以在上面构建更多有意思的东西,比如对神经网络、机器学习数据计算扩展,还有如图数据、二级索引、时序数据、全文索引等等。http://antirez.com/news/110(备注:antirez是redis最核心开发成员,90%以上的代码是他贡献的)

    七、ElasticSearch(最好的搜索服务)

    fe95f43400fb55db8a42b7e5b572dca73fbecaa0

    Elasticsearch

    Elasticsearch本是一项搜索服务,但是因为它实在太强大太好用了,以至于有一些业务把它作为数据存储与搜索服务。搜索与数据库本来就非常密切,很早以前的数据搜索都会采用数据库内置的like模糊查询或全文检索实现,但随着互联网搜索业务的快速发展,对搜索选项也要求更丰富,另外早期的搜索并不一定需要数据库这样完全实时的需求,所以数据库对全文搜索的支持一直不太理想,这也产生了很多的专业搜索引擎产品,Lucence就是最流行的开源搜索引擎框架。近几年随着大数据快速发展,搜索引擎需要有更强的分布式支撑,另外由于业务的竞争,需要大量的日志数据采集与分析,实时性要求更高, Elasticsearch 在这方面脱颖而出, Elasticsearch 是基于lucence开发的分布式搜索服务,并不只是一个框架(Lucence需要二次开发),而是可以直接使用的服务。 Elasticsearch 对文档模型也有了进一步的增强,更有一些文档型数据库的感觉,甚至有人把它完全当分布式数据存储服务(主流大数据存储真的没有太好的准实时查询功能)。

    ElasticSearch在2016年快速增长,从去年13名前进到第11名。ElasticSearch今年发布了5.0版本,这个版本号跳跃得比较大,主要是因为elastic公司考虑到与自己旗下的Kibana等产品版本号统一,解决用户搭建ELK或ElasticStack日志分析架构选择组件版本的困扰。

    八、Neo4j(最好的图数据库)

    图数据库一直是NoSQL领域非常重要的分支,Neo4j可以说是图数据库的绝对领导者,虽然这个名字很土(很容易联想到log4j、dom4j这些通用java组件)

    e1aa8abfc0405a442a4ba176eb8daecb9956e411

    neo4j

    图数据库虽然现在流行度并不算太高,主要原因是目前大部份问题可以采用关系型数据库或大数据方案解决,图数据库更擅长描述基于关联关系的场景应用,可以用来解决一些特殊的场景,如人员关联关系、事务关联关系等等,比如社交关系计算、物流路径计算等等。但是由于图数据库整个理论不像关系型数据库那么扎实,大家也没有总结出太多的实践经验,再加上性能与扩展性上并不是很突出,所以影响力还不大。

    从我个人认为图数据库是非常有前景的,因为当前关系型数据库对于傻瓜计算是比较擅长,但对于人工智能方面非常无力,而图数据库的结构更像人的大脑信息保存模式,不擅长搞大数据运算,但是可以很容易发现两个相隔十万八千里的对像关系。关系型数据库擅长把一类东西模式化存储,比如有汽车、衣服、家具、食物、照片、朋友等很多信息,RDBMS可以设计为按每种类别用一张表格存储,这样可以很方便回答类型下面的问题:

    1. 总共保存了多少件衣服
    2. 红色的汽车有哪些
    但是要回答下面两个问题会相对困难:
    1. 找出所有是长方型白色的东西
    2. 找出附近有宝马汽车的朋友或(朋友的朋友)照片

    如果要回答上面问题,RDBMS需要再增加维护各种属性与物品的关系。但是像上面这种关联性问题会有很多组合,所以通过RDBMS来维护并不轻松。图数据库的存储格式更适合解决这类问题,因为它更擅长关联查找计算。图数据库更像人脑计算,如果未来机器学习大量应用,或许是图数据库普及的时刻。

    Neo4j提供了类似SQL的图查询语言Cypher,Cypher语言的描述能力非常强大,甚至已经成为图查询语言的通用标准。一个简单的图数据库Cypher查询语言如下:

    11ef55bd5269fb4fba781dff9410c3d85080e62d

    Cypher

    下图是Neo4j官网列出的典型客户:

    cc0b5b7f547cd5537972c5bd7ea6e8e55b21b4e9

    Neo4j典型客户Neo4j典型客户

    九、Cassandra(最好的列式数据库)

    02e3a06a4de2ee400df571571c2d6a556bea7364

    cassandra

    ​现在把Cassandra说为列式数据库完全是不太恰当的归类,最初的Cassandra确实是有列式数据库的概念,但是实际上现在已经完全看不到列式的东西,可以说完全是一个标准分布式数据库。Cassandra除了具备表、字段、二级索引这些概念外,还支持触发器、物化视图,你敢信吗,但他真的支持。Cassandra的接口语言是CQL,CQL查询数据用select,支持insert、update、delete,创建表也是用create table,创建索引也是用create index,语法与SQL基本一模一样,但是功能方面有一些限制,比如不支持多表关联,对where条件也有许多严格的限制等等。另外增加支持了list、set、map、tuple等高级数据类型支持,可以说是SQL的一种扩展。

    Cassandra与HBase起步与实现原理很像,但是应用的场景却差别很大。Cassandra在国外非常流行,但是国内基本没有用户,而HBase在国内非常流行。这是为什么呢?我个人理解是:在Facebook推出Cassandra的时候,国内各大互联网公司也是研究得热火朝天,但是因为Cassandra产品并不太成熟,另外原厂Facebook不久后又放弃了这个产品,加上国内除了BAT以外的厂商并没有太多分布式数据库的压力,所以并没有快速流行。当时的 Cassandra也不能解决BAT的分布式数据库需求, 而同时像阿里巴巴等公司大量宣传用MySQL去IOE的经验,采用了Cobar与TDDL这样类似的中间件架构,很多公司都开始朝这个方向走,因为对系统相对改造成本更小,所以大家也不关心Cassandra的后来发展。而HBase是基于Hadoop体系产生的数据存储产品,这个领域MySQL也没有优势,国内大数据也发展地非常火热,加上BAT、小米大量宣传HBase成功案例,所以HBase快速流行起来。

    十、SQLite(最流行的嵌入式数据库)

    嵌入式数据库有很多种,在以前说不出哪种市场占有率最高,但是随着手机移动开发的流行,SQLite嵌入式数据库异军突起,占领了手机嵌入式数据库的领导地位。在google上搜索iOS数据库或Android数据库开发,立马全屏都是SQLite的介绍。SQLite是一个完整的关系型数据库,支持标准SQL,支持函数索引、外键、视图、触发器、ACID,扩展支持自定义函数、JSON、全文索引、GIS等高级特性,可以说功能非常全,但是程序包不到500KB大小,可以在几百KB的内存上运行,是当前手机或掌上嵌入式设备存储结构化数据的最好选择。

    SQLite是开源免费软件,同时也有收费功能,主要是支持加密、压缩等高级特性,这些功能对于数据安全要求比较高的业务非常有意义。

    SQLite一直在持续更新,但最近大的功能不多,目前最新版本是SQLite 3.15.2,也许是他太领先了,找不到对手,另外开源协议是Public Domain,可以说是基本是没有任何限制的开源协议,相比MySQL、MongoDB等开源数据库来说,没有任何使用风险,不清楚商业营收是否有保障。

    OceanBase(最有潜力的分布式关系型数据库)

    717b5b93798bfb616146a08ec8f1087e9ad01ae6

    云数据库OceanBase

    ​OceanBase是一款阿里巴巴/蚂蚁金服自主研发的高性能、分布式的关系型数据库,支持完整的ACID特性。它高度兼容MySQL协议与语法,让用户能够以最小的迁移成本使用高性能、可扩展、持续可用的分布式数据库服务,同时对用户数据提供金融级可靠性的保障。

    OceanBase主打的是分布式与高可用特性,目前已经支持了关系型数据库最主要的功能,高度兼容MySQL语法,你可以使用MySQL命令客户端或MySQL JDBC Driver直接访问OceanBase,这个特性对于应用改造成本非常低。

    OceanBase有超过6年的研发历史,在国产数据库中,OceanBase在功能方面并不算最强大,但是发展非常快,2015年底正式发布了OceanBase 1.0。另外,存储过程这些更复杂的特性也在研发中。OceanBase已经是支付宝、网商银行最核心的数据库,承载了支付宝双十一所有交易服务。OceanBase天生就有阿里巴巴集团应用场景锤炼,特别是支付宝、网商银行这种支付与银行领域,并且数据库技术也是阿里非常看重的核心竞争力,所以起点非常高,并且OceanBase已经通过阿里云对外输出,希望未来能成为世界顶级数据库引擎。下图是2016年阿里巴巴集团CEO逍遥子在互联网大会介绍OceanBase:

    f57a28334359e63cf0accbd259afdd62ba17117a

    阿里巴巴集团CEO在互联网大会介绍OceanBase

    ​OceanBase目前并不对外提供下载,但是可以通过阿里云使用OceanBase,如果你是一家对高性能与高可用及海量存储要求非常高的业务,那阿里云OceanBase是不错的选择,直接使用云服务,也免去了运维管理成本。

    全球云数据库服务大比拼

    数据库服务一直是云计算厂商非常核心的竞争力,从目前公有云市场来看,AWS、Azure、阿里云这三家厂商是排在前面,并且各有特色,下表是几大厂商提供的数据库服务产品对比:

    8bd562f1bb8258968b3eb0e93bcc470b94a29f00

    3A(AWS、Azure、阿里云)数据库服务

    AWS

    AWS可以说是产品非常全,并且客户体量非常大,产品的成熟度也非常高。

    7c20f6108dbc1efcdd9b3f3e1b632aca39830c1e

    AWS Database Service

    2016年主要是发布了SnowBall数据迁移系列产品,可以帮助用户快速迁移PB级的数据量到云上。下图是AWS最新发布的Snowmobile,可以用卡车来完成上百PB的数据迁移,比传输网络传输快50倍。

    66615f57f77ec37fb6d6c81526112ca742e860dc

    Snowmobile

    Azure

    Azure是微软出品, SQLServer是微软自家核心数据库引擎,同时SQLServer在数据管理与迁移工具方面非常强大,2016年又推出SQLServer Stretch Server的混合云解决方案,可以说在SQLServer方面支持力度最强。Azure除了SQLServer之外,同时也提供了表存储、Redis缓存、数据仓库,并通过第三方支持MySQL服务,给用户提供了丰富的选择。

    1ba15600fe7df7eb1340431ecda4610ffd54fe67

    Azure Database Service

    阿里云

    阿里云近两年快速发力,两年前只有MySQL与SQLServer两个引擎,发展到现在的十几种,如PostgreSQL、MongoDB、Redis、DRDS、ADS(分析型数据库服务)、Greenplum等等,丰富的数据库引擎也是阿里云的核心竞争力之一。在国内,阿里云的性价比也最有优势。

    a39966a424c2f4cbf3d481ce373d0ad361ce4530

    阿里云数据库服务

    除了支持丰富的数据库引擎外,2016年阿里云也正式发布数据传输与数据管理两个数据库服务类的产品。

    225dbcd8da6a6588fec0646be2bf49eb8c542c8c

    数据传输

    数据传输服务包括数据迁移、同步、订阅,你不仅可以非常方便地数据迁移上云,还能轻松搭建异地机房数据同步架构,通过数据同步或订阅也可以方便的将数据实时分发到搜索引擎或数据仓库。

    9c7a5882495f6e2a76037007679e1faf6eaba2b1

    数据管理

    数据管理服务在阿里云用户活跃度非常高,是一款可以免费使用的服务,它能很高效的帮助你管理各种数据源中的数据,包括MySQL、SQLServer、MongoDB、Redis等等,你不再需要使用Navicat、phpMyAdmin等客户端数据库工具。数据也是在内网传输,更安全高效。数据管理服务还提供了各种数据图表分析、数据变更统计、性能诊断等十几项特色功能。更有意思的是,只要数据库可以连接上,就算你的数据库在本地,你不是阿里云的用户也可以免费使用数据管理服务。

    云计算国际上还有两家航母级公司在使劲往里面投入

    一家是Oracle

    Oracle可以说在云计算方面起步较晚, 市场份额还比较低, 但是Oracle的产品线是全宇宙最全的,从IaaS、PaaS、DaaS、SaaS全都覆盖,自家做数据库、OS、CPU、服务器,还有最全的SaaS类软件。Oracle在数据库云服务主要销售Oracle、MySQL数据库及Hadoop大数据服务。AWS这种云计算服务对于传统基础IT公司冲击特别大,特别是IaaS及DaaS方面,现在Microsoft、Oracle、IBM都在痛苦的转型,各自都在结合自己的优势突围。云计算给惠普、DELL、EMC这种偏硬件的企业压力更大。

    另一家是Google

    Google是最先提出云计算的概念,但是发展得非常不顺利,因为Google提的云计算与当前的流行的概念已经完全不一样了。Google最早主要是提供GAE这个PaaS服务,没有搞起来。最近两年完全转型为IaaS+PaaS,和AWS非常像,新的平台叫GCP(Google Cloud Platform),但是公有云市场已经被AWS领先很多。Google在数据库方面带来了分布式技术的突破,研发了BigTable、Spanner这样领先的分布式数据库技术,但是BigTable与Spanner只是一项内部应用的技术,离市场需要的产品不一样,业界大部份公司还不需要这样复杂的技术。云计算服务不仅要有技术基础,更需要有很强的产品设计能力。另外云计算和互联网一样,是一个基础设施,不能因为用户上了云计算就必须要全部改变他原有的软件架构,就像不能因为用户要上网就必须把电脑全换了一样的道理。

    Google公有云服务地址: https://cloud.google.com/products/,以下是Google主要提供云计算服务:

    57ee14bf496780a2b29b6d2bd42c2bdb97480f0f

    国内其他云厂商也提供了数据库服务,包括腾讯云、百度云、华为云,但是产品线及成熟度还有待提升,这里就不详细说了。

    数据库2017年展望

    数据库一直是IT界非常活跃的技术,也是当今计算机系统非常核心的构成。从网络/层次数据库到关系型数据库,到面向对像数据库、分布式数据库、时序数据库,然后是NoSQL(KV型、文档型、列式数据库、图数据库)与大数据以及NewSQL,可以说,数据库界从来没有消停过。全球顶级软件厂商都非常重视在数据库领域投入,包括微软(SQLServer)、Oracle(Oracle+MySQL)、IBM(DB2)、SAP(Sybase+HANA)、Google(Spanner)、Facebook(RocksDB)、阿里巴巴(OceanBase)、Amazon(Aurora)等等。相信数据库在未来竞争会更加激烈,这里对数据库在2017年做一个简单的展望:

    1. MySQL超越Oracle成为流行度第一的产品
    2. RDBMS、NoSQL、大数据继续互相学习,RDBMS地位仍然稳固
    3. 图数据库开始发力
    4. 机器学习应用于数据库领域
    5. 数据库云服务竞争激烈,混合云解决方案会是重要战场
    6. 国产分布式数据库OceanBase加入市场竞争

    作者:叶正盛  来源:新浪微博
    展开全文
  • 硬盘数据恢复软件,U盘数据恢复软件,内存卡数据恢复软件。格式化数据恢复软件。手机数据恢复。硬盘数据恢复。移动硬盘数据恢复。相机储存卡数据库
  • 微软宣布将用 beta 预览版...此次微软向 Linux 系统提供数据库软件也是为了进一步发展微软在数据库市场的经营份额, SQL Server 是微软的旗舰数据库软件,其与 Windows Server 是微软一直以来盈利性最强的产品,不过...
  • 点击下方公众号「关注」和「星标」回复“1024”获取独家整理的学习资料!最近看到一款数据库客户端工具,DataGrip,是大名鼎鼎的JetBrains公司出品的,就是那个出品Intelli...
  • DBeaver是一个基于 Java 开发,免费开源的通用数据库管理和开发工具,使用非常友好的 ASL 协议。可以通过官方网站或者 Github 进行下载。下载与安装DBeaver 社区版可以通过官方网站或者 Github 进行下载。两者都为...
  • 其中包括戴尔迄今为止性能最强的四路服务器PowerEdge:trade_mark: 6800及6850,支持英特尔:registered:至强:registered:双核技术及最新版Microsoft:registered: SQL Server 数据库软件。该套件为客户迁移到Microsoft...
  • Starry Night Pro Plus 8是世界最强的,也是最专业好用的天文模拟软件,主要方便天文爱好者使用,软件提供了多达100个地球和月球地图显示岩石和元素位置、矿物成分、化学分布、重力、磁场、显著的地貌数据。...
  • 2019年5月8日-5月10日,由国内知名IT技术社区主办的数据库技术交流盛会——DTCC 2019将在北京新云南皇冠假日大酒店召开。数据风云,十年变迁,DTCC见证并铭记了国内数据库技术的关键成长历程。作为DTCC的老朋友和...
  • 强烈推荐 10 本我私藏的数据库书单,附读书方法

    千次阅读 多人点赞 2020-06-22 10:26:03
    二哥有推荐的数据库书单吗?关于 MySQL 和 Oracle 的,谢谢了。 读者小猫私信问了我上面这个问题,我觉得问题挺典型的,值得写篇文章分享一下。因为对于 Java 程序员来说,几乎不可避免地要和数据库打交道,MySQL ...
  • 北京――戴尔公司今日宣布在国内市场推出一套功能全面的数据库套件,其中包括戴尔迄今为止性能最强的四路服务器PowerEdge 6800及6850,支持英特尔至强双核技术及最新版Microsoft SQL Server 数据库软件。该套件为...
  • Java知识体系最强总结(2021版)

    万次阅读 多人点赞 2019-12-18 10:09:56
    基础知识 并发理论 并发关键字 Lock体系 并发容器 线程池 原子操作类 并发工具 并发实践 数据结构与算法 数据结构 算法 排序算法 LeetCode 数据库 Oracle MySQL 数据库基础知识 数据类型 引擎 索引 三大范式 常用SQL...
  • 最强文件搜索神器!每个人的电脑都保存着大量的软件、MP3、照片、游戏、文档、电子书等文件。Everthing可以在闪电般的瞬间从海量的硬盘中找到你需要的文件,速度快到让你难以置信。 它体积小巧,界面简洁易用,快速...
  • 2019年5月8日-5月10日,由国内知名IT技术社区主办的数据库技术交流盛会——DTCC 2019将在北京新云南皇冠假日大酒店召开。数据风云,十年变迁,DTCC见证并铭记了国内数据库技术的关键成长历程。作为DTCC的老朋友和...
  • 目前最强大的人力资源管理软件,任何电脑都可以安装,可以根据自己的思路增减管理模块。 目前最强大的人力资源管理软件,任何电脑都可以安装,可以根据自己的思路增减管理模块。
  • SMART 的使用困惑 SMART 确实是最强的,但是在使用时,却相对麻烦。整个网站的整体运行逻辑,我个人猜想是: 收到用户提交的ID或者序列 查看后台是否保存了对应的ID和序列 如果保存了,那么就直接返回保存的结果,...
  • Access数据库操作软件研究

    千次阅读 2016-03-28 18:42:03
    研究了一些不用装Access对mdb数据库做操作的软件;总结如下; 1  此工具可用;可操作记录;执行SQL语句;操作表结构和创建表大概有些难;...这个是目前可能不用装Access,对mdb数据库操作功能最强软件;不过用
  • 数据库DataBase

    2021-03-04 13:54:12
    常见的DBMS(数据库软件): MySQL: Oracle公司产品, MySQL在08年被Sun公司收购,09年Sun公司被Oracle收购, 目前市占率第一, 开源软件, 原MySQL创始人从Oracle离职创办MariaDB Oracle: Oracle公司产品,闭源, 性能最强
  • 点击上方蓝色字体,选择“设为星标”回复”资源“获取更多资源大数据技术与架构点击右侧关注,大数据开发领域最强公众号!暴走大数据点击右侧关注,暴走大数据!ClickHouse相关文章推荐:战...
  • Postgresql数据库介绍

    2020-09-06 13:49:10
    文章目录一、数据库介绍1.数据库DB引擎排行榜2.数据库的主要优势 一、数据库介绍 1.数据库DB引擎排行榜 当前数据库的使用情况 https://db-engines.com/en/ranking 2.数据库的主要优势 1. PostgreSQL完全免费,是...
  • 数据库的一些总结

    2022-01-15 15:12:27
    文章目录前言一、数据库基本概念1.什么是数据库2.SQL和 MySQL的区别3.数据库的三大范式二、数据库索引1.为什么要使用索引2.什么时候使用索引3. 索引中的数据结构与算法Hash索引:位图索引B树索引:B+树索引:B+树跟B...
  • 1.理论上个人、组织信息、材料都可以通过编译导入软件进而秒搜出,不仅是写作辅助软件,可以利用成自己的私人高端数据库。 2.素材库1.0版确实内容较少,在掌握全文搜索功能后有些词条作者确实少有精力和统筹各行...
  • 2021年12月国产数据库大事记-墨天轮

    千次阅读 2022-01-13 15:26:47
    本文为墨天轮社区整理的2021年12月国产数据库大事件和重要产品发布消息。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 10,955
精华内容 4,382
关键字:

最强数据库软件