上一篇中谈到了nosql的一些背景,&怎么样从关系数据库切换到了nosql这样的模式。我们从原来的schema的数据描述切换到了利用分布式文件系统进行数据承载,然后来进行不能保证严格的CAP的这样数据存储的一个模式。
NoSQL优点
1).第一个好处就是说,它的成本低,因为它开源。
2).第二它的数据可以分散到系统中的各个节点,有一定的可扩展性。这也是由它底层的分布式文件系统,底层的这种数据处理平台(mapreduce或者是spark)所决定的,然后它有一定的可分布性能。之前说到mapreduce,或者是分布式文件系统(HDFS)中整个系统的扩展性,实际上是一个scale out的模式。也就是说当添加新的服务器,新的硬件设备之后,它的scalability能够得到相应的扩大。那么由底层系统决定,所以它上面是有一定的可扩展性。
3).同时它有对于这种schema,并没有一个非常严的一个要求,在nosql里面,它的数据承载是一系列的文件。这些文件实际上并不要求在传统关系数据库里面比较严格的表格化的、数据结构数据类型化的这样的一个数据描述,同时它还支持一定的叫做relax的这种CAP的,这样一个保证也就是说,在我保证一定的数据partition的一个前提下,我依然能够保证一定的数据的一致性以及数据的可用性。所以它是渐进的,逼近了CAP的一个保证。
NoSQL缺点
在nosql里面,有哪些是它目前还没有办法克服?或者说是我们使用了nosql作为我们的这个数据仓库、数据平台之后,我们有哪一些性能或者说哪些操作,是我们不能达到的?那么我们看看我们到底在这里面,放弃了什么东西?
1).首先我们不能做,在关系数据库里面表格&表格,数据库&数据库之间的join操作,因为它要求强的schema的数据模型。
2).还不能做类似的这个groupOrderBy,那么他们也都要求表格和表格之间进行并联,进行这个schema化的操作,那么还有一些复杂的sql的命令可能在我们这里面也不一定能够得到有效的支持。
3).当然今天nosql,衍生出的产品也支持了类似于sql,或者说更加精细的这样数据查询工作。但是本质上它依然受限于刚刚我们说到的,比如说数据的join、数据的group、数据的order。同时它在发展之初,它的编程环境也不如sql那样友好。
NoSQL原语操作
那我们来看在nosql中,它提供的这个原语性的操作有哪些呢?
可分成四类:
前面的几类是和数据的,这个原始的操作是有关的get,我们可以从nosql里面,将数据读取出来,或者put我们可以把数据塞入到nosql的环境当中,我们可以从里面删除数据。那么最后一个execute,就是说我们可以对要求的这样,一个数据范围进行一些操作,进行一些计算处理,或者是分析,在典型的nosql系统中,实际上是执行了相对比较原生的系统的程序和系统代码,那么当然也给了大家足够的想象空间,可以通过execute来做到非常复杂的查询的支持。
NoSQL具体的实现方法
nosql在具体的实现当中,大概是有一些什么样的考虑,有些什么样的办法,那么大致的可以分成两类:
1).Key和Value这样的一个模式。Key和Value对应的底层系统是类似于分布式文件系统(GFS,HDFS),这样的一个环境底下,我们可以通过对分布式文件系统进行改进,使得它原生的这个key value的模式,可以支持上层的这种nosql数据的放入和执行。
2).还有一个是从schema角度,一个叫做schema less的模式。也就是说在nosql里面,引入了一定的schema的数据属性,然后来进行这个数据的放置,数据的操作以及数据的查询,有一定的schema。但它的schema支持的并不全,不像传统关系数据那样全,它是从量的角度进行数据库的一种设计。
3).这两种模式特性是什么样?
3.1.Key Value的模式:
优点:首先基于Key Value,它的数据的模型很简单,所以它在数据读写,以及操作过程中会相对比较快,scalability和原来分布式文件系统的scalability是一致的,所以它的scalability是很好的,同时它的这个数据模型比较简单(model比较简单),它也能够按照scale out的方式进行扩展。
缺点:它对数据处理任务有一定要求,比如说并不是所有的数据处理任务,都能够平稳的转换到key value这样的模式。一些相对复杂的,比如说图的这种结构,也许就需要上层的开发人员有一定转化的能力,你才能用这种模式进行开发,否则会带来性能上的这种下降,或者说直接就不能做到。
3.2.schema less的模式:
优点:我们可以看到,那么schema的data,实际上它会相对比较灵活,因为他至少支持了一定的数据描述,然后它可以保证eventual的consistency,我们之前已经提到过,它也有一定的分布化的能力。已经有了一系列的系统,实际上也验证了这一点,它可以提供一定的性能上的保证,那么之前做的一系列的系统也支持了这一条。但本质上,它的数据模型还是相对比较复杂,它和NoSQL最开始设计的原则还是有一定的不匹配,所以在今天很多的工业界的,基于key value这种模式实际上还是一个非常重要的选择。
缺点:那么与关系数据库相比,它还是没有办法支持的acid,这种transcation属性的一个保证,而与nosql相比,它可能又不是那么简单。所以大家可以理解为,它处在这两者之间,那么同时也就具有这两者的优缺点。
summary
1.并不是任何场景,“NoSQL”系列数据库都优于传统的关系型数据库,一般来说,在以下情况下,比较适合使用“NoSQL”系列数据库:
1).数据库表的schema经常变化;比如在线商城,维护产品的属性经常要增加字段,如果该表的数据量过百万,新增字段会带来额外开销(重建索引等)。NoSQL应用在这种场景,可以极大提升DB的可伸缩性,开发人员可以将更多的精力放在业务层。
2).数据库表字段是复杂数据类型;对于复杂数据类型,比如SQL Sever提供了可扩展性的支持,像xml类型的字段。但是该字段不管是查询还是更改,效率非常一般。主要原因是是DB层对xml字段很难建高效索引,应用层又要做从字符流到dom的解析转换。NoSQL以json方式存储,提供了原生态的支持,在效率方便远远高于传统关系型数据库。
3).并发数据库请求。
4).海量数据的分布式存储;海量数据的存储如果选用大型商用数据,如Oracle,那么整个解决方案的成本是非常高的,要花很多钱在软硬件上。NoSQL分布式存储,可以部署在廉价的硬件上,是一个性价比非常高的解决方案。
2.Neo4J和FlockDB属于图存储类型的数据库,而MongoDB属于文档存储类型的数据库,db4o属于对象存储类型的数据库。