重新定义数据库历史的时刻

提起 VividCortex 公司的创建者兼 CEO Baron Schwartz ，大家可能会比较陌生，但读过他的著作《高性能 MySQL》的一定大有人在。他同时也做过许多开源软件的性能分析、监控和管理工作。同时他还对许多不同的数据库社区有所贡献，包括 Oracle、PostgreSQL、Redis 和 MongoDB 等。最近他在博客上分享了一些关于数据库的想法。从 2000 年左右 LAMP 组合引起的互联网大潮开始，到后来竞争者的出现，从其现象展示出来的一些关键因素，他谈到了我们可以从中得到的收获，以及对未来的展望。

为什么 LAMP 组合可以获得这么大的成功呢？其实它的每个组成部分都有很多东西可以讲，而且反应了技术架构上的变化，或者说是架构变化的产物。但我觉得其中的 MySQL 则是今天数据库趋势的领头羊。

MySQL 的成功与互联网的繁荣相辅相成，它成功的因素有很多，很难下定论，但很明确的一点就是它“足够好”。MySQL 的巨大成功也造就了后来的 NoSQL 大潮，但随着 NoSQL 的定义由“不要 SQL”慢慢冷却退化成“不只是 SQL”，并且慢慢地都支持了类 SQL 的语言，在这一切发生之后，Baron Schwartz 相信关系型数据库仍将持续发展并长久不衰，但它的统治地位已经被动摇，新兴的技术中必然有些会发展得可以与之平起平坐。他认为现在已经可以看出数据库技术发生了一些历史性的转变。

下一代通用型数据库

关系型数据库和 SQL 使用起来都是比较痛苦的。SQL 并不能非常直观地反映出写 SQL 的人的真实意图。而且在一条 SQL 执行的时候，如果不是一个数据库专家，你并不了解数据库在背后到底做了多少事情，由此会产生多少副作用。而且将 SQL 写到程序代码里时也是非常痛苦的，因为现代编辑器可以在写代码的同时就帮你解决许多编程语言的问题，但对于程序代码中的 SQL 语言块它们却无能为力。在编辑器看来它们就是一个个无意义的字符串，没办法进行编译、语法检查、甚至类型检查等等。一直到程序运行起来，你才能得到一些晦涩的执行返回。

因此 SQL 是有许多方面可以改进的，比如让程序代码和数据库使用相同的语言和工具集；设计一种数据库查询语言，让它与编程语言的工作方法类似；将数据库与程序的内存空间映射起来……等等。当然由此会引入许多新问题，毕竟当初 SQL 被发明出来时就是解决了一批旧问题，又引入了许多新问题。历史总是惊人的相似。

事实上正是这些原因引发了 2009 年左右出现的一代新型数据库，比如 map-reduce 数据库、键值型数据库、Javascript 数据库等。它们都有着各自美好的初衷，在某些领域做得非常出色，也在某些方面饱受诟病。作为新兴数据库技术的密切观察者，Baron Schwartz 曾经非常看好 MongoDB、Redis 和 Riak。现在事实也证明 MongoDB 和 Redis 使用的广泛性。虽然 Schwartz 不敢断言这两种数据库胜出的绝对原因，但肯定有部分原因是在于使用它们时是非常愉悦的：

Redis 的设计理念很简单：为一条数据打上标签，然后就可以用这个标签去获取并操作数据了。数据结构非常丰富，而且数据结构的设计也和程序员们的习惯非常吻合，处理数据的操作正是构建应用程序的基础操作。而且，Redis 非常专注于把这些事情做好，并且不会分心去解决别的问题。

MongoDB 的概念也类似，基本就是数据库应该可以存储嵌套的、结构化的文档，并且可以直接映射为编程语言中使用的数据结构或对象。并且在此之上 MongoDB 还有另外一个强大的工具：可以直接使用应用得非常广泛的 JavaScript 来查询数据库。还有，它内置分布式的特性，因此你的业务程序就不必再考虑分片细节了。

同时代出现的其它 NoSQL 型数据库由于没有用类似思路去解决相似问题，所以在大潮过后，它们也就慢慢退出历史舞台了。比如 Cassandra 解决了分布式问题，但给程序员们的表现手段实在有限，最终成了一个非常高可用却不怎么强大的数据库，因此没有什么吸引力。

Baron Schwartz 认为：

人们将来创造出来的更加现代的数据库必将是非常实用而且好用的。

时间序列数据库

时间序列数据库会把事件带上时间戳保存起来，并将时间戳作为数据模型的一个非常天然而基本的组成部分。它们支持做基于时间的分析，以支持基于时间的查询为第一要务。许多时间序列数据库甚至强制要求任何查询都必须将时间作为一个维度。

Baron Schwartz 曾细致地讨论过时间序列数据库，曾经论证世界就是时间序列，而且分享过他认为的时间序列数据库应该满足的需求（尽管针对需求这一部分，他的有些观点已经发生了改变）。在现有的这个类型的数据库产品中，Schwartz 认为 InfluxDB 最有前途，Elasticsearch 也不错。

InfluxDB 最近的受关注度在急剧上升，因为它在试图定义“一个原生的基于时间的数据库到底是怎样的”，并试图回答作为一个数据库满足这样的特性是否已经足够，以及在有了这样的特性之后，用户还可能希望再添加些什么功能。定义一款数据库的功能边界很难，但现在看起来 InfluxDB 做得相当不错。

ElasticSearch 在某些方面提供了时间序列的功能，但它的核心并不在此。它实际上是一个有时间概念的分布式查询引擎。这样做很自然，人们也会相应的有疑问：如果你准备使用一个有时间的非时间序列数据库，那为什么你不干脆使用一个有时间序列功能的关系型数据库？

Baron Schwartz 认为不管怎样，有一件事情非常确定：

时间序列非常重要，一定会有非常棒的专用的时间序列数据库来满足这个需求。绝对不能只是满足于某种其它类型的数据库声称：“哦，我们也支持那个功能！”

流式数据库

流式数据库，也有人称之为发布 - 订阅型、消息队列、消息中间件等，这些概念都是类似的。这些数据库的核心内容基本就是日志和总线。它们不会永久地存储数据，只是帮你暂时有序地保存数据，以后再读出。这种类型的数据库可以有效地帮你将复杂的企业内部技术架构简化。只要在思想观念上做转变，就会喜欢使用它，而且用上了就会爱不释手。Baron Schwartz 预测到：

在这个领域里也出现了许多产品，比如 Spark。但依我看来，Apache Kafka 是毫无争议的游戏规则改变者。它实在是一项标志性的转折点技术。在这里我不会试着解释为什么，我只是指点你们去了解一下 Kafka 背后的公司——Confluent。去读读与她相关的材料吧。我知道有很多非常棒的人都在那里工作，他们都非常有天份，聪明，这些不是肤浅的市场宣传。你可以从他们的成果中受益非浅。

结论

Baron Schwartz 并不认为 NoSQL 仅仅是昙花一现，尽管的确有很多不怎么样的技术已经销声匿迹了。痛苦和解决方案都是真实存在过的，能否存活下来的决定因素在于一项技术是不是真的适合市场。在将来，传统关系型数据库所未能满足的三个方面将会有蓬勃发展：向后兼容的新型关系型和SQL、时间序列型和流式数据库。让大家一起拭目以待吧！

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。