2. 什么是NoSQL？
创新互联主营萨尔图网站建设的网络公司,主营网站建设方案,成都app开发,萨尔图h5重庆小程序开发搭建,萨尔图网站营销推广欢迎萨尔图等地区企业咨询
2.1 NoSQL 概述
NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，
泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。
（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 关系型数据库与NoSQL的区别？
3.1 RDBMS
高度组织化结构化数据
结构化查询语言（SQL）
数据和关系都存储在单独的表中。
数据操纵语言，数据定义语言
严格的一致性
基础事务
ACID
关系型数据库遵循ACID规则
事务在英文中是transaction，和现实世界中的交易很类似，它有如下四个特性：
A (Atomicity) 原子性
原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入100元至B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。
C (Consistency) 一致性
一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。
I (Isolation) 独立性
所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。
3.2 NoSQL
代表着不仅仅是SQL
没有声明性查询语言
没有预定义的模式
键 - 值对存储，列存储，文档存储，图形数据库
最终一致性，而非ACID属性
非结构化和不可预知的数据
CAP定理
高性能，高可用性和可伸缩性
分布式数据库中的CAP原理(了解)
CAP定理：
Consistency(一致性), 数据一致更新，所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容错性) 可靠性
P: 系统中任意信息的丢失或失败不会影响系统的继续运作。
定理：任何分布式系统只可同时满足二点，没法三者兼顾。
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，
因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：
CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。
而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。
所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。
说明：C：强一致性 A：高可用性 P：分布式容忍性
举例：
CA：传统Oracle数据库
AP：大多数网站架构的选择
CP：Redis、Mongodb
注意：分布式架构的时候必须做出取舍。
一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。
因此牺牲C换取P，这是目前分布式数据库产品的方向。
4. 当下NoSQL的经典应用
当下的应用是 SQL 与 NoSQL 一起使用的。
代表项目：阿里巴巴商品信息的存放。
去 IOE 化。
ps：I 是指 IBM 的小型机，很贵的，好像好几万一台；O 是指 Oracle 数据库，也很贵的，好几万呢；M 是指 EMC 的存储设备，也很贵的。
难点：
数据类型多样性。
数据源多样性和变化重构。
数据源改造而服务平台不需要大面积重构。
value值里可以存放一组数据，取出来再解析。关键是key的设计，一般设计成查询条件的组合，中间用冒号分隔。
像MongoDB, Cassandra, HBase, DynamoDB, 和
Riak这些NoSQL缺乏传统的原子事务机制，所谓原子事务机制是可以保证一系列写操作要么全部完成，要么全部不会完成，不会发生只完成一系列中一两个
写操作;因为数据库不提供这种事务机制支持，开发者需要自己编写代码来确保一系列写操作的事务机制，比较复杂和测试。
这些NoSQL数据库不提供事务机制原因在于其分布式特点，一系列写操作中访问的数据可能位于不同的分区服务器，这样的事务就变成分布式事务，在分
布式事务中实现原子性需要彼此协调，而协调是耗费时间的，每台机器在一个大事务过程中必须依次确认，这就需要一种协议确保一个事务中没有任何一台机器写操
作失败。
这种协调是昂贵的，会增加延迟时间，关键问题是，当协调没有完成时，其他操作是不能读取事务中写操作结果的，这是因为事务的all-or-
nothing原理导致，万一协调过程发现某个写操作不能完成，那么需要将其他写操作成功的进行回滚。针对分布式事务的分布式协调对整体数据库性能有严重
影响，不只是吞吐量还包括延迟时间，这样大部分NoSQL数据库因为性能问题就选择不提供分布式事务。
MongoDB, Riak, HBase, 和 Cassandra提供基于单一键的事务，这是因为所有信息都和一个键key有关，这个键是存储在单个服务器上，这样基于单键的事务不会带来复杂的分布式协调。
那么看来扩展性性能和分布式事务是一对矛盾，总要有取舍?实际上是不完全是，现在完全有可能提供高扩展的性能同时提供分布式原子事务。
FIT是这样一个在分布式系统提供原子事务的策略，在fairness公平性, isolation隔离性, 和throughput吞吐量(简称FIT)可以权衡。
一个支持分布式事务的可伸缩分布式系统能够完成这三个属性中两个，公平是事务之间不会相互影响造成延迟;隔离性提供一种幻觉好像整个数据库只有它自
己一个事务，隔离性保证当任何同时发生的事务发生冲突时，能够保证彼此能看到彼此的写操作结果，因此减轻了程序员为避免事务读写冲突的强逻辑推理要求;吞
吐量是指每单元时间数据库能够并发处理多少事务。
FIT是如下进行权衡：
保证公平性fairness 和隔离性isolation, 但是牺牲吞吐量
保证公平性fairness和吞吐量, 牺牲隔离性isolation
保证隔离性isolation和吞吐量throughput, 但是牺牲公平性fairness.
牺牲公平性：放弃公平性，数据库能有更多机会降低分布式事务的成本，主要成本是分布式协调带来的，也就是说，不需要在每个事务过程内对每个机器都依
次确认事务完成，这样排队式的确认commit事务是很浪费时间的，放弃公平性，意味着可以在事务外面进行协调，这样就只是增加了协调时间，不会增加互相
冲突事务因为彼此冲突而不能运行所耽搁的时间，当系统不需要公平性时，需要根据事务的优先级或延迟等标准进行指定先后执行顺序，这样就能够获得很好的吞吐
量。
G-Store是一种放弃公平性的 Isolation-Throughput
的分布式key-value存储，支持多键事务(multi-key transactions)，MongoDB 和
HBase在键key在同样分区上也支持多键事务，但是不支持跨分区的事务。
总之：传统分布式事务性能不佳的原因是确保原子性(分布式协调)和隔离性同时重叠，创建一个高吞吐量分布式事务的关键是分离这两种关注，这种分离原
子性和隔离性的视角将导致两种类型的系统，第一种选择是弱隔离性能让冲突事务并行执行和确认提交;第二个选择重新排序原子性和隔离性机制保证它们不会某个
时间重叠，这是一种放弃公平的事务执行，所谓放弃公平就是不再同时照顾原子性和隔离性了，有所倾斜，放弃高标准道德要求就会带来高自由高效率。
Apache三剑客：HBase, Cassandra, CouchDB。HBase的前景最为看好，因为它的开发者众多并且都是顶尖高手。Cassandra目前有很多否定的声音。CouchDB的小而精悍，赞誉很多，将要正式发布的CouchBase融合了MemBase和CouchDB，很令人期待。
HBase和Cassandra都是效仿Google的BigTable的基于列的数据库，它们都是用Java写的。另外一类似的数据库是HyperTable，百度用在一些后台分析，因为它是C++写的，速度比较快。不过HyperTable有点边缘，不太流行。这些基于列的开源数据库目前都比Goolge的BigTable差之少一个数量级
CouchDB是一个文档数据库。其最大的竞争者是MongoDB。MongoDB和HBase都采用主从服务器设计。CouchDB的服务器分布设计和Cassandra类似，Peer to Peer类型的。主从服务器设计一般能更好的strong consistent，属于CAP理论中的CP类型。 CouchDB和Cassandra一般认为都是eventual consistent，属于CAP理论中的AP类型。但其实MongoDB和Cassandra都可以设置成strong consistent或者eventual consistent。
以上所提到的数据库都支持MapReduce。好像出了HyperTable都支持非主键索引。HBase和strong consistent配置的MongoDB都支持最基本的锁定（HBase单行锁定，MongoDB单文档锁定），因此可以实现transaction，但是实现有点复杂和低效。单就transaction这一点，目前开源NoSQL数据库没有做的比较好的。
MongoDB的最大卖点是不需构建非主键索引也能执行很多查询。但是MongoDB的服务器分布设计实在不能让人恭维，可以说是NoSQL数据库中最Ugly的实现。
K-V数据库比较多，而且上面提到的基于列的数据库和文档数据库其实也都是K-V数据库。比较流行的纯种K-V数据库有:
Memcached: 非常流行，不支持持久化
VMWare's Redis: 很流行，新浪和知乎都在用，CP类型。
MemBase: 由很多Memcached的开发者开发，使用sqlite作底层存储。在社交游戏中用的比较多, zynga在用，CP类型。
Riak, 分布式实现和CouchDB/Cassandra比较像，AP类型。支持MapReduce。
Linkin's Voldemort， 在K-V中少见的eventual consistent ，AP类型。
TT, TC
纯基于二维座标索引的是Neo4j。但是现在MongoDB和CouchDB都集成这一特性。
目前CouchDB的开发者成立的公司CouchOne收购了MemBase，将其底层sqlite换成CouchDB推出了CouchBase，从而引入MapReduce以支持非主键索引。CouchBase暂时还没有正式发布官方正式版，不过快了。虽然CouchDB是eventual consistent的，但是CouchBase的开发者宣称CouchBase保持了MemBase的strong consistent特性，具体实现有待以后研究。
如果从成熟的角度来看，比较成熟并且十分流行的的有CouchDB，Memcached，Redis。
HBase和MongonDB和Cassandra都比较新，处于频繁更新之中。最有前途的是HBase，但是Hadoop/HBase集群的维护常常需要很多专业人员并且需要构建一个比较大的集群才能最大化体现出威力，因此用户主要是Facebook, yahoo, 百度和阿里巴巴等大公司。
个人比较期待CouchBase。
转载仅供参考，版权属于原作者。祝你愉快，满意请采纳哦