NOSQL选择与比较

关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生，现在这两年，各种各样非关系数据库，特别是键值数据库(Key-Value Store DB)风起云涌，多得让人眼花缭乱。大约有10多个开源的NosqlDB，例如：
Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，HBase，CouchDB，Flare， memcachdb

@H_403_93@Redis

@H_403_93@Redis 是一个很新的项目，刚刚发布了 @H_403_93@2.4.8 版本。 @H_403_93@Redis 本质上是一个 @H_403_93@Key-Value 类型的内存数据库，很像 @H_403_93@memcached ，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据 @H_403_93@flush 到硬盘上进行保存。因为是纯内存操作， @H_403_93@Redis 的性能非常出色，每秒可以处理超过 @H_403_93@10 万次读写操作，是我知道的性能最快的 @H_403_93@Key-Value DB 。

Redis的出色之处不仅仅是性能，@H_403_93@Redis最大的魅力是支持保存@H_403_93@List链表和@H_403_93@Set集合的数据结构，而且还支持对@H_403_93@List进行各种操作，例如从 List两端@H_403_93@push和@H_403_93@pop数据，取@H_403_93@List区间，排序等等，对@H_403_93@Set支持各种集合的并集交集操作，此外单个@H_403_93@value的最大限制是@H_403_93@1GB。@H_403_93@Redis可以用来实现很多有用的功能，比方说用他的@H_403_93@List来做@H_403_93@FIFO双向链表，实现一个轻量级的高性能消息队列服务，用他的@H_403_93@Set可以做高性能的@H_403_93@tag系统等等。另外@H_403_93@Redis也可以对存入的@H_403_93@Key-Value设置@H_403_93@expire时间，因此也可以被当作一个功能加强版的@H_403_93@memcached来用。

@H_403_93@MemCached

@H_403_93@ Memcached 是 @H_403_93@danga.com （运营 @H_403_93@LiveJournal 的技术团队）开发的一套分布式内存对象缓存系统，用于在动态系统中减少数据库负载，提升性能。
特点

协议简单

基于 @H_403_93@libevent 的事件处理

内置内存存储方式

@H_403_93@memcached 不互相通信的分布式

@H_403_93@3、@H_403_93@MemCacheDB

它是新浪互动社区事业部为在 @H_403_93@Memcached 基础上，增加 @H_403_93@Berkeley DB 存储层而开发一款支持高并发的分布式持久存储系统，对任何原有 @H_403_93@Memcached 客户端来讲，它仍旧是个 @H_403_93@Memcached ，但是，它的数据是可以持久存储的。

其中 @H_403_93@Berkeley DB百度百科后：

@H_403_93@Berkeley DB是一个开源的文件数据库，介于关系数据库与内存数据库之间，使用方式与内存数据库类似，它提供的是一系列直接访问数据库的函数，而不是像关系数据库那样需要网络通讯、sql解析等步骤

@H_403_93@

@H_403_93@@H_403_93@5、 @H_403_93@Cassandra

Cassandra 项目是 @H_403_93@Facebook 在 @H_403_93@2008 年开源出来的，随后 @H_403_93@Facebook 自己使用 @H_403_93@Cassandra 的另外一个不开源的分支。目前除了 Facebook 之外， @H_403_93@twitter 和 @H_403_93@digg.com 都在使用 @H_403_93@Cassandra 。 Cassandra 的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对 @H_403_93@Cassandra 的一个写操作，会被复制到其他节点上去，对 @H_403_93@Cassandra 的读操作，也会被路由到某个节点上面去读取。对于一个 @H_403_93@Cassandra 群集来说，扩展性能是比较简单的事情，只管在群集里面添加节点就可以了 @H_403_93@.

Cassandra 也支持比较丰富的数据结构和功能强大的查询语言，和 @H_403_93@MongoDB 比较类似，查询功能比 @H_403_93@MongoDB 稍弱一些。 @H_403_93@Cassandra 以单个节点来衡量，其节点的并发读写性能不是特别好， @H_403_93@Cassandra 每秒大约不到 @H_403_93@1 万次读写请求。

@H_403_93@7 、 @H_403_93@MongoDB

@H_403_93@ MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似 json 的 @H_403_93@bson 格式，因此可以存储比较复杂的数据类型。 @H_403_93@Mongo 最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。

@H_403_93@ @H_403_93@Mongo 主要解决的是海量数据的访问效率问题，根据官方的文档，当数据量达到 @H_403_93@50GB 以上的时候， @H_403_93@Mongo 的数据库访问速度是 @H_403_93@MysqL 的 @H_403_93@10 倍以上。 @H_403_93@Mongo 的并发读写效率不是特别出色，根据官方提供的性能测试表明，大约每秒可以处理 @H_403_93@0.5 万－ @H_403_93@1.5 次读写请求。由于 @H_403_93@Mongo 可以支持复杂的数据结构，而且带有强大的数据查询功能，因此非常受到欢迎，很多项目都考虑用 @H_403_93@MongoDB 来替代 @H_403_93@MysqL 来实现不是特别复杂的 @H_403_93@Web 应用。

MongoDB vs Cassandra简单比较：

@H_403_93@1.数据结构

@H_403_93@ MongoDB使用文档型存储，其数据结构为与@H_403_93@JSON类似的@H_403_93@BSON结构，而@H_403_93@Cassandra支持的是@H_403_93@key－@H_403_93@value式存储，而每个@H_403_93@key－@H_403_93@value还会保存一个时间戳，这个时间戳实际上起到了版本控制的作用。

@H_403_93@2.索引结构

@H_403_93@MongoDB的索引几乎与关系型数据库完全一样，其普通索引、联合索引、唯一索引的意义和实现上都可以参考对@H_403_93@MysqL索引的理解。而 Cassandra由于其是一个@H_403_93@key－@H_403_93@value结构的存储，如果你要对@H_403_93@value进行条件查找，那么就必须建立反向索引，重新建立一个 value－@H_403_93@key的键值对。

@H_403_93@3. 部署

@H_403_93@ MongoDB 提供了 @H_403_93@Replica Sets 的高可用部署方式，配置好 @H_403_93@RS 的节点后，整个集群会自动选举出 @H_403_93@Primary 机器供写入操作，并自动复制数据到其它节点。它还具有故障后自动选举新的主机的机制。而 @H_403_93@Cassandra 提供的策略更为灵活，它通过一种对网络结构可感知的机制，它让你可以配置数据是备份在本地网络中的其它节点还是备份到远端的数据中心。

新华网目前用于满足海量存储需求和访问的 @H_403_93@Nosql 数据库是 @H_403_93@mongoDB 。由于现在新华网的应用很多是为了满足高并发的需求，满足极高读写性能需求。满足这样需求的产品必须具有分布式缓存的功能。因而根据需求选择了的 @H_403_93@Key-Value 数据库 @H_403_93@:Redis ， @H_403_93@Tokyo Cabinet ， @H_403_93@memcached,memcachdb 进行比较。

NOSQL选择与比较

猜你在找的NoSQL相关文章