Gepiu的博客

有点想法很好,有点行动更好

树欲动...


NoSQL数据库选择

HBaseRedisMongoDBCouchbaseLevelDB 五款较主流的NoSql数据库产品,比较其适用场景以及开发语言因素:最终我们的新项目选择了HBase


HBase

HBase 是 Apache Hadoop 中的一个子项目,属于 bigtable 的开源版本,所实现的语言为Java(故依赖 Java SDK)。HBase 依托于 Hadoop 的 HDFS(分布式文件系统)作为最基本存储基础单元。
HBase在列上实现了 BigTable 论文提到的压缩算法、内存操作和布隆过滤器。HBase的表能够作为 MapReduce 任务的输入和输出,可以通过Java API来访问数据,也可以通过REST、Avro或者Thrift的API来访问。

优势
  1. 存储容量大,一个表可以容纳上亿行,上百万列;
  2. 可通过版本进行检索,能搜到所需的历史版本数据;
  3. 负载高时,可通过简单的添加机器来实现水平切分扩展,跟Hadoop的无缝集成保障了其数据可靠性(HDFS)和海量数据分析的高性能(MapReduce);
  4. 在第3点的基础上可有效避免单点故障的发生。
  5. 基于Java语言实现及Hadoop架构意味着其API更适用于Java项目;
缺点
  1. 占用内存很大,且鉴于建立在为批量分析而优化的HDFS上,导致读取性能不是最高;
适用场景
  1. bigtable类型的数据存储;
  2. 对数据有版本查询需求;
  3. 应对超大数据量要求扩展简单的需求。

Redis

Redis 是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的API。目前由VMware主持开发工作。

优势

1. 非常丰富的数据结构;
2. Redis提供了事务的功能,可以保证一串 命令的原子性,中间不会被任何操作打断;
3. 数据存在内存中,读写非常的高速,可以达到10w/s的频率。

缺点
  1. Redis3.0后才出来官方的集群方案,但仍存在一些架构上的问题;
  2. 持久化功能体验不佳——通过快照方法实现的话,需要每隔一段时间将整个数据库的数据写到磁盘上,代价非常高;而aof方法只追踪变化的数据,类似于mysql的binlog方法,但追加log可能过大,同时所有操作均要重新执行一遍,恢复速度慢;
    3. 由于是内存数据库,所以,单台机器,存储的数据量,跟机器本身的内存大小。虽然redis本身有key过期策略,但是还是需要提前预估和节约内存。如果内存增长过快,需要定期删除数据。
适用场景

适用于数据变化快且数据库大小可遇见(适合内存容量)的应用程序。


MongoDB

MongoDB 是一个高性能,开源,无模式的文档型数据库,开发语言是C++。它在许多场景下可用于替代传统的关系型数据库或键/值存储方式。

优势
  1. 强大的自动化 sharding 功能;
  2. 全索引支持,查询非常高效;
    3. 面向文档(BSON)存储,数据模式简单而强大。
  3. 支持动态查询,查询指令也使用JSON形式的标记,可轻易查询文档中内嵌的对象及数组。
    5. 支持 javascript 表达式查询,可在服务器端执行任意的 javascript函数。
缺点

1. 单个文档大小限制为16M,32位系统上,不支持大于2.5G的数据;
2. 对内存要求比较大,至少要保证热数据(索引,数据及系统其它开销)都能装进内存;
3. 非事务机制,无法保证事件的原子性。

适用场景
  1. 适用于实时的插入、更新与查询的需求,并具备应用程序实时数据存储所需的复制及高度伸缩性;
  2. 非常适合文档化格式的存储及查询;
    3. 高伸缩性的场景:MongoDB 非常适合由数十或者数百台服务器组成的数据库。
    4. 对性能的关注超过对功能的要求。

Couchbase 

CouchDB 和 Membase 合并了。合并之后的公司基于 Membase 与 CouchDB 开发了一款新产品,新产品的名字叫做 Couchbase。
Couchbase 可以说是集合众家之长,目前应该是最先进的Cache系统,其开发语言是 C/C++。
Couchbase Server 是个面向文档的数据库(其所用的技术来自于Apache CouchDB项目),能够实现水平伸缩,并且对于数据的读写来说都能提供低延迟的访问(这要归功于Membase技术)。

优势

1. 高并发性,高灵活性,高拓展性,容错性好;
2. 以 vBucket 的概念实现更理想化的自动分片以及动态扩容;

缺点

1. Couchbase 的存储方式为 Key/Value,但 Value 的类型很为单一,不支持数组。另外也不会自动创建doc id,需要为每一文档指定一个用于存储的 Document Indentifer;
2. 各种组件拼接而成,都是c++实现,导致复杂度过高,遇到奇怪的性能问题排查比较困难,中文文档比较欠缺;
3. 采用缓存全部key的策略,需要大量内存。节点宕机时 failover 过程有不可用时间,并且有部分数据丢失的可能,在高负载系统上有假死现象;
4. 逐渐倾向于闭源,社区版本(免费,但不提供官方维护升级)和商业版本之间差距比较大。

适用场景
  1. 适合对读写速度要求较高,但服务器负荷和内存花销可遇见的需求;
  2. 需要支持 memcached 协议的需求。

LevelDB 

LevelDB 是由谷歌重量级工程师(Jeff Dean 和 Sanjay Ghemawat)开发的开源项目,它是能处理十亿级别规模 key-value 型数据持久性存储的程序库,开发语言是C++。
除了持久性存储,LevelDB 还有一个特点是 —— 写性能远高于读性能(当然读性能也不差)。

优势
  1. 操作接口简单,基本操作包括写记录,读记录和删除记录,也支持针对多条操作的原子批量操作;
  2. 写入性能远强于读取性能,
  3. 数据量增大后,读写性能下降趋平缓。
缺点
  1. 随机读性能一般;
    2. 对分布式事务的支持还不成熟。而且机器资源浪费率高。
适应场景

适用于对写入需求远大于读取需求的场景(大部分场景其实都是这样)。