主流的Nosql数据库的对比

主流的Nosql数据库的对比

 

 MongoDB，Cassandra，CouchDB，Hypertable， Redis，Riak，Neo4j，Hadoop HBase，

Couchbase，MemcacheDB

 

1. Hadoop HBase

 

Hbase的优势及应用场景：

 

1. 半结构化或非结构化数据: 

对于数据结构字段不够肯定或杂乱无章很是难按一个概念去进行抽取的数据适合用HBase，由于HBase支持动态添加列。

1. 记录很稀疏： 

RDBMS的行有多少列是固定的。为null的列浪费了存储空间。HBase为null的Column不会被存储，这样既节省了空间又提升了读性能。

3. 多版本号数据： 

依据Row key和Column key定位到的Value可以有随意数量的版本号值，所以对于需要存储变更历史记录的数据，用HBase是很方便的。比方某个用户的Address变动，用户的Address变动记录也许也是具备研究意义的。

4. 仅要求最终一致性： 

对于数据存储事务的要求不像金融行业和财务系统这么高，只要保证最终一致性就行。（好比HBase+elasticsearch时，可能出现数据不一致）

5. 高可用和海量数据以及很大的瞬间写入量： 

WAL解决高可用，支持PB级数据，put性能高

适用于插入比查询操做更频繁的状况。好比，对于历史记录表和日志文件。（HBase的写操做更加高效）

业务场景简单： 

不须要太多的关系型数据库特性，列入交叉列，交叉表，事务，链接等。

 

Hbase的缺点：

1. 单一RowKey固有的局限性决定了它不可能有效地支持多条件查询
2. 不适合于大范围扫描查询
3. 不直接支持 SQL 的语句查询
4. java语言实现及Hadoop架构意味着其API更适用于Java项目
5. 占用内存很大，且鉴于创建在为批量分析而优化的HDFS上，致使读取性能不高；API相比其它 NoSql 的相对笨拙。

 

可是Hadoop/HBase集群的维护经常须要不少专业人员而且须要构建一个比较大的集群才能最大化体现出威力，所以用户主要是Facebook, yahoo, 百度和阿里巴巴等大公司。因此咱们用它来开发系统是一件

 

 

最佳应用场景：适用于偏好BigTable:)而且须要对大数据进行随机、实时访问的场合。

例如： Facebook消息数据库（更多通用的用例即将出现）

 

1. MongoDB 数据库

 

MongoDB是一个新的和广泛使用的数据库。 它是一个基于文档的非关系数据库提供程序。

MongoDB是个面向文档的数据库，使用JSON风格的数据格式。它很是适合于网站的数据存储、内容管理与缓存应用，而且经过配置能够实现复制与高可用性功能。

MongoDB具备很强的可伸缩性，性能表现优异。它使用C++编写，基于文档存储。此外，

MongoDB还支持全文检索、跨WAN与LAN的高可用性、易于实现的复制、水平扩展、基于文档的丰富查询、在数据处理与聚合等方面具备很强的灵活性。

MongoDB社区很是活跃，不少开发框架都迅速提供了对MongDB的支持。

 

优势：

1. MongoDB 的架构较少。它是一个文档数据库，它的一个集合持有不一样的文档。
2. 从一个到另外一个的文档的数量，内容和大小可能有差别。支持多种文档！
3. MongoDB 中单个对象的结构很清淅。
4. MongoDB 中没有复杂的链接。
5. MongoDB 提供深度查询的功能，由于它支持对文档的强大的动态查询。
6. MongoDB 很容易扩展。
7. 它使用内部存储器来存储工做集，这是其快速访问的缘由。
8. MongoDB更加灵活，由于能够在文档中直接插入数组之类的复杂数据类型，而且文档的key和value不是固定的数据类型和大小，因此开发者在使用MongoDB时无须预约义关系型数据库中的”表”等数据库对象，设计数据库将变得很是方便，能够大大地提高开发进度。
9. 适用于须要动态查询支持；须要使用索引而不是 map/reduce功能；须要对大数据库有性能要求；须要使用 CouchDB但由于数据改变太频繁而占满内存的应用程序。

 

缺点：

mongodb不支持事务操做。
1.  因此事务要求严格的系统（若是银行系统）确定不能用它

2.③MongoDB没有如MySQL那样成熟的维护工具，这对于开发和IT运营都是个值得注意的地方。

3. mongo 命令行 shell 使用 linenoise 而不是 readline，中文支持问题严重

 

 

 

 

 

 

 

 

 

 

 

 

 

3.  Redis

这是个开源、高级的键值存储。因为在键中使用了hash、set、string、sorted set及list，所以Redis也称做数据结构服务器。这个系统能够帮助你执行原子操做，好比说增长hash中的值、集合的交集运算、字符串拼接、差集与并集等。Redis经过内存中的数据集实现了高性能。此外，该数据库还兼容于大多数编程语言。

 

  redis是一个key-value存储系统，数据存储在内存中，它的优势主要以下：

 1. 支持多种数据类型

    包括set,zset,list,hash,string这五种数据类型，操做很是方便。好比，若是你在作好友系统，查看本身的好友关系，若是采用其余的key-value系统，则必须把对应的好友拼接成字符串，而后在提取好友时，再把value进行解析，而redis则相对简单，直接支持list的存储(采用双向链表或者压缩链表的存储方式)。

  2. 持久化存储

    做为一个内存数据库，最担忧的，就是万一机器死机，数据会消失掉。redi使用rdb和aof作数据的持久化存储。主从数据同时，生成rdb文件，并利用缓冲区添加新的数据更新操做作对应的同步。

  3. 丰富的特性

    pub/sub，key过时策略，事务，支持多个DB等

   4. 性能很好

因为是全内存操做，因此读写性能很好，能够达到10w/s的频率。公司有项目使用redis，目前的访问频率是80w/s，经过适当的部署，线上运行一切ok。

 

redis的缺点主要以下：

  1. 因为是内存数据库，因此，单台机器，存储的数据量，跟机器自己的内存大小有关。虽然redis自己有key过时策略，可是仍是须要提早预估和节约内存。若是内存增加过快，须要按期删除数据。

  2. 若是进行完整重同步，因为须要生成rdb文件，并进行传输，会占用主机的CPU，并会消耗现网的带宽。不过redis2.8版本，已经有部分重同步的功能，可是仍是有可能有完整重同步的。好比，新上线的备机。

1. 修改配置文件，进行重启，将硬盘中的数据加载进内存，时间比较久。在这个过程当中，redis不能提供服务。

总结来讲，主要优势有

（1）很是丰富的数据结构，且这些数据结构的常见操做均是原子性的；
（2） 高速读写。Memcached提供了CAS命令，能够保证多个并发访问操做同一份数据的一致性问题。 Redis没有提供CAS命令，不过Redis提供了事务的功能，能够保证一串 命令的原子性，中间不会被任何操做打断。MYSQL使用了锁，而memcache未使用锁，进而效率极高。总之，Redis用本身实现的事件分离器，代码量很短，没有CAS，没有lock，于是效率很是高。

缺点：

1 Redis不具有自动容错和恢复功能，主机从机的宕机都会致使前端部分读写请求失败，须要等待机器重启或者手动切换前端的IP才能恢复。

2 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，下降了系统的可用性。

3 Redis的主从复制采用全量复制，复制过程当中主机会fork出一个子进程对内存作一份快照，并将子进程的内存快照保存为文件发送给从机，这一过程须要确保主机有足够多的空余内存。若快照文件较大，对集群的服务能力会产生较大的影响，并且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行，也就是网络波动都会形成主机和从机间的一次全量的数据复制，这对实际的系统运营形成了不小的麻烦。

4 Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源形成了很大的浪费。

总结来讲：主要缺点有

（1）持久化。 Redis直接将数据存储到内存中，可经过两种方式持久化：定时快照（snapshot）和基于语句的追加（AppendOnlyFile，aof）。Snapshot的方法是指每隔一段时间将整个数据库的数据写到磁盘上，很明显，每次均是写所有数据，代价很是高；而aof方法只追踪变化的数据，这相似于mysql的binlog方法，但追加log可能过大，同时全部操做均要从新执行一遍，恢复速度慢。
（2）耗内存。尽管Redis对一些数据结构采用了压缩算法存储，但占用内存量仍是太高。

 

适用场景：适用于数据变化快且数据库大小可碰见（适合内存容量）的应用程序。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1. 4.    Cassandra

这是个Apache软件基金会的项目，Cassandra是个分布式数据库，支持分散的数据存储，能够实现容错以及无单点故障等。换句话说，“Cassandra很是适合于那些没法忍受数据丢失的应用”。

优势：

Cassandra的主要特色就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra 的一个写操做，会被复制到其余节点上去，对Cassandra的读操做，也会被路由到某个节点上面去读取。

模式灵活 
使用Cassandra，像文档存储，你没必要提早解决记录中的字段。你能够在系统运行时随意的添加或移除字段。这是一个惊人的效率提高，特别是在大型部署上。
真正的可扩展性 
Cassandra是纯粹意义上的水平扩展。为给集群添加更多容量，能够指向另外一台电脑。你没必要重启任何进程，改变应用查询，或手动迁移任何数据。
多数据中心识别 
你能够调整你的节点布局来避免某一个数据中心起火，一个备用的数据中心将至少有每条记录的彻底复制。

缺点：

Cassandra的设计初衷就不是存储大文件

Twitter为何要停用Cassandra

1. Cassandra仍然缺乏大并发海量数据访问的案例及经验，Cassandra来源自Facebook，可是在Facebook内部Cassandra目前只用在inbox search产品上，容量大约有100-200T。且Inbox Search在Facebook的基础架构中也并不是核心应用。而且还传出很多rumors说facebook已经放弃Cassandra。

2. 新产品须要必定稳按期，Cassandra代码或许还存在很多问题，可是Twitter若是投入大量的精力来改进Cassandra和比较优化MySQL的投入来看有点得不偿失。在QCon Beijing上@nk也提到Cassandra在Twitter的内部测试中曾经暴露出很多严重的问题。

缺点的讨论：

一、它未采用hdfs文件系统，因此存在与Hadoop难以协同的问题。数据源在cassandra存储体系中，不利于mapreduce分析。

二、该开源体系尚不成熟，代码稳定性存在不肯定性，前后被一些大型互联网公司采用又弃用。

三、其快速查询的功能有hbase这样的列存式数据库这样的替代品。

最佳应用场景：当使用写操做多过读操做（记录日志）若是每一个系统组建都必须用 Java编写（没有人由于选用 Apache的软件被解雇）

例如：银行业，金融业（虽然对于金融交易不是必须的，但这些产业对数据库的要求会比它们更大）写比读更快，因此一个天然的特性就是实时数据分析

 

5. Hypertable

Hypertable模仿的是Google的BigTable数据库系统。Hypertable的建立者将“成为高可用、PB规模的数据库开源标准”做为Hypertable的目标。换言之，Hypertable的设计目标是跨越多个廉价的服务器可靠地存储大量数据。

Hypertable是一个开源、高性能、可伸缩的数据库，它采用与Google的Bigtable类似的模型。在过去数年中，Google为在 PC集群 上运行的可伸缩计算基础设施设计建造了三个关键部分。第一个关键的基础设施是Google File System（GFS），这是一个高可用的文件系统，提供了一个全局的命名空间。它经过跨机器（和跨机架）的文件数据复制来达到高可用性，并所以免受传统 文件存储系统没法避免的许多失败的影响，好比电源、内存和网络端口等失败。第二个基础设施是名为Map-Reduce的计算框架，它与GFS紧密协做，帮 助处理收集到的海量数据。第三个基础设施是Bigtable，它是传统数据库的替代。Bigtable让你能够经过一些主键来组织海量数据，并实现高效的 查询。Hypertable是Bigtable的一个开源实现，而且根据咱们的想法进行了一些改进。

 

主要功能特色：

负载均衡的处理，版本控制和一致性，可靠性，分布为多个节点。

 

 

6. Riak

Riak是最为强大的分布式数据库之一，它提供了轻松且可预测的伸缩能力，向用户提供了快速测试、原型与应用部署能力，从而简化应用的开发过程。

 

最佳应用场景：适用于想使用相似 Cassandra（相似Dynamo）数据库但没法处理 bloat及复杂性的状况。适用于你打算作多站点复制，但又须要对单个站点的扩展性，可用性及出错处理有要求的状况。

例如：销售数据搜集，工厂控制系统；对宕机时间有严格要求；能够做为易于更新的 web服务器使用。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

7. Neo4j

Neo4j是一款NoSQL图型数据库，具备很是高的性能。它拥有一个健壮且成熟的系统的全部特性，向程序员提供了灵活且面向对象的网络结构，可让开发者充分享受到拥有完整事务特性的数据库的全部好处。相较于RDBMS，Neo4j还对某些应用提供了很多性能改进。

优势：

1. 数据的插入，查询操做很直观，不用再像以前要考虑各个表之间的关系。
2. 提供的图搜索和图遍历方法很方便，速度也是比较快的。

缺点：

1. 最不能让人忍受的就是极慢的插入速度。多是由于建立节点和边的时候须要保存一些额外信息（为了查询服务）。不知道是否是我代码的问题，插入10000个节点，10000条边花了将近10分钟...
2. 超大节点。当有一个节点的边很是多时（常见于大V），有关这个节点的操做的速度将大大降低。这个问题很早就有了，官方也说过会处理，然而如今仍然不能让人满意。
3. 提升数据库速度的经常使用方法就是多分配内存，然而看了官方操做手册，貌似没法直接设置数据库内存占用量，而是须要计算后为其”预留“内存...

 

最佳应用场景：适用于图形一类数据。这是 Neo4j与其余nosql数据库的最显著区别

例如：社会关系，公共交通网络，地图及网络拓谱

鉴于其明显的优缺点，Neo4j适合存储”修改较少，查询较多，没有超大节点“的图数据。

另外，针对Neo4j的缺点，有一款使用混合索引的数据库Arangodb也许是一个不错的考虑对象。根据其官网的说明，Arangodb不只具备通常图形数据库的优势，并且在各类操做的速度上领先于Neo4j

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

8. Couchbase

虽然Couchbase是CouchDB的派生，不过它已经成为了一款功能完善的数据库产品。它向文档数据库转移的趋势会让MongoDB感到压力。每一个节点上它都是多线程的，这是个很是主要的可伸缩性优点，特别是当托管在自定义或是Bare-Metal硬件上时更是如此。借助于一些很是棒的集成特性，诸如与Hadoop的集成，Couchbase对于数据存储来讲是个很是不错的选择。

Redis相比Couchbase来讲，拥有更多的数据结构和并支持更丰富的数据操做，一般在Couchbase里，你须要将数据拿到客户端来进行相似的修改再set回去（你须要先先经过get方法从服务器读取数据文档，并将文档反序列化为json对象，以后修改json对象对应属性，再经过set方法将数据写入服务器，序列化后进行存储）。这大大增长了网络IO的次数和传输中的数据体积。在Redis中，这些复杂的操做一般和通常的GET/SET同样高效。

 

适用场景：最佳应用场景：适用于数据变化较少，执行预约义查询，进行数据统计的应用程序。适用于须要提供数据版本支持的应用程序。

 

 

 

 

 

 

9.. MemcacheDB

这是个分布式的键值存储系统，咱们不该该将其与缓存解决方案搞混；相反，它是个持久化存储引擎，用于数据存储并以很是快速且可靠的方式检索数据。它遵循memcache协议。其存储后端用于Berkeley DB中，支持诸如复制与事务等特性。

优势

 一.部分容灾

假设只用一台memcache，若是这台memcache服务器挂掉了，那么请求将不断的冲击数据库，这样有可能搞死数据库，从而引起”雪崩“。若是使用多台memcache服务器，因为memcache使用一致性哈希算法，万一其中一台挂掉了，部分请求仍是能够在memcache中命中，为修复系统赢得一些时间。

 二.容量问题

一台memcache服务器的容量毕竟有限，可使用多台memcache服务器，增长缓存容量。

 三.均衡请求

使用多台memcache服务器，能够均衡请求，避免全部请求都冲进一台memcache服务器，致使服务器挂掉。

四.利用memcache分布式特性

使用一台memcache服务器，并无利用memcache的数据分布式特性。

缺点

   1.不能持久化存储

   2.存储数据有限制：1M 【大于1M，认为就行分割】（内存碎片）

   3.mm存储数据只能key-value

   4.集群数据没有复制和同步机制 【崩溃不会影响程序，会从数据库中取数据】

   5.内存回收不能及时  LRU(算法)：未使用内存》过时内存》最近最少使用内存   这是惰性删除