Nosql简介
背景:
众所周知,随着社交网络,网络视频,网络游戏的使用,网络资料量呈现爆炸性增长;这时,大数据时代出现。 业界总结出大数据的四个特点(4V):Volumn(数据体量大), Velocity(价值密度低), Variety(类型繁多), Veracity(处理速度快)。
普通关系数据库不合适处理这样庞大的数据。为了弥补关系型数据库的不足,各种各样的NoSQL数据库应运而生。
接下来说说关系数据库的不足:
因为它毕竟是一个通用型的数据库,并不能完全适应所有的用途。具体来说它并不擅长以下处理:
- 大量数据的写入处理
- 为有数据更新的表做索引或表结构(schema)变更
- 字段不固定时应用
- 对简单查询需要快速返回结果的处理
为什么使用Nosql:
Nosql是“Not Only SQL”的缩写,它的意义是:适用关系型数据库的时候就使用关系型数据库,不适用的时候也没有必要非使用关系型数据库不可,可以考虑使用更加合适的数据存储。 不像关系型数据库,相对地,NoSQL数据库只应用在特定领域,基本上不进行复杂的处理,但它恰恰弥补了之前所列举的关系型数据库的不足之处。
优点:
易于分散和处理:
关系型数据库并不擅长大量数据的写入处理。 原本关系型数据库就是以JOIN为前提的,就是说,各个数据之间存在关联是关系型数据库得名的主要原因。 为了进行JOIN处理,关系型数据库不得不把数据存储在同一个服务器内,这不利于数据的分散。
NoSQL数据库原本就不支持JOIN处理,各个数据都是独立设计的,很容易把数据分散到多个服务器上。 由于数据被分散到了多个服务器上,减少了每个服务器上的数据量,即使要进行大量数据的写入操作,处理起来也更加容易。同理,数据的读入操作当然也同样容易。
提升性能和增大规模:
想要使服务器能够轻松地处理更大量的数据:
- 提升性能:提升性能指的就是通过提升现行服务器自身的性能来提高处理能力。程序方面也不需要进行变更,但需要一些费用。若要购买性能翻倍的服务器。
- 增大规模:使用多台廉价的服务器来提高处理能力。它需要对程序进行变更,但由于使用廉价的服务器,可以控制成本。另外,以后只要依葫芦画瓢增加廉价服务器的数量就可以了。
注意: NoSQL数据库基本上来说为了“使大量数据的写入处理更加容易(让增加服务器数量更容易)”而设计的。但实际上NoSQL数据库还有各种各样的特点,如果能够恰当地利用这些特点将会是非常有帮助。
Nosql数据库:
NoSQL的官方网上显示现在的Nosql数据库有122种之多。其中存在着“key-value存储”、“文档型数据库”、“列存储数据库”等种类
key-value存储: 最常见的NoSQL数据库,它的数据是以key-value的形式存储的。虽然它的处理速度非常快,但是基本上只能通过key的完全一致查询获取数据。根据数据的保存方式可以分为临时性、永久性和两者兼具三种。
临时性:memcached属于这种类型。把所有数据都保存在内存中
- 在内存中保存数据
- 可以进行非常快速的保存和读取处理
- 数据有可能丢失
永久性:Tokyo Tyrant、Flare、ROMA等属于这种类型。是把数据保存在硬盘上。
- 在硬盘上保存数据
- 可以进行非常快速的保存和读取处理(但无法与memcached相比)
- 数据不会丢失
两者兼具: Redis属于这种类型。
Redis首先把数据保存到内存中,在满足特定条件(默认是15分钟一次以上,5分钟内10个以上,1分钟内10000个以上的key发生变更)的时候将数据写入到硬盘中。 这样既确保了内存中数据的处理速度,又可以通过写入硬盘来保证数据的永久性。这种类型的数据库特别适合于处理数组类型的数据。
- 同时在内存和硬盘上保存数据
- 可以进行非常快速的保存和读取处理
- 保存在硬盘上的数据不会消失(可以恢复)
- 适合于处理数组类型的数据
面向文档的数据库: MongoDB、CouchDB属于这种类型。
不定义表结构:面向文档的数据库具有以下特征:即使不定义表结构,也可以像定义了表结构一样使用。 关系型数据库在变更表结构时比较费事,而且为了保持一致性还需修改程序。然而NoSQL数据库则可省去这些麻烦(通常程序都是正确的),确实是方便快捷。 可以使用复杂的查询条件:面向文档的数据库可以通过复杂的查询条件来获取数据。虽然不具备事务处理和JOIN这些关系型数据库所具有的处理能力,但除此以外的其他处理基本上都能实现。这是非常容易使用的NoSQL数据库。
- 不需要定义表结构
- 可以利用复杂的查询条件(不具备事务处理和JOIN)
面向列的数据库:Cassandra、Hbase、HyperTable属于这种类型。
普通的关系型数据库都是以行为单位来存储数据的,面向列的数据库是以列为单位来存储数据的。
注意:NoSQL不是为了替代SQL而出现的,它是一种替补方案,而不是解决方案的首选。