首先是文档，然后是基于结构化文档的导航数据库，然后是IMS和CODASYL。大约40年前，第一个关系数据库出现了。在1980年代和90年代的大部分时间里，“数据库”严格来说是一种“关系数据库”——SQL（标准查询语言）占主导地位。后来，随着面向对象的编程语言越来越流行，有人认为解决面向对象语言和关系数据库之间“阻抗不匹配”的方法是在数据库中映射对象。所以我们终于有了“面向对象的数据库”。对象数据库的有趣之处在于，在许多情况下，它们基本上是带有内置对象映射器的普通数据库。这种数据库逐渐失宠，下一个真正主流的尝试是2010年代的“NoSQL”。1、攻击SQLNoSQL攻击关系型数据库和SQL的方法相同。这次的主要问题是Internet颠覆了已有40年历史的关系数据库管理系统(RDBMS)体系结构的基本前提。该数据库旨在节省宝贵的磁盘空间和垂直扩展。然而，现在有太多的用户和太多的任务，胖服务器无法处理。NoSQL数据库声称，如果数据库没有连接、没有标准查询语言（因为实施SQL需要时间）并且没有数据完整性，那么它可以水平扩展以处理许多用户。这解决了扩大规模的问题，但也带来了新的问题。与这些联机事务处理系统(OLTP)并行开发的是另一种关系数据库，称为联机分析处理系统(OLAP)。此类数据库支持关系结构，但执行查询时知道它们将返回大量数据。1980年代和90年代的企业在很大程度上仍然是批量驱动的。此外，OLAP系统为开发人员和分析人员提供了将数据想象和存储为n维数据集的能力。如果您设想基于两个索引的2D数组和查询基本上与常数时间一样高效，但随后在其之上添加另一个维度，以便您可以执行3个或更多因素（如供应、需求和竞争对手数量），您可以更有效地进行分析和预测。然而，构建这些元素是一项费力且高度面向批处理的工作。图形数据库与横向扩展NoSQL大约同时进入市场。许多事情本身并不是“关系”的，或者不是基于集合论和关系代数，而是基于亲子关系或朋友的朋友关系。一个典型的例子就是模型中的产品系列-产品品牌-模型-部分。如果您想知道“我的笔记本电脑上的主板是什么？”，制造商的采购可能很复杂，品牌或型号可能还不够。如果您想知道某个产品系列中使用的所有板，在经典（非CTE，即公用表表达式）SQL中，您必须遍历表并分多个步骤进行查询。最初，大多数图形数据库根本没有分片。事实上，许多类型的图分析可以在不将数据实际存储为图的情况下完成。2.NoSQL做出但未兑现的承诺NoSQL数据库的扩展性确实比Oracle数据库、DB2或SQLServer（它们都是基于40年前的设计）好得多。但是，每个NoSQL数据库都有新的局限性：(1)Key-value存储·没有比db.get(key)更简单的查询了。但是，世界上有很多数据和使用场景无法通过这种方式进行结构化。另外，我们实际上是在谈论缓存策略。在任何数据库中，主键查找都很快。重要的是内存中的数据。理想情况下，它们像哈希图一样缩放。但是，如果您必须访问数据库30次才能将数据放回原处或执行任何类型的复杂查询，这将不起作用。这些系统现在更常作为其他数据库前面的缓存来实现。（例如：Redis。）(2)文档数据库·此类数据库流行的原因是它们使用JSON，并且对象很容易序列化为JSON。此类数据库的第一个版本没有连接，将整个“实体”放入一个巨大的文档中有其自身的缺点。如果没有事务保证，您还会遇到数据完整性问题。今天的一些文档数据库支持不太可靠的事务类型，但它与大多数人习惯的保护级别不同。此外，即使对于简单的查询，此类数据库在延迟方面通常也很慢，尽管它们在吞吐量方面的扩展性更好。（例如：MongoDB和AmazonDocumentDB。）(3)列存储·这种数据库的查询速度与键值存储一样快，并且可以存储更复杂的数据结构。然而，像连接3个表（RDBMS术语）或3个集合（MongoDB术语）这样的事情是一件很痛苦的事情。这种数据库非常适合时间序列数据（给我下午1点到2点之间发生的所有交易）。还有其他更深奥的NoSQL数据库。然而，所有这些数据库的共同点是它们不支持常见的数据库习惯用法，并且倾向于关注“特殊用途”。一些流行的NoSQL数据库（如MongoDB）具有出色的数据库前端和生态系统工具，开发人员可以轻松采用它们，但存储引擎有严重的局限性，更不用说在弹性和可扩展性方面的局限性了。3.数据库标准仍然很重要关系数据库占主导地位的原因之一是它们有一个共同的工具生态系统。首先是SQL。虽然数据库方言可能有所不同——如果您是一名开发人员或分析师，希望从SQLServer6.5升级到Oracle7，您可能必须修复查询并使用“(+)”进行外部联接，但简单实用，复杂很容易转换。其次，您有ODBC和后来的JDBC等。几乎任何可以连接到一个RDBMS的工具（除非它专门设计用于管理该RDBMS）都可以连接到任何其他RDBMS。每天都有很多人连接到RDBMS，将??数据转存到Excel中进行分析。我指的不是Tableau或数百种其他工具，而是“祖父”Excel。NoSQL放弃标准。MongoDB不使用SQL作为主要语言。当MongoDB的主要竞争对手Couchbase正在寻找一种查询语言来取代基于Java的mapreduce框架时，它创建了自己的SQL方言。标准很重要，无论是为了支持工具生态系统，还是因为许多查询数据库的人都不是开发人员——他们知道SQL。4.GraphQL和状态管理的兴起你知道那个总是竖起两个大拇指搭便车的人，希望他的应用程序进入数据库，但不关心如何？事实证明，整整一代开发人员都想这样做。而GraphQL（与图数据库无关）将对象图存储在底层数据存储系统中。这样开发者就不用担心这个问题了。早期的尝试是对象关系映射(ORM)工具，例如Hibernate。他们获取一个对象，并基本上根据对象到表的映射设置将该对象转换为SQL。该工具的许多前几代都难以配置。此外，我们面临着一个学习过程。大多数GraphQL实现都与对象关系映射工具（如Sequelize或TypeORM）兼容。结构良好的GraphQL实现和API不会在整个代码中泄露状态管理问题，而是随着对象图的变化写入和返回相关数据。谁在应用层真正关心数据是如何存储的？面向对象和NoSQL数据库的基础之一是应用程序开发人员需要了解数据在数据库中存储方式的复杂性。当然，这对于开发人员来说很难驾驭更新的技术，但它不再困难，因为GraphQL完全消除了这个问题一篇论文，然后编写了一个名为“Spanner”的实现，描述了全球分布式关系数据库如何工作。Spanner引发了关系数据库技术的新一轮创新浪潮。您实际上可以拥有一个关系数据库，它不仅可以扩展，而且可以在需要时进行全局扩展。我们谈论的是现代意义上的大规模，而不是经常令人失望且日益复杂的RAC/Streams/GoldenGate方法。所以，在关系系统中“存储对象”的前提是错误的。如果关系数据库的主要问题是后端而不是前端怎么办？这就是所谓的“NewSQL”或更恰当地命名为“分布式SQL”数据库背后的想法。这个想法是将NoSQL存储知识和Google的Spanner概念与成熟的开源RDBMS前端（例如PostgreSQL或MySQL/MariaDB）相结合。这意味着什么？这意味着你可以吃蛋糕。这意味着您可以拥有多个节点并向外扩展——包括跨云可用性区域。这意味着您可以拥有多个数据中心或云地理位置-只有一个数据库。这意味着作为用户，您可以拥有真正的可靠性和永不崩溃的数据库集群。同时，整个SQL生态系统还是有用的！您无需重建整个IT基础设施即可做到这一点。虽然您可能害怕“丢弃并替换”传统RDBMS，但大多数企业并不打算使用更多Oracle。最重要的是，您仍然可以在云端和世界各地使用SQL和您的所有工具。
