NoSQL总结分类

NoSQL数据库异军突起,随着Digg和 sf.net大型应用不断采取NoSQL,NoSQL运动已经蓬勃发展,NoSQL数据库很多,如何对他们分类,以便方便地根据自己应用特色选择不同的NoSQL数据库呢?

NoSQL = HVSP 无(传统关系数据库的)join或明显事务的高容量简单处理。

按照数据模型保存性质将当前NoSQL分为四种:
1.Key-value stores键值存储, 保存keys+BLOBs (二进制大对象Binary Large OBjects)
2.Table-oriented 面向表, 主要有Google的BigTable和Cassandra.
3.Document-oriented面向文本, 文本是一种类似XML文档,MongoDB 和 CouchDB
4.Graph-oriented 面向图论. 如Neo4J.

NoSQL一般都是分布式数据库,高性能是其特点,因此,数据是如何被分布、复制/碎片以及合成就成为关键,这其中涉及你的应用对数据一致性的要求,见CAP原理,不同一致性处理方式决定不同类型:
1.基本上基于Dynamo. 核心思想就是在多个节点之间获得最终一致性就可以,即使你有时会读到脏数据. 好处是写数据时从来不会阻塞。那种强制性节点一致性,如2PC,两段事务提交将会让你的写关闭停顿,使用Dynamo-like风格你能将数据写到多个节点中,通过一致hashing,然后你可以从这些节点读取数据,返回正确结果给用户。

2.基本基于BigTable. 这种模型中,使用常用方式保持节点充分的一致性。比如同步复制,由数据自己活或数据所在位置来实现一致性,不同产品实现细节不一样。

比如:MongoDB有一个面向文本类型的数据模型, 它采取类似BigTable-like 复制策略;Cassandra有面向表table-like数据模型, 采取的是Dynamo-like风格.

以后应该有数据是如何被持久化保存到磁盘上的区分,不同NoSQL处理策略不一样,有的是写一次保存一次;有的是定期保存,后者性能要好些。

当然,也有按照列记录来划分的,见http://nosql-database.org/

我觉得cassandra,terrastore,riak相对于mongodb最大的优势就是多个master,解决了单点写的故障的问题~~

2010年03月23日 16:37 "arden"的内容
mongodb最大的优势就是多个master,解决了单点写的故障的问题 ...

mongodb是类似大表性质,这种性质使用同步复制技术来实现,一般是Master-slaver架构,这种主从结构也可以解决单点写故障问题。

下图是Tokyo Cabinet 和Tyrant 的M/S结构原理:


[该贴被banq于2010-03-24 12:04修改过]


像hbase,casandra,bigtable这一类的都是面向列存储的,面向列存储的优点就是适合于数据结构松散的,事务要求不严格的,读写要求严格的地方,也适合olap,而传统的RDBMS是基于行存储,行存储的优势就是事务和一致性保证,适合OLTP。目前互联网应用,大多数应该都是符合列存储需求的。当然了如果像friendfeed那样,用mysql来搞个key-value也可以,但是代价高,要分库,分表,sharding,映射等等。还不如用个能支持高并发读写的存储产品来的方便。

2010年03月24日 23:05 "xmuzyu"的内容
像hbase,casandra,bigtable这一类的都是面向列存储的,..而传统的RDBMS是基于行存储 ...

呵呵,你这是在陈述NoSQL和SQL的区别,在NoSQL内部也存在分类方式,一个是Dynamo风格和BigTable风格。

相关文章:
HBase vs Cassandra

[该贴被banq于2010-04-06 14:09修改过]

2010年03月22日 15:46 "banq"的内容
按照数据模型保存性质将当前NoSQL分为四种 ...

我用MongoDB做了一个实验,存储1000000条包含6个字符串字段的对象,用时30秒,确实是采用传统DB+ORM没办法比的,那这数据应该如何存储呢?比如MongoDB,它是基于DBCollection来存储数据,一个数据库可以有很多的Collection,那我在Collection的基础上做报表,那么MongoDB如何满足我的需求的,比如User,Address,Phone这种类似的关系,一个User对应N个Address,一个Address对应N个Phone,我是应该把User,Address,Phone存储到一个Collection,还是分别存在三个Collection中,然后通过MongoDB提供的查询语法来查找或者通过Java程序来构建。针对以上所说的四种不同的数据存储策略,是不是又会影响到领域模型的划分呢?目前的NoSql数据库概念,究竟应该是称作No-Sql还是No-Relation?不知道Banq对此有何看法?

2010年04月15日 14:48 "lendo"的内容
针对以上所说的四种不同的数据存储策略,是不是又会影响到领域模型的划分呢?目前的NoSQL数据库概念,究竟应该是称作No-Sql还是No-Relation?不知道Banq对此有何看法? ...

NOSQL只是数据储存方案,属于对象(领域模型)持久化方案的一种,两个层次不一样,就象人和人睡觉这两个概念完全不一样。

Relation关系主要特征是SQL,NOSQL就是No Relation,或者Not Only Relation.

相关讨论:
从CAP看No SQL分类

[该贴被banq于2010-05-12 11:17修改过]

我来务个虚。

至少我能看到这样的可能性,在编程时将数据虚化,程序员只考虑语法,也就是,数据将以何种语法写入容器,和,同样的数据将以何种语法读出容器,数据将以什么语法被删除。

至于后台是用数组,链表,还是轻量级或重量级的关系数据库实现,或者使用key-value方式实现,是编译后台完成的,编译后台具有这样的能力,当语法被约束为SQL时,数据库将被编译为关系数据库,特别的,如果附加额外的约束,例如,某语法要求最高效率,那么这个关系数据库就被特化了。

也许现在离这样的目标还是太远,但至少我看到学术界有类似方向的研究。