CouchDB退出，NoSQL运动开始分崩离析？_第1张图片

CouchOne是知名NoSQL项目CouchDB背后的开发公司（几个月前还叫Couchio呢）。该公司的核心开发人员Mikeal Rogers在官方博客发表文章“Moving Away from NoSQL: Why Size Matters and Small is Better”（走出NoSQL：为什么大小才是关键，小才更好）。明确表示CouchDB项目自己不再认为是NoSQL的一分子，将走自己的路。

文中透露，A NOSQL Summer的创始人Tim Anglade几个星期之前在Palo Alto组织了一次NoSQL讨论会（视频），有来自许多知名NoSQL项目（包括Cassandra, Hadoop, MongoDB等）的代表参加。主题包括回顾NoSQL运动的起源，目前在技术和业务方面的状况以及面临的机遇。作为与会者，Mikeal Rogers感到，在NoSQL这个大帽子下，有不少问题是所有项目都想解决的，但各个项目也都有自己的想法，而NoSQL这个大帽子将问题和挑战中的差异抹杀了。NoSQL甚至已经成为了大规模数据存储的同义词，而这一点是所有与会者都不同意的。而且，传统数据库公司也开始在NoSQL这个时髦词上做文章，开始用这个标签推销自己已经兜售多年的专有数据库产品了。

Rogers指出，必须认识到一个事实：目前的NoSQL项目中只有少数蕴含优秀的技术，将在不可避免的淘汰过程中脱颖而出，与未来出现的其他解决方案一起生存下来。他表示：“对于我们而言，将专注于支持离线数据和应用，让其他人去追逐NoSQL吧。”CouchDB要转而专注于解决云计算的阿基里斯之踵（致命弱点）——在不稳定的互联网连接条件下，用户仍然能够访问自己的数据。CouchDB的操作基于HTTP，而且已经对Android等移动平台已经有很好的支持，的确是一个值得考虑的云存储方案。

ReadWriteWeb的评论文章同意，NoSQL标签虽然让一些项目获得了更多曝光率，但确实也造成了许多误解。作为媒体，RWW依然会继续使用NoSQL这个词，但是如果这个词成为历史，也许并不是坏事。

O'Reilly公司的资深编辑Mike Loukides听到这个消息后，在Twitter上评论（无法直接访问）：“我早就说过NoSQL是个没啥意义的大帽子，CouchDB的人算是想明白了。”

the425Group的Matt Aslett评论：

NoSQL的大旗下囊括了键值、文档、图、列等多种类型的数据存储技术，特性和适用范围都各不相同，这种总称的确屏蔽了彼此之间的差异，造成诸多不便。随着产品和厂商逐渐成熟，各自的关注点都将转向更具体的使用场景，因此NoSQL的分崩离析也就不可避免了。CouchDB不是唯一要走出NoSQL的项目，事实上有些项目已经在开发SQL接口。这标志着成熟而非危机。

Aslett还强调，NoSQL经常与大规模分布式数据处理相提并论，实际上这只是NoSQL数据库的使用场景之一，CouchDB的移动开发环境就很好地体现了该方案基于对等的双向复制的能力。他认为NoSQL数据库会有光明的未来，但是没有必要老争论NoSQL这个词本身。

Rogers的文章最后说：“有时候，宏观思考意味着从小处着眼，可惜NoSQL的定义不符合此道。”的确，CouchDB在服务器端应用的表现上不如MongoDB，和Cassandra、Redis、Tokyo Cabinet、Riak等又差异很大，但它对移动平台的良好支持、为JavaScript Web开发提供的极大便利、本身可以作为Web应用宿主以及作为云计算平台组件的大构想，都非常有特色。与其在一个含混不清的大帽子下被使用者糊里糊涂地比来比去，还不如自己专心把特色做出来。

让我们祝福CouchDB。祝福NoSQL。也许作为一个名词，NoSQL已经完成历史使命，但它曾经发挥的作用却无法抹杀。

【小百科】

NoSQL是一个宽泛的术语，用来指与经典的关系型数据库管理系统在某些方面不同的数据存储技术。它们可以没有固定的表模式，通常不用join操作，可以水平地扩展。比较著名的NoSQL方案有Google的BigTable，Amazon的Dynamo，MongoDB，CouchDB、Cassandra、Redis、Tokyo Cabinet、Riak等，大部分都是开源的。

这个术语1998年由Carlo Strozzi发明，最初用来指不提供SQL接口的轻量关系数据库。他后来指出，如果用来指非关系数据库的话，应该叫NoREL之类。2009年初Last.fm的Johan Oskarsson想组织一个活动讨论开源分布式数据库时，云计算公司Rackspace的工程师Eric Evans又想到了这个术语，从此，NoSQL成为许多新兴的非关系型、分布式数据存储的总称，它们经常不提供关系型数据库的关键特性——ACID（原子性、一致性、隔离性、持久性）保证。