NoSQL总结分类

10-03-22 banq
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/

arden
2010-03-23 16:37
我觉得cassandra,terrastore,riak相对于mongodb最大的优势就是多个master，解决了单点写的故障的问题~~

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

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

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




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


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

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


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

相关文章：

HBase vs Cassandra

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

lendo
2010-04-15 14:48
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对此有何看法？

banq
2010-04-15 18:12
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修改过]

uda1341
2010-09-04 22:46
我来务个虚。

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

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

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