NoSQL

NoSQL(转)
转自:http://baike.baidu.com/view/2677528.htm

简介

  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项目都是开源的,因此它们缺乏供应商提供的正式支持。这一点它们与大多数开源项目一样,不得不从社区中寻求支持。

编辑本段缺点

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

History

The term NoSQL was used in 1998 as the name for a lightweight open source relational database that did not expose a SQL interface. Its author, Carlo Strozzi, claims that as the NoSQL movement "departs from the relational model altogether it should therefore have been called more appropriately 'NoREL', or something to that effect."[5]

Eric Evans, a Rackspace employee, reintroduced the term NoSQL in early 2009 when Johan Oskarsson of Last.fm wanted to organize an event to discuss open-source distributed databases.[6] The name attempted to label the emergence of a growing number of non-relational, distributed data stores that often did not attempt to provide ACIDguarantees (the key attributes of classic relational database systems such as IBM DB2, MySQL, Microsoft SQL Server, PostgreSQL, Oracle RDBMS, etc).

The "no:sql(east)" conference 2009 in Atlanta had a strong influence on the NoSQL debate. Its self-conception was "a conference of non-relational data stores", and its motto was "select fun, profit from real_world where relational=false;". Thus, the most common interpretation of "NoSQL" is "non-relational". Another solution is to use the term "NoREL", which is not widely used. Either way, NoSQL is not meant as anti-RDBMS but emphasizes the advantages of Key-Value Stores, Document Databases, and Graph Databases.[citation needed]

[edit]Architecture

Typical modern relational databases have shown poor performance on certain data-intensive applications, including indexing a large number of documents, serving pages on high-traffic websites, and delivering streaming media.[7] Typical RDBMS implementations are tuned either for small but frequent read/write transactions or for large batch transactions with rare write accesses. NoSQL on the other hand, services heavy read/write workloads.[7] Real-world NoSQL deployments include Digg's 3 TB for green badges (markers that indicate stories upvoted by others in a social network),[8] Facebook's 50 TB for inbox search, and eBay's 2 PB overall data.

NoSQL architectures often provide weak consistency guarantees, such as eventual consistency, or transactions restricted to single data items. Some systems, however, provide full ACID guarantees, in some instances by adding a supplementary middleware layer (e.g., CloudTPS).[9] Two systems have been developed that provide snapshot isolation for column stores: Google's Percolator system based on BigTable[10], and a transactional system for HBase developed at the University of Waterloo[11]. These systems, developed independently, use similar concepts to achieve multi-row distributed ACID transactions with snapshot isolation guarantee for the underlying column store, without the extra overhead of data management, middleware system deployment, or maintenance introduced by the middleware layer.

Several NoSQL systems employ a distributed architecture, with the data held in a redundant manner on several servers, often using a distributed hash table. In this way, the system can readily scale out by adding more servers, and failure of a server can be tolerated.[12]

Some NoSQL advocates[who?] promote very simple interfaces such as associative arrays or key-value pairs. Other systems, such as native XML databases, promote support of the XQuery standard.[citation needed] <>

[edit]Taxonomy

NoSQL implementations can be categorized by their manner of implementation:

[edit]Document store

  • Apache Jackrabbit
  • Apache CouchDB
  • Lotus Notes
  • MongoDB
  • XML database
    • MarkLogic Server
    • eXist
  • SimpleDB
  • Terrastore

[edit]Graph

  • AllegroGraph
  • Core Data
  • Neo4j
  • DEX
  • FlockDB

[edit]Key/value store on disk

  • BigTable
  • CDB
  • Citrusleaf database
  • membase
  • Memcachedb
  • Redis
  • Tokyo Cabinet
  • Tuple space
  • Keyspace
  • TreapDB

[edit]Key/value cache in RAM

  • memcached
  • Citrusleaf database
  • Velocity
  • Redis
  • Tuple space

[edit]Eventually‐consistent key‐value store

  • Cassandra
  • Dynamo
  • Hibari
  • Project Voldemort
  • Riak [13]

[edit]Key-value stores implementing the Paxos algorithm

  • Keyspace

[edit]Hierarchical key-value store

  • GT.M

[edit]Ordered key-value store

  • NMDB
  • Memcachedb
  • Berkeley DB
  • IBM Informix C-ISAM

[edit]Multivalue databases

  • OpenQM
  • Rocket U2
  • Revelation Software's OpenInsight

[edit]Object database

  • Db4o
  • GemStone/S
  • InterSystems Caché
  • JADE
  • Objectivity/DB
  • ZODB
  • ObjectStore

[edit]Tabular

  • BigTable
  • Mnesia
  • Hbase
  • Hypertable

[edit]Tuple store

  • Apache River

[edit]See also

  • Structured storage
  • List of object database management systems
  • Triplestore
  • CAP theorem
  • Faceted search

你可能感兴趣的:(NoSQL)