多模型数据库的故事

在过去八年左右的时间里，数据库世界发生了巨大的变化。 你还记得word数据库相当于关系数据库的时候吗？ 关系数据库统治这个领域已经超过四十年了。 有很好的理由。 它们具有很强的一致性、事务性和表达性，它们是很好的集成工具，等等。

但是四十年是很长的一段时间。 这段时间发生了很多变化，尤其是在科技领域。 今天，我们可以看到关系数据库不能满足当今信息技术世界的所有需求。 有了固定的数据库模式，数据的静态表示和阻抗不匹配只是关系数据库用户面临的一些障碍。 这反过来又为一个全新的数据库分支发展NoSQL数据库提供了空间。

“NoSQL”这个词很漂亮，它最早出现在2009年。 然而，现在社区似乎一致认为它实际上不仅仅代表SQL。 此外，该术语涵盖了广泛的数据库。 为什么会这样？ 由于关系数据库模型并不完全适合每个人的问题，人们开始创建不同的数据库，其模型能够更好地处理他们所面临的障碍。 因此，这些数据库彼此非常不同。

这就是数据库模型如何成为NoSQL数据库和它们运行方式之间的主要区别。 今天，我们可以根据NoSQL数据库的数据库模型来区分几种类型的数据库:

• 键值存储:用单键将数据存储在数组中。

• 列存储:按列顺序在列族中存储数据。

• 图形存储:对具有节点、边和属性的查询使用图形结构来表示和存储数据。

• 文档存储:以自描述结构存储数据，这些自描述结构通常彼此相似，但不必相同(文档)。

这些模型中的每一个都处理不同类型的问题，使得它们对某些解决方案有利，对其他解决方案不利。 例如，文档数据库擅长存储非结构化数据，但不擅长存储关系数据，如图形数据库。 但是模型之间的这种区别也是NoSQL繁荣得以发生的秘密。 用户越来越意识到数据及其本质。 这样，NoSQL数据库世界让我们能够为我们的解决方案选择最佳的数据模型。

然而，如果你在一个大系统上工作，这个系统有许多不同的部分，有许多不同的问题要处理，那该怎么办？ 系统中还有大量不同类型的数据，更重要的是，在系统的不同部分，这些数据的性质是不同的。 应该使用哪个数据库——或者更准确地说，应该使用哪个数据库模型？ 这就是多语种持久性的出现。

这实质上意味着您应该针对单个后端使用多个数据库。 系统的每一部分都将使用最适合其需求的不同数据库。 系统中处理结构化数据的部分将使用关系数据库模型，而处理非结构化、类似对象的数据的部分将使用文档数据库模式，处理分析数据的部分将使用列数据库模型，等等。

当然，这说起来容易做起来难。 至少可以说，确保一个包含多个数据库的项目具有容错性是一项挑战。 除了增加代码复杂性之外，数据一致性和数据重复也成为常见问题。 部署也变得更加复杂和频繁。 此外，这些数据库的同步是一个不容忽视的问题。 例如，如果您想在某个时刻备份数据，这可能是一个问题，因为每个数据库需要不同的备份时间。

因此，多语种持久性是一个必须发展的好主意。 多模型数据库试图解决的正是我们面临的多语种持久性概念的问题。

多模型数据库背后的想法是什么？ 多模型数据库正试图将不同的数据库模型整合到一个整合的引擎中。 这个引擎应该能够使用统一的查询语言，并公开一个能够在所有数据库模型上使用的应用编程接口。 就个人而言，这起初是一颗难以下咽的药丸。 让我们简单解释一下多模型数据库是如何将信息从一个数据模型映射到另一个数据模型的。

主要概念是将所有数据保存在一个数据模型中，然后通过将较高级别的模型映射到较低级别的表示来表示其他模型。 例如，假设我们在多模型数据库中有三个模型:文档、键值和图形。 通过创建单独的顶点集合和单独的边集合，可以在文档数据库模型中映射图形。

文档数据库中的文档通常对每个文档都有唯一的标识符。 这样，它就可以映射到键值存储上，其中键是文档的唯一标识符，值是整个文档的值。 我们也可以看到这些关系数据库是如何映射到键值模型的。 因此，最低级别的表示是键值结构，所有其他模型都可以映射到它。 一旦建立了这一点，就可以很容易地在此基础上创建查询语言。

当然，这些特性需要建立在高性能的多键ACID事务之上，并且在某种程度上它们保留了NoSQL可伸缩性和容错性的优势。 我刚刚描述了完美的数据库吗？ 它让您能够在不牺牲性能或可伸缩性的情况下更改数据模型。 这的确是梦想。

在市场上，已经有各种各样的多模型数据库，如OrientDB、DataStax、Couchbase等等。

多模型数据库允许我们既使用多语种持久性概念的最佳特性，又最小化其局限性。 现在，我们可以创建使用多个数据库模型的复杂系统，并使用一个引擎来实现这一点。 这样，开发、操作和部署的复杂性被最小化。

阅读更多关于卢比克密码的作者。