NoSQL的三个“五”

　　四分之一个世纪以来，关系型数据库（RDBMS）一直是主流数据库模型。但是现在非关系型数据库，“云”或者“NoSQL”数据库，正在作为一种替代数据库模型获得越来越多的占有率。我们先关注非关系型NoSQL数据库的10个关键特征：排在前5位的优点和前5位的挑战。

　　NoSQL的五大优点

　　1：弹性扩展

　　多年来，数据库负载需要增加时，数据管理员只能依赖于纵向扩展（scale-up）--买更多更强的服务器，而不是依赖横向扩展（scale-out）--将数据库分布在多台主机上。无论如何，随着交易频率、可用性要求的提高，和数据库向云上和虚拟环境中迁移的需求的提出，基于商业硬件的横向扩展所带来的经济效益已经变得无法拒绝。

　　相对于RDBMS系统不能轻松的在商业集群上进行横向扩展，新生的NoSQL数据设计上就是要能够透明的利用新节点进行扩展。NoSQL数据库的设计通常要考虑利用低成本的商业硬件。

　　2:大数据

　　就像过去二十年中交易率的提高已经超出了人们的想象，被存储的数据的规模也极大的增加了。O'Reilly聪明的称这种现象为“数据的工业革命”。RDBMS系统的能力也在提高去适应这种增长，但就像交易率上的限制一样，单个RDBMS系统实际能管理的数据规模已经无法满足一些企业的需求。今天，NoSQL系统，例如Hadoop，已经能过处理“大数据”级别的数据容量；而这种数据容量远超过最大的RDBMS系统的处理能力。

　　3.告别DBA（再见？）

　　尽管这些年RDBMS供应商声称有很多易管理性上的提高措施，高级RDBMS系统上的维护还是离不开训练有素但昂贵的DBA们。DBA需要紧密的参与高级RDBMS系统的设计、安装和持续的调优。

　　理论上讲，NoSQL数据库通常从最基本的设计就要求更少的管理：自动化修复和数据分布、更简单的数据模型带来更少的管理操作和调优需求。实际上，DBA已死的说法多少有点夸张。总要有人为关键业务数据存储的性能和可用性负责。

　　4:经济性

　　NoSQL数据库通常使用廉价服务器集群去管理迅猛发展的数据和交易容量，而RDBMS倾向依赖昂贵的专业服务器和存储系统。结果就是，NoSQL系统的每千兆字节成本或者每秒的交易成本要很多倍的低于RDBMS系统，这使得你可以非常低的成本去存储和处理更多的数据。

　　5：灵活的数据模型

　　变更管理对于大型RDBMS产品是很头疼的。在RDBMS中，即使是微小的数据模型变更也需要非常小心的处理，而且可能要求系统停机或者降低服务级别。

　　NoSQL数据库的数据模型限制则轻松的多—或者根本就没有。NoSQL的键值存储和文档数据库允许应用在一个数据元素中存储任何结构的数据。即使是相对严格的基于BigTable的NoSQL数据库（Cassandra，HBase）通常也允许没有太多限制的创建新列。

　　结果就是，应用或者数据库模式的改变不需要作为一个复杂的变更单元进行管理。理论上讲，这允许应用可以更快的迭代，当然，很清楚的一点是，如果应用不能保证数据的完整性这可能带来不良的副作用

　　NoSQL5大挑战

　　NoSQL数据库的前景很被看好,但是要应用到主流的企业还有许多困难需要克服。这里是几个首先要解决的问题。

　　1:完备

　　RDBMS系统已经存在很长时间了。而NoSQL的拥护者认为存在时间的增长就是它退化的信号。但是对大多数CIO来说RDBMS是稳定的。多数情况下，RDBMS系统是稳定且多功能的。相比较而言，大多数NoSQL产品的一些关键组件还有待实现。

　　大多数的开发者都渴望生活在科技的前沿，但是企业却必须小心谨慎。

　　2:支持

　　企业要保证，如果一个关键系统崩溃，他们能够得到及时的有支持。所有RDBM提供商都付出很大的力量用以朝代高水平的企业支持。

　　相比之下，大部分NoSQL系统都是开源项目，尽管每一个NoSQL数据库通常都有一家或多家公司提供支持，但这些公司通常是小公司，缺少全球影响力，支持资源和像Oracle，Microsoft，或者IBM一样的信誉。

　　3:数据分析和商业智能

　　为了满足流行的Web2.0应用对可扩展的要求，NoSQL数据库应运而生。因而，它们的功能集都是顷向于为这些应用服务。但是在Web应用增删改查的业务中产生的数据具有商业价值。从这些数据库中挖掘潜在的商业信息提高企业的效率和竞争力以及商业智能（BI）对所有企业来讲都是IT所面昨的关键的问题。

　　NoSQL数据库缺少即席查询和数据分析工具。即便一个简单的查询都需要专业的编程技能，并且传统的BI工具不提供对NoSQL的连接。

　　HIVE和PIG是为解决这个问题而出现的，他们提供了更方便的数据访问方式，可以访问存储在Hadoop集群上的数据甚至其他NoSQL数据库。QuestSoftware已经开发了一个云数据库产品—Toad—可以为多种NoSQL提供即席查询能力。

　　4:管理

　　NoSQL的设计目标可能是零管理方案，对现实离这一目标太远。目前NoSQL的安装和维护都需要掌握技术。

　　5.专业性

　　熟悉关系数据库概念和编程的开发者遍布全球各领域，但是几乎每一个非关系数据库的开发者都仍然处在学习当中。随着时间推移，这种情况当然会被解决，但是就现在而言，找一个关系数据库的开发人员或者是管理人员，显然更加容易

　　相信很多开发者都有个疑问，如果以一种简单、灵活的方法来存储程序数据，应该选择NoSQL还是SQL呢？

　　NoSQL数据库提供了非常完美的体验：一个安装包，启动数据库，使用JSONAPI进行数据读写操作。此外，NoSQL支持快速迭代。

　　SQL方案需要更多的预先投资：配置服务器，插入数据，设定数据表，以对象关系映射系统来进行数据获取。

　　两者对比权衡，创业公司更青睐NoSQL。那么要拥抱NoSQL，需要经历哪些阶段呢？

　　阶段一：排除

　　决定使用NoSQL便意味着你做出了两个重要决定：无需ACID事务和无需一个架构。这看起来是无害的，但是其结果会对程序产生深远影响。

　　排除的第一种形式是你不需要ACID事务。这在应用的早期阶段常见，但是随着用户规模增长，事务处理的逻辑能力将会使你的程序更易于运作。所以完全放弃事务是不可取的。

　　排除的第二种形式是不需要架构。这意味着程序可以有效处理数据间的逻辑，而无需借助传统关系型数据库的关系处理能力。

　　阶段二：愤怒

　　NoSQL数据库的设计目的是在分布式机器集群中取得连续性和可用性的平衡。因此，你不得不使用复杂的分布式算法来进行协调，同步和错误处理。

　　某天当你发现数据丢失而愤怒不已时，将发现事务和架构是多么重要。

　　阶段三：商讨

　　当愤怒消退后，或许你会尝试把事务和架构补充回NoSQL中。首先是为应用程序编写事务管理器。但是交易系统通常很庞杂，模块之间相互依赖，涉及到并发控制，错误恢复和权限访问。你可能会成功，但最终的结果将很难进行扩展或维护。

　　第二个方法是使用复杂组织条件和处理来增强数据整合，确保数据完整性。这些规则嵌入在应用程序逻辑并需要传达给每个使用该数据库的开发团队。

　　阶段四：沮丧

　　当为你找出一个可行的事务处理方案和一个临时的架构处理方案时，你可能发现你的NoSQL不能很好地处理其它需求。它不能联接表，不能对记录进行分组，更不必说复杂的查询。这时你会变得沮丧，试图寻求集群运维专家的帮忙。

　　阶段五：接受

　　看来NoSQL也有其不足之处。最后接受这个事实，你批判性地评估自己的数据库解决方案。你试图区分数据中哪些属于关系型哪些不属于关系型。最终，找出一个使NoSQL和关系型数据库友好共处的方案：扩展关系型满足一部分需求，扩展NoSQL满足另外一部分需求。

　　被媒体广泛宣传的新技术，必须经过个人实践，找出适合自己的部分才是有价值的；否则，拔苗助长，生搬硬套只会徒增烦恼。

　　小编结语：

　　更多内容尽在课课家教育！