近些年来，NoSQL慢慢成为了主流。许多开发者把这些NoSQL数据库，比如MongoDB、Cassandra、Redis或者Hadoop等，当作他们构建应用的数据库首选，而把老旧的传统数据库废弃不用。

选用NoSQL数据库，经常是建立在其不实或者夸大的宣传，和对传统关系型数据库性能不佳的假定上。开发者在选择数据库时，会特别看重操作成本，以及稳定性和成熟性。更多的不同NoSQL和关系型数据库的局限对比，可以参考Aphyr上Jepsen的一些列文章。

这篇文章会解释给大家为什么我们发现MySQL对于键值存储场景来说，比大多数专有NoSQL引擎还要好。另外，本文也会提供给大家在MySQL中如此应用的参考。

当用户点击一个链接到Wix网站时，他/她的浏览器会发送一个带有网站地址的HTTP请求给Wix的服务器。无论是自定义域名（比如：domain.com）请求一个Wix的优质地址，还是一个在Wix域名下的免费的子域名（比如：user.wix.com/site），这个HTTP请求都会发生。服务器不得不在网站地址中执行键值查询来处理用户对某个地址的请求。我们用路由来表示URL，进行下面的讨论。

路由表用于将站点地址解析为一个站点对象。因为站点可以暴露在多个路由中，所以是多对一的关系。一旦网站被发现，则应用将其加载以备使用。站点对象本身具有复杂的结构，其中包涵两个子列表，列表中的对象表示了站点使用的不同服务。下面是一个对象的模型图，假设使用了标准SQL数据库和归一化模型：

当使用传统的归一化模型更新网站时，我们需要一个事务来更新多表，以确保保持数据一致性（注意，这里的事务使用的是数据库级别的锁来避免并发写，有些时候用来避免在受影响的表中并发读）。继续使用这一模型，我们可能会有每张表的串行键、外键以及在路由表中对于URL列的索引。

然而，这里有几个使用归一化模型带来的问题：

这些问题相当于限制了我们使用MySQL（或者其它任何SQL引擎）时的吞吐量和并发。因为这些短板，外加事实上我们需要的是键值存储，所以许多开发者倾向于使用NoSQL作为解决方案以提供更高的吞吐和更多的并发，甚至是更好的稳定性、一致性和高可用。

在Wix，我们发现，当我们“有创造性的”使用MySQL作为键值存储时，能够提供比上面提到的使用归一化数据模型或者其它大多数NoSQL数据库引擎更好的性能。简单的使用MySQL来作为NoSQL引擎，我们现有的系统，无论是在伸缩性、吞吐量、并发和延迟指数上，相较NoSQL都具有令人惊艳的性能。下面列举一些数据：

值得注意的是，对于绝大多数的键值引擎，无论是开源数据库还是云数据库，1.0毫秒的延迟被认为是相当令人惊讶的水平。然而我们用MySQL就实现了这一壮举（考虑到还使用了基本的SQL引擎）

这是我们实际使用的模型：

任何未被当做查询条件的字段，都被放置在一个单一的blob字段（上面的site_data字段）。其中包含子对象表，和其他表本身的字段。另外注意，我们并未使用串行键，相反的，我们使用了一个varchar(50)的字段，用于存储客户端生成的GUID值——关于这部分，详见下一章节。

下面是我们使用的一个查询，具备高吞吐的同时，还具备了低延迟：

工作原理是这样的，首先使用唯一索引在路由表上执行查询，应该尽的到一条记录。接着使用这条记录的主键，在站点表执行查询，返回的记录也是一条。

嵌套的查询语法可以确保这两个 SQL查询仅在数据库记录中查询一次。

上面的结果显示，平均延迟在1毫秒以下，并且在高流量和高更新率的情况下能保证一致性。虽然没有使用事务，但是update却是半事务的。因为我们在一条插入语句中输入了完整的网站地址，直到进入路由表，这条记录才会被发现。

所以如果我们首先输入了站点网址，然后是路由，我们就能确保有一个一致性的状态，即使是在最边缘的情况下，我们也仅仅是在站点表中有一些“孤儿”数据。

使用从上面例子（或者在Wix的其它案例）中的到的经验，我们简要的列举出了一个使用MySQL当做NoSQL引擎使用的参考。

当使用MySQL当做NoSQL引擎使用时，首先要记住的一点是避免使用数据库级别的锁或者是复杂查询：

当为优化读设计模型时，鞋面是额外的一些经验仅供参考：

当查询时：

我们打算另外写一篇文章来介绍有关实时迁移和应用控制事务的更多内容。

总结

最值得在这篇文章中看到的是如何打破思维尝试不同的思考。使用MySQL来当做NoSQL引擎，看起来是不错的，虽然MySQL最开始并不是为此而设计的。本文中演示的，是一个使用MySQL而不是NoSQL引擎来构建键值访问。在Wix，MySQL是我们的键值存储场景的选择是因为操作简单、使用简单，并且MySQL本身有极好的生态。此外，MySQL还能提供额外的低延迟、高吞吐和数据一致性保证，即使不能超越其它NoSQL引擎，至少也算打个平手吧。