1、NoSQL基础概念
NoSQL基础概念
大数据问题
ACID
A原子性 (要全部执行,要么全都不执行)
C一致性 (一旦事物执行失败,通过回滚操作还原)
I隔离性 (两个事物不能同时进行)
D持久性 (一旦事物执行完成了,就立即将结果进程持久存储)
大数据处理
并行数据库
NoSQL数据库
NewSQL数据库
云数据
CAP理论
BASE理论
数据存储模型
列式数据库应用
键值数据库应用
文档数据库应用
MongoDB 它本身的名字是从humongous来的,MongoDB是一个高可扩展、易伸缩的、开源的、基于C++语言研发的一款文档类型的NoSQL关系型数据库,MongoDB是基于JSON格式来组织数据的, 程序本身使用C++语言研发,支持索引,在单个collection上支持多达64个索引,所以它的性能极强,MongoDB还支持强大的复制功能,第一种是主从复制,但是这种方案已经被MongoDB所舍弃了,第二种是副本集的复制,MongoDB有自己内部的副本集复制机制,类似于MySQL的主从结构,但是它能够实现当一个节点故障时迅速,自己内部选举另外一个节点成为新的主节点,不影响后面的数据操作;
MongoDB适用场景
MongoDB不适用的场景
大数据问题
ACID
A原子性 (要全部执行,要么全都不执行)
C一致性 (一旦事物执行失败,通过回滚操作还原)
I隔离性 (两个事物不能同时进行)
D持久性 (一旦事物执行完成了,就立即将结果进程持久存储)
大数据处理
并行数据库
NoSQL数据库
NewSQL数据库
云数据
CAP理论
BASE理论
数据存储模型
列式数据库应用
键值数据库应用
文档数据库应用
MongoDB 它本身的名字是从humongous来的,MongoDB是一个高可扩展、易伸缩的、开源的、基于C++语言研发的一款文档类型的NoSQL关系型数据库,MongoDB是基于JSON格式来组织数据的, 程序本身使用C++语言研发,支持索引,在单个collection上支持多达64个索引,所以它的性能极强,MongoDB还支持强大的复制功能,第一种是主从复制,但是这种方案已经被MongoDB所舍弃了,第二种是副本集的复制,MongoDB有自己内部的副本集复制机制,类似于MySQL的主从结构,但是它能够实现当一个节点故障时迅速,自己内部选举另外一个节点成为新的主节点,不影响后面的数据操作;
MongoDB适用场景
MongoDB不适用的场景
NoSQL基础概念
MongoDB也是属于NoSQL的领域,其实NoSQL从某种角度来讲,NoSQL是一种技术形式,或者说是一种技术流派,而不是一种特定的技术,它不像MySQL一样一种关系型数据库,一款实实在在的产品,而NoSQL不是,NoSQL只是一种技术实现方式,而不是某一个特定的产品,通过某种角度来讲,我们可以把它称为,和关系型数据库是相对应的,而关系型数据库当中可能包含了像MySQL、DB2、Oracle等等,而NoSQL也有众多产品,但是NoSQL又不能完全和关系型数据库对比起来,因为关系型数据库本身是一种特定的技术,它就叫关系型数据库,但NoSQL虽然叫非关系型数据库,他却仍然内部分散成了很多流派;
大数据问题
大数据其实是一个比较模糊的概念,多大的数据算是大数据,很多时候很多人都叫做海量数据,说白了,就是我们的数据量非常大,非常非常多,后来也就有了Big Data这种称呼了,事实上现代的互联网公司,他们每年都在产生大量的数据,因此对于这样的海量数据的处理,或者说保存了大量数据的这种企业公司来讲 ,他们慢慢就开始面临了数据处理、数据挖掘和分析的这种问题,但事实上很多中小型的数据量依然还是要小得多,所以真正拥有了大量数据的,比如搜索引擎类的,社交类公司,他们才拥有真正意义的大数据;
比如百度、Google、微博,他们无论是靠搜索引擎爬虫爬来的,还是通过众包方式产生的,当数据量到一定的程度以后,通过一个所谓的精准算法的设定,它可以在这些数据里面提取一些有助于人类做决策的结果,据说有人说过,像非典或者某一次病毒的来临最早能够提供预测的是Google,或许它的获取方式就是在某一时刻某一区域内,搜索关键词的量会比较大,由此得出的结论,所以这样的公司才算是真正意义上的掌握了人类社会科技发展趋势的这么一家公司;
像Google这样的公司,他们也在不断的在全球进行资源整合,大量的收购公司,而国内也是比如腾讯,阿里巴巴这些国内的龙头企业,也是在大量的收购公司,但是可以看到国内的这些企业在收购时他们并不是在技术发展的角度来收购的,而仅仅是为了所谓的资源整合完成整个产业链的整合,有的领域有有的领域没有,而自己又来不及从头构建,然后就直接买,今天买一个搜索引擎,明天买一个视频服务,构建一个全产业链,而所谓着这种机制是从商业模式来考虑的,而任何一家纯粹依赖于商业模式想做百年企业,无益于痴人说梦;
而像Google这样的公司,这么多年来看他们所收购的公司,都是在人工智能,在机器人构建这一领域的公司,就是在某一个特定角度的领域走在世界前沿的公司,作为一个技术公司,如果不在技术本身进行深入研究和公司的话,纯粹靠商业模式来赚钱,这不是一种长久的做法,不管怎么讲,他们也是真正的有着所谓的大数据的公司,而他们也才会真正面临大数据的问题;
ACID
ACID,是指在可靠数据库管理系统(DBMS)中,事务(transaction)所应该具有的四个特性:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability).这是可靠数据库所应具备的几个特性.所以ACID就是这四大特性的缩写。
A原子性 (要全部执行,要么全都不执行)
事务的原子性指的是,事务中包含的程序作为数据库的逻辑工作单位,它所做的对数据改操作要全部执行,要么全部不执行。这种特性称为原子性。 事务的原子性要求,如果把一个事务看作是一个程序,它要么完整的被执行,要么完全执行。就是说事务的操纵序列或者完全应用到数据库或者完全不影响数据库。这种特性称为原则性 假如用户在一个事务内完成了对数据库的更新,这时所有的更新对外部世界必须是可见的,或者完全没有更新。前者称事务已提交,后者称事务撤销。DBMS必须确保由成功提交的事物完成的所有操作在数据库内有完全的反映,而失败的事务对数据库完全没有影响;
C一致性 (一旦事物执行失败,通过回滚操作还原)
指在一个事务执行之前和执行之后数据库都必须处于一致性状态。这种特性称为事务的一致性。假如数据库的状态满足所有的完整性约束,就说该数据库是一致的。一致性处理数据库中对所有语义约束的保护。假如数据库的状态满足所有的完整性约束,就说该数据库是一致的。例如,当数据库处于一致性状态S1时,对数据库执行一个事务,在事务执行期间假定数据库的状态是不一致的,当事务执行结束时,数据库处在一致性状态S2;
I隔离性 (两个事物不能同时进行)
指并发的事务是相互隔离的。即一个事务内部的操作及正在操作的数据必须封锁起来,不被企图进行修改的事务看到 分离性是DBMS针对并发事务间的冲突提供的安全保证。DBMS可以通过加锁在并发执行的事务间提供不同级别的分离。假如并发交叉执行的事务没有任何控制。操纵相同的共享对象的多个并发事务的执行可能引起异常情况;
DBMS可以在并发执行的事务间提供不同级别的分离。分离的级别和并发事务的吞吐量之间存在反比关系。较多事务的可分离性可能会带来较高的冲突和较多的事务流产。流产的事务要消耗资源,这些资源必须要重新被访问。因此,确保高分离级别的DBMS需要更多的开销;
D持久性 (一旦事物执行完成了,就立即将结果进程持久存储)
持久性意味着当系统或介质发生故障时,确保已提交事务的更新不能丢失。即一旦一个事务提交,DBMS保证它对数据库数据的改变应该是永久性的,耐得住任何系统故障。持久性通过数据库备份和恢复来保证 持久性意味着当系统或介质发生故障时,确保已提交事务的更新不能丢失。即对已提交事务的更新恢复。一旦一个事务被提交,DBMS必须保证提供适当的冗余,使其耐的住系统故障。所以,持久性主要在于DBMS的恢复性能;
大数据处理
对于大数据分析和处理来讲,无论是哪几种解决方式将数据存储下来,那么接下来就需要面临如何做分析和处理了,比方说找到我们比较感兴趣的数据,甚至是分析整个存储下来数据的走势,这也是需要面临的一个问题,目前来讲大数据的处理无非就是并行技术,但是大多的分析和处理模型上,常见的无非就是MapReduce机制,将数据先做Map给他切割到多个节点上去给它做聚合,这就叫做MAPReduce,把大数据映射成键值对,而后对各个键值对做处理后,再把这些处理过的键值对儿,做聚合,最终得出聚合结果,对于我们的Hadoop其实也就是这么一个系统,首先Hadoop提供了所谓大数据存储的问题,因为它用到的是分布式文件系统来存储的,它不是这种把数据归结成简单数据模型的这种方式,它是把它当做文件来处理的,如果把它抽出来作为一个一个数据单元存储的话,也可以放在NoSQL当中,所以在Hadoop组件中就有一个组件叫做Hbase,Hbase也是NoSQL的一种,所以Hadoop实现了大数据的存储,处理对于Hadoop来讲,提供的MapReduce框架,因此它能够让我们的程序员开发一些程序,按需要对数据进行处理并分析我们需要用到的结果;
既然有大数据的问题,很多公司也存在大数据的问题,事实上数据的增长量确实是非常非常大,这样带来的结果就是数据的存储、分析都会面临着很大的瓶颈,像我们传统去查看数据的方式比如cat打开一个文件,因为任何数据要想能够被程序或者进程所应用,所以它一定是要被载入内存以后才可以的,所以如果是一个IT的数据,而且是一个文本文档,使用cat查看一下结果是什么,这是能够想得明白的,如果我们有一个1TB的web日志数据,如果我们在从中想分析一个哪一个页面的访问量是最大的,那么就需要遍历这整个文件中的所有的页面的访问量,而且还要给它进行一次排序,排完序还要找到最大的哪个访问量的页面,这通常对任何一个单机主机的CPU,它也未必能够应付这样的场景,因此大数据的处理,对于我们传统意义上单机的处理,无论是网络IO还是磁盘IO,对CPU无论是控制器还是运算器,还包括我们的内存,都带来的极大的挑战,他们无法应付这种场景,而对系统本身要进行扩展的话,无非就有两种模式,向上或向外,而向上总是有那么一时刻再也无法向上扩展了,再加资源再加服务器,很有可能是对性能是降低的,而向上扩展的这种方式的性价比也是不低的,因此并行的处理方式,是现在面临大数据的问题,比较常见的解决方式,而目前来说,对大数据的存储和管理主要有四大类数据存储和管理系统;
并行数据库
并行数据库系统是指那些在共享体系结构中进行数据操作的数据库系统,这些系统大多数都采用所谓的关系数据模型,并且支持SQL语句查询,说白了就是对传统的关系型数据库模型,做到了并行扩展的技术,就像我们的MySQL的分片技术,将一个数据给它分割以后,切片存储在多个不同的数据库节点上,以实现存储的,所以为了能够实现并行操作,系统中还采用了两个关键技术,一个是水平切片,一个SQL的分区查询,因为经过水平切片之后我们的数据是分割在不同的多个物理数据库节点上,因此每一个节点我们称之为一个分区,那我们这个时候接下来的查询操作很可能就要跨分区进行查询了,因此最后的查询尽可能要查询的分区越少越好,依然采用关系型数据库的方式通过水平切割的方式扩展其存储能力,这种我们称之为并行数据库系统;
NoSQL数据库
NoSQL我们称之为一种技术流派,NoSQL不是一种单一的技术,这个词是1998年出世的,一个人开发出一个轻量级不提供SQL功能的关系型数据库,因为背离了关系型数据库本身的功能,由此大概是09年的时候在一次所谓的分布式开源数据的讨论上首次提出NoSQL的概念,所以说09年NoSQL才正式走进人们的视野,事实上NoSQL本身不是一种新技术,在关系型数据库出现之前的那些数据库,他们也都是非关系型数据库,所以从这个角度来讲,NoSQL指的是那些非关系型的分布式的不提供ACID数据库设计范式的数据库管理系统,NoSQL通常有几个特点。
第一,使用日常简单的数据模型,不像关系型数据库当中,各种约束使得整个数据库为了能够遵循关系型数据库设计的范式,通常需要很复杂的设计,这样会消耗非常多是系统资源,但数据量非常大的时候,事实上是很难应用的,所以简单数据模型在这种数据当中仅是类似于键值的这种方式来记录数据的,这也是最常见的应用机制。
第二,他们通常还提供了元数据,和数据分离,就像我们的分布式一样,元数据放在一个节点上,数据放在一堆节点上,这种模式就是所谓的元数据和数据分离的模式,而大多数的NoSQL在实现的时候也是类似这样的功能,但是我们知道像关系型数据的MySQL在存储数据时使用INODB这种存储引擎,把表结构表的索引数据全部是存在一个表空间当中的,管理起来极为不便,而且不太容易实现扩展。
第三,弱一致性,我们分布式系统主要关注CAP理论中的其中两个,可用性和分区容错性,所以他们是弱一致性的,但是弱一致性,其中有一个目标叫做最终一致性,有一个操作可能现在不是一致性的,但是一旦某一个时刻之后他们就会变为一致性。
第四,高吞吐量,事实上,NoSQL主要是为了海量数据存储,或者说比并行高性能读写,由此他们所提供的吞吐能力通常都非常强。
第五,较高的水平扩展能力和底端硬件集群,也就是说NoSQL他们设计用来就是为了应用这些常见的PC Server端的,也就是那些以Server架构设计的X86系列的中低端的服务器系统,而非那些专用的商用机,所以他们主要应用在底端硬件集群上,而实现的一种能够提供并行的处理存储能力的这么一种架构;
NoSQL虽然提供的较高的扩展性和灵活性,但是NoSQL系统其实也是有它的缺点的,比如第一,不支持ACID,也就意味着它没有办法保证严格意义的事物操作,因此对于那些高事物要求的场景来讲,NoSQL是不适用的,第二点,功能过于简单,我们要实现非常复杂的模型时,还不得不进行设计才可以,第三没有统一的查询语言,每一个NoSQL都有自己专用的查询语言;
NewSQL数据库
关系型数据库,在处理事物时,对性能影响是非常大的,我们一般来讲需要优化的性能有很多,像通信、存储、日志、锁等,对于关系型数据库在处理事务时有几个要素,对性能影响非常大,像节点之间的通信,日志本身,锁,事物的处理主要也就是靠内部的加锁方式实现的,缓冲区管理,为了事物功能的实现,他们通常会将数据组织成固定大小的页,这种大小的页要缓存在我们的内存中,通常会对整个系统带来一定的开销,那么因此为了解决这个问题,很多新式的数据库在,这些数据库采用一些比较好的设计方式,比如取消了比较耗资源的缓冲池,把整个数据搬到内存中来执行,把所有数据都运行在内存中,而这种数据库就是一种内存数据库,他们摒弃了早起关系型数据库当中加锁的机制,它可以在并行模式下,让多线程使用同一个锁,以代替比较昂贵的单机上实现的所谓故障恢复操作等,由此像这种纠正了传统关系型数据库在它固有性能问题上的处理解决方案,进而能够提升其性能的,并且为了能够表示自己有别于这些传统的关系型数据库,这些解决方案就取了一个NewSQL,他们依然是SQL,只不过与传统的SQL在这些,非常容易出现性能问题的层面上打破了单机本身容易出现的问题,将整个设计模式,扩展到了多机系统上,目前来讲实现了NewSQL的产品有Clustrix、GenieDB、ScaleBase、Drizzle等;
云数据
随着NoSQL和NewSQL数据库阵营的崛起,但是像这些所谓的开源的非关系型数据库产品,不断的去蚕食固有的数据库市场的份额,像MongoDB就已经是NoSQL最为流行的一个产品之一,那么云数据管理系统,指的是数据库即服务,在很多云叫做DBAAS,用户无需本机安装数据库服务,像亚马逊提供的就叫做RDS,这些都是几个著名的产品;
CAP理论
大概是2000年7月份加州大学伯克利分校的Eric Brewer在ACM PODC这个杂志上首次提出这么一个CAP理论基础猜想,两年之后大概是2002来自于麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了的的确确是存在这么一个定理的,因此使得其后来直接成为了一个定理,被任何分布式系统设计者所广泛采用,而且在设计时基本上也遵循次定理;
C:一致性;
A:可用性;
P:网络分区容错性;
其实任何一个分布式系统最多只能满足CAP中至多两个,最多只能同时满足两项,由于分布式系统P(网络分区容错性)我们必须得容忍它,比如得保证它存在,因此我们只能从CA之间进行选择,所以这样带来的结果要么是CP要么是AP,而CP主要考虑,一致性和容错性,AP主要考虑可用性和容错性;
但是我们只保证可用,而放弃一致性的话,其实数据的没有什么价值和意义的,因此一个没有一致性的分布式系统没有任何价值,所以即便我们采用AP这种法则,通常我们应该最终要保证C能实现,只不过是在一个特定的时间窗口以后,再给予满足,所以后来基于这种方式进行权衡就有了BASE理论;
BASE理论
BA:基本可用,指的是分步系统在出现不可预知的故障时,允许损失部分可用性,所以叫基本可用;
S:软状态,所谓软状态指的是,允许系统状态存在中间状态,而且该状态的存在不会影响整体可用性,也就是说允许系统在不同的节点的数据副本之间窗口在保证数据同步时,允许接受一定程度的时间延迟,在一个时间窗口内用户从不同节点所获得的数据可以是不同的;
E:最终一致性,系统中的所有副本,经过S的这个时间窗口以后,最终必须能达到数据一致性的状态;
数据存储模型
NoSQL有很多流派,而对NoSQL划分的流派就是根据其数据存储模型来划分的,一般来讲NoSQL可以简单划分为以下几个数据模型;
列式数据存储模型:关系型数据库都是以行来管理的,而列式数据存储模型来讲,它是每一个列来当做一个单独的数据存储和管理的,所以它不支持关系型数据库中的表的这种连接查询,因为它在数据存储时是围绕列展开的,因此它没办法实现连接查询;
文档数据存储模型:文档存储它把每一行数据都组织成一个单位,一个文档,把每一行文件想象成一个文档,而这个文档里面分别记录了这一个实体的所有信息,仍然存储为一个键值对,但是把这个键值对存储为一个组,这个组就叫做一个文档,所以在关系型数据中是一行一行的数据,而在文档数据库中是一个文档一个文档的数据,而文档和文档之间是没有关系的,并且在一个文档中它的格式扩展是非常灵活的,在关系型数据当中如果发现我们要新增一个列,那么这个整个表都会受到影响,而文档数据库是单独管理的,所以如果某一个文档要进行扩展是对其他文档的不会有任何影响的,所以它的设计是非常的灵活,而MongoDB就是一个文档数据库;
键值数据存储模型:把所有数据都存储为键值对,键值数据模型的主要思想是来自于hash表的,在hash表中有一个特定的key和一个value对应的指针,因此它里面所存储的数据无非就是键值对;
列式数据库应用
应用场景:在分布式文件系统上提供支持随机读写的分布式数据存储;
典型产品:HBase、Cassandra
数据模型:以列为中心进行存储,将同一列数据存储在一起;
优点:快速查询、高可用扩展性,易于实现分布式扩展;
键值数据库应用
应用场景:内容缓存,主要用于大量并行数据访问高负载场景;
典型产品:Redis、MemcacheDB、DynamoDB
数据模型:基于hash表实现key-value模型
优点:读写极快;
文档数据库应用
应用场景:非强事物需求的应用;
典型产品:MongoDB、ElasticSearch、CouchDB
数据模型:键值模型,存储为文档
优点:数据模型无需事先定义
MongoDB 它本身的名字是从humongous来的,MongoDB是一个高可扩展、易伸缩的、开源的、基于C++语言研发的一款文档类型的NoSQL关系型数据库,MongoDB是基于JSON格式来组织数据的, 程序本身使用C++语言研发,支持索引,在单个collection上支持多达64个索引,所以它的性能极强,MongoDB还支持强大的复制功能,第一种是主从复制,但是这种方案已经被MongoDB所舍弃了,第二种是副本集的复制,MongoDB有自己内部的副本集复制机制,类似于MySQL的主从结构,但是它能够实现当一个节点故障时迅速,自己内部选举另外一个节点成为新的主节点,不影响后面的数据操作;
它能够支持自动分片的机制,Mongodb还支持MapReduce的机制,所以非常容易做数据处理中的聚合操作,并且MongoDB还可以在所有的分片节点上进行并行查询,如果我们对它对分片的话,基于MapReduce机制能够实现并行的查询,这就是所谓的并行处理机制,MongoDB内部自己就实现了并行处理的功能;
MongoDB适用场景
MongoDB特别适用于WEB站点,缓存,并且在较大数据量或者比较长的value的情况下也是非常适用的,并且还比较适用于对扩展性比较高的场景,它的数据存储本身没有严格的要求,是以JSON形式存储的;
MongoDB不适用的场景
对事物要求比较高的场景下是不适用的,并期望通过SQL接口来实现数据操作的这种场景是不太适用的;