本文是NoSQL三篇技术文章的第二篇。更多请见《你的企业离NoSQL还有多远？》、《NoSQL解决方案为什么需要固态硬盘？》。

像很多新兴技术一样，NoSQL也经历了一段炒作期，很多企业纷纷部署NoSQL数据库，结果往往是喜忧参半。NoSQL技术曾经被炒得沸沸扬扬，技术人员都去接受NoSQL的培训，但短暂的繁荣后，NoSQL复归平寂。这不能怪任何人。供应商宣称自己的解决方案能解决所有问题，开发者则兴致盎然地讲数据库扩展性有多重要。

组织自身，以为解决数据库难题的方法终于来到了。而现在，第一代NoSQL数据库已经发展到高潮，解决方案也已经成熟，是时候总结一下过去十年里的教训了。本文总了企业使用NoSQL时常犯的三点错误，以及如何规避这些错误。

NoSQL，不只是可扩展

Seven Databases in Seven Weeks一书的作者Eric Redmond认为，人们往往错误的认为NoSQL就是web扩展。要真这样以为可就贻笑大方了。

虽然非关系型数据库产生于谷歌和亚马逊这种希望解决web环境中大规模扩展问题的公司，而文档型数据库Mongo的名字也来源于英文单词humongous（巨大无比的），暗示数据和业务量巨大。但是，如果只从扩展性角度考量NoSQL，只能一叶障目。其实，哪怕是很小的公司，它们基本只需要处理宜用图表表现的社交媒体数据，也能从NoSQL解决方案中获益。而有些要处理海量数据的大公司，可能仍然依赖SQL成熟的查询系统。数据库的选择不只是数据扩展性那么简单，更要从应用案例和非功能性需求来考量。

建议：冷静思考，把业务需求和现实条件放在首位。一味复制谷歌的架构不会让你成为下一个谷歌。

开发者合格吗？

Making Sense of NoSQL的作者Ann Kelly和Dan McCreary指出了另一个问题。最近，有一项高调宣传的web工程，由于集成团队能力太差而终告失败。书中记录到，“公司买进了一个耐用、强大又成熟的NoSQL数据库MarkLogic，但是他们雇了一个只懂Java编程和关系型数据库的集成人员。他们花了三四千万美元进行编码，但这完全没必要，最终也只能白白丢掉。”文中提到这个网站就是声名狼藉的奥巴马医保。

Dan认为，这样的NoSQL问题的出现已经不是第一次了，也不会是最后一次。只要开发团队没有在非关系型数据库编写代码的经验，组织就可能重蹈覆辙。对于习惯了旧有流程的开发者来说，使用新技术时重复开发的现象很常见。在文档存储的流线型环境里已经完全没有必要再用UML和Java精心设计代码了。

建议：在文档型数据库中，文档直接映射到对象，代码精简、重点突出。如果代码激增，就需要检查工具、方法和技术团队了，从而找出问题所在。

分布式仍然是难啃的骨头

Eric Redmond认为，无论是在实施还是后续管理阶段，知识和经验都是无可替代的。“其实当谈到规模巨大，数据库本身并不是问题，问题在于实际操作过程中，如何进行管理。你可以安装Couch，在一台机器上运行一系列查询。但如果你把任务分布到多个机器上，这就变成了一个分布式系统，完全变成另外一个东西了。这对于系统管理员和操作员的要求都极高。一条查询或许能在本地机器上快速运行，但未必能能在上百台机器上横向扩展，两者没有实质性的联系。

Redmond表示，好在一些NoSQL数据库的设计帮助开发者避免了这种困境。Couch就是一个例子，它假定用户会对很多服务器进行查询，所以自动使用了MapReduce。很多人指责Riak的易用性，Redmond认为，Riak之所以难以使用，主要是因为在分布式环境里写查询很困难。

建议：选择符合最佳实践的NoSQL数据库。另外，键值存储是最简单的实现简易扩展的方法之一。