NoSQL选型

传统“关系型数据库”在应付互联网WEB2.0应用已显示的力不从心,由其是超大规模和高并发的SNS类型的WEB2.0网站。主要须要应对如下三方面难题:数据库

一、对数据库高并发读写的要求。json

二、对数据库高可扩展性和高可用性的要求。并发

三、对海量数据高效存储和访问的要求。分布式

 

”关系型数据库“固有的特性的确用处不大高并发

一、对数据库事务一致性要求低。不少WEB应用不要求严格的数据库事务,有些对读一致性要求不高,更有些对写一致性也要求不高。性能

二、对数据库写实时性和读实时性要求低。如发送消息给订阅者,能够接受延迟。网站

三、对复杂SQL查询的要求低。如很是忌讳多张大表关联查询。spa

 

为了解决以上问题,”非关系型数据库“(NoSql -- not only SQL)应运而生,再很短的时间内涌现出众多的NoSQL产品。他们各有各的适用场景,你是否对这些特性有所了解?你是否在选型时一片茫然? 本文将解答你的疑惑,帮助你选择正确的NoSQL产品,让你少走些弯路。设计

NoSQL数据库分类:xml

一、key-value存储型--知足极高读写要求。 

二、文档存储型--海量存储和访问的数据库。

三、列存储型--高可扩展性,可用性,面向分布式计算的数据库。

四、图存储型--适合存储关系

类型

部分表明

特色

列存储

Hbase

Cassandra

Hypertable

顾名思义,是按列存储数据的。最大的特色是方便存储结构化和半结构化数据,方便作数据压缩,对针对某一列或者某几列的查询有很是大的IO优点。

文档存储

MongoDB

CouchDB

文档存储通常用相似json的格式存储,存储的内容是文档型的。这样也就有有机会对某些字段创建索引,实现关系数据库的某些功能。

key-value存储

Tokyo Cabinet / Tyrant

Berkeley DB

MemcacheDB

Redis

能够经过key快速查询到其value。通常来讲,存储无论value的格式,照单全收。(Redis包含了其余功能)

图存储

Neo4J

FlockDB

InfoGrid

图形关系的最佳存储。使用传统关系数据库来解决的话性能低下,并且设计使用不方便。

对象存储

db4o

Versant

经过相似面向对象语言的语法操做数据库,经过对象的方式存取数据。

xml数据库

Berkeley DB XML

BaseX

高效的存储XML数据,并支持XML的内部查询语法,好比XQuery,Xpath。

相关文章
相关标签/搜索