一、NoSQL诞生的原因随着互联网的飞速发展，各种类型的应用层出不穷，所以在这个云计算时代，对技术的诉求越来越多，主要体现在以下四个方面：1.低延迟读写速度：快速的应用响应可以大大提高用户满意度；原因：当数据量达到一定规模时，关系型数据库的系统逻辑非常复杂，很容易出现死锁等并发问题，读写速度下降非常严重；2、支持海量数据和流量：对于搜索等大规模应用，需要使用PB级数据，能够处理百万级流量；原因：支持能力有限：现有的关系型解决方案无法像谷歌那样支持海量数据存储3.大规模集群管理：系统管理员希望分布式应用更容易部署和管理；原因：由于存在类似Join这样的多表查询机制，导致数据库难以扩展；4、巨大运营成本的考虑：IT管理者希望硬件成本、软件成本、人工成本能够大幅度降低；原因：企业级数据库license价格惊人，而且随着系统规模不断上涨；为了解决上述几种需求，业界推出了多种新型数据库，并且由于它们在设计上与传统的NoSQL数据库相比有很多优势和较大的差异，所以统称为“NoSQL”系列数据库。总的来说，在设计上，他们非常注重数据的高并发读写和海量数据的存储。与关系型数据库相比，它们在架构和数据模型上做了“减法”，而在扩展性和并发性上做了“加法”。现在主流的NoSQL数据库有BigTable、HBase、Cassandra、SimpleDB、CouchDB、MongoDB、Redis等。2、为什么要用NoSQL数据库？1.NoSQL拥有灵活的数据模型，可以处理非结构化/半结构化大数据现在，我们可以很容易地通过Facebook、D&B等第三方获取和访问数据，比如个人用户信息、地理位置数据、社交图谱、用户-生成的内容、机器日志数据和传感器生成的数据。这些数据的使用正在迅速改变通信、购物、广告、娱乐和关系管理的性质。不使用这些数据的应用程序很快就会被用户遗忘。开发人员希望使用非常灵活的数据库，这些数据库可以轻松容纳新的数据类型，并且不受第三方数据提供商内容结构变化的负担。许多新数据是非结构化或半结构化的，因此开发人员还需要能够有效存储这些数据的数据库。不幸的是，关系数据库使用的严格定义的、基于模式的方法无法快速适应新的数据类型，更不用说非结构化或半结构化数据了。NoSQL提供的数据模型可以很好地满足这种需求。许多应用程序将受益于这种非结构化数据模型，例如CRM、ERP、BPM等，它们可以通过这种灵活性存储数据，而无需修改表或创建更多列。这些数据库也非常适合原型设计或快速应用，因为这种灵活性使得新功能的开发变得非常容易。2、NoSQL容易实现可扩展性（scaleup和scaleup）如果你有很多用户频繁并发使用你的应用程序，那么你需要考虑可扩展的数据库技术而不是传统的RDBMS。对于关系型技术，很多应用开发者会发现动态可伸缩性很难实现，这时就应该考虑转用NoSQL数据库。对于云应用程序，关系数据库最初是普遍的选择。但是在使用过程中遇到了越来越多的问题，因为它们是集中向上扩展的，而不是横向扩展的。这使得它们不适合需要简单和动态可伸缩性的应用程序。NoSQL数据库从一开始就是分布式和水平可扩展的，因此非常适合互联网应用的分布式特点。在三层互联网架构的Web/应用层，向上扩展多年来一直是默认的扩展方式。随着应用的用户数量增加，我们需要增加更多的服务器，性能是通过负载均衡来实现的。此时，成本与用户数量成线性比例。在NoSQL数据库出现之前，扩展数据库层的默认方式是向上扩展。为了支持更多的并发用户和存储更多的数据，你需要越来越好的服务器、更好的CPU、更多的内存和更大的磁盘来维护所有的表。然而，一个好的服务器意味着更复杂、更私密，也更昂贵。这与网络/应用层使用的廉价硬件形成鲜明对比。3、动态模式关系型数据库需要在添加数据前定义模式。例如，如果您需要存储电话号码、姓名、地址、城市和州等客户信息，SQL数据库需要提前知道您要存储什么。这对于敏捷开发模型来说是一场灾难，因为数据库的架构通常需要在每次完成新功能时进行更改。因此，开发时如果想把客户喜欢的商品添加到数据库中，就得把这一列添加到表中，然后只需要将整个数据库迁移到新的schema中即可。4.由于自动分片是结构化的，关系型数据库通常会垂直扩展，单台服务器必须承载整个数据库，以保证数据的可靠性和持续可用性。这样做的代价是非常昂贵，规模有限，并且数据库基础设施成为故障点。这个问题的解决方案是水平扩展，增加服务器而不是增加单个服务器的容量。NoSQL数据库通常支持自动分片，这意味着它们本质上是在应用程序甚至不知道的情况下自动跨多个服务器分发数据。数据和查询负载在多台服务器之间自动平衡，当服务器出现故障时，可以快速透明地更换它。5.复制大多数NoSQL数据库还支持自动复制，这意味着你可以获得高可用性和灾难恢复。从开发人员的角度来看，存储环境本质上是虚拟化的。3、NoSQL的优缺点就优点而言，主要体现在以下三点：扩展简单：典型的例子是Cassandra。由于其架构类似于经典的P2P，因此可以很容易地通过添加新节点来扩展集群；快速读写：主要例子是Redis，由于逻辑简单，纯内存操作，性能非常好，单节点每秒可以处理10万次以上的读写操作；低成本：这是分布式数据库的共同特点，主要是开源软件，没有昂贵的许可证费用；但是，NoSQL数据库仍然存在很多不足，常见的有：不支持SQL：如果不支持SQL行业标准，会给用户带来一定的学习和应用迁移成本；支持的功能不够丰富：现有产品提供的功能比较有限，大部分NoSQL数据库不支持事务，也不支持事务像MSSQLServer和Oracle可以提供各种附加功能，比如BI和报表，ETC。;现有产品不够成熟：大部分产品还处于起步阶段，与关系数据库几十年的完善不一样；以上NoSQL产品的优点缺点都比较普遍。在实际情况下，每个产品都会根据其遵循的数据模型和CAP理念而有所不同。4.适用场景NoSQL数据库正在成为数据库领域的重要力量。如果使用得当，它可以带来很多好处。但是，企业应该非常小心并意识到这些数据库的局限性和问题。NoSQL近两年越来越火，尤其是大型互联网公司对这项技术非常热衷。根据笔者的经验，不是在任何场景下，NoSQL都优于关系型数据库。下面说一下什么时候使用NoSQL：1.数据库表schema变化频繁如果数据量超过百万，增加新的字段会带来额外的开销（重建索引等）。NoSQL应用在这个场景下，可以极大的提高DB的可扩展性，开发者可以更专注于业务层。2.数据库表字段是复杂数据类型对于复杂数据类型，比如SQLSever提供了扩展性支持，比如xml类型的字段。很多用过的同学应该都知道，无论是查询还是更改这个字段，效率都很一般。主要原因是DB层很难为xml字段建立高效的索引，应用层需要做字符流到DOM的解析转换。NoSQL以json形式存储，提供原生生态支持，比传统关系型数据库高效便捷。3、高并发数据库请求这种类型的应用在web2.0网站中很常见。很多应用对数据一致性的要求很低，而关系数据库事务和大表连接已经成为“性能杀手”。在高并发的情况下，sql和no-sql的性能对比，由于环境和角度的不同，一直存在争议。这并不意味着在任何场景下no-sql总是比sql快。有篇文章分享给大家，http://artur.ejsmont.org/blog/content/insert-performance-comparison-of-nosql-vs-sql-servers4。海量数据的分布式存储如果选择海量数据的存储对于大规模的商业数据，比如Oracle，整个方案的成本是非常高的，在软件和硬件上都会花费大量的资金。NoSQL分布式存储，可以部署在廉价的硬件上，是一种非常划算的解决方案。Mongo的自动分片已经应用于生产环境。http://www.mongodb.org/display/DOCS/Sharding并不意味着NoSQL可以解决所有问题。像ERP系统、BI系统，大多数情况下推荐使用传统的关系型数据库。主要原因是这类系统的业务模型复杂，使用NoSQL会增加系统的维护成本。五、选择SQL还是NoSQL以上解释了为什么要使用NoSQL。接下来我们看看如何在我们的项目中引入NoSQL，以及是否要在项目中引入NoSQL。过去，我们只需要学习和使用一种数据库技术就可以完成几乎所有的数据库应用开发。因为成熟稳定的关系型数据库产品并不多，可供大家选择的免费版本就更少了，所以互联网领域基本选择免费的MySQL数据库。在WEB2.0高速发展的时代，我们发现关系型数据库在性能、扩展性、数据的快速备份与恢复、易用性等方面并不总能满足我们的需求。我们越来越倾向于根据业务场景选择合适的数据库，并将多个数据库整合使用。几年前的一篇文章《One Size Fits All - An Idea Whose Time Has Come and Gone》已经阐述了这一点。当我们在讨论是否使用NoSQL的时候，你也需要了解NoSQL有很多种。在NoSQL百花齐放的今天，正确选择NoSQL比选择关系型数据库更具挑战性。NoSQL虽然好用，但是选择起来很麻烦，这也是很多人观望的原因之一。6、NoSQL的分类NoSQL只是一个概念。NoSQL数据库根据数据的存储模型和特点分为多种类型。上面对NoSQL数据库类型的划分并不是绝对的，而是基于存储模型的一种笼统划分。它们之间没有绝对的界限，有重叠。比如TokyoCabinet/Tyrant的Table类型存储可以理解为文档类型存储，而BerkeleyDBXML数据库就是基于BerkeleyDB开发的。7、选型和使用建议虽然2009年出现了比较激进的文章《关系数据库已死》，但是我们心里都知道，关系型数据库还活得好好的，你不能用关系型数据库。但也说明了关系型数据库在处理WEB2.0数据时确实遇到了瓶颈。那么我们应该使用NoSQL还是关系型数据库呢？我认为我们不需要做出绝对的回答。我们需要根据我们的应用场景来决定我们使用什么。如果关系型数据库在你的应用场景中能够很好的工作，并且你非常擅长使用和维护关系型数据库，那么我认为你根本不需要迁移到NoSQL，除非你是一个喜欢折腾的人。如果你身处金融、电信等数据为王的关键领域，目前正在使用Oracle数据库提供高可靠性。除非遇到特别大的瓶颈，否则不要贸然尝试NoSQL。然而，在WEB2.0网站中，大多数关系型数据库都存在瓶颈。开发者在优化磁盘IO和数据库扩展性方面花费了很多精力，比如数据库分片、主从复制、异构复制等。然而，这些任务对技术能力的要求越高，越往上挑战。如果你正在经历这些场合，那么我认为你应该试试NoSQL。1、选择合适的NoSQLNoSQL的种类那么多，NoSQL的种类也有很多种，我们到底应该选择什么样的NoSQL作为我们的存储呢？这不是一个很好回答的问题，影响我们选择的因素有很多，可能会有很多选择。随着业务场景的变化，选择可能会随着需求的变化而变化。我们经常需要考虑以下几种情况：数据结构特点。包括结构化、半结构化、字段是否可能变化、是否有大文本字段、数据字段是否可能变化。写特征。包括insertratio，updateratio，小字段数据是否频繁更新，原子更新要求。查询功能。包括查询条件和查询热点范围。比如用户信息的查询可能是随机的，而新闻的查询是基于时间的，越新越频繁。2、NoSQL与关系数据库的结合其实NoSQL数据库只是在某些方面（性能、扩展）对关系数据库的一种补偿。单从功能上来说，关系型数据库几乎可以满足NoSQL的所有功能，所以选择NoSQL的原因是没有功能。因此，我们一般会结合使用NoSQL和关系型数据库，各取所长。当我们需要使用关系特性时，我们使用关系数据库，当我们需要使用NoSQL特性时，我们使用NoSQL数据库。举个简单的例子，比如用户评论的存储。评论大概有主键id、评论的objectaid、评论的内容、用户uid等字段。我们可以确定的是，wherecontent=''肯定不会在数据库中查询评论内容，而且评论内容也是一个很大的文本域。那么我们可以将主键id、评论对象aid、用户id存入数据库，将评论内容存入NoSQL，这样数据库就节省了存储内容所占用的磁盘空间，从而节省了大量的IO，以及缓存内容更容易。//从MySQL中查询评论主键id列表commentIds=DB.query("SELECTidFROMcommentswhereaid='commentobjectid'LIMIT0,20");//根据主键id列表从NoSQL中取出评论实体数据CommentsList=NoSQL.get(commentIds);NoSQL在一些应用中取代了MySQL，比如一些配置的关系键值映射存储、用户名和密码的存储、session存储等，NoSQL可以完全取代MySQL存储。不仅性能更高，开发起来也更方便。3、NoSQL作为缓存服务器在MySQL+Memcached的架构中，我们处处都要精心设计我们的缓存，包括过期时间设计、缓存实时性设计、缓存内存大小评估、缓存命中率等等。NoSQL数据库通常具有非常高的性能。在大多数场景下，您不必考虑在代码层为NoSQL构建Memcached缓存。NoSQL数据本身在Cache上做了很多优化工作。Memcached等内存缓存服务器缓存的数据大小受内存大小的限制。如果使用NoSQL代替Memcached来缓存数据库，将不再受内存大小的限制。虽然可能会有少量的磁盘IO读写，可能比Memcached慢，但是可以用来缓存数据库查询操作。【本文为《大数据与云计算》专栏作者原创稿件，转载请通过微信?联系授权】点此查看本作者更多好文
