本节书摘来自异步社区出版社《解读NoSQL》一书中的第1章，第1.3节，作者： 【美】Dan McCreary（丹•麦克雷） , Ann Kelly（安•凯利），更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.3 NoSQL案例研究
我们的经济正在发生变革，企业想要保持竞争力就必须找到吸引并留住客户的新方法。要做到这一点，就必须得到技术和相关技术人员及时有效的支持。在这个技术前沿时代，解决方案需要运用新的思考方式，即如何实现从传统的思维方式向流程化、技术化的思维方式转变。
以下的案例研究展示了如何用打破陈规的思维方式更快、更经济、更有效地解决问题。表1-2总结了NoSQL解决方案用于解决特定业务问题的5个案例研究。表中展示了问题、业务驱动因素和最终结果。当你查看后面详细案例研究部分的内容时，你会发现这些案例都有一个共同的主题：很多业务问题需要新思路和新技术来提供最佳的解决方案。
1.3.1 案例研究：LiveJournal的Memcache技术
LiveJournal博客系统的工程师们正致力于研究如何运用他们最宝贵的资源——每个Web服务器中的RAM——来运行系统。LiveJournal网站存在一个问题：这个网站太受欢迎了，浏览网站的用户数量也在不断增长。要满足这种不断增长的需求就需要不断增加Web服务器，并且每个服务器都要有自己单独的RAM。
为了提高性能，LiveJournal工程师发现了一些将最常被数据库查询的数据保存在RAM中的方法，避免了在数据库中进行相同SQL查询的昂贵成本。但是查询数据的副本是保存在各自Web服务器的RAM中，所以即使是同一个机架上的服务器也不会知道旁边的服务器已经在RAM中保存了查询数据的副本。
因此，LiveJournal的工程师发明了一个简单的方法来区分每一个SQL查询，那就是为每一个SQL查询设计一个“签名”。每个签名或散列值就代表一个SQL SELECT语句。Web服务器之间只需要发送一个请求，就可以知道其他服务器中是否已经有执行的SQL结果的副本。如果其中一个服务器已有副本，它会将查询结果回传给发出请求的服务器，这样就避免了已经不堪重负的SQL数据库数据往返的昂贵成本。他们将这个新系统称作Memcache，这是因为它管理了RAM中的内存高速缓存。
许多其他软件工程师在以前也遇到过这个问题。大型的共享内存的服务器资源池这个概念其实并不新，不同的是这次LiveJournal的工程师们在这个概念上领先了一步。他们不仅让这些系统运行（并且运行良好）并通过开放资源许可共享了他们的软件，还标准化了Web前端的通信协议（被称为memcached协议）。现在，如果有人想缓解因用户反复查询而导致的数据库超负荷运行的话，前端工具是一个不错的选择。
1.3.2 案例研究：Google的MapReduce——利用商用硬件生成搜索索引
关于NoSQL运动最有影响力的一个案例研究就是Google的MapReduce系统。在本节，Google将和我们分享如何使用廉价的商用CPU将大量的Web数据转换为内容搜索索引。
尽管它们分享的内容是标志性的，但其实映射函数和化简函数的概念并不新。映射函数和化简函数仅仅是数据转换两个阶段的名称而已，如图1-2所示。
图1-2 Map和Reduce函数可以在独立的转换系统中将大数据集划分成小块。关键是要将每个函数隔离，这样就可以将其扩展到多个服务器
转换的初始阶段被称为映射操作（map operation），它们负责数据的提取、转换和过滤。然后将结果送到下一层，即化简函数（reduce function）。化简函数将结果进行排序、整合和汇总，从而得到最终结果。
映射和化简函数背后的核心概念基于坚实的计算机科学工作，那还是在20世纪50年代，麻省理工学院的程序员通过当时比较有影响力的LISP系统实现了这些函数。与其他编程语言不同，LISP重视转化独立列表数据的函数，这是许多在分布式系统下表现出色的函数式编程语言的基础。
Google扩展了映射和化简函数使其能够处理数十亿网页并能在数以千计的低成本商用CPU上可靠运行。利用这两个函数，Google 在海量数据上实现了让映射任务和化简任务经济高效地运行。Google对MapReduce的运用使其他人对函数式编程的威力以及函数式编程系统通过数以千计的低成本CPU进行扩展的能力刮目相看。一些软件包，如Hadoop，很大程度上就是模仿这些函数。
MapReduce的应用启发了来自雅虎和其他组织的工程师们对Google的MapReduce创建了开源版本。它让我们逐渐意识到传统过程编程的局限性并鼓励我们使用函数式编程系统。
1.3.3 案例研究：Google的Bigtable——一个有着数十亿行和百万列的表
当Google发布Bigtable系统白皮书《A Distributed Storage System for Structured Data》的时候也影响了许多软件开发人员。Bigtable 背后的动力是存储用网页爬虫在互联网上收集到的HTML页面、图片、声音、视频和其他媒体的需求。这些数据太过庞大，以至于不太适合用单个关系型数据库进行存储，所以Google建立自己的存储系统。该系统建立的基本目标是可以轻易扩容以应对不断增长的数据存储需求并且不需要在硬件上投入过多。它既不是一个完整的关系型数据库也不是一个文档系统，Google称它为与结构化数据一起工作的“分布式存储系统”。
据说，Bigtable项目非常成功。它通过创建一个大表存储Google开发人员所需的数据从而为他们提供了数据的单一表格视图。此外，这个系统还允许物理硬件位于任何数据中心甚至世界上的任何角落，在这样的环境中，开发人员不需要关心自己所操控的数据所在的物理位置。
1.3.4 案例研究：亚马逊的Dynamo——每天24小时接收订单
Google的工作主要关注如何使分布式的批处理和报表生成更简单，而没有考虑对高度可伸缩的Web店面每天24小时运行需求的支持。在这方面，亚马逊考虑到了。亚马逊发表了另一篇的标志性论文《Amazon's 2007 Dynamo: A Highly Available Key-Value Store》。Dynamo背后的业务驱动是亚马逊需要创建一个高可用的Web店面来支持来自世界各地每天24小时不间断的交易。
在几个不同地点经营的传统实体零售商的优势在于他们的收银机和销售设备只需要在营业时间运行，而在非营业时间可以做日常报告、备份和软件升级。亚马逊的运营模式与之不同，亚马逊的客户来自世界各地，每时每刻都有人在网站上购物。在购买周期内，任何的宕机都可能带来数百万美元的损失，所以亚马逊的系统在服务过程中需要用铁一般的可靠性和可伸缩性来确保零损失。
在Dynamo刚开始应用时，亚马逊使用关系型数据库来支持它的购物车系统和结账系统。他们拥有RDBMS软件的无限许可和充足的咨询预算，允许他们为项目雇用最好的和最精明的顾问。尽管有着充足的预算和权力，但他们最终还是意识到仅靠关系模型无法满足未来的业务需求。
NoSQL社区里面的很多人都把亚马逊的Dynamo白皮书视为NoSQL运动的重要转折点。在关系模型还广泛使用的年代，NoSQL挑战了当时的现状和当时的最佳应用。亚马逊发现，键值存储接口简单，更易于复制数据且更加可靠。最终，亚马逊用键值存储的形式构建了一个可靠的、可扩展的，并且可以支持每天24小时运行的商业模式的一站式服务系统，这使得亚马逊成为世界上最成功的网络零售商之一。
1.3.5 案例研究：MarkLogic
2001年，一群住在旧金山湾区附近富有文档搜索经验的工程师们成立了一家专注于处理海量XML文档的公司。由于XML文档包含标记（markup），所以他们将公司命名为MarkLogic。
MarkLogic定义了两种类型的集群节点：查询和文档节点。查询节点接收查询请求并协调与执行查询相关的所有活动。文档节点包含XML文档，并负责在本地文件系统上执行查询。
查询请求被发送到一个查询节点后，即被分发到每个包含XML文档索引的远端服务器。所有符合要求的文档会被返回至查询节点。当所有文档节点完成响应后，查询结果即被返回。
MarkLogic的架构是将查询任务移动至文档而不是将文档移动至查询服务器，这样的架构对千兆字节的文档具有线性可扩展性。
MarkLogic发现他们在美国联邦政府系统中的产品有一个需求，即TB级的智库信息以及大型出版物需要存储和搜索它们的XML文档。自2001年以来，MarkLogic已经发展成为成熟的、通用的、高度可扩展的文档存储并对ACID事务和细粒度的、基于角色的访问控制提供支持。最初，MarkLogic开发者使用的主要语言是XQuery与REST的组合，新版本支持Java和其他语言的编程接口。
MarkLogic 是一个商业产品，对于任何超过 40 GB 的数据集都需要软件许可。NoSQL 与商用产品和开源产品联系紧密，为业务问题提供了创新的解决方案。
1.3.6 实践
为了展示这些概念在这本书中如何应用，我们将为您介绍Sally的解决方案。Sally在一个有许多业务部门的大型组织中担任解决方案架构师。解决方案架构师帮助存在信息管理问题的业务部门选择最好的解决方案来应对这些信息挑战。Sally致力于解决需要定制开发的应用程序项目，她对于SQL和NoSQL技术有着深入的了解。Sally的工作就是为业务问题寻求最适合的解决方案。
现在让我们通过两个案例来看看Sally是如何应用她的知识的。在第一个案例中，一个需要跟踪硬件采购的设备授权信息的团队来寻求Sally的建议。由于在RDBMS中已经保存了硬件的信息，并且这个团队在SQL方面很有经验，Sally推荐他们扩展RDBMS以包含授权信息并使用连接操作创建报表。在这种情况下，SQL就很合适了。
在第二个示例中，一个负责在关系型数据库中存储数字图片信息的团队找到 Sally。他们遇到的问题是数据库性能正对他们的Web应用页面产生负面影响。在这种情况下，Sally推荐他们将所有图片移至键值对形式的存储系统，用一个URL代表一个图片。键值存储对读密集型应用程序做了优化并能与内容分发网络相协作。当我们把图片管理负载从RDBMS迁出之后，Web应用程序以及其他应用程序的性能都得到了改善。
请注意，Sally没有将她的工作简单地按照非此即彼的方式，即不是RDBMS就是NoSQL的方式进行选择。有时最好的解决方案是兼收并蓄的。
