选择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提供健壮的索引,但是性能很差,一般和其他缓存结合起来。

3
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使用经验。

tuhaitao
2010-01-09 01:06
我觉现在盛行的这些mem cached技术只是一个过度产品, 如果说硬盘的速度够快,快到能跟内存一样的情况,那么有谁还会使用这些mem cached呢,建议有兴趣的人买块固态硬盘,上边装个mysql,调优后拿出数据,跟现在的mem cache比比,在我的观点来看,sql是种好东西,面向结果的语言,比OO更高一个层次,只是二维表的技术需要改进,数据库肯定会继续发展下去,只是实现不同了.

jametong
2010-05-17 23:49
这就提供了近似内存性能,因为没有磁盘的查询seeks开销, 同时又避免了纯内存操作的durability问题

这段话本身是有点缺陷的..

memTable/SSTable 其实相当于普通的数据库的Log机制(或者日志文件系统的日志). memTable主要解决的还是写性能问题, 读取时还是需要通过BloomFilter来判断是否需要读取特定的SSTable, 而且一个Columnfamily可能会有多份SSTable, 这个读io的延迟可能超过普通的DB访问, 如果一次get Key需要读取多个columnfamily的话, 读延时会进一步增加. 因此基于SSTable/memTable的系统基本上都会着重介绍它们的写性能, 而不会强调其读性能..

当然由于BloomFilter以及Key Cache/Row cache的存在, Cassandra中的大部分读请求都可以以很低读延时返回.

摘录
建议有兴趣的人买块固态硬盘

使用SSD的数据库也是无法达到memCached的处理能力与延时要求的, 两者的基本设计有很大的差别, memCached类似的内存数据库更多是通过hash-Tree的方式来检索/存储数据, 每次都可以直接定位到所需的数据, 而数据库基本是通过类似于B-Tree类型的索引来完成检索, 随着数据量的增长, B-Tree的层级越来越大, 这样底层系统需要支持的物理IO就会越来越多, 哪怕是使用SSD(每个io延时0.2毫秒),数量多了性能也还是会出现很大的Degradation的.

猜你喜欢