误区
非关系,意思就是没有关系，没有关系,怎么做关联,怎么提取数据?
NoSQL(NoSQL = Not Only SQL )，意即"不仅仅是SQL"。其实指的就是关系型数据库以外的数据库。
总结
mysql就像老式拖拉机，皮实，稳定，可靠性好，能装很多货物。但是现在社会高速发展，大家速度有了一定要求，nosql就像是一台跑车，华丽、速度快。但是可靠性并不好，容量也不够大。所以就将redis(nosql)+mysql，即跑车拉着拖拉机。这样速度容量都有了。
关系型数据库
1.所谓关系模型就是“一对一、一对多、多对多”等关系模型，关系模型就是指二维表格模型,因而一个关系型数据库就是由二维表及其之间的联系组成的一个数据组织。
2.关系型数据可以很好地存储一些关系模型的数据，比如一个老师对应多个学生的数据（“多对多”），一本书对应多个作者（“一对多”），一本书对应一个出版日期（“一对一”）
3.关系模型是我们生活中能经常遇见的模型，存储这类数据一般用关系型数据库
关系型（sql）数据库的缺点
互联网的不断发展，用户的不断增多导致传统关系型数据库遇到了性能瓶颈，具体表现在以下几个方面
1.对数据库高并发读写的需求(High performance)
关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。比如微博的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等。
2.对海量数据的高效率存储和访问的需求(Huge Storage)
类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付
3.对数据库的高可扩展性和高可用性的需求
在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移
nosql的优点
1.大数据量，高性能
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了
2.易扩展
NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性(去掉了“一对一、一对多、多对多”等关系模型)。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力
3.高可用
NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。
为什么nosql支持分布式
1.nosql本身就不支持事务，外键，而事务的问题在于要支持ACID特性（原子性，一致性），即要么全部成功要么全部失败。但是你如何保证一个事务的一致性。一次大的事务操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。这一点很难做，nosql由于本身没有事务的限制，不妨碍它在多个节点上操作。
既然支持分布式，大部分NoSQL为什么不提供分布式事务？
如果要支持分布式事务，那么在分布式事务中实现原子性需要彼此协调，而协调是耗费时间的，每台机器在一个大事务过程中必须依次确认，这就需要一种协议确保一个事务中没有任何一台机器写操作失败。而类似redis等nosql数据库是以性能、快速著称，所以从性能考虑。大部分NoSQL数据库因为性能问题就选择不提供分布式事务
为什么新的分布式数据库又开始支持关系模型了？
之所以新的分布式数据库又开始支持关系模型了，是因为大部分程序员的数据库水平太糟糕。
https://www.zhihu.com/question/51158165
mysql如何实现分布式事务？
1.基于XA协议的两阶段提交，XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。
XA事务，即所谓的分布式事务却令人感到云里雾里。一是资料很少，网上的各种配置资料都是流于表面；二是可能实际应用的人也少。二阶段提交（Two-phase Commit）
首先，XA事务是基于二阶段提交（Two-phase Commit）实现的。二阶段提交本身并没有什么令人疑惑的地方。看wiki就可以知道是怎么回事了。
简而言之，有二种角色，事务管理者（DM, Transaction Manager），资源管理器（RM, Resource Manager），通常即数据库或者JMS服务器。
为什么会出现这些数据库的演进？
历史背景的变化
1.早期数据库还有层级数据库、网状数据库。早期程序员出了些sql语句还得考虑数据物理存放方式来决定怎么执行查询更高效。泰国繁琐和麻烦。
2.后来出现了关系模型，彻底改变了数据库程序员的生活：不用管数据怎么存了，你只要用SQL写好查询，然后查询优化器会帮你把面向业务的查询逻辑转换成可以高效在数据的物理结构上执行的物理查询。这简直就像一下从汇编时代跨越到了高级语言的时代啊。早期的数据库还需要大家自己思考怎么建索引，相当于告诉查询优化器哪些列是在查询中有用，后来数据库已经可以自动提示你该加什么索引了，大部分程序员终于可以欢乐地彻底扔掉数据库存储引擎的知识了。
3.分布式出现后原本的关系型数据库不管用了。分布式最大的问题是网络延迟问题，而网络延迟是物理问题，没这么容易解决。跨机事务做不了啊，查询优化器再牛逼也优化不了跨网络的join。
4.就出现了nosql这种不需要事务，可扩展性强的产品
5.但是nosql太难用了，就像回到了以前汇编的时代，所以基于这种情况下，新的分布式数据库又开始支持关系模型了。
