nosql 分类

类型

部分代表

特点

列存储

Hbase

Cassandra

Hypertable

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

文档存储

MongoDB

CouchDB

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

key-value存储

Tokyo Cabinet / Tyrant

Berkeley DB

MemcacheDB

Redis

Riak

可以通过key快速查询到其value。一般来说,存储不管value的格式,照单全收。(Redis包含了其他功能)

图存储

Neo4J

FlockDB

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

对象存储

db4o

Versant

通过类似面向对象语言的语法操作数据库,通过对象的方式存取数据。

xml数据库

Berkeley DB XML

BaseX

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

板桥的分类:http://www.jdon.com/jivejdon/thread/38312

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/

通过CouchDB看文档型数据库含义特点:

http://www.ibm.com/developerworks/cn/opensource/os-couchdb/

在面向文档的数据库中,每个名片都储存在各自的文档中,并且每个文档都可以定义它需要使用的字段。因此,对于没有传真号码的人而言,就不需要定义传真的值,而对于有传真号码的人,则根据他们的意愿定义该值。

这两种数据库的另一个不同点是惟一标识符的储存。在关系数据库中通常可以使用主键,它由一个自动递增特性或序列生成器生成。当然,这些标识符仅相对于所使用的表或数据库是惟一的 — 其他表或数据库还可以使用它们。如果同时对不同网络上的两个数据库执行更新操作,这两个数据库不会同时准确地获取下一个惟一标识符。CouchDB 没有自动递增或序列特性。相反,它为每个文档分配一个通用惟一标识符(Universally Unique Identifier,UUID),这就杜绝了其他数据库意外地选择相同的惟一标识符的情况。

Total views.

© 2013 - 2018. All rights reserved.

Powered by Hydejack v6.6.1