之前看过一本名叫<<大数据挑战的书>>,里面主要讲了NOsql的内容,感觉讲得确实不错,今天来重新温习一下,我们大话NOsql。说道NOsql,我们肯定联想到的内容就是BigData大数据了,不错,当今的时代就是大数据的时代了。如果放在前几年,互联网还没有这么发达的情况下,也许谁也不会听过这个名词。在讲正题的时候,我做了张图来看看一般服务端架构在面对业务发展的需要时候,一般的演变趋势:
所以如果公司的数据量发展到一定规模的话,可以采用Nosql.好了终于引出了Nosql这个今天的主题了。Nosql可以理解为”NotOnlysql”,主要指的是非关系型,分布式,不提供ACID的数据库设计模式,强调的是类似于Map的“键值存储”,和”文档存储“。面对海量数据,Nosql采用了一种弱类型的数据,采用更加简单的数据模型,一般都是用字符串表示所有的数据类型。但是他可能不会像关系型数据库一样有那么好的强一致性,应该nosql是一种最终一致性。Nosql也避免了许多诸如联表查询等复杂操作,基本就是简单的赋值,取值等,
可以实现比较难高的吞吐量。现在的数据库系统可谓是五彩缤纷,来张图看看:
在介绍nosql之前,要知道的一些海量数据的理论性知识,CAP理论,C,(Consistency)强一致性,A(Available)可用性,P(PartitionTolerance)分区容忍性,可以理解为系统在存在网络分区的情况下仍然可以接受请求。自然这让我们联系到了另一个理论ACID,A(Atomic)原子性,C(Consistent)一致性,I(Isolation)隔离性,D(Durablitity)持续性。还有一个比较重要的协议2PC两阶段提交协议,许多分布式关系数据库采用此协议来完成分布式事务。下面我们来真正了解一下具体的NOsql。
K-V数据库
首先我们来了解是Redis,Redis是一个开源的,高级key-value的数据库。他的value不仅支持String类型,而且还有list,set等结构,Redis采用的是内存进行数据存储,等数据到达一定规模后,在持久化到文件或磁盘中。基于Redis的特点,新浪微博采用的就是Redis,对于微博这样的结构清晰,数据规模庞大的应用来说,Redis当然最适合不过了。
Column-Oriented列式数据库
说到列式数据库,我们不得不提到他的始祖,Bigtable数据库,在后来衍射出的很多数据库都能看到他的影子,列式数据库强调的是一种面向列的稀疏存储,还有一个列族的概念,跟关系型数据库的单行单列,不一样,比较典型的Hadoop采用的HBase数据库。
文档型数据库
文档型数据,我这里说的有2种,MongoDB,还有一个CouchDB,两者有很多共同点存储的都是JSON类型数据类型,在文档数据库中文档成为了数据存储的一个基本单位,因此,所存储的数据,甚至可以要求是无结构的,文档可长,可短,每一个都以类似于”{“”id”:200,“msg”:”haha”}这样的json格式保存在数据库中。我们重点关注一下MongoDB,在MongoDB中存在着类似于sql查询语句的操作,但是又不是跟sql语句完全相同,比如db,user,find(),MongoDB支持Map/Reduce模型,CouchDB具体RestFulAPI,可以实现用Http请求实现操作。二者数据库都借助了Map/Reduce,技术提高了数据处理的效率,这对于与存储非结构化,和半结构化的数据都有很大的帮助。
图存数据库
图存数据库我刚刚听说这个名词的时候,也是觉得难以理解,官方给出的定义:图存数据库使用基础的数据结构,来存储代表一个图形的数据,能够通过非常方便的方式优雅的呈现任何类型的数据。图存数据库现在一般有3类,Neo4j数据库,GraphDB图存数据库,OrientDB,图存数据库的查询会模仿图的遍历实现查找,通过朋友找到朋友的朋友,最终找到目标。
Nosql就是分为上述的4种类型,突然心血来潮,相到一个比较重要的知识点,数据处理,数据处理平常也总是有人在提起,我就提提,我说的数据处理指的是传统的压缩算法的实现,一般有2种,一个哈弗曼编码,学过计算机的,数据结构都上过的吧,另一个L.Z算法系列的,现在应该已经很多版本了吧,是基于窗口互动的,核心思想就是复用相同的字符串,如果后面的字符串出现了前面重复,用一个标记代替,可以大大节省压缩数量。
好了,花了1000多字,理了理思路,也起到了复习的效果了。