尽管关系数据库用于存储数据已经有几十年的历史，而且对很多用例而言，这仍然代表着一类可行的方案，但NoSQL正在成为人们当前的选择，尤其是考虑可伸缩性和性能的时候。本文是对Couchbase的产品管理主管Dipti Borkar的采访，主要谈到了从关系数据库向NoSQL迁移的挑战、收益和过程。
InfoQ：何时才是放弃SQL转而寻求NoSQL解决方案的时机呢？
Dipti Borkar：这个问题可能有些尖锐——事实上，大多数情况下并不是放弃SQL转而寻求NoSQL解决方案，而是为了让应用和用例满足需求的变化，从一种方案转向另一种方案。一般而言，在构建现代Web和移动应用时，不管是伸缩模型还是数据模型，对灵活性都有特定的需求，而这种需求正式从SQL向NoSQL迁移的推动因素。
典型的Web应用程序是采用三层架构构建的。应用程序要向外扩展时，一般是简单地在负载均衡器之后添加更多的商品化Web服务器来支持更多用户。而对于越来越重要的云计算模型而言，向外扩展能力是其核心原则。在云计算模型中，虚拟机实例很容易根据需求进行相应地添加或删除。
然而，当涉及到数据层时，关系数据库（RDBMS）不但无法向外扩展，也没有提供灵活的数据模型，这方面有很多挑战。要处理更多的用户，这意味着要加入一台更为大型的服务器，而大型的服务器复杂度很高，一般是专有的而且非常昂贵，不像基于Web或云的架构中所使用的商品化硬件那样廉价。因此，当公司开始发现现有应用或新应用所用的关系数据库存在性能问题时，特别是这一切与用户数目的增长有关时，他们意识到需要一个更快的、有弹性的数据库层。现在是时候评估NoSQL技术并将其作为交互式Web应用的数据库层了。
InfoQ：在从SQL向NoSQL迁移时，需要哪些主要步骤？
Dipti Borkar：在使用NoSQL数据库时，不同的组织或项目追求的目标是五花八门的。所以很多迁移还是取决于具体的使用情况。下面是迁移时的一些通用指导原则：
#1 理解应用的关键需求：
某些与NoSQL匹配的需求如下：
#2理解NoSQL产品的不同类型：
有一个常见的误区，就是认为所有的NoSQL数据库都是等同的。比如，Cassandra的列存储数据模型可能适用于分析类应用，而图形数据库Neo4j则适用于需要访问实体间关系的应用。
我们会特别关注分布式的、面向文档的NoSQL技术，Couchbase和MongoDB 就是两个最常见的、应用最广泛的例子。
#3 证明理念的可行性
一旦将潜在的选择缩小到数据库层，在集成应用程序的关键特性时，要计划好如何证明相关理念的可行性。可以看一下响应时间、吞吐性能和易扩展能力。
#4 文档建模与开发
对于文档数据库，数据模型会从固定的表格模式转为灵活的文档对象，因此需要在数据建模上花些时间。
#5 分阶段向产品部署
对交互式Web应用程序而言，运行的稳定性是非常重要的。当推出Web应用程序时，应该像对待采用传统关系数据库系统的应用程序一样进行测试和和阶段部署。请确保所选的数据库支持跨集群监控，并且能够方便地在线伸缩以支持按需扩容，还需要支持其他数据库管理工具。
#6 跟上最新的趋势
在美国有很多高质量、免费的实践式NoSQL培训课程。要确保成功实现NoSQL方案，最好是有一支受过培训的开发团队，而且该团队应该了解最新的服务器发型版本和供应商的产品。
下面是几个最大的培训机构的链接：
InfoQ：从SQL向NoSQL迁移时，有哪些主要的困难？
Dipti Borkar：主要困难基本上可以归结为理解传统的关系数据库系统和文档数据库的差异。最重要的区别是数据模型：
如上图所示，关系数据库中的每条记录都要符合某一模式——字段（列）数是固定的，而且每个字段都应该有一个明确的目的和数据类型。每条记录都有一样的模式。多个表之间的数据是规范化的。优点是数据库中的数据很少出现冗余。缺点是模式的改变需要执行一些代价很高的“alter table”语句，因为要避免数据库出现不一致状态，这种操作需要同时锁住很多表。
而使用文档数据库时，每个文档的结构可以与其他文档完全不同。数据库不需要额外管理文档模式的改变。
InfoQ：NoSQL文档数据库有什么优点？
Dipti Borkar：文档数据库的主要优点包括以下几个方面：
InfoQ：如果告诉开发者采用了NoSQL，他们会作何反应？
Dipti Borkar：对于NoSQL技术，开发者会感到非常激动，尤其是因为某些数据库所带来的开发的简洁性。文档数据库有极为灵活的模式，而且易于使用。
因为不需要修改底层数据库的模式，对于应用的变更，开发者可以进行更为快速地迭代。如果开发者构建应用程序时所用的数据为稀疏数据，或者是不断变化的数据，或者是他们无法掌控的来自第三方的数据，文档数据库尤为有用。
InfoQ：与现有的开发人员一起工作并让他们学习新技术，这是否可行？还是需要寻找新的掌握NoSQL技术的开发人员？
Dipti Borkar：应用开发者会发现某些NoSQL技术是非常容易使用的，特别是那些支持JSON文档格式的技术。越来越多的开发者在应用中使用JSON为对象建模。因此，将数据直接以JSON格式保存在数据库中能够减少跨栈的阻抗失配。
严重依赖SQL的开发者可能需要适应并学习文档建模方法。重点是，他们需要反思如何使用文档来对数据进行逻辑组织，而不是将数据规范化为固定的数据库模式。
InfoQ：你是否有过或者听过向NoSQL迁移时的失败案例？如果有的话，错在什么地方？
Dipti Borkar：架构师和开发者应该确保所选的方案或数据库能够满足他们的关键需求。例如，如果所选的数据库更适合于分析类应用，那么这种数据库可能无法满足交互式应用的延迟和吞吐量需求。如果没有研究所有需求就匆忙地做出选择，这样的项目可能会因数据访问的响应时间过长而导致用户体验很差。对于可伸缩性，用户提前应该有所计划。还有一个问题更为严重的例子，在某些情况下，应用规模已经疯长了，但所选的数据库却跟不上这种规模，无法向外扩展。
同时，对于更适合于OLTP风格应用的数据库，如果将其应用于高级数据分析或复杂处理，效果可能也不好。大数据方案估计是更好的选择。
InfoQ：向NoSQL迁移时，有哪些主要的教训？
Dipti Borkar：向NoSQL迁移时，开发者会受益良多。数据模型更为灵活并且不需要僵硬的模式，这就是一个很大的优点。你可能也会看到性能的明显提升以及数据层水平向外扩展的能力。 但是大多数NoSQL产品仍处于产品周期的前期阶段。虽然像复杂连接或多文档事物等功能可以在应用中模拟，但这时开发者使用传统的关系数据库可能更舒服。对某些项目而言，混合方法或许是最好的选择。
查看英文原文： Transitioning from RDBMS to NoSQL. Interview with Couchbase’s Dipti Borkar
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至 [email protected]。也欢迎大家通过新浪微博（ @InfoQ）或者腾讯微博（ @InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。