MySQL到NoSQL：数据的重思和查询方式的转换

来源：51cto

2013/4/7 14:05:18

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

分享到：新浪微博腾讯微博

本文关键字： MySQL NoSQL 数据库

以下为译文：

如果你有一个建立在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)。