摘要：在众多NoSQL数据库的轰炸下，身为数据工作者的你肯定在做是否迁移的考虑。而迁移后所面对的操作方式转换也是重点考虑的之一，Couchbase副总裁MC Brown认为过渡的首要工作就是对数据的重思，并讨论了查询方式的转换。

从关系型数据库转移至NoSQL数据库——比如从MySQL转移到Couchbase，你需要对你的数据进行再思考。至于为什么是Couchbase而不是MongoDB什么的，因为博文的作者MC Brown是现任Couchbase副总裁，所以你懂得；同时这篇Couchbase博文还涉及到迁移后对查询的影响。

以下为译文：

如果你有一个建立在MySQL上的数据库，你可能就会考虑是否需要以及更重要的如何将数据库（和你的应用程序）转移到Couchbase上。最大的绊脚石不在Couchbase建立或者是存储信息方面（尽管他们也很重要），而是数据的重思，你需要使用另一种方式去处理你的数据，然后对应用程序作出相应的变化。

下面将着眼如何把MySQL数据库结构转换成Couchbase Server，并针对两个数据库的查询方式改变进行讨论。

首先：数据结构的重思

MySQL（以及其它的SQL类型并且以表格为基础的数据库）强迫你将数据打造成表格的形式。你所有的数据就是一张表，当你储存复杂结构类型数据时，一个单独的数据片可能拆分成多于一张的表格。对于一些应用程序以及数据类型，如此存储数据是一个完美的逻辑以及合理的途径。而同样对于某些应用程序，使用这样的方法去存储数据并不是很适合。

下面看一个典型的例子，一个recipe（食谱）数据库。因为Cheffy.com是建立在MySQL之上，所以MC Brown对此非常清楚。基础的表格结构是一个核心表，称为recipe，包括了食谱的name、subtitle、description和servings。当然还有一些其它的recipe信息，比如：成分清单（Ingredients）、方法步骤（Method）、元数据（Metadata）以及通过一个独立的recipe ID连接到原recipe表的关键词（Keywords）。你可以在下图中看到这些主要部分：

这个结构有一些潜在的好处，一些特定的操作可以非常简单的完成。举个例子，比如说查询一些包含原料“carrot（胡萝卜）”的recipe（食谱）。你可以从Ingredients表中查找“carrot”，并鉴于这点得到一个匹配的recipe列表。通过使用join你可以获得一个recipe列表，从中获取他们的title以及一些其它的信息，通过搜索Ingredient表，使用join连接两张表中的recipe ID。

当然这种查询方法很简单，可以收集到一个食谱的所有信息。然而当你想给用户演示这个食谱时，将会变得很复杂。你可以通过一个单独的查询来完成，然而有时候通过几个查询来完成这个更容易，分别获取recipe、ingredients、metadata等表格的数据。在应用程序层，通过建立对象就可以自动的完成这些操作，同时这也是此类操作的基础方法。

对于许多用户和应用程序，通常会建立一个特殊的层去做这些事情，或者是选用一个对象映射系统将底层表格式的数据映射成应用程序使用的高等级对象。这里的recipe就是一个例子，在其它各种各样的应用程序中也有类似的存在，包括invoicing （invoice、supplier、 destination, invoice lines) 和 blog posts (post content、keywords、creator、 comments）。

这种基于表格的解决方案本身并没有什么问题，但是在这种场景下，key被跨表格的储存，同样这也意味着需要保持这几个表格的同步。举个例子，当某条记录被删除时会出现什么样的情况？你必须删掉连接到原表上的其它记录（不管是手动删除或者是级联删除）。类似的，当加载一个食谱信息时，你可能需要运行5-10个查询。

Couchbase使用了一个不同的方法。取代将信息分割存入多张表格，在Couchbase中你只需要储存一个单独的结构（JavaScript Object Notation JSON）格式。JSON格式允许很多复杂的数据结构，包括字段、对象和标量类型，可以用它们组成一个完整的记录。这就意味着你可以使用一个“文档（document）”代替之前你使用多个表格来储存实体（recipe，blog post）

现在只需要在一处就可以对整个recipe进行操作，也就是只需要一个操作就可以从Couchbase数据库中获得你想要的信息。

这里对内容没有强制的结构或者是定义，Couchbase数据库中的任何文档都可以储存任何的信息和结构。然而你还可以使用一个验证程序来检查提供给数据库文档的结构，验证可以同时针对字段以及字段的类容。

鉴于这里没有严格的数据结构类型，它可以给存储带来更高的灵活性。举个例子，你不需要额外的操作就可以向recipe文档中添加新的部分“食谱的提供人”。

这里同样没有多重表这个概念，这里只有数据库，数据库中只包含了文档。如果你想让同一个数据库支持各种不同类型的信息，你可以向文档中加入字段。比如你可以如此来定义一个recipe：

那么type就可以作为标记在数据库其它的地方使用，用以识别（选择）你正在加载的数据。

其次：如果什么都是文档，那么你该如何查询

第一节中已经讨论过如何在MySQL上使用一条简单的SQL语句来获得一个原料中包含胡萝卜菜谱的列表。在MySQL中我们通过搜索ingredients表中与carrot匹配的recipe ID值，然后通过join从recipe表中获得recipe title。出于速度考虑，你可能会使用一个索引来提升查询的响应时间，用以保存单独的每一条记录。

在Couchbase所有数据都是文档，并且这里也没有嵌入的方法用以查询表格中的字段，这里既没有字段也没有表格。因为Couchbase中本就没有严格的数据结构模型（同样也没有方法让数据库引擎去确定自由格式文档中的字段），那么我们该如何完成在普通表格上的操作呢

Couchbase支持一个构造称为view，而这个view与MySQL中的view非常神似；除下在Couchbase中，view是唯一从数据库文档中获得列表的方法，而在MySQL中view只是丰富了一个选择。View事实上定义了3件事情：

• View中包含的信息结构。你可以想象成表结构的定义，就像你在MySQL中建立一张表。
• 用以搜索的字段或者是信息。一个view将输出两项结果，key和value。Key将被传入方法以发现你需要搜索什么，更具体的说就是你需要查询的数据库内容。
• 结构和key上的索引。索引同样用于提升搜索的性能。

View使用JavaScript在一个设计文档中进行定义，使用一个文档作为参数的函数。一旦view被构造，数据库中的每个文档都会提供给view，然后view查询并输出你需要的结果。不用担心JavaScript，JavaScript将只在服务器上执行（不会在客户端上执行）。

现在回到MySQL，一个没有where的查询，查询输出选择的字段，并且在输出结果中构造一个匹配行的列表。下面，详解一个SQL语句：

当在MySQL上运行一个查询，MySQL服务器从一张或者多张表中取得信息，然后构建输出结果列表：

在Couchbase中，View从单一的文档中获取记录，并且在处理过程中附带建立一个索引。结果则是view抓取的所有文档列表。

在MySQL中执行一个带where的查询，索引一般被期望帮助你查询需要的记录：

而在Couchbase中，生成的view就是你的表格，当你对view进行查询，Couchbase使用这些键的值（以及生成的相关索引）和过滤后（你指定）的返回信息，生成最终的匹配列表。

总结

上文主要针对MySQL到Couchbase的转变，通过上面的两个步骤基本上可以完成这个过渡。然而一些更高级的操作必然需要一些更多的思考，MC Brown在Couchbase博客同样发布了转换的第二部分，包括了更多高级查询的思考。