之前有和公司的同事们进行过相关的交流,交流会上做了一些相关资料的编写,大致从各方收集资料来讲解数据库的发展历程,涉及到数据库的历史,和目前在用的几个主流数据库。
早期数据库理论:
模式介绍:
满足以下两个条件的基本层次联系的集合为层次模型
a、有且只有一个结点没有双亲结点,这个结点称为根节点;
b、根以外的其他结点有且只有一个双亲结点。
层次数据库系统只能处理一对多的实体联系的原因:在层次模型中,每个结点表示一个记录类型,记录类型之间的联系用结点之间的连线(有向边)表示,这种联系是父子之间的一对多的联系。
以下是一个层次模型的示例,它像一棵倒立的树,结点的双亲是唯一的。同一双亲的子女结点称为兄弟结点,没有子女结点的结点称为叶结点。
层次模型的特点:任何一个给定的记录值只能按其层次路径查看,没有一个子女记录值能够脱离双亲记录值而独立存在。
层次数据库的操作以及优缺点:
a.操作特点
插入:如果没有相应的双亲结点值不能插入它的子女结点值。
删除:如果删除双亲结点值,则相应的子女结点值也将同时被删除。
b.优点:
(1)模型简单,对具有一对多层次关系的部门描述非常自然,直观,容易理解,这是层次数据库的突出优点
(2)用层次模型的应用系统性能好,特别是对于那些实体间联系固定的且预先定义好的应用,采用层次模型来实现,其性能优于关系模型
(3)层次数据模型提供了良好的完整性支持。
c.缺点:
(1)现实世界中很多联系是非层次性的,如多对多联系,一个节点具有多个双亲等,层次模型不能自然的表示这类联系,只能通过引入冗余数据或引入虚拟结点来解决(例:一个教师教导多个班级,一个班级拥有多个教师)
(2)对插入和删除操作的限制比较多
(3)查询子女结点必须通过双亲结点
历史案例:IMS于1969年投入运行,它是在操作系统DOS/VS(Disk Operation System/Virtual Storage)支持下运行
模式介绍:
满足一下两个条件的基本层次联系的集合为网状模型
a、允许一个以上的结点无双亲;
b、一个结点可以有多于一个的双亲。
备注:层次模型实际上是网状模型的一个特例。
网状数据库操作及优缺点:
a.操作特点:
DBTG在末世数据定义语言中提供了DBTG数据库完整性的若干概念和语句,主要有:
1)支持记录码的概念。唯一标识记录的数据项的集合称为码,例如学生的学号,不允许有两个相同的学号。
2)保证一个联系中双亲记录和子女记录之间是一对多的联系。
3)可以支持双亲记录和子女记录之间的某些约束条件。
b.优点:
(1)能够更为直接地描述现实世界,如一个结点可以有多个双亲
(3)具有良好的性能,存取效率较高
c.缺点:
(1)结构比较复杂,而且随着应用环境的扩大,数据库的结构就变得越来越复杂,不利于最终用户掌握
(2)其DDL,DML语言复杂,用户不容易使用。用于记录之间联系是通过存取路径实现的,应用程序访问数据库时必须选择适当的存取路径。因此,用户必须了解系统的结构的细节,加重了编写应用程序的负担
案例:美国DBTG(Data Base Task Group)应用标准,DBTG系统中,数据库的记录类型用结点表示
诞生背景:
虽然网状数据库和层次数据库已经很好的解决了数据的集中和共享问题,但是在数据库独立性和抽象级别上扔有很大欠缺。用户在对这两种数据库进行存取时,仍然需要明确数据的存储结构,指出存取路径。而关系型数据库就可以较好的解决这些问题。
模式介绍:
1)关系:一个关系对应通常说的一张表;
2)元组:表中的一行即为一个元组;
3)属性:表中的一列即为一个属性,给每一个属性起一个名称即属性名;
4)码:也称为码键,表中的某个属性组,它可以唯一确定一个元组;
5)域:一组具有相同数据类型的值的集合。属性的取值范围来自某个域;
6)分量:元组中的一个属性值。
7)关系模式:对关系的描述,一搬表示为:关系名(属性1,属性2,…,属性n)
关系模型要求关系必须规范化的,关系必须满足一定的规范条件,这些规范条件中最基本的一条就是,关系的每一个分量必须是一个不可分的数据项,也就是说,不允许表中还有表。
关系型数据库操作及优缺点:
a.操作特点:
关系模型的数据操纵主要包括查询、插入、删除和更新数据,它的数据操纵是集合操作,操作对象和操作结果都是关系。
这些操作必须满足关系的完整性约束条件:实体完整性、参照完整性和用户定义的完整性。
b.优点:
(1)建立在严格的数学概念的基础上
(2)概念单一,无论实体还是实体之间的联系都是用关系来表示。对数据的检索和更新结构也是关系(也就是我们常说的表)
(3)它的存取路径对用户透明,从而具有更高的独立性、更好的安全保密性,简化了程序员的工作个数据库开发建立的工作。
诞生背景:
NoSQL,泛指非关系型的数据库。随着互联网web2.0网站的兴起,传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSql数据库在特定的场景下可以发挥出难以想象的高效率和高性能,它是作为对传统关系型数据库的一个有效的补充。
NoSQL(NoSQL = Not Only SQL ),意即“不仅仅是SQL”,是一项全新的数据库革命性运动,早期就有人提出,发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储,相对于铺天盖地的关系型数据库运用,这一概念无疑是一种全新的思维的注入。
在理论计算机科学中,CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer’s theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点:
根据定理,分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致,即丧失了C性质。如果为了保证数据一致性,将分区一侧的节点设置为不可用,那么又丧失了A性质。除非两个节点可以互相通信,才能既保证C又保证A,这又会导致丧失P性质。
键值数据库就类似传统语言中使用的哈希表。可以通过key来添加、查询或者删除数据库,因为使用key主键访问,所以会获得很高的性能及扩展性。
键值数据库主要使用一个哈希表,这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署、高并发。
典型产品: Memcached、Redis、MemcacheDB
列存储数据库将数据存储在列族中,一个列族存储经常被一起查询的相关数据,比如人类,我们经常会查询某个人的姓名和年龄,而不是薪资。这种情况下姓名和年龄会被放到一个列族中,薪资会被放到另一个列族中。
这种数据库通常用来应对分布式存储海量数据。
典型产品: Cassandra、HBase
文档型数据库的灵感是来自于Lotus Notes办公软件,而且它同第一种键值数据库类似。该类型的数据模型是版本化的文档,半结构化的文档以特定的格式存储,比如JSON。文档型数据库可以看作是键值数据库的升级版,允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。
面向文档数据库会将数据以文档形式存储。每个文档都是自包含的数据单元,是一系列数据项的集合。每个数据项都有一个名词与对应值,值既可以是简单的数据类型,如字符串、数字和日期等;也可以是复杂的类型,如有序列表和关联对象。数据存储的最小单位是文档,同一个表中存储的文档属性可以是不同的,数据可以使用XML、JSON或JSONB等多种形式存储。
典型产品: MongoDB、CouchDB
图形数据库允许我们将数据以图的方式存储。实体会被作为顶点,而实体之间的关系则会被作为边。比如我们有三个实体,Steve Jobs、Apple和Next,则会有两个“Founded by”的边将Apple和Next连接到Steve Jobs。
典型产品: Neo4J、InforGrid
2017年时序数据库忽然火了起来。开年2月Facebook开源了beringei时序数据库;到了4月基于PostgreSQL打造的时序数据库TimeScaleDB也开源了,而早在2016年7月,百度云在其天工物联网平台上发布了国内首个多租户的分布式时序数据库产品TSDB,成为支持其发展制造,交通,能源,智慧城市等产业领域的核心产品,同时也成为百度战略发展产业物联网的标志性事件。时序数据库作为物联网方向一个非常重要的服务,业界的频频发声,正说明各家企业已经迫不及待的拥抱物联网时代的到来。
时序数据是基于时间的一系列的数据。在有时间的坐标中将这些数据点连成线,往过去看可以做成多纬度报表,揭示其趋势性、规律性、异常性;往未来看可以做大数据分析,机器学习,实现预测和预警。
时序数据库就是存放时序数据的数据库,并且需要支持时序数据的快速写入、持久化、多纬度的聚合查询等基本功能。
对比传统数据库仅仅记录了数据的当前值,时序数据库则记录了所有的历史数据。同时时序数据的查询也总是会带上时间作为过滤条件。
诞生:
1、MySQL的历史可以追溯到1979年,一个名为Monty Widenius的程序员在为TcX(TCX DataKonsult )的小公司打工,并且用BASIC(初学者通用符号指令代码)设计了一个报表工具,使其可以在4MHz主频和16KB内存的计算机上运行。当时,这只是一个很底层的且仅面向报表的存储引擎,名叫Unireg。
2、1990年,TcX公司的客户中开始有人要求为他的API提供SQL支持。Monty直接借助于mSQL的代码,将它集成到自己的存储引擎中。令人失望的是,效果并不太令人满意,决心自己重写一个SQL支持。
3、 1996年,MySQL 1.0发布,它只面向一小拨人,相当于内部发布。到了1996年10月,MySQL 3.11.1发布(MySQL没有2.x版本),最开始只提供Solaris下的二进制版本。一个月后,Linux版本出现了。在接下来的两年里,MySQL被依次移植到各个平台。
4、后被Orcale收购,Monty又组织开发了mariaDB和Mysql应用一致。
应用场景:
各种系统级应用:
Mysql之所以能成为Web站点以及系统开发者们最青睐的数据库管理系统,是因为MySQL数据库的安装配置都非常简单,使用过程中的维护也不像很多大型商业数据库管理系统那么复杂,而且性能出色。还有一个非常重要的原因就是MySQL是开放源代码的,完全可以免费使用。
其他使用特点:
与oracle的区别:
应用区别:Mysql与Oracle的区别
特性区别:
MySQL的特点
1、性能卓越,服务稳定,很少出现异常宕机;
2、开放源代码无版本制约,自主性及使用成本低;
3、历史悠久,社区和用户非常活跃,遇到问题及时寻求帮助;
4、软件体积小,安装使用简单且易于维护,维护成本低;品牌口碑效应;
5、支持多种OS,提供多种API接口,支持多种开发语言,对流行的PHP,Java很好的支持
MySQL的缺点
1、MySQL最大的缺点是其安全系统,主要是复杂而非标准,另外只有到调用mysqladmin来重读用户权限才会发生改变;
2、MySQL的另一个主要的途径之一是缺乏标准的RI(Referential Integrity-RI)机制,RI限制的缺乏(在给定字段域上的一种固定的范围限制)可以通过大量的数据类型来补偿;
3、MySQL不支持热备份;
Oracle的特点
1、兼容性:Oracle产品采用标准SQL,并经过美国u构架标准技术所(NIST)测试,与IBM SQL/DS、DB2、INGRES、IDMS/R等兼容。
2、可移植性:Oracle的产品可运行于很宽范围的硬件与操作系统平台上。可以安装在多种 大、中、小型机上,可在多种操作系统下工作。
3、可联结性:Oracle能与多种通讯网络相连,支持各种协议。
4、高生产率:Oracle产品提供了多种开发工具,能极大地方使用户进行进一步的开发。
5、开放性:Oracle良好的兼容性、可移植性、可连接性和高生产率使Oracle RDBMS具有良好的开放性。
Oracle的缺点
1、对硬件要求很高;
2、价格比较昂贵;
3、管理维护麻烦一些;
4、操作比较复杂,需要技术含量高;
诞生:
出生于西西里岛的意大利人(antirez)发明的。
antirez早年是系统管理员,2004到2006年做嵌入式工作,之后接触web,2007年和朋友共同创建一个网站LLOOGG.com并为了解决这个网站的负载问题,而在2009年开发了Redis数据库。
LLOOGG.com网站是一个访客信息网站,网站可以通过javascript脚步,将访客IP地址、所属的国家、阅览信息、访问网页地址传送给LLOOGG.com网站。
在Redis诞生前,LLOOGG使用的数据库是mysql,而每次mysql执行推入或弹出操作,都需要进行硬盘的读写操作,程序的性能严重受制于硬盘的I/O,很多操作都堆在那里,然后网站就没法运作了。
这个负载问题根本原因就是硬盘IO,所以antirez在不改变硬件的基础上,通过提升列表的性能来解决负载问题,决定自己写一个具有列表结构的内存数据库原型。最重要的数据存储于内存而不是硬盘,所以程序的性能不会受制于硬盘IO限制,可以以极快的速度执行针对列表的推入和弹出操作。结果试验,确实解决了当时负载问题,于是antirez使用C语言重写这个内存数据库,并给它加上了持久化功能,这个就是Redis的诞生。
使用Redis思想解决方案:
每当存储上限超过列表最大长度
这是Redis诞生的最初思想与使用场景。
工作机制:
应用场景:
使用特点:
Redis有不同的数据结构类型,可应用场景也分别不同
字符串结构使用非常广泛,一个常见的用途就是缓存用户信息。我们将用户信息结构体使用 JSON 序列化成字符串,然后将序列化后的字符串塞进 Redis 来缓存。同样,取用户信息会经过一次反序列化的过程。
Redis 的字符串是动态字符串,是可以修改的字符串,内部结构实现上类似于 Java 的 ArrayList,采用预分配冗余空间的方式来减少内存的频繁分配,如图中所示,内部为当前字符串实际分配的空间 capacity 一般要高于实际字符串长度 len。当字符串长度小于 1M 时,扩容都是加倍现有的空间,如果超过 1M,扩容时一次只会多扩 1M 的空间。需要注意的是字符串最大长度为 512M。
Redis 的列表相当于 Java 语言里面的 LinkedList,注意它是链表而不是数组。这意味着 list 的插入和删除操作非常快
Redis 的列表结构常用来做异步队列使用。将需要延后处理的任务结构体序列化成字符串塞进 Redis 的列表中轮询数据进行处理
Redis 的字典相当于 Java 语言里面的 HashMap,它是无序字典。内部实现结构上同 Java 的 HashMap 也是一致的
hash 结构也可以用来存储用户信息,不同于字符串一次性需要全部序列化整个对象,hash 可以对用户结构中的每个字段单独存储。这样当我们需要获取用户信息时可以进行部分获取。而以整个字符串的形式去保存用户信息的话就只能一次性全部读取,浪费流量,效率低
Redis 的集合相当于 Java 语言里面的 HashSet,它内部的键值对是无序的唯一的。它的内部实现相当于一个特殊的字典,字典中所有的 value 都是一个值 NULL
。
用户可以速地向集合添加元素,或者从集合里面 删除元素,也可以对多个集合进行集合运算操作,比 如计算并集、交集和差集。
集合的应用
应用
诞生背景:
Cassandra最初由Facebook的两名印度人Avinash Lakshman (亚马逊Dynamo的作者之一)和Prashant Malik 共同开发。 它被开发用于为Facebook收件箱搜索功能提供支持。
以下是Cassandra历史上最重要的几个事件:
应用特点:
高可扩展性: Cassandra具有高度的可扩展性,可以帮助您可随时添加更多硬件,以便根据需求附加更多客户和更多数据。
刚性结构: Cassandra没有一个单一的故障点,它可用于无法承受故障的关键业务应用程序。
简单的数据分发: Cassandra中的数据分发非常简单,因为它可以灵活地通过在多个数据中心复制数据来分发所需的数据。
快速写入: Cassandra的设计是在低廉的商品硬件上运行。 它执行快速写入,可以存储数百TB的数据,而不会牺牲读取效率。
列式存储特征:
列式存储的数据可根据各自列族单独get,行式数据需要读取整行数据,数据冗余、速率、网络流量上都有所影响。
数据压缩:
在列式数据中,单个列族中的数据重复率高,可根据映射位图进行压缩,压缩率高。
行式数据的数据重复率非常低,压缩效率差。
例:
数据重组:
查询和update需要对数据进行组合,按索引进行列族的组合,比其他种类数据库效率差。
应用场景:
Cassandra的读取操作比较麻烦,单独的CQL不支持OR、GROUP等函数,适合存储分析数据进行分布统计。
案例:
与HBase区别:
1.HBase强制依赖HDFS
2.Cassandra的写入性能更好,适合数据接入
诞生背景:
2007年,Dwight Merriman, Eliot Horowitz和Kevin Ryan成立10gen软件公司,在成立之初,这家的公司目标进军云计算行业,为企业提供云计算服务。在开发云计算产品时,他们准备开发一个类似于数据库的组件,为云计算产品提供存储服务。当时是关系型数据库一统天下的时间,他们觉得传统的关系型数据库无法满足他们的要求,他们想要一款程序员不懂SQL语言也可以使用的数据存储产品。
在网络上找了一圈,不管是开源的还是闭源的产品,都没找到让他们满意的东西,既然找不到,那就自己开发吧,反正他们也有那个技术实力,10gen的创始人都来自谷歌,他们创建的网络广告公司DoubleClick被谷歌收购了,这是他们的第二次创业。
10gen公司不使用关系型数据库是由一定的原因的,当时他们还在DoubleClick公司的时候,就吃过关系型数据库的苦头。DoubleClick是一家网络广告公司,服务美国众多的知名公司,该公司每秒提供40万个广告,但在可伸缩性和敏捷性方面经常遇到困难,因此他们不得不经常自己开发和使用许多自定义数据存储来解决现有关系型数据库的不足,这让他们很是苦恼。
因此他们决定开发一款数据库产品解决他们在DoubleClick时遇到的问题,并为自己的云计算产品提供存储服务。
2008年,10gen进行第一轮A轮融资,150万美元,投资方为Union Square Venture,估值150万美元。
2009年,经过将近2年的开发,10gen开发出了MongoDB的雏形并将它开源以及正式命名为MongoDB,同时成立开源社区,通过社区运营MongoDB。MongoDB并不是“芒果数据库”,开始我也这么认为的,mongo取自单词humongous的中间部分,意味巨大无比的数据库,能够存储海量的数据库。10gen将MongoDB定义为面向集合、模式自由、自由扩展、使用程序语言和API访问的文档数据库。
商业模式:
1、通过免费开源的MongoDB吸引用户。
2、推出MongoDB的商业付费技术支持、数据库托管服务、MongoDB Atlas和MongoDB Enterprise Advanced等收费产品或服务,增加创收渠道。
3、深耕社区,通过社区黏住用户,通过社区和用户建立良好的互动关系,根据用户的反馈改进MongoDB,让MongoDB更好用。通过不同地区的MongoDB用户组大会推广MongoDB的相关产品。
4、在产品易用性上做到极致。
应用特点:
文档是数据库,Json数据存储
2007年, 10gen 创始人Eliot和Dwight在寻找一个能够支持他们的云计算平台的海量数据库。不奇怪,当时成熟的数据库基本上都是基于单机架构的传统关系型数据库如Oracle, MS SQLServer等。即便Oracle支持一些集群部署,其扩展性也仅限于2到4台服务器的范围。在没有很好的解决方案的情况下,10gen的创始人决定自己研发一个数据存储服务,能够把开发者使用的程序对象数据存到一个类似于数据库的地方,并提供非常易用的API让开发者可以对数据进行常见的增删改查操作。为了最大程度方便开发者,Eliot决定使用JSON作为数据格式来存储。JSON的数据在英文中被称之为JSON Document,这也是文档数据库名字的由来。
自动分片
在关系型数据库中,当数据量达到一定程度,单个节点服务器资源充分饱和无法保证及时的服务响应时间时,通常会采用分区分表的数据库优化方案。但是这些方案都是侵入式的,很多时候意味着应用程序需要做较大的改动,来配合数据库端的改动。而MongoDB的自动分片,可以在一个集群的几个分片服务器内自动进行数据的分布和均衡。在尽可能把数据均匀的分布到多个存储节点的同时,为应用开发者提供无缝的体验。开发者无须关心数据的具体位置,程序也不需要因为分片与否而进行修改。采用分片技术,开发者可以很容易使用数十甚至数百个节点。早期的用户如百度就是基于这种分片技术,为3亿多用户、3000亿条数据量的百度云盘文件元数据管理提供有效的集群解决方案。
应用场景:
不选择有应用的场景:
诞生背景:
利用数据和数据的关系,构建更加庞大的关系图谱
应用特点:
在这个例子中,A~E表示Node 的编号,R1~R7 表示Relationship编号,P1~P10 表示Property的编号。
例,通过B,便利第一层关系A、D,通过第二层关系A、遍历到C,依次。
(1)闪电般的读/写速度,无与伦比的高性能表现。
(2)非结构化数据存储方式,在数据库设计上具有很大的灵活性。
(3)能很好地适应需求变化,并适合使用敏捷开发方法。
(4)很容易使用,可以用嵌入式、服务器模式、分布式模式等方式来使用数据库。
(5)使用简单框图就可以设计数据模型,方便建模。
(6)图数据的结构特点可以提供更多更优秀的算法设计。
(7)完全支持ACID完整的事务管理特性。
(8)提供分布式高可用模式,可以支持大规模的数据增长。
(9)数据库安全可靠,可以实时备份数据,很方便恢复数据。
(10)图的数据结构直观而形象地表现了现实世界的应用场景。
应用场景:
社交网络图谱
反欺诈多维关联分析场景
企业关系图谱
在数据量极大的情况下,略显吃力