导言
数据的存储和组织对于应用程序的成功至关重要。自穿孔卡片和自动演奏钢琴时代以来,方法已经得到了发展。关系型数据库 将数据存储在一系列 行 和 列 中,并在连接的 表 之间进行存储,这在过去几十年中一直是压倒性的首选。这些数据库依赖 结构化查询语言 (SQL) 来访问信息并将其结果传达给请求者。
随着应用程序设计的不断发展,新的数据库因其不同的优势而变得越来越受欢迎。在本指南中,我们将介绍一种流行的 NoSQL 数据库类型:面向文档的数据库。我们将讨论它们是什么以及它们的起源、文档 的工作原理、它们的特性以及它们的优点和缺点。
什么是文档数据库?
文档数据库 是一种 NoSQL 数据库类别,它将数据存储为 JSON 和其他数据序列化格式的文档,而不是像 SQL 关系型数据库那样的列和行。它们是键值存储 NoSQL 数据库概念的一个子类。文档数据库因其与现代编程技术的紧密联系而提供了更好的开发者体验。JSON 易于阅读,并且可以转换为当今开发者最常编写的语言。
文档数据库提供了与传统关系型数据库截然不同的结构和体验。关系型数据库将数据存储在单独的程序员定义的表中,一个对象可能会分散在多个表中。这种分离需要使用 连接语句 才能从数据库中获得期望的返回结果。文档模型将对象的所有信息存储在数据库的单个实例中,并且数据库中的每个对象都可能与下一个对象截然不同。从理论上讲,这种能力消除了对 对象关系映射器 (ORM) 的需求,具体取决于用例。
如果您正在使用 MongoDB,请查看 Prisma 的 MongoDB 连接器!您可以使用 Prisma Client 来自信地管理生产 MongoDB 数据库。
要开始使用 MongoDB 和 Prisma,请查看我们的 从头开始入门指南 或如何 添加到现有项目。
文档
如前所述,文档是任何文档数据库的核心。根据文档数据库的不同,文档以 JSON、XML、YAML 或二进制形式(如 BSON)封装和编码数据。
文档模型对开发者具有吸引力的要素之一是它与编程语言中对象的相似性。在使用文档时,结构或缺乏结构会让人感到熟悉。
文档的基本格式如下所示
{field1: value1,field2: value2,field3: value3,...fieldN: valueN}
扩展基本语法,作者集合中的单个文档可能如下所示
{"ID": "001","Books": { 'Grey Bees', 'Death and the Penguin' },"Author": "Andrey Kurkov"}
需要注意的关键是能够在 Books
字段中存储多本书。在关系型数据库中,这是不可能的。需要有一个 Author
表和一个 Book
表,并通过 键 连接。 Book
表中的这个外键很可能类似于 author.id
,其中每个记录都分配给一个作者。我们可以通过以下表格可视化差异
author.id | 姓名 |
---|---|
001 | Andrey Kurkov |
book.title | author.id |
---|---|
灰蜜蜂 | 001 |
死亡与企鹅 | 001 |
了解了文档的结构和功能后,我们可以更进一步,探索文档模型呈现的优点和缺点。
文档模型的优势
文档数据库具有明显的优势和劣势,文档模型是否适合取决于具体的应用程序。文档模型的灵活性、易于扩展性和快速启动的敏捷性是其优点,但也存在相当大的权衡。
灵活性
文档数据库提供了关系型数据库无法比拟的灵活性。文档数据库分别定义每个文档的结构。形式是文档自身定义的特征,而不是记录必须符合的外部结构。这与关系型数据库的刚性相反。
文档模型不会使结构更改像关系型数据库那样昂贵。更改不需要更改所有现有记录以匹配新结构。您可以随时更改要记录的单个记录的数据,延迟或跳过不具有相同结构的其他文档,而无需任何要求。
您的数据库结构可以随着应用程序逻辑的开发而快速发展。这使得更改的负担更小,因为与每次结构更改相关的同步和 迁移 过程更少。数据库系统将允许您要应用的任何新文档结构与所有先前的结构共存。
文档模型提供的灵活性鼓励您存储逻辑的迭代和演变。但是,重要的是要记住,软件本身不太可能像您进行更改时那样为您提供尽可能多的数据保证。假设数据集合的形状没有商定的标准。在这种情况下,作为开发人员,您有责任强制执行一致性并在适当的情况下修改文档,以使您的数据保持良好理解的状态。
可扩展性
文档模型通常允许您避免 垂直扩展,并在应用程序增长时采用更具成本效益的 水平扩展 方法。尽管该领域有所增长,但关系模型在可扩展性方面存在固有的困难。
文档数据库可以避免关系型数据库遇到的许多这些缺点,这归因于其系统构建数据的方式。通过将相关数据共置在单个文档中,可以最大限度地减少不同主机之间的协调。分片 数据集是文档数据库中更常见的策略。这是因为基于文档的操作通常不需要太多协调,因为许多操作都针对单个记录。
由于文档数据库中各个文档和集合之间存在的 约束 和链接较少,因此协调通常更容易,并且操作往往更独立。这使得文档数据库提供商可以将性能和 可用性 放在首位,而关系型数据库则以 一致性 为代价做出让步。
这导致了在数据安全性以及系统处理中断和网络分区能力方面的权衡。显着区别在于,文档数据库在调整一致性级别与性能和可用性方面往往具有更大的灵活性。相比之下,关系型数据库通常要求一致性始终是首要任务。
敏捷性
文档模型的 无模式 功能可以使数据库非常快速地启动并运行。创建文档后,只需要最少的维护,您可以立即开始将对象作为文档插入。
文档数据库提供的敏捷性使其在实施时不必知道数据的确切结构。数据模型可能会发生变化,并且在开发开始时制定明确的计划可能具有挑战性。敏捷性和灵活性的结合使开发人员可以立即启动数据库实例并使用文档集合填充它,并随着应用程序的演变而演变模型。
但是,这种缺乏模式的情况也带来了权衡。数据的 一致性 需要持续管理,而不是从预定义模式的计划中进行管理。预先了解数据的外观和访问模式是有优势的。关系型数据库迫使您考虑这一点。
结论
本文介绍了文档数据库以及它们为何是最受欢迎的 NoSQL 产品之一。我们介绍了文档的结构和功能,以及文档模型的优势及其相关的权衡。
文档数据库提供了一种与关系型数据库不同的组织和访问数据的方法。从仅有传统模型发展到如今,为开发者提供了选择,这令人兴奋。根据您的应用程序,您可以决定哪些特性和优势最符合您的理念和目标。
如果您正在使用 MongoDB,请查看 Prisma 的 MongoDB 连接器!您可以使用 Prisma Client 来自信地管理生产 MongoDB 数据库。
要开始使用 MongoDB 和 Prisma,请查看我们的 从头开始入门指南 或如何 添加到现有项目。