本节书摘来自异步社区出版社《解读NoSQL》一书中的第1章，第1.2节，作者： 【美】Dan McCreary（丹•麦克雷） , Ann Kelly（安•凯利），更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.2 NoSQL的商业驱动
哲学家、科学家Thomas Kuhn提出了“模式转变”（paradigm shift）的概念来描述在科学试验中反复出现的过程，也是这样才有很多创新的思想爆发出来，并以非线性的方式影响了世界。我们将采用Kuhn对于模式转变的定义去思考和解释当今NoSQL运动以及思维模式、架构、涌现的方法的改变。
许多使用基于单CPU的关系型系统的机构都面临着技术的十字路口：机构的需求正在发生变化。企业通过不断采集和分析海量的可变数据获得价值，并基于获得的信息对业务作出快速调整。
图1-1展示了来自于数据容量、流动速度、多样性和敏捷性的需求是如何在NoSQL解决方案的涌现中起关键作用的。正由于这些商业驱动都对单处理器的关系型模型产生压力，它的基础正变得不那么稳定，再也不能满足机构的需求。
图1-1 我们看见了诸如数据容量、处理速度、多样性和敏捷性的商业驱动是如何对单CPU系统产生压力，甚至导致崩溃。数据容量和流动速度涉及处理飞速到达的大型数据集的能力，而多样性则涉及如何将各种不同类型的数据转化为结构化的表，敏捷性则涉及系统如何快速地对业务改变进行响应
1.2.1 容量
毫无疑问，迫使机构关注他们目前的RDBMS的替代品的关键因素是需要通过商用处理器集群查询海量数据。直到2005年左右，对性能的提升还停留在购买更快的处理器。但现在，提高处理器的处理速度并不是一个合适的选择。这是因为随着芯片集成度的提高，当芯片过热时，热量将不再能够及时地消散。这种现象，被称之为“功率墙”（power wall），也正是如此，迫使了系统的设计者将注意力从提高单个芯片的处理速度转移到让更多的芯片协同工作。规模向外扩展（也叫横向扩展）而不是规模向上扩展（更快的处理器）的需求，使机构将数据问题切分成独立的路径并交给独立的处理器去分而治之地工作，也就是从串行执行到并行执行。
1.2.2 速度
尽管海量数据已经成为了一个使用户放弃RDBMS的原因，但是单处理器系统的快速读写能力的瓶颈亦是关键。许多基于单处理器的RDBMS已经不能满足由一些面向公众的网站所发出的实时写入和在线查询的需求。每当新加入一行，RDBMS都会频繁地对该行的许多列新建索引，这个过程会影响系统性能。当RDBMS被作为网上商店的后台，网络拥塞所引发的随机突发事件会使系统对所有人的响应变慢，而且对系统进行调优以满足必须的高速读写吞吐量的代价是非常高的。
1.2.3 敏捷性
基于 RDBMS 构建应用最复杂的部分莫过于数据读取和写入的过程。如果你的数据具有嵌套和重复子组的数据结构，你就需要一个对象关系映射层（ORM）。该层负责根据对数据库的增删改查的操作在关系型数据库持久化层对对象数据进行导出或导入。这个过程并不简单，并且当开发新应用或者修改现有的应用需要快速改变时，该层并不能很好地作出变化。
通常，对象关系映射的工作需要对对象关系映射框架（如Java的Hibernate或者.Net系统的NHibernate）非常熟悉和有经验的工程师。但就算是有经验的工程师，小小的改动也将拖慢开发速度和测试流程。
从上面可以看到，速度、容量、多样性和敏捷性是与NoSQL运动关系最紧密的驱动力。现在你已经熟悉了这些驱动力，你也可以审视一下自己的机构，看看NoSQL的解决方案是否能够对这些驱动力产生积极的影响，从而帮助业务面对当今竞争激烈的市场的需求变化。
