从关系数据库向 NoSQL 迁移：采访 Couchbase 的产品管理主管 Dipti Borkar

尽管关系数据库用于存储数据已经有几十年的历史，而且对很多用例而言，这仍然代表着一类可行的方案，但 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 匹配的需求如下：

• 快速应用开发
  — 变化的市场需求
  — 变化的数据需求
• 可伸缩性
  – 未知的用户需求
  – 访问、添加和更新数据使吞吐量持续增长而带来的需求
• 一致的性能
  – 低响应时间，以便支持更好地用户体验
  – 高吞吐量，以便处理快速地增长
• 运行可靠性
  – 高可用性，能够优雅地处理失效并尽量减小对应用的影响
  – 内置监控 API，便于运行时维护

#2 理解 NoSQL 产品的不同类型：

有一个常见的误区，就是认为所有的 NoSQL 数据库都是等同的。比如，Cassandra 的列存储数据模型可能适用于分析类应用，而图形数据库 Neo4j 则适用于需要访问实体间关系的应用。

我们会特别关注分布式的、面向文档的 NoSQL 技术，Couchbase 和 MongoDB 就是两个最常见的、应用最广泛的例子。

#3 证明理念的可行性

一旦将潜在的选择缩小到数据库层，在集成应用程序的关键特性时，要计划好如何证明相关理念的可行性。可以看一下响应时间、吞吐性能和易扩展能力。

#4 文档建模与开发

对于文档数据库，数据模型会从固定的表格模式转为灵活的文档对象，因此需要在数据建模上花些时间。

#5 分阶段向产品部署

对交互式 Web 应用程序而言，运行的稳定性是非常重要的。当推出 Web 应用程序时，应该像对待采用传统关系数据库系统的应用程序一样进行测试和和阶段部署。请确保所选的数据库支持跨集群监控，并且能够方便地在线伸缩以支持按需扩容，还需要支持其他数据库管理工具。

#6 跟上最新的趋势

在美国有很多高质量、免费的实践式 NoSQL 培训课程。要确保成功实现 NoSQL 方案，最好是有一支受过培训的开发团队，而且该团队应该了解最新的服务器发型版本和供应商的产品。

下面是几个最大的培训机构的链接：

- CouchConf

- NoSQL Now

InfoQ：从 SQL 向 NoSQL 迁移时，有哪些主要的困难？

Dipti Borkar：主要困难基本上可以归结为理解传统的关系数据库系统和文档数据库的差异。最重要的区别是数据模型：

如上图所示，关系数据库中的每条记录都要符合某一模式——字段（列）数是固定的，而且每个字段都应该有一个明确的目的和数据类型。每条记录都有一样的模式。多个表之间的数据是规范化的。优点是数据库中的数据很少出现冗余。缺点是模式的改变需要执行一些代价很高的“alter table”语句，因为要避免数据库出现不一致状态，这种操作需要同时锁住很多表。

而使用文档数据库时，每个文档的结构可以与其他文档完全不同。数据库不需要额外管理文档模式的改变。

InfoQ：NoSQL 文档数据库有什么优点？

Dipti Borkar：文档数据库的主要优点包括以下几个方面：

• 灵活的数据模型
  数据不需要明确的模式就能插入，而且插入数据的格式可以随时变化——这为应用带来了极大的灵活性，最终会带来实际的业务敏捷性。
• 容易扩展
  有些 NoSQL 数据库不需要应用参与就能自动跨服务器传播数据。通过数据与 I/O 的跨服务器传播，可以在不停掉应用的情况下添加和删除服务器。
• 一致性和高性能
  先进的 NoSQL 数据库技术能够在系统内存中缓存数据，这对开发者和运维团队是完全透明的。

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 产品仍处于产品周期的前期阶段。虽然像复杂连接或多文档事物等功能可以在应用中模拟，但这时开发者使用传统的关系数据库可能更舒服。对某些项目而言，混合方法或许是最好的选择。

关于被采访人

Dipti Borkar是 Couchbase 的产品管理主管，她负责 Couchbase 服务器（一种 NoSQL 数据库）的产品路线图，并与客户和用户一起工作来理解对低延迟、可伸缩数据存储方案的新兴需求。在数据库方面，Dipti 拥有深厚的技术经验，她曾经在 IBM 担任过软件工程师，还曾是 DB2 服务器团队的项目经理，后来在 MarkLogic 担任过高级产品经理。Dipti 从加州大学圣地亚哥分校获得了计算机科学硕士学位，她的主攻方向就是数据库。她还获得了加州大学伯克利分校哈斯商学院的 MBA 学位。****

查看英文原文： Transitioning from RDBMS to NoSQL. Interview with Couchbase’s Dipti Borkar

****- - - - - -

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。****