主流的Nosql数据库的对比
MongoDB，Cassandra，CouchDB，Hypertable， Redis，Riak，Neo4j，Hadoop HBase，
Couchbase，MemcacheDB
- Hadoop HBase
Hbase的优点及应用场景：
1. 半结构化或非结构化数据:
对于数据结构字段不够确定或杂乱无章非常难按一个概念去进行抽取的数据适合用HBase，因为HBase支持动态添加列。
- 记录很稀疏：
RDBMS的行有多少列是固定的。为null的列浪费了存储空间。HBase为null的Column不会被存储，这样既节省了空间又提高了读性能。
3. 多版本号数据：
依据Row key和Column key定位到的Value能够有随意数量的版本号值，因此对于须要存储变动历史记录的数据，用HBase是很方便的。比方某个用户的Address变更，用户的Address变更记录也许也是具有研究意义的。
4. 仅要求最终一致性：
对于数据存储事务的要求不像金融行业和财务系统这么高，只要保证最终一致性就行。（比如HBase+elasticsearch时，可能出现数据不一致）
5. 高可用和海量数据以及很大的瞬间写入量：
WAL解决高可用，支持PB级数据，put性能高
适用于插入比查询操作更频繁的情况。比如，对于历史记录表和日志文件。（HBase的写操作更加高效）
业务场景简单：
不需要太多的关系型数据库特性，列入交叉列，交叉表，事务，连接等。
Hbase的缺点：
- 单一RowKey固有的局限性决定了它不可能有效地支持多条件查询
- 不适合于大范围扫描查询
- 不直接支持 SQL 的语句查询
- java语言实现及Hadoop架构意味着其API更适用于Java项目
- 占用内存很大，且鉴于建立在为批量分析而优化的HDFS上，导致读取性能不高；API相比其它 NoSql 的相对笨拙。
但是Hadoop/HBase集群的维护常常需要很多专业人员并且需要构建一个比较大的集群才能最大化体现出威力，因此用户主要是Facebook, yahoo, 百度和阿里巴巴等大公司。所以我们用它来开发系统是一件
最佳应用场景：适用于偏好BigTable:)并且需要对大数据进行随机、实时访问的场合。
例如： Facebook消息数据库（更多通用的用例即将出现）
- MongoDB 数据库
MongoDB是一个新的和普遍使用的数据库。 它是一个基于文档的非关系数据库提供程序。
MongoDB是个面向文档的数据库，使用JSON风格的数据格式。它非常适合于网站的数据存储、内容管理与缓存应用，并且通过配置可以实现复制与高可用性功能。
MongoDB具有很强的可伸缩性，性能表现优异。它使用C++编写，基于文档存储。此外，
MongoDB还支持全文检索、跨WAN与LAN的高可用性、易于实现的复制、水平扩展、基于文档的丰富查询、在数据处理与聚合等方面具有很强的灵活性。
MongoDB社区非常活跃，很多开发框架都迅速提供了对MongDB的支持。
优点：
- MongoDB 的架构较少。它是一个文档数据库，它的一个集合持有不同的文档。
- 从一个到另一个的文档的数量，内容和大小可能有差异。支持多种文档！
- MongoDB 中单个对象的结构很清淅。
- MongoDB 中没有复杂的连接。
- MongoDB 提供深度查询的功能，因为它支持对文档的强大的动态查询。
- MongoDB 很容易扩展。
- 它使用内部存储器来存储工作集，这是其快速访问的原因。
- MongoDB更加灵活，因为可以在文档中直接插入数组之类的复杂数据类型，并且文档的key和value不是固定的数据类型和大小，所以开发者在使用MongoDB时无须预定义关系型数据库中的”表”等数据库对象，设计数据库将变得非常方便，可以大大地提升开发进度。
- 适用于需要动态查询支持；需要使用索引而不是 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版本，已经有部分重同步的功能，但是还是有可能有完整重同步的。比如，新上线的备机。
- 修改配置文件，进行重启，将硬盘中的数据加载进内存，时间比较久。在这个过程中，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对一些数据结构采用了压缩算法存储，但占用内存量还是过高。
适用场景：适用于数据变化快且数据库大小可遇见（适合内存容量）的应用程序。
- 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的内部测试中曾经暴露出不少严重的问题。
缺点的讨论：
1、它未采用hdfs文件系统，所以存在与Hadoop难以协同的问题。数据源在cassandra存储体系中，不利于mapreduce分析。
2、该开源体系尚不成熟，代码稳定性存在不确定性，先后被一些大型互联网公司采用又弃用。
3、其快速查询的功能有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还对某些应用提供了不少性能改进。
优点：
- 数据的插入，查询操作很直观，不用再像之前要考虑各个表之间的关系。
- 提供的图搜索和图遍历方法很方便，速度也是比较快的。
缺点：
- 最不能让人忍受的就是极慢的插入速度。可能是因为创建节点和边的时候需要保存一些额外信息（为了查询服务）。不知道是不是我代码的问题，插入10000个节点，10000条边花了将近10分钟…
- 超大节点。当有一个节点的边非常多时（常见于大V），有关这个节点的操作的速度将大大下降。这个问题很早就有了，官方也说过会处理，然而现在仍然不能让人满意。
- 提高数据库速度的常用方法就是多分配内存，然而看了官方操作手册，貌似无法直接设置数据库内存占用量，而是需要计算后为其”预留“内存…
最佳应用场景：适用于图形一类数据。这是 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(算法)：未使用内存》过期内存》最近最少使用内存 这是惰性删除
