这次的NoSQL专栏系列将先整体介绍NoSQL，然后介绍如何把NoSQL运用到自己的项目中合适的场景中，还会适当地分析一些成功案例，希望有成功使用NoSQL经验的朋友给我提供一些线索和信息。
成都创新互联公司企业建站,10多年网站建设经验，专注于网站建设技术，精于网页设计，有多年建站和网站代运营经验，设计师为客户打造网络企业风格，提供周到的建站售前咨询和贴心的售后服务。对于做网站、网站设计中不同领域进行深入了解和探索，创新互联在网站建设中充分了解客户行业的需求，以灵动的思维在网页中充分展现，通过对客户行业精准市场调研，为客户提供的解决方案。
NoSQL概念随着web2.0的快速发展，非关系型、分布式数据存储得到了快速的发展，它们不保证关系数据的ACID特性。NoSQL概念在2009年被提了出来。NoSQL最常见的解释是“non-relational”，“Not Only SQL”也被很多人接受。（“NoSQL”一词最早于1998年被用于一个轻量级的关系数据库的名字。）
NoSQL被我们用得最多的当数key-value存储，当然还有其他的文档型的、列存储、图型数据库、xml数据库等。在NoSQL概念提出之前，这些数据库就被用于各种系统当中，但是却很少用于web互联网应用。比如cdb、qdbm、bdb数据库。
传统关系数据库的瓶颈
传统的关系数据库具有不错的性能，高稳定型，久经历史考验，而且使用简单，功能强大，同时也积累了大量的成功案例。在互联网领域，MySQL成为了绝对靠前的王者，毫不夸张的说，MySQL为互联网的发展做出了卓越的贡献。
在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。
到了最近10年，网站开始快速发展。火爆的论坛、博客、sns、微博逐渐引领web领域的潮流。在初期，论坛的流量其实也不大，如果你接触网络比较早，你可能还记得那个时候还有文本型存储的论坛程序，可以想象一般的论坛的流量有多大。
Memcached+MySQL
后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。
Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端。当时，如果你去面试，你说你有Memcached经验，肯定会加分的。
Mysql主从读写分离
由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。
分表分库随着web2.0的继续高速发展，在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但是由于在互联网几乎没有成功案例，性能也不能满足互联网的要求，只是在高可靠性上提供了非常大的保证。
MySQL的扩展性瓶颈
在互联网，大部分的MySQL都应该是IO密集型的，事实上，如果你的MySQL是个CPU密集型的话，那么很可能你的MySQL设计得有性能问题，需要优化了。大数据量高并发环境下的MySQL应用开发越来越复杂，也越来越具有技术挑战性。分表分库的规则把握都是需要经验的。虽然有像淘宝这样技术实力强大的公司开发了透明的中间件层来屏蔽开发者的复杂性，但是避免不了整个架构的复杂性。分库分表的子库到一定阶段又面临扩展问题。还有就是需求的变更，可能又需要一种新的分库方式。
MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。
关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。
NOSQL的优势易扩展NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。
大数据量，高性能
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。
灵活的数据模型
NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。
高可用NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。
总结NoSQL数据库的出现，弥补了关系数据（比如MySQL）在某些方面的不足，在某些方面能极大的节省开发成本和维护成本。
MySQL和NoSQL都有各自的特点和使用的应用场景，两者的紧密结合将会给web2.0的数据库发展带来新的思路。
NewSQL是对一类现代关系型数据库的统称，这类数据库对于一般的OLTP读写请求提供可横向扩展的性能，同时支持事务的ACID保证。这些系统既拥有NoSQL数据库的扩展性，又保持传统数据库的事务特性。NewSQL重新将“应用程序逻辑与数据操作逻辑应该分离”的理念带回到现代数据库的世界，这也验证了历史的发展总是呈现出螺旋上升的形式。
在21世纪00年代中，出现了许多数据仓库系统 (如 Vertica，Greeplum 和AsterData)，这些以处理OLAP 请求为设计目标的系统并不在本文定义的NewSQL范围内。OLAP 数据库更关注针对海量数据的大型、复杂、只读的查询，查询时间可能持续秒级、分钟级甚至更长。
NoSQL的拥趸普遍认为阻碍传统数据库横向扩容、提高可用性的原因在于ACID保证和关系模型，因此NoSQL运动的核心就是放弃事务强一致性以及关系模型，拥抱最终一致性和其它数据模型 (如 key/value，graphs 和Documents)。
两个最著名的NoSQL数据库就是Google的BigTable和Amazon的Dynamo，由于二者都未开源，其它组织就开始推出类似的开源替代项目，包括Facebook的 Cassandra (基于BigTable和Dynamo)、PowerSet的 Hbase(基于BigTable)。有一些创业公司也加入到这场NoSQL运动中，它们不一定是受BigTable和Dynamo的启发，但都响应了NoSQL的哲学，其中最出名的就是MongoDB。
在21世纪00年代末，市面上已经有许多供用户选择的分布式数据库产品。使用NoSQL的优势在于应用开发者可以更关注应用逻辑本身，而非数据库的扩展性问题；但与此同时许多应用，如金融系统、订单处理系统，由于无法放弃事务的一致性要求被拒之门外。
一些组织，如Google，已经发现他们的许多工程师将过多的精力放在处理数据一致性上，这既暴露了数据库的抽象、又提高了代码的复杂度，这时候要么选择回到传统DBMS时代，用更高的机器配置纵向扩容，要么选择回到中间件时代，开发支持分布式事务的中间件。这两种方案成本都很高，于是NewSQL运动开始酝酿。
NewSQL数据库设计针对的读写事务有以下特点：
1、耗时短。
2、使用索引查询，涉及少量数据。
3、重复度高，通常使用相同的查询语句和不同的查询参考。
也有一些学者认为NewSQL系统是特指实现上使用Lock-free并发控制技术和share-nothing架构的数据库。所有我们认为是NewSQL的数据库系统确实都有这样的特点。
大数据技术发展史：大数据的前世今生
今天我们常说的大数据技术，其实起源于Google在2004年前后发表的三篇论文，也就是我们经常听到的“三驾马车”，分别是分布式文件系统GFS、大数据分布式计算框架MapReduce和NoSQL数据库系统BigTable。
你知道，搜索引擎主要就做两件事情，一个是网页抓取，一个是索引构建，而在这个过程中，有大量的数据需要存储和计算。这“三驾马车”其实就是用来解决这个问题的，你从介绍中也能看出来，一个文件系统、一个计算框架、一个数据库系统。
现在你听到分布式、大数据之类的词，肯定一点儿也不陌生。但你要知道，在2004年那会儿，整个互联网还处于懵懂时代，Google发布的论文实在是让业界为之一振，大家恍然大悟，原来还可以这么玩。
因为那个时间段，大多数公司的关注点其实还是聚焦在单机上，在思考如何提升单机的性能，寻找更贵更好的服务器。而Google的思路是部署一个大规模的服务器集群，通过分布式的方式将海量数据存储在这个集群上，然后利用集群上的所有机器进行数据计算。 这样，Google其实不需要买很多很贵的服务器，它只要把这些普通的机器组织到一起，就非常厉害了。
当时的天才程序员，也是Lucene开源项目的创始人Doug Cutting正在开发开源搜索引擎Nutch，阅读了Google的论文后，他非常兴奋，紧接着就根据论文原理初步实现了类似GFS和MapReduce的功能。
两年后的2006年，Doug Cutting将这些大数据相关的功能从Nutch中分离了出来，然后启动了一个独立的项目专门开发维护大数据技术，这就是后来赫赫有名的Hadoop，主要包括Hadoop分布式文件系统HDFS和大数据计算引擎MapReduce。
当我们回顾软件开发的历史，包括我们自己开发的软件，你会发现，有的软件在开发出来以后无人问津或者寥寥数人使用，这样的软件其实在所有开发出来的软件中占大多数。而有的软件则可能会开创一个行业，每年创造数百亿美元的价值，创造百万计的就业岗位，这些软件曾经是Windows、Linux、Java，而现在这个名单要加上Hadoop的名字。
如果有时间，你可以简单浏览下Hadoop的代码，这个纯用Java编写的软件其实并没有什么高深的技术难点，使用的也都是一些最基础的编程技巧，也没有什么出奇之处，但是它却给社会带来巨大的影响，甚至带动一场深刻的科技革命，推动了人工智能的发展与进步。
我觉得，我们在做软件开发的时候，也可以多思考一下，我们所开发软件的价值点在哪里？真正需要使用软件实现价值的地方在哪里？你应该关注业务、理解业务，有价值导向，用自己的技术为公司创造真正的价值，进而实现自己的人生价值。而不是整天埋头在需求说明文档里，做一个没有思考的代码机器人。
Hadoop发布之后，Yahoo很快就用了起来。大概又过了一年到了2007年，百度和阿里巴巴也开始使用Hadoop进行大数据存储与计算。
2008年，Hadoop正式成为Apache的顶级项目，后来Doug Cutting本人也成为了Apache基金会的主席。自此，Hadoop作为软件开发领域的一颗明星冉冉升起。
同年，专门运营Hadoop的商业公司Cloudera成立，Hadoop得到进一步的商业支持。
这个时候，Yahoo的一些人觉得用MapReduce进行大数据编程太麻烦了，于是便开发了Pig。Pig是一种脚本语言，使用类SQL的语法，开发者可以用Pig脚本描述要对大数据集上进行的操作，Pig经过编译后会生成MapReduce程序，然后在Hadoop上运行。
编写Pig脚本虽然比直接MapReduce编程容易，但是依然需要学习新的脚本语法。于是Facebook又发布了Hive。Hive支持使用SQL语法来进行大数据计算，比如说你可以写个Select语句进行数据查询，然后Hive会把SQL语句转化成MapReduce的计算程序。
这样，熟悉数据库的数据分析师和工程师便可以无门槛地使用大数据进行数据分析和处理了。Hive出现后极大程度地降低了Hadoop的使用难度，迅速得到开发者和企业的追捧。据说，2011年的时候，Facebook大数据平台上运行的作业90%都来源于Hive。
随后，众多Hadoop周边产品开始出现，大数据生态体系逐渐形成，其中包括：专门将关系数据库中的数据导入导出到Hadoop平台的Sqoop；针对大规模日志进行分布式收集、聚合和传输的Flume；MapReduce工作流调度引擎Oozie等。
在Hadoop早期，MapReduce既是一个执行引擎，又是一个资源调度框架，服务器集群的资源调度管理由MapReduce自己完成。但是这样不利于资源复用，也使得MapReduce非常臃肿。于是一个新项目启动了，将MapReduce执行引擎和资源调度分离开来，这就是Yarn。2012年，Yarn成为一个独立的项目开始运营，随后被各类大数据产品支持，成为大数据平台上最主流的资源调度系统。
同样是在2012年，UC伯克利AMP实验室（Algorithms、Machine和People的缩写）开发的Spark开始崭露头角。当时AMP实验室的马铁博士发现使用MapReduce进行机器学习计算的时候性能非常差，因为机器学习算法通常需要进行很多次的迭代计算，而MapReduce每执行一次Map和Reduce计算都需要重新启动一次作业，带来大量的无谓消耗。还有一点就是MapReduce主要使用磁盘作为存储介质，而2012年的时候，内存已经突破容量和成本限制，成为数据运行过程中主要的存储介质。Spark一经推出，立即受到业界的追捧，并逐步替代MapReduce在企业应用中的地位。
一般说来，像MapReduce、Spark这类计算框架处理的业务场景都被称作批处理计算，因为它们通常针对以“天”为单位产生的数据进行一次计算，然后得到需要的结果，这中间计算需要花费的时间大概是几十分钟甚至更长的时间。因为计算的数据是非在线得到的实时数据，而是历史数据，所以这类计算也被称为大数据离线计算。
而在大数据领域，还有另外一类应用场景，它们需要对实时产生的大量数据进行即时计算，比如对于遍布城市的监控摄像头进行人脸识别和嫌犯追踪。这类计算称为大数据流计算，相应地，有Storm、Flink、Spark Streaming等流计算框架来满足此类大数据应用的场景。 流式计算要处理的数据是实时在线产生的数据，所以这类计算也被称为大数据实时计算。
在典型的大数据的业务场景下，数据业务最通用的做法是，采用批处理的技术处理历史全量数据，采用流式计算处理实时新增数据。而像Flink这样的计算引擎，可以同时支持流式计算和批处理计算。
除了大数据批处理和流处理，NoSQL系统处理的主要也是大规模海量数据的存储与访问，所以也被归为大数据技术。 NoSQL曾经在2011年左右非常火爆，涌现出HBase、Cassandra等许多优秀的产品，其中HBase是从Hadoop中分离出来的、基于HDFS的NoSQL系统。
我们回顾软件发展的历史会发现，差不多类似功能的软件，它们出现的时间都非常接近，比如Linux和Windows都是在90年代初出现，Java开发中的各类MVC框架也基本都是同期出现，Android和iOS也是前脚后脚问世。2011年前后，各种NoSQL数据库也是层出不群，我也是在那个时候参与开发了阿里巴巴自己的NoSQL系统。
事物发展有自己的潮流和规律，当你身处潮流之中的时候，要紧紧抓住潮流的机会，想办法脱颖而出，即使没有成功，也会更加洞悉时代的脉搏，收获珍贵的知识和经验。而如果潮流已经退去，这个时候再去往这个方向上努力，只会收获迷茫与压抑，对时代、对自己都没有什么帮助。
但是时代的浪潮犹如海滩上的浪花，总是一浪接着一浪，只要你站在海边，身处这个行业之中，下一个浪潮很快又会到来。你需要敏感而又深刻地去观察，略去那些浮躁的泡沫，抓住真正潮流的机会，奋力一搏，不管成败，都不会遗憾。
正所谓在历史前进的逻辑中前进，在时代发展的潮流中发展。通俗的说，就是要在风口中飞翔。
上面我讲的这些基本上都可以归类为大数据引擎或者大数据框架。而大数据处理的主要应用场景包括数据分析、数据挖掘与机器学习。数据分析主要使用Hive、Spark SQL等SQL引擎完成；数据挖掘与机器学习则有专门的机器学习框架TensorFlow、Mahout以及MLlib等，内置了主要的机器学习和数据挖掘算法。
此外，大数据要存入分布式文件系统（HDFS），要有序调度MapReduce和Spark作业执行，并能把执行结果写入到各个应用系统的数据库中，还需要有一个大数据平台整合所有这些大数据组件和企业应用系统。
图中的所有这些框架、平台以及相关的算法共同构成了大数据的技术体系，我将会在专栏后面逐个分析，帮你能够对大数据技术原理和应用算法构建起完整的知识体系，进可以专职从事大数据开发，退可以在自己的应用开发中更好地和大数据集成，掌控自己的项目。
希望对您有所帮助！~
NoSQL 数据库因其功能性、易于开发性和可扩展性而广受认可，它们越来越多地用于大数据和实时 Web 应用程序，在本文中，我们通过示例讨论 NoSQL、何时使用 NoSQL 与 SQL 及其用例。
NoSQL是一种下一代数据库管理系统 (DBMS)。NoSQL 数据库具有灵活的模式，可用于构建具有大量数据和高负载的现代应用程序。
“NoSQL”一词最初是由 Carlo Strozzi 在 1998 年创造的，尽管自 1960 年代后期以来就已经存在类似的数据库。然而，NoSQL 的发展始于 2009 年初，并且发展迅速。
在处理大量数据时，任何关系数据库管理系统 (RDBMS) 的响应时间都会变慢。为了解决这个问题，我们可以通过升级现有硬件来“扩大”信息系统，这非常昂贵。但是，NoSQL 可以更好地横向扩展并且更具成本效益。
NoSQL 对于非结构化或非常大的数据对象（例如聊天日志数据、视频或图像）非常有用，这就是为什么 NoSQL 在微软、谷歌、亚马逊、Meta (Facebook) 等互联网巨头中特别受欢迎的原因。
一些流行的 NoSQL 数据库包括：
随着企业更快地积累更大的数据集，结构化数据和关系模式并不总是适合。有必要使用非结构化数据和大型对象来更好地捕获这些信息。
传统的 RDBMS 使用 SQL（结构化查询语言）语法来存储和检索结构化数据，相反，NoSQL 数据库包含广泛的功能，可以存储和检索结构化、半结构化、非结构化和多态数据。
有时，NoSQL 也被称为“ 不仅仅是 SQL ”，强调它可能支持类似 SQL 的语言或与 SQL 数据库并列。SQL 和 NoSQL DBMS 之间的一个区别是 JOIN 功能。SQL 数据库使用 JOIN 子句来组合来自两个或多个表的行，因为 NoSQL 数据库本质上不是表格的，所以这个功能并不总是可行或相关的。
但是，一些 NoSQL DBMS 可以执行类似于 JOIN的操作——就像 MongoDB 一样。这并不意味着不再需要 SQL DBMS，相反，NoSQL 和 SQL 数据库倾向于以不同的方式解决类似的问题。
一般来说，在以下情况下，NoSQL 比 SQL 更可取：
许多行业都在采用 NoSQL，取代关系数据库，从而为某些业务应用程序提供更高的灵活性和可扩展性，下面给出了 NoSQL 数据库的一些企业用例。
内容管理是一组用于收集、管理、传递、检索和发布任何格式的信息的过程，包括文本、图像、音频和视频。NoSQL 数据库可以通过其灵活和开放的数据模型为存储多媒体内容提供更好的选择。
例如，福布斯在短短几个月内就构建了一个基于 MongoDB 的定制内容管理系统，以更低的成本为他们提供了更大的敏捷性。
大数据是指太大而无法通过传统处理系统处理的数据集，实时存储和检索大数据的系统在分析 历史 数据的同时使用流处理来摄取新数据，这是一系列非常适合 NoSQL 数据库的功能。
Zoom使用 DynamoDB（按需模式）使其数据能够在没有性能问题的情况下进行扩展，即使该服务在 COVID-19 大流行的早期使用量激增。
物联网设备具有连接到互联网或通信网络的嵌入式软件和传感器，能够在无需人工干预的情况下收集和共享数据。随着数十亿台设备生成数不清的数据，IoT NoSQL 数据库为 IoT 服务提供商提供了可扩展性和更灵活的架构。
Freshub就是这样的一项服务，它从 MySQL 切换到 MongoDB，以更好地处理其大型、动态、非统一的数据集。
拥有数十亿智能手机用户，可扩展性正成为在移动设备上提供服务的企业面临的最大挑战。具有更灵活数据模型的 NoSQL DBMS 通常是完美的解决方案。
例如，The Weather Channel使用 MongoDB 数据库每分钟处理数百万个请求，同时还处理用户数据并提供天气更新。
什么是NoSQL
大家有没有听说过“NoSQL”呢?近年，这个词极受关注。看到“NoSQL”这个词，大家可能会误以为是“No!SQL”的缩写，并深感愤怒：“SQL怎么会没有必要了呢?”但实际上，它是“Not Only SQL”的缩写。它的意义是：适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。
为弥补关系型数据库的不足，各种各样的NoSQL数据库应运而生。
为了更好地了解本书所介绍的NoSQL数据库，对关系型数据库的理解是必不可少的。那么，就让我们先来看一看关系型数据库的历史、分类和特征吧。
关系型数据库简史
1969年，埃德加?6?1弗兰克?6?1科德(Edgar Frank Codd)发表了划时代的论文，首次提出了关系数据模型的概念。但可惜的是，刊登论文的《IBM Research Report》只是IBM公司的内部刊物，因此论文反响平平。1970年，他再次在刊物《Communication of the ACM》上发表了题为“A Relational Model of Data for Large Shared Data banks”(大型共享数据库的关系模型)的论文，终于引起了大家的关注。
科德所提出的关系数据模型的概念成为了现今关系型数据库的基础。当时的关系型数据库由于硬件性能低劣、处理速度过慢而迟迟没有得到实际应用。但之后随着硬件性能的提升，加之使用简单、性能优越等优点，关系型数据库得到了广泛的应用。
通用性及高性能
虽然本书是讲解NoSQL数据库的，但有一个重要的大前提，请大家一定不要误解。这个大前提就是“关系型数据库的性能绝对不低，它具有非常好的通用性和非常高的性能”。毫无疑问，对于绝大多数的应用来说它都是最有效的解决方案。
突出的优势
关系型数据库作为应用广泛的通用型数据库，它的突出优势主要有以下几点:
保持数据的一致性(事务处理)
由于以标准化为前提，数据更新的开销很小(相同的字段基本上都只有一处)
可以进行JOIN等复杂查询
存在很多实际成果和专业技术信息(成熟的技术)
这其中，能够保持数据的一致性是关系型数据库的最大优势。在需要严格保证数据一致性和处理完整性的情况下，用关系型数据库是肯定没有错的。但是有些情况不需要JOIN，对上述关系型数据库的优点也没有什么特别需要，这时似乎也就没有必要拘泥于关系型数据库了。
关系型数据库的不足
不擅长的处理
就像之前提到的那样，关系型数据库的性能非常高。但是它毕竟是一个通用型的数据库，并不能完全适应所有的用途。具体来说它并不擅长以下处理：
大量数据的写入处理
为有数据更新的表做索引或表结构(schema)变更
字段不固定时应用
对简单查询需要快速返回结果的处理
。。。。。。
NoSQL数据库
为了弥补关系型数据库的不足(特别是最近几年)，NoSQL数据库出现了。关系型数据库应用广泛，能进行事务处理和JOIN等复杂处理。相对地，NoSQL数据库只应用在特定领域，基本上不进行复杂的处理，但它恰恰弥补了之前所列举的关系型数据库的不足之处。
易于数据的分散
如前所述，关系型数据库并不擅长大量数据的写入处理。原本关系型数据库就是以JOIN为前提的，就是说，各个数据之间存在关联是关系型数据库得名的主要原因。为了进行JOIN处理，关系型数据库不得不把数据存储在同一个服务器内，这不利于数据的分散。相反，NoSQL数据库原本就不支持JOIN处理，各个数据都是独立设计的，很容易把数据分散到多个服务器上。由于数据被分散到了多个服务器上，减少了每个服务器上的数据量，即使要进行大量数据的写入操作，处理起来也更加容易。同理，数据的读入操作当然也同样容易。
提升性能和增大规模
下面说一点题外话，如果想要使服务器能够轻松地处理更大量的数据，那么只有两个选择：一是提升性能，二是增大规模。下面我们来整理一下这两者的不同。
首先，提升性能指的就是通过提升现行服务器自身的性能来提高处理能力。这是非常简单的方法，程序方面也不需要进行变更，但需要一些费用。若要购买性能翻倍的服务器，需要花费的资金往往不只是原来的2倍，可能需要多达5到10倍。这种方法虽然简单，但是成本较高。
另一方面，增大规模指的是使用多台廉价的服务器来提高处理能力。它需要对程序进行变更，但由于使用廉价的服务器，可以控制成本。另外，以后只要依葫芦画瓢增加廉价服务器的数量就可以了。
不对大量数据进行处理的话就没有使用的必要吗？
NoSQL数据库基本上来说为了“使大量数据的写入处理更加容易(让增加服务器数量更容易)”而设计的。但如果不是对大量数据进行操作的话，NoSQL数据库的应用就没有意义吗?
答案是否定的。的确，它在处理大量数据方面很有优势。但实际上NoSQL数据库还有各种各样的特点，如果能够恰当地利用这些特点将会是非常有帮助。具体的例子将会在第2章和第3章进行介绍，这些用途将会让你感受到利用NoSQL的好处。
希望顺畅地对数据进行缓存(Cache)处理
希望对数组类型的数据进行高速处理
希望进行全部保存
多样的NoSQL数据库
NoSQL数据库存在着“key-value存储”、“文档型数据库”、“列存储数据库”等各种各样的种类，每种数据库又包含各自的特点。下一节让我们一起来了解一下NoSQL数据库的种类和特点。
NoSQL数据库是什么
NoSQL说起来简单，但实际上到底有多少种呢?我在提笔的时候，到NoSQL的官方网站上确认了一下，竟然已经有122种了。另外官方网站上也介绍了本书没有涉及到的图形数据库和对象数据库等各个类别。不知不觉间，原来已经出现了这么多的NoSQL数据库啊。
本节将为大家介绍具有代表性的NoSQL数据库。
key-value存储
这是最常见的NoSQL数据库，它的数据是以key-value的形式存储的。虽然它的处理速度非常快，但是基本上只能通过key的完全一致查询获取数据。根据数据的保存方式可以分为临时性、永久性和两者兼具三种。
临时性
memcached属于这种类型。所谓临时性就是 “数据有可能丢失”的意思。memcached把所有数据都保存在内存中，这样保存和读取的速度非常快，但是当memcached停止的时候，数据就不存在了。由于数据保存在内存中，所以无法操作超出内存容量的数据(旧数据会丢失)。
在内存中保存数据
可以进行非常快速的保存和读取处理
数据有可能丢失
永久性
Tokyo Tyrant、Flare、ROMA等属于这种类型。和临时性相反，所谓永久性就是“数据不会丢失”的意思。这里的key-value存储不像memcached那样在内存中保存数据，而是把数据保存在硬盘上。与memcached在内存中处理数据比起来，由于必然要发生对硬盘的IO操作，所以性能上还是有差距的。但数据不会丢失是它最大的优势。
在硬盘上保存数据
可以进行非常快速的保存和读取处理(但无法与memcached相比)
数据不会丢失
两者兼具
Redis属于这种类型。Redis有些特殊，临时性和永久性兼具，且集合了临时性key-value存储和永久性key-value存储的优点。Redis首先把数据保存到内存中，在满足特定条件(默认是15分钟一次以上，5分钟内10个以上，1分钟内10000个以上的key发生变更)的时候将数据写入到硬盘中。这样既确保了内存中数据的处理速度，又可以通过写入硬盘来保证数据的永久性。这种类型的数据库特别适合于处理数组类型的数据。
同时在内存和硬盘上保存数据
可以进行非常快速的保存和读取处理
保存在硬盘上的数据不会消失(可以恢复)
适合于处理数组类型的数据
面向文档的数据库
MongoDB、CouchDB属于这种类型。它们属于NoSQL数据库，但与key-value存储相异。
不定义表结构
面向文档的数据库具有以下特征：即使不定义表结构，也可以像定义了表结构一样使用。关系型数据库在变更表结构时比较费事，而且为了保持一致性还需修改程序。然而NoSQL数据库则可省去这些麻烦(通常程序都是正确的)，确实是方便快捷。
可以使用复杂的查询条件
跟key-value存储不同的是，面向文档的数据库可以通过复杂的查询条件来获取数据。虽然不具备事务处理和JOIN这些关系型数据库所具有的处理能力，但除此以外的其他处理基本上都能实现。这是非常容易使用的NoSQL数据库。
不需要定义表结构
可以利用复杂的查询条件
面向列的数据库
Cassandra、Hbase、HyperTable属于这种类型。由于近年来数据量出现爆发性增长，这种类型的NoSQL数据库尤其引人注目。
面向行的数据库和面向列的数据库
普通的关系型数据库都是以行为单位来存储数据的，擅长进行以行为单位的读入处理，比如特定条件数据的获取。因此，关系型数据库也被称为面向行的数据库。相反，面向列的数据库是以列为单位来存储数据的，擅长以列为单位读入数据。
高扩展性
面向列的数据库具有高扩展性，即使数据增加也不会降低相应的处理速度(特别是写入速度)，所以它主要应用于需要处理大量数据的情况。另外，利用面向列的数据库的优势，把它作为批处理程序的存储器来对大量数据进行更新也是非常有用的。但由于面向列的数据库跟现行数据库存储的思维方式有很大不同，应用起来十分困难。
高扩展性(特别是写入处理)
应用十分困难
最近，像Twitter和Facebook这样需要对大量数据进行更新和查询的网络服务不断增加，面向列的数据库的优势对其中一些服务是非常有用的，但是由于这与本书所要介绍的内容关系不大，就不进行详细介绍了。
总结：
NoSQL并不是No-SQL，而是指Not Only SQL。
NoSQL的出现是为了弥补SQL数据库因为事务等机制带来的对海量数据、高并发请求的处理的性能上的欠缺。
NoSQL不是为了替代SQL而出现的，它是一种替补方案，而不是解决方案的首选。
绝大多数的NoSQL产品都是基于大内存和高性能随机读写的（比如具有更高性能的固态硬盘阵列），一般的小型企业在选择NoSQL时一定要慎重！不要为了NoSQL而NoSQL，可能会导致花了冤枉钱又耽搁了项目进程。
NoSQL不是万能的，但在大型项目中，你往往需要它！
