关闭

什么是NoSQL

344人阅读 评论(0) 收藏 举报
分类:

NoSQL,指的是非关系型的数据库。随着互联网web2.0网站的兴起,传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。


简介
  NoSQL,意即反SQL运动,是一项全新的数据库革命性运动,早期就有人提出,发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储,相对于目前铺天盖地的关系型数据库运用,这一概念无疑是一种全新的思维的注入。

现今状况
  现今的计算机体系结构在数据存储方面要求具备庞大的水平扩展性①,而NoSQL致力于改变这一现状。目前Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型数据库。
  NoSQL项目的名字上看不出什么相同之处,但是,它们通常在某些方面相同:它们可以处理超大量的数据。
  这场革命目前仍然需要等待。的确,NoSQL对大型企业来说还不是主流,但是,一两年之后很可能就会变个样子。在NoSQL运动的最新一次聚会中,来自世界各地的150人挤满了CBS Interactive的一间会议室。分享他们如何推翻缓慢而昂贵的关系数据库的暴政,怎样使用更有效和更便宜的方法来管理数据。
  “关系型数据库给你强加了太多东西。它们要你强行修改对象数据,以满足RDBMS (relational database management system,关系型数据库管理系统)的需要,”在NoSQL拥护者们看来,基于NoSQL的替代方案“只是给你所需要的”。
  1.水平扩展性(horizontal scalability)指能够连接多个软硬件的特性,这样可以将多个服务器从逻辑上看成一个实体。 
我们为什么要使用NOSQL非关系数据库?
  随着互联网web2.0网站的兴起,非关系型的数据库现在成了一个极其热门的新领域,非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,例如:
  1、High performance - 对数据库高并发读写的需求
  web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息,所以基本上无法使用动态页面静态化技术,因此数据库并发负载非常高,往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住,但是应付上万次SQL写数据请求,硬盘IO就已经无法承受了。其实对于普通的BBS网站,往往也存在对高并发写请求的需求。
  2、Huge Storage - 对海量数据的高效率存储和访问的需求
  对于大型的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应用来说,并不要求这么高的实时性。
  3、对复杂的SQL查询,特别是多表关联查询的需求
  任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的复杂SQL报表查询,特别是SNS类型的网站,从需求以及产品设计角度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。
  因此,关系数据库在这些越来越多的应用场景下显得不那么合适了,为了解决这类问题的非关系数据库应运而生。
  NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构,通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。该术语在 2009 年初得到了广泛认同。
  当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而 NoSQL 存储就是为了实现这个需求。Google 的BigTable与Amazon的Dynamo是非常成功的商业 NoSQL 实现。一些开源的 NoSQL 体系,如Facebook 的Cassandra, Apache 的HBase,也得到了广泛认同。从这些NoSQL项目的名字上看不出什么相同之处:Hadoop、Voldemort、Dynomite,还有其它很多。 

特点
  它们可以处理超大量的数据。
  它们运行在便宜的PC服务器集群上。
  PC集群扩充起来非常方便并且成本很低,避免了“sharding”操作的复杂性和成本。
  它们击碎了性能瓶颈。
  NoSQL的支持者称,通过NoSQL架构可以省去将Web或Java应用和数据转换成SQL友好格式的时间,执行速度变得更快。
  “SQL并非适用于所有的程序代码,” 对于那些繁重的重复操作的数据,SQL值得花钱。但是当数据库结构非常简单时,SQL可能没有太大用处。
  没有过多的操作。
  虽然NoSQL的支持者也承认关系数据库提供了无可比拟的功能集合,而且在数据完整性上也发挥绝对稳定,他们同时也表示,企业的具体需求可能没有那么多。
  Bootstrap支持。
  因为NoSQL项目都是开源的,因此它们缺乏供应商提供的正式支持。这一点它们与大多数开源项目一样,不得不从社区中寻求支持。

缺点
  但是一些人承认,没有正式的官方支持,万一出了差错会是可怕的,至少很多管理人员是这样看。
  “我们确实需要做一些说服工作,”,“但基本在他们看到我们的第一个原型运行良好之后,我们就能够说服他们,这是条正确的道路。”

 

 

 

*************************参考***************************************

NoSQL的竞争者:MySQL/HandlerSocket和VoltDB
转载地址:
http://news.cnblogs.com/n/80854/


 一般认为NoSQL数据库在性能方面要优于传统的SQL数据库。但是有两个SQL的解决方案宣布:对于大型系统的高可扩展性需求,SQL仍然是可行的解决方案!这两个SQL解决方案分别是MySQL加NoSQL层插件和支持SQL的VoltDB数据库。
  MySQL + HandlerSocket
  Yoshinori Matsunobu是Sun/Oracle的前雇员,从事MySQL的研发工作,目前是DeNA的首席数据库和基础设施架构师,他以插件的方式为MySQL/InnoDB提供解决方案,可以在一台2.53GHZ、8核CPU、32G内存的Nehalem服务器上把每秒的查询数量(qps)提升到750,000以上。在同样的硬件环境下,无插件的MySQL只能提供100,000左右的qps,如果使用memecached的话,可以增加到大约400,000。经过对RDBMS的分析,Matsunobu意识到大部分时间都花在SQL的开销上,比如调用MYSQLparse()、MYSQLlex()、make_join_statistics()和JOIN::optimize()等。他写到:
很显然性能降低的原因主要在SQL层,而不是“InnoDB(存储)”层。MySQL必须做很多事情......但memcached/NoSQL是不需要做这些额外工作的。
  SQL层的功能包括解析SQL语句、打开/锁定/解锁/关闭表、解决并发问题等。Matsunobu的解决方案就是增加额外的NoSQL层:
我们认为最好的方式就是在MySQL内部实现一个NoSQL的网络服务器。也就是说,编写一个网络服务器作为MySQL的插件(守护插件),用来监听特定端口,接收NoSQL的协议和API,然后通过MySQL内部存储引擎API直接访问InnoDB。这种方式很像NDBAPI,不同的是它可以与InnoDB交互。
  他的团队开发了HandlerSocket插件,有了这个插件,MySQL更像一个NoSQL数据库,通过监听一个独立的端口,接收从SQL层来的简单查询请求,例如主键查询,索引扫描和插入/更新/删除。这一变化把数据库性能提升到了750K qps以上。常用端口可以接收处理复杂查询,其核心仍然是SQL数据库。DeNA采用SQL/NoSQL混合的方式取得了成功,据Matsunobu所言,在相同的时间内,这种解决方案把多个memcached和MySQL主从服务器的方案远远甩在了后面。

  VoltDB
  另一个很有希望的SQL解决方案是VoltDB,这是一个内存中的开源OLTP SQL数据库,能够保证事务的完整性(ACID)。VoltDB是由原Ingres和Postgres的架构师Mike Stonebraker设计的。该数据库主要特征如下:
为了获得最大化吞吐量,数据保存在内存中(而不是在硬盘),这样可以有效消除缓冲区管理。 
VoltDB通过SQL引擎把数据分发给集群服务器的每个CPU进行处理。 
每个单线程分区自主执行,消除锁定和闩锁的需求。 
VoltDB可以通过简单的在集群中增加附加节点的方式实现性能的线性增加。 
  正如其开发者宣称的那样,该数据库的性能使其成为NoSQL解决方案的有力竞争者:
VoltDB在单节点上可以每秒处理53000个事务请求(TPS),其他DBMS在相同的硬件环境下只能处理1155个。VoltDB的扩展是近似线性的──在12个节点的VoltDB集群上进行同样测试,可以处理560,000 TPS。 
基准案例:某个客户的在线游戏在12个节点的VoltDB集群上处理了130万 TPS。 
VoltDB还针对NoSQL的键-值存储方式作了基准测试,VoltDB在处理各种键-值存储负载的情况下获得了相同或更好的性能。 
  除了它的性能,VoltDB的主要优势是可以与SQL用户进行交流,这些SQL用户是很好的资源。
  近期还会推出VoltDB的企业版本,包括基于浏览器的数据库管理系统,提供、管理和监控数据库集群。除了免费的社区版本,针对企业版的支持也开始了。
  查看英文原文:MySQL/HandlerSocket and VoltDB: Contenders to NoSQL

     (http://voltdb.com/voltdb-enterprise-edition)
  作者:Abel Avram 
  翻译:池建强  
****************************************************************

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:1310308次
    • 积分:16796
    • 等级:
    • 排名:第615名
    • 原创:372篇
    • 转载:805篇
    • 译文:0篇
    • 评论:96条
    最新评论