转自：http://www.infoq.com/cn/news/2017/04/redefine-database-history
提起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认为不管怎样，有一件事情非常确定：
时间序列非常重要，一定会有非常棒的专用的时间序列数据库来满足这个需求。绝对不能只是满足于某种其它类型的数据库声称：“哦，我们也支持那个功能！”
xxx