为什么需要用非关系型数据库(NOSQL)?

为什么需要NOSQL

随着互联网web2.0网站的兴起,非关系型的数据库现在成了一个极其热门的新领域,非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,例如:
  
  1、High performance——对数据库高并发读写的需求
  
  Web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息,所以基本上无法使用动态页面静态化技术,因此数据库并发负载非常高,往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住,但是应付上万次SQL写数据请求,硬盘IO就已经无法承受了。其实对于普通的BBS网站,往往也存在对高并发写请求的需求,例如像JavaEye网站的实时统计在线用户状态,记录热门帖子的点击次数,投票计数等,因此这是一个相当普遍的需求。
  
  2、Huge Storage——对海量数据的高效率存储和访问的需求
  
  类似Facebook,twitter,Friendfeed这样的SNS网站,每天用户产生海量的用户动态,以Friendfeed为例,一个月就达到了2.5亿条用户动态,对于关系数据库来说,在一张2.5亿条记录的表里面进行SQL查询,效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统,例如腾讯,盛大,动辄数以亿计的帐号,关系数据库也很难应付。
  
  3、High Scalability && High Availability——对数据库的高可扩展性和高可用性的需求
  
  在基于web的架构当中,数据库是最难进行横向扩展的,当一个应用系统的用户量和访问量与日俱增的时候,你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说,对数据库系统进行升级和扩展是非常痛苦的事情,往往需要停机维护和数据迁移,为什么数据库不能通过不断的添加服务器节点来实现扩展呢?
  
  在上面提到的“三高”需求面前,关系数据库遇到了难以克服的障碍,而对于web2.0网站来说,关系数据库的很多主要特性却往往无用武之地,例如:
  
  1. 数据库事务一致性需求
  
  很多web实时系统并不要求严格的数据库事务,对读一致性的要求很低,有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。
  
  2. 数据库的写实时性和读实时性需求
  
  对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出来这条数据的,但是对于很多web应用来说,并不要求这么高的实时性,比方说我(JavaEye的robbin)发一条消息之后,过几秒乃至十几秒之后,我的订阅者才看到这条动态是完全可以接受的。
  
  3、对复杂的SQL查询,特别是多表关联查询的需求
  
  任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的复杂SQL报表查询,特别是SNS类型的网站,从需求以及产品设计角度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。
  
  因此,关系数据库在这些越来越多的应用场景下显得不那么合适了,为了解决这类问题的非关系数据库应运而生,现在这两年,各种各样非关系数据库,特别是键值数据库(Key-Value Store DB)风起云涌,多得让人眼花缭乱。例如:
  Cassandra,Voldemort,MongoDB,Dynomite,HBase,CouchDB,Hypertable, Riak,Tin, Flare, Lightcloud, KiokuDB,Scalaris, Kai, ThruDB。。。

什么是NOSQL

NoSQL(NoSQL = Not Only SQL),意即“不仅仅是SQL”,是一项全新的数据库理念,泛指非关系型的数据库。

非关系型数据库与关系型数据库的区别:

  1. 关系型数据库的数据是存储在硬盘中,而非关系型数据的数据是存储在内存中

  2. 关系型数据库有固定的数据模型,也就是说事先要定义好表

  3. 关系型数据库的表与表之间有关系:一对一、一对多、多对多

  4. 非关系型数据库存储的数据结构非常简单,不能事先定义好表,都是以"键值对"类型的数据进行存储

主流的NOSQL产品

 

  • 键值(Key-Value)存储数据库

    相关产品: Tokyo Cabinet/Tyrant、Redis、Voldemort、Berkeley DB

    典型应用: 内容缓存,主要用于处理大量数据的高访问负载。

    数据模型: 一系列键值对

    优势: 快速查询

    劣势: 存储的数据缺少结构化

  • 列存储数据库

    相关产品:Cassandra, HBase, Riak

    典型应用:分布式的文件系统

    数据模型:以列簇式存储,将同一列数据存在一起

    优势:查找速度快,可扩展性强,更容易进行分布式扩展

    劣势:功能相对局限

  • 文档型数据库

    相关产品:CouchDB、MongoDB

    典型应用:Web应用(与Key-Value类似,Value是结构化的)

    数据模型: 一系列键值对

    优势:数据结构要求不严格

    劣势: 查询性能不高,而且缺乏统一的查询语法

  • 图形(Graph)数据库

    相关数据库:Neo4J、InfoGrid、Infinite Graph

    典型应用:社交网络

    数据模型:图结构

    优势:利用图结构相关算法。

    劣势:需要对整个图做计算才能得出结果,不容易做分布式的集群方案。

NOSQL的特点

  1. 数据存放在内存中(但是它会在后台定期地将数据备份到硬盘中)

  2. 没有固定的数据结构(不用事先定义好表)

在大数据存取上具备关系型数据库无法比拟的性能优势,例如:

  • 易扩展

    NoSQL数据库种类繁多,但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系,这样就非常容易扩展。也无形之间,在架构的层面上带来了可扩展的能力。

  • 大数据量,高性能

    NoSQL数据库都具有非常高的读写性能,尤其在大数据量下,同样表现优秀。这得益于它的无关系性,数据库的结构简单。

  • 灵活的数据模型

    NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式。而在关系数据库里,增删字段是一件非常麻烦的事情。如果是非常大数据量的表,增加字段简直就是一个噩梦。这点在大数据量的Web2.0时代尤其明显。

  • 高可用

    NoSQL在不太影响性能的情况,就可以方便的实现高可用的架构。比如Cassandra,HBase模型,通过复制模型也能实现高可用。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章