NoSQL数据库的爆红给了很多人信心，有些人认为NoSQL将会在不远的未来碾压传统数据库一统江湖，但是也有人认为NoSQL只是昙花一现，传统数据库仍会稳坐霸主宝座，还有人认为NoSQL与SQL最终必将走向融合......众说纷纭，究竟NoSQL与SQL是怎样的一种存在，本文将客观的对比NoSQL与SQL，希望能够对大家正确认识SQL和NoSQL有所帮助。
什么是NoSQL?
简单来说，NoSQL是一个不遵循关系数据库模型的新的数据存储后端，这意味着我们所说的“容器”与传统的基于SQL后端的有区别。
NoSQL技术正在随着需求的变化不断发展，而传统数据库技术已经基本成熟，近几年，应用程序对数据库的要求越发高了，尤其是对大数据、集群和文件存储库，新的高要求对传统数据库提出了挑战，同时也为NoSQL的发展提供了机遇。
NoSQL支持：
应用程序处理大量数据(大数据)；
应用程序快速转换数据关系和数据类型(半结构化，非结构化和多态数据)；
开发人员使用敏捷方法进行团队工作：相比瀑布式和迭代式开发，敏捷开发的周期更短；
应用程序作为服务，可以在网上发布；
应用程序可以交付给成千上万的用户，不只是公司内的少数人；
应用程序的未来负载无需确定：如果需要扩展，基础软件可以再后端集群中轻松完成动态扩展。
市面上有很多NoSQL解决方案的，有开源的也有不开源的，有些NoSQL是专门未解决某些问题而设计的，但是无论NoSQL有多少种，它们都有一个共同的特点那就是是提供更好的可扩展性和性能，为了实现这一目标，NoSQL放弃了RDBMS的一些功能，同时引入了一些新的功能。
NoSQL的实现
SQL DB的一个突破性变化是SQL后端是通用存储系统，而NoSQL专注于特定类型的数据，所以NoSQL数据库在范围上更高效，并且允许具有更高性能的系统，NoSQL也可以与SQL结合使用从而获得更好的性能。
文档型数据库
这种类型的数据库不需要具有一致的数据结构，所以适用于多态数据或数据结构不断变化的场景，它可以将标准化实体(如键值数据集或EAV模型)转换为简单文档集。
目标：存储非类型化数据集
示例：MongoDB，CouchDB
目的：异构数据，面向工作，敏捷开发
图数据库
NoSQL数据库往往会删除关系来实现更好的性能，但是图数据库却正好是相反的，它反而是在加强实体之间的关系。
目标：描述数据关系
示例：Neo4j，GiraffeDB。
目的：数据挖掘
键值存储
这是一种设计用于存储大量键值对数据的数据库。键值数据库适用于那些频繁读写，拥有简单数据模型的应用。
目标：以键值形式存储数据
示例：Redis，Cassandra，MemcacheDB
目的：键值存储
NOSQL的优点
我们都知道NoSQL数据库具有传统RDBMS没有的优势，能够解决RDBMS不能解决的问题。如今NoSQL在很多关键系统中也有很多应用，如在一些大型云系统和SaaS产品。所以现在的问题是企业是否要迁移?迁移之后是否有利可图?我们不能只凭供应商的宣传就做决定，我们需要客观的来看待NoSQL有哪些有优势，适用于哪些场景。
NoSQL数据库是为了弥补传统关系数据库技术的限制而创建的，所以这就意味着NoSQL数据库中会有一些传统RDBMS没有的功能或是对RDBMS的相关功能做了改进。
NoSQL操作便捷，以下方面都很擅长：
大数据：包含大量数据的数据集。
可变数据：数据结构可以是结构化、半结构化和非结构化，NoSQL还可以转换数据类型。
动态开发：在需要敏捷冲刺、快速迭代、频繁代码推送以及总结响应变化的上下文中拥有动态性的数据库是非常有帮助的。
面向对象：易于使用和灵活的编程。
可扩展：可以轻松实现高效、可扩展的架构，这一点虽然传统RDBMS也可以做到，但是它们实现起来难度较高。
开源：大多数解决方案都是开源的，所以没有许可证的费用。
发展进行时
NoSQL数据库提供更好的性能并更具可扩展性，其数据模型更接近应用程序中使用的域模型。如今基于NoSQL数据库的初创公司正在飞速发展，大多数的NoSQL数据库都是开源的，这意味着开发、实施和共享软件的成本较低。
NOSQL的局限
在对NoSQL数据库评估时有一点很值得注意，NoSQL是一个多样的生态系统，所有不是所有的NoSQL产品都有一样的缺点，这一特点虽然对我们总结造成了一定的难度，但是对企业来说却不见得是一件坏事。因为它意味着企业可以对很多不同的NoSQL解决方案进行利弊权衡，从而选择一个就符合自己需求的方案。
安全
安全是每个产品都想要达到的，但是理论上没有绝对的安全，任何一种技术都可能存在安全问题，不只是NoSQL技术，SQL技术也不例外。安全和产品的发展是相辅相成的，安全提升一个档次，产品自然也就会受追捧。一个年轻的产品可能会有许多未知的安全问题，因为还没有足够的时间和经验对其进行测试，很多安全约束都会被忽略。目前，大多是NoSQL平台都是年轻的产品，所以我们建议企业在选择时尽量选择比较成熟的产品或是业内知名供应商提供的产品。
数据一致性
我们刚开始学习数据库时，应该就被告知ACID是传统RDBMS在事务过程中保证数据一致性的最佳选择，但是大多数NoSQL技术都不支持ACID，它们遵循的是最终一致性原则，简单来说就是过程松、结果紧，最终结果必须保证一致性。这样做虽然拥有一定的一致性风险，但是我们获得了一些性能提升。
JOIN
当我们和NoSQL技术人员交谈时，经常会听到NoSQL因为删除了关系，性能得到了大幅的提升。我们承认关系可能会带来性能的下降，但是放弃关系来换取性能一定是值得的吗?不一定吧，就像你爬上背的行囊一样，行囊可能会拖慢你的步伐，但是到达山顶后你能够吃好睡好，在接着走更长的路。
RDBMS使用关系将数据从一个表链接到另一个表，以便将数据保存在单个位置，并且不进行数据复制。Join允许将不同表的数据连接起来进行操作，表之间的连接也是需要额外计算的成本。虽然Join可能会带来一些额外的开销，但是这种开销还是在可以接受的范围内。所以NoSQL声称没有Join功能并不一定是优势，有时，我们只需要删除一些不必要的关系或重组数据也可以得到一些性能的提升。
还有一个问题就是一致性，假设我们有一个类别的嵌套树，许多产品作为树的叶。 在传统RDMS中，更改类别树只需对类别表上的外键进行更新，然后这个更改会自动反映在所有子类别和产品上。而在NoSQL中，我们需要对大量的子元素进行更新。
棘手的交易
如果说我们放弃Join来换取速度，这是我们可以接受的，但是在NoSQL实现中难以保持各种条目一致性就可能会造成严重的后果。当你按顺序执行交易操作时，中间遇到一些问题，很可能会得到不一致的数据，尤其是第一次实现的NoSQL技术。如果应用程序管理事务时出现错误，事务回滚产生的脏数据也是很难处理的。
缺少技术标准
SQL是一种标准语言，即使在大家实现的是不同的数据库技术，只要不是基于ORM层生成的查询，大多数的代码都可以被其他人重新利用，这样就有助于开发人员快速适应不同的数据库解决方案，并且使得迁移更容易。
而NoSQL则恰恰相反，NoSQL每个供应商都有自己特定的语法，没有任何共享的标准，所以更加混乱。这种混乱也意味着不同的NoSQL之间要实现应用程序的迁移会更加困难，因为很难能找到一个精通多种NoSQL技术的程序员。
模式的灵活性可能会是个麻烦
NoSQL系统的一个特性是它们不需要模式，程序员往往是在保存数据结构的那一刻来决定数据结构，所以数据结构的意义体现的就不是很明显，所以你可以利用一些自动化工具轻松的创建一个数据库模型。但是如果发生代码错误，传统RDBMS是结构化的，你要切换一些字段或错误的字段模式，它会有不一致保护，但是NoSQL因为没有定义任何模式，所以没有关于数据的信息保存，往往不知道所有的过程和结构，所以出现错误时很难避免，更为糟糕的是，它可能会给开发人员带来更多的责任和工作量。
此外，所有项目都不是一蹴而就的，而是不断迭代生成的，尤其是有些公司会将部分项目委托给供应商，这时就必须考虑项目结束时要容易切换，所以结构化的数据可能会更容易。另一个问题是团队成员不可能永远开发一个项目，团队成员的工作交换是平常的，但是并不是所有的人都了解数据结构的所有知识。
分析
如果将多个嵌套数据保存在单个文档中，那么很可能会丢失“SUM”，“COUNT”等分析功能，这也许在应用程序的第一次开发过程中不会是一个大的问题，但是之后可能会需要一些数据来做报告，那么应该怎么办呢?数据库在填写完毕之后，数据结构就很难改变了，如果定义好的数据结构发生泄漏，那么就有可能发生不可预测的结果，所以分析是NoSQL的难点。有些NoSQL的商业工具可能会连接到传统数据库的管理分析部分，但这种支持还是有限的。
另外一种解决方法是复制NoSQL数据库中非结构化数据库的某种“关系”，也许会需要创建许多集合和连接对象，如果你按照这种路径进行报告分析的话，那么它的性能可能和SQL差不多，但是如果数据库中需要分析和计数的部分较少，这种方法还是值得一试。
工具匮乏
NoSQL查询语言和语法缺乏标准化可能也反映在工具，大多数的NoSQL平台都是很年轻的，这里所说的查询工具指的是在数据库之间进行数据迁移，管理备份等工作的工具。
NoSQL项目还处在发展阶段，预计工具也会随着项目的发展而成长，相信在不久的未来这个问题就会得以解决。
缺乏标准化也使得第三方供应商难以构建可以支持多种NoSQL解决方案的工具。此外，年轻的平台意味着更少的用户，而用户数量也会对成熟工具的开发造成一定的影响。
性能比较
性能比较最重要的就是在相同的环境和条件下进行比较，如使用相同的硬件和相同的调谐水平。这里我们选择的是在同一台机器上安装了MongoDB和SQLServer Express，使用基于标准框架的C#代码构建了基准，通过这种两种方式来保存数据，为了确保公平，一切都是共享的(实体，逻辑，数据生成)。
我们用来作对比的操作包括：插入、查询、分析和事务。
对单个实体进行批量操作
该测试进行的在相同的对象集合的情况下，哪个数据库能够在更短的时间内进行插入，该测试采用的对象集合逐步增大以检测两个系统的性能缩放。
搜索
该测试的主要目的是检测查询功能，我们将测试分为以下几个部分：
CASE 1使用主键获取一个实体：此模式是使用唯一标识符从db获取单个实体。
CASE 2全扫描：假设你在寻找一个已被删除的元素，数据库必须扫描完所有索引，然后回复“no”。
CASE 3分页查询：通过过滤器和顺序条件进行复杂查询，查询完毕之后只获取一页数据。
我们模拟了各种不同比例的模式的测试，具体情况如下表：
第一次测试我们采用的一个小数据集，包含有250万行数据。
第二次测试我们采用的是一个较大的数据集，包含有500万行数据。
从以上我们可以看出NoSQL不及SQL，但是随着数据量的增加和全扫描比例的减少，NoSQL的性能逐步趋于稳定。
交易
大家都知道大多数NoSQL是不支持事务，很多人也认为放弃交易可能会对性能有所帮助，但是我们可以从中获益多少呢?
分析
export：所有数据树上的Join
report：汇总所有类别中的所有项目
KPI：汇总所有总和
我们采用的是数据集有400万行数据
兴趣点
每一次新技术的兴起必将带来一些革命性的功能，但是首先要打破开发者先入为主的观点，所以有时候问题的爆发反而是成长的契机。
真正的创新要避免自己成为以下两种人：
“激进派”：无条件拥抱变革，随时准备和过去的技术做切割。
“保守派”：痛恨改变，拒绝任何新技术。
在实际的生活中，我们要对新技术保持一个中立清醒的态度，要了解什么样的新技术是可以为我们所用的，在使用新技术之前要对项目进行评估，如果我们对工作一直秉持着批判的态度，那么可能就会有不好的结果。
NoSQL技术也是同样的道理，如果十分了解NoSQL的优劣势，那么我们就可以扬长避短，学习、理解和应用才是进步之法。
NoSQL数据库的应用场景
上文阐述了这么多，相信大家都会明白NoSQL的出现不是为了替代SQL，而是弥补SQL的不足，不同的存储系统有不同的功能，并且在某些特定领域会有自己特殊的功能，数据库的性能好坏大部分取决于项目的特点。
一般企业在有以下需求的时候NoSQL会成为最佳解决方案：
当你的项目在未来可能会需要扩展。
当你的项目需要处理大量数据，或者是在不远的未来需要处理大量数据。
当分析组件在应用程序中的重要性不是很高。
当你的应用程序需要NoSQL数据库相关功能，而RDBMS无法满足时。
在有些情况下，NoSQL可以是一个很好的替代方案，如果你的需求有99%符合NoSQL解决方案，那么肯定非NoSQL莫属，但如果你的需求需要事务、关系或者是其他的标准RDBMS特性，那么你就可以让NoSQL和RDBMS结合使用。
NoSQL的性能有多好?
NoSQL的性能评估要取决于具体的用例，如果我们的使用场景是数据量大，那么NoSQL性能提升很明显，但如果是在小数据集上，并且包含很多查询功能，那么NoSQL的性能可能会有所下降。NoSQL可以很好的在数据库层加速，但是最终用户体验还是有很多因素控制的，如缓存、网络延迟等。假设一个页面使用传统数据库需要500ms，使用NoSQL需要50ms，页面渲染需要200ms，网络数据传输需要1s，所以我们看到它在数据库层性能提升了90%，但对最终用户来说，性能提升只有26%。从这个例子中我们可以看出系统的改进是很复杂的，有些情况下NoSQL是不足以解决性能问题的。
NoSQL系统是否已经成熟应用于生产环境?
如果是从企业需求或者是项目需求的角度来看，我们可以说NoSQL已经成熟了，您可以大胆的使用。但是其实现实中并不是所有的企业都有NoSQL的需求，因为不是所有的项目都需要处理大数据或是需要大规模扩展，即使是大多数的SaaS产品也都是很简单的。据我所知，现在的数据库中很难找到超过10万行的表，所以在这种情况下，传统RDBMS是完全足够应对的。
SQL是否过时?
当我们发明了飞机，那么汽车就过时了吗?当然不是，虽然飞机的速度比汽车快，但它们都是主流的交通工具，拥有不同的应用场景。NoSQL和SQL也是一样，它们只是用两种不同的方式来存储数据，具有不同的特性，需要用户根据实际情况来决定用哪一个。
SQL不适合大数据项目，就像你要去一个岛需要乘坐飞机，而不是开车，而SQL也有自己的优势，就像去超市买牛奶开车就行，不需开飞机。NoSQL不是要取代SQL,它们之间更像是一种互补的关系。
NoSQL市场准备好了吗?
要回答这个问题的关键是开发人员的经验，大多数的数据库程序员都已经习惯了关系型数据库，甚至有的已经在关系型数据库领域工作或培训了较长时间，所以如何在较短的时间内转变思维方式是一个问题。
很多DBA已经在RDBMS掌握了方法技巧，不愿意放弃，重新来学习NoSQL。所以NoSQL的繁荣更多的要把希望寄托在新一代DBA身上。另外，NoSQL工具的短缺也是一个问题，但是随着NoSQL项目的增长，工具不会成为一个永久性的问题。
什么是最佳方案?
这个问题其实很难也很简单，适合自己的就是最佳方案，无需纠结于SQL还是NoSQL.。