这篇文章将讨论MySQL文档存储最近的一些进展。

MySQL 5.7.12的开始，意味着MySQL可以作为一个真正的文档存储被使用。这是个好消息!

在这篇文章里，我将看下创造历史的MySQL工作能更好地为“NoSQL”的工作量和MySQL文档存储提供了更多的细节。

然而使用可靠的、高性能的MySQL存储引擎存储或通过SQL访问非关系型数据的想法在如今并不新鲜。

先前的努力

MyCached(Memcache协议支持MySQL)在2009年出版。在2010年我们得到了HandlerSocket插件，能够提供更好的性能和更强大的接口。2011年引入MySQL集群(NDB)支持MemcacheD协议和MemcacheD获得 InnoDB 表作为 MySQL 5.6 的一部分。

这些努力是好的，但重点是rear-window视图。他们提供了一个基本的键值接口，但许多开发人员需要的是灵活性的非结构化数据和内在丰富性的结构化数据(如文档存储引擎MongoDB)。

当MySQL团队明白需求后，MySQL 5.7就附带了些优秀的特性，比如JSON文档的支持，在相同应用程序下允许混合结构化和非结构化数据的应用。这种支持包括对JSON字段上的索引，以及从应用程序中对“内部”的文档字段做一个简单的参考。

MariaDB 5.3试图与动态列支持JSON的功能。更多JSON的功能在MariaDB 10.1上有所增加，但这些的实现都不如MySQL 5.7要好。这个计划是为了MariaDB 10.2赶上MySQL 5.7。

JSON在SQL数据库中，仍然是一个正在进行的工作，而且并没有得到官方的标准。现在不同的DBMS实现方式不同，我们还没有看到一个标准的MySQL实现方式。

MySQL作为文件存储

正当我们以为我们会等待MySQL 5.8对未来“NoSQL”有所改进，我们的团队释放MySQL 5.7.12一个新的“X插件”，这个插件允许我们使用MySQL作为文件存储，避免使用SQL。

时间将会告诉我们这个新插件的稳定性和性能是否有进步，但这绝对是在正确方向上所迈出的一步!

不像微软DocumentDB，MySQL团队当时选择不支持MongoDB协议。然而他们的协议，看起来大大激发了MongoDB和其他的文档存储数据库。这种方法有好处和缺点。一方面说，要用你自己的语法和协议允许您支持丰富的内置MySQL功能或处理部分不是MongoDB的协议。另一方面，这也意味着你不能只用MongoDB的应用程序指向MySQL。

在现实中，协议级别的兼容性在这个相对简单的应用程序中通常只结束工作。复杂的应用程序常常依靠not-well-documented副作用或特定的性能属性，需要一些应用程序更改。

MySQL文档存储的伟大之处是，它支持从会话开始交易。对于用户想要使用基于文档的API，但同时也不想放弃安全的数据一致性和ACID事务，这是非常重要的。

新的MySQL 5.7壳提供了一个方便的命令行接口使用文档对象和支持SQL脚本、JavaScript、Python。

这努力的总体结果是开发人员熟悉MySQL，知道谁还需要文档存储功能，将能够继续使用 MySQL 而不在其环境中添加 MongoDB （或一些其他文档存储数据库） 的组合。

毫无疑问， 这是 MySQL 生态系统中的早期努力 ！MongoDB和其他公司已经开始了！他们的API是丰富的，支持更多的产品和框架，更好的文档记录，和更多的理解社区……和通常更成熟。

最大的问题是，何时在MySQL生态系统中MySQL团队能够集中精力基于文档做API的“first-class citizen”?作为一个例子，他们需要确保稳定驱动程序存在多种语言(目前，选择很有限)。

很高兴见到MySQL更进一步，通过其他领域驱动采用NoSQL系统 ，通过最简单的方式实现高可用性和可扩展性。 在2000年代早期，MySQL的复制和人工切分是伟大的，但在如今已经远远落后于现代易用性和动态可扩展性的要求。

想了解更多关于MySQL 5.7 这个激动人心的新发展?加入我们Percona生活！ Jan Kneschke, Alfredo Kojima, Mike Frank 将提供MySQL文档存储的概述以及分享内部实现的更多细节。