选择NoSQL的几种理由

09-11-10 banq
              

来自NoSQL Ecosystem选择NoSQL的几种种理由:

1.Scalability

有两种理由寻求一种分布式数据库:

1)支持多个数据中心

2)可以透明在线为你的应用增加新服务器。

下面是NoSQL数据库支持这两点列表:

非分布式的NoSQL数据库包括有 CouchDB, MongoDB, Neo4j, Redis, and Tokyo Cabinet. 当然他们可以为分布式的持久层架构服务,MongoDB 提供有限的划分碎片sharding支持, 正如 CouchDB分离的Lounge项目一样, Tokyo Cabinet能用于作为Voldemort存储引擎.

2.Data and Query Model

NoSQL 支持各种数据类型数据模型,图片 视频 等等

当你需要查询或更新一个值的一部分时,Key/value模型是最简单有效实现。

面向文本数据库是Key/value的下一步, 允许内嵌和Key关联的值. 支持查询这些值数据,这比简单的每次返回整个blob类型数据要有效得多。

Neo4J是唯一的存储对象和关系作为数学图论中的节点和边. 对于这些类型数据的查询,他们能够比其他竞争者快1000s

Scalaris是唯一提供跨越多个key的分布式事务。

3.Persistence Design(内部数据是如何保存的?)

内存数据库是非常快的,(Redis在单个机器上可以完成每秒100,000以上操作)但是数据集超过内存RAM大小就不行. 而且 Durability (服务器当机恢复数据)也是一个问题

Memtables和SSTables缓冲 buffer是在内存中写(“memtable”), 写之前先追加一个用于durability的日志中.

但有足够多写入以后,这个memtable将被排序然后一次性作为“sstable.”写入磁盘中,这就提供了近似内存性能,因为没有磁盘的查询seeks开销, 同时又避免了纯内存操作的durability问题.(个人点评 其实Java中的Terracotta早就实现这两者结合)

B-Trees提供健壮的索引,但是性能很差,一般和其他缓存结合起来。

              

2
bloodrate
2009-11-13 15:18

我搞不懂Key-Value怎么存储企业应用那种复杂的多维数据关系,难道某一个key对象的value又是一组key-value对应的集合?

banq
2009-11-13 15:42

2009年11月13日 15:18 "bloodrate"的内容
我搞不懂Key-Value怎么存储企业应用那种复杂的多维数据关系,难道某一个key对象的value又是一组key-value对应的集合?

复杂的多维数据关系可以使用对象关系来替代,数据关系也涉及到一致性问题,如果你对数据之间关系一致性没有那么高要求,根据CAP原理,你就可以使用Key-Value了,但是如果你又想高度一致的关系,又想高性能,又具有可靠性,根据CAP定理是不可能的。

企业应用可以采取Not Only SQL架构,见我在"CAP原理和BASE思想"中的领域模型 + 分布式缓存 + 存储 + JMS异步的BASE解决方案图:

CAP原理和BASE思想

[该贴被admin于2009-11-14 08:20修改过]

itian
2009-12-08 17:42

最近一个新项目打算NoSQL,数据不会到达海量,但是数据量要到达千万级别,平均Socket连接达到十万级别,目前打算用纯Java + MongoDB,不知道banq老师怎么看?对于MongoDB,或者其它的KVS,期待您更多NoSQL讨论,介绍。

banq
2009-12-08 18:04

我也只是在研究学习,共同切磋,MongoDB比CouchDB更适合高实时性,依据CAP定律,它重可用性要高于一致性。

推荐:最近有一篇NOSQL Patterns总结得不错,将NoSQL上升到模式,进行总结。(翻墙才能看)

别忘记分享你的MongoDB使用经验。

2Go 1 2 下一页