NoSQL现状及发展趋势

3.1 NoSQL介绍
NoSQL是相对SQL数据库的说法，也就是非关系型数据库，由于互联网的迅速发展，云计算与Web2.0。这样大量的交互给数据库提出了更高的性能要求，传统的数据库（本文泛指SQL数据库），即关系数据库虽然具备良好的事物管理，但在处理大量数据的应用时很难在性能上满足设计要求。NoSQL就是主要为了解决当下大量高并发高要求的数据库应用需求，关系数据库具有严格的参照性，一致性，可用性，原子性，隔离性等特点，因此会产生一些例如表连接等操作，这样会大大降低系统的性能。而在当前很多应用场景下对性能的要求远远强于传统数据库关注的点，NoSQL就是为了解决大规模数据与多样数据种类等问题，尤其是其中大数据的相关问题。
NoSQL最早被提出是在20世纪80年代，在当时更多是强调的是与关系数据库区别对待，最近这些年被提及的更多是强调协助解决大数据等相关问题。
主要解决的问题是数据库性能的优化和大数据的处理问题，传统的数据库运行在单击环境下，想要扩充性能更多采用sacle-up（升级服务器性能），而NoSQL大都原生支持分布式的环境，更多的采用的sacle-out的方式去解决数据处理能力的扩充问题，这样可以轻松的保证良好的性能的情况下可以轻松的用廉价的存储集合成集群，例如增加相应的存储节点。
3.2 NoSQL应用情况介绍
国内的互联网蓬勃发展，不仅涌现出BAT（百度，阿里巴巴，腾讯）之类的巨头，也带动了整个互联网行业的发展，大量的创业型公司如春笋般的涌出，在国家层面也提出了“互联网+”和“万众创业”的口号。更多传统的行业也开始拥抱互联网。但是无论是做所谓的生态平台还是传统业务的转型，涉及到的业务是多种多样的。这个时候企业架构师对于应用系统的核心——数据库管理 不仅有传统的SQL选项也有了NoSQL这种适合特定场景需求的选项。
web2.0的流行让信息传播更加的迅速，网民不仅成了信息的消费者，每个人也是信息的创建者，微博（类似还有facebook或则是twitter等社交网站）每时每刻都有大量的用户在线，在保证可用性的情况下，按照CAP理论，一致性，可用性和分区容忍是无法同时满足的，只能同时满足两个需求。现在的应用规模不断增长，单机由于性能原因必然不能承受，因此分区容忍是必须要得到保证的，剩下的就是可用性和一致性的问题，大量的评论对数据库的操作并不需要像银行系统那样必须保证强一致性，可能银行对于账户余额的综合保持不变的敏感程度更高，但是最新的评论是否被看到这样的强一致性保证而丢失系统的可用性这是意义不大的，因此我们可以采取最终一致性的办法保证系统的可用性而牺牲数据的短暂的不一致性，在更新操作还没有同步到其他客户端的这个时间叫做一致性窗口时间。像类似对于一致性不太敏感的业务场景下，关系数据库严格遵守CAP的实时一致性可以降低为最终一致性，换来的却是性能的大幅上升，这样的换取是值得的。
在大数据领域、数据仓库、大数据分析、BI等分析领域都需要处理大量的数据样本，这样的情况下，采用传统的关系数据库无法在性能上得到满足对于很多数据的处理也没有提供很好的接口去处理。因此我们需要采用更加定制的数据管理产品，更加地具有弹性，例如Hadoop在底层采用HBase去存储。还采用了非常高效的ReduceMap工具去操纵数据。在数据量变得异常庞大的情况下一些基本操作效率基本没有差别。
NoSQL近来年越来越受到互联网公司的重视，在业务量（通常是用户量）的规模在一定范围内，传统的关系数据库完全可以满足要求，没必要最开始去采用NoSQL，由于SQL数据库发展几十年，相关技术是非常稳定的，项目的前期最重要的是完成核心产品功能的交付而不是“一步到位”去追求未来不确定的架构。况且大部分采用NoSQL的公司很多也是采用了SQL与NoSQL结合的方式应用。把大量变化频率比较小或者对性能要求不太高的数据存放在SQL，把大量访问频繁或者对性能要求高的数据存放在NoSQL里。因此再次证明了NoSQL的目的并不是要替代SQL而是要更好地服务于业务。
当前的NoSQL主要应用在性能上和功能上，从性能上来说，同样的需求貌似传统的关系数据库也可以解决，只是在采用了分表、分库、集群各种优化手段之后依然很难去提升需求的更替或者是对长期来说是很大的挑战，或者是解决方案所投入的成本已经超出部署NoSQL可能面临的风险之上，企业会采用NoSQL来支撑业务的发展。从功能上来说，现在各行业的大数据革命必然对海量数据存储和处理有着十分高的要求，这个情况下传统的关系数据库很难达到类似Hadoop这样的数据存储处理能力，因此这样选择NoSQL是必要的。
目前的应用情况主要分为了四个场景去使用NoSQL，第一种是采用NoSQL作为镜像。

图3.1 同时写入

这样是在传统的MySQL基础上去增加了一层同时完成对NoSQL的数据的存取，这样利用了NoSQL的优势，对于严格保证一致性的数据我们读取MySQL，对于性能要求比较高的部分我们操作NoSQL。如果还要保证数据的同步性，我们可以采用MySQL与NoSQL同步的方法。如图：

图3.2 同步写入

这样在操作MySQL的情况下，系统自动的将数据同步到NoSQL，但是这样的技术上的挑战比较大，而且还要让MySQL有底层的协议支持。
目前应用比较广泛的还有MySQL与NoSQL组合的方式。例如：

图3.3 NoSQL辅助

我们可以将比较简单的数据存放在MySQL，这样我们可以在对应的字段上存放索引，然后将取出的数据去查询NoSQL，一般MySQL存放比较小、简单的数据，NoSQL存放比较复杂大量的数据，这样我们可以尽可能地节省MySQL的性能开销。MySQL的查询命中率也得到了提升，NoSQL的扩展性也得到了利用。
或者是将NoSQL放在主要位置，这样的业务一般对性能和扩展性的要求明显大于数据的一致性，因为传统的厂商更趋于使用成熟稳定的数据库产品。

图3.4 直接NoSQL

这样的架构我们一般是在不需要复杂关系查询的情况下使用，由于在存放记录的时候，我们可能每次存放的结果数据都是不一样的，采用这样的结构可以大大增加系统的扩展性，如果采用传统的关系数据库可能要修改字段。这样的性能也是非常高效的。而且现在一些NoSQL也逐渐增加了对于一些复杂关系的查询。
还有采用以NoSQL为数据源的架构：

图3.5 直接读写NoSQL

这种架构可以在代码层面直接将数据存放到NoSQL，但是为了考虑到数据的一致性和保证传统关系查询等操作的方便，可能希望将数据同步复制到MySQL等数据存储，但是复制的过程交给底层协议，我们使用的时候只需要将数据存放到NoSQL即可，这个架构的难点在于复制同步的过程。