MongoDB 可调节的一致性,其他数据库都不行系列 (白皮书 翻译)--2

这篇具有很好参考价值的文章主要介绍了MongoDB 可调节的一致性,其他数据库都不行系列 (白皮书 翻译)--2。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题,有需求都可以加群群内有各大数据库行业大咖,CTO,可以解决你的问题。加群请联系 liuaustin3 ,(共2000人左右 1 + 2 + 3 + 4 +5) 新人奖直接分配到5群,另欢迎 OpenGauss 的技术人员加入。

mongodb,数据库,mongodb

这里翻译一篇关于 mongodb 数据一致性的白皮书,这是一份有10页的文档。基于数据一致性的部分内容,在其他的传统数据库,缓存数据库都不存在,也是一个让传统DBA 想不明白的部分,所以进行翻译。

继续第一篇:

在上一篇中我们讨论了写入和读取的concern的级别,下面我们将讨论细节,在本文中,我们将在存储引擎层引用一个事务为wiredTiger事务,为提供高可用性,Mongodb 提供了作为复制集运行数据库的功能,复制集合采用基于 leader的一致性协议,类似raft协议,在一个复制集中存在一个primary和众多的secondary,主节点接受客户的数据写入并将其 插入到oplog的日志,oplog是一个逻辑日志,齐总每个条目包含关于如何应对单个数据库操作的信息,每个条目都有自己的时间戳这些时间戳是有序的,这些时间戳在节点日志中是唯一且完全有序的,oplog条目不包含足够的信息来撤销操作,可以看做一个普通的文档的集合,当不在需要的时候,最老的文档将被删除,文档会被重复利用,循环利用,从节点复制OPLOG并应用,通过这个方式来同步数据,基于这样的方式,其他的从及节点也可以从,secondary 上拉去自己还未得到的oplog,一旦受到就应用,不必以事务的方式来应用。

客户端写入必须发送到主节点,而读取可以发送到主节点或从节点,客户通过驱动程序与复制集进行交互,驱动程序是一个客户端的库,实现了与复制集正确通信兵监控其健康状态的标准规范,在内部,驱动程序通过类似RPC的协议与复制集的节点通信,以BSON格式发送数据,为实现水平扩展MongoDB 还提供了分片功能,允许用户将数据分布在多个复制集中,但本文不会讨论分片的详细信息。

MongoDB中的一致性级别,在MongoDB复制集中,一致性级别通过ReadConcern和writeConcern级别想客户暴露,这两个级别是任何读取或写入操作的参数,要理解和读取和写入关注的语义,需要对MongoDB 复制系统中的操作的生命周期有了解,MongoDB复制系统将进入系统的而每个写入操作串行到oplog中,当操作由副本集的主节点处理时,该操作的效果必须被写入数据库,并且该操作的描述也必须写入oplog,MongoDB中的所有操作都发生在wiredTiger 事务中,当操作的事务提交是,我们称为本地提交,一旦他被写入数据库和oplog中,他可以被复制到从节点,当oplog数据传播到足够多的节点的情况下,我们称之为大多数提交,这意味着它在复制集中是永久持久性。

writeConcern可以被指定为数值,或majority,在任何写入语句中,w:1写操作的客户端将在该写入在服务器的主节点后,立即受到确认,当你将语句中带入 w:N 完成的时候,写操作至少会写入N个服务器后才在本地将事务提交,当你写入 w:majority的时候,写操作客户端在写入操作被大多数提交之前不会受到事务的确认信息。

这意味着,写入将对复制级中任意一组节点的临时或永久性来说是具有弹性的,这也是Mongodb 在事务的一致性上,能做到其他数据库无法达到的弹性。假设你希望你写入的数据在操作系统层面或硬件层面不存在丢失的可能性,则 w:大多数,可以向你的写入的客户端保证数据不丢失。

写关注还可以接受一个布尔值,"j"参数,该参数确定数据在想客户端确认之前是否在复制节点上被日志记录,甚至你可以指定数据必须写到你指定的那个节点上,本文不再详细讨论j 或 tag set选项,指定写入关注客户端操作可能会收到服务器不同类型的相应,这些写入关注相应可分为两类,满足和不满足,满足的写入关注意味着必须以满足必要条件,如在w:2的情况下,客户端会保证已经有两个数据库服务器节点写入了数据后才能反馈写入任务完成,对于不满足的写入关注,这并不一定意味着写入失败,写入只是为达到预期的写入节点数量的需求,稍等写入达到节点的数量要求就会进行反馈。

readConcern 确定从服务器返回的数据的持久性和在某些情况下的一致性,在readConcern级别"local"执行读取操作的时候,返回的数据将反应查询执行在副本集合中的部分节点的局部情况,(这里不是翻译,是我个人的理解,传统DBA可以理解为脏读,但仅仅是类似并不是概念的完全对齐,只是方便快速理解),这里并没有保证返回的数据是大多数提交的,他只反应特定节点所知道的最新的数据情况,存在读取的数据。在他读取任何本地提交的数据,使用readConcern级别"majority"进行读取操作,保证只返回大多数提交的数据,对于大多数读取,返回的数据的是否是最新的并不重要,而是已经确认一定会commit的数据。

同时MongoDB还提供了可线性化的readConcern,当w:majority写操作结合时提供最强的一致性保证,使用readConcern 级别“线性化”进行读取的操作保证返回在读取操作开始前返回的结果如上提出的在大多数Mongodb 已经落盘。在操作中这是自动判断的,在读取的某个瞬间来判断返回的数据是否在大多数节点应用。

MongoDB提供可用和快照读取的级别,支持因果一致性读取的能力,同时MongoDB 本身虽然是文档数据库,但具有MVCC的能力,提供快照隔离,由可用“读取”关注提供的一些特定的细节在本文中,不做讨论。

mongodb,数据库,mongodb文章来源地址https://www.toymoban.com/news/detail-841259.html

到了这里,关于MongoDB 可调节的一致性,其他数据库都不行系列 (白皮书 翻译)--2的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 分布式数据库-事务一致性

    version: v-2023060601 author: 路__ 分布式数据库的“强一致性”应该包含两个方面: serializability(串行) and linearizability(线性一致) ,上述图为“Highly Available Transactions: Virtues and Limitations”论文中对于一致性模型的介绍。图中箭头表示一致性模型之间的关系。对于异步网络上的分

    2024年02月08日
    浏览(37)
  • 缓存和数据库一致性问题分析

    目录 1、数据不一致的原因 1.1 并发操作 1.2 非原子操作 1.3 数据库主从同步延迟 2、数据不一致的解决方案 2.1 并发操作 2.2 非原子操作 2.3 主从同步延迟 2.4 最终方案 3、不同场景下的特殊考虑 3.1 读多写少的场景 3.2 读少写多的场景 导致缓存和数据库数据不一致的原因有三个

    2024年02月14日
    浏览(30)
  • 如何保证ES和数据库的数据一致性?

    在业务中,我们通常需要把数据库中的数据变更同步到ES中,那么如何保证数据库和ES的一致性呢?通常有以下几种做法: 双写 在代码中,对数据库和ES进行双写,并且先操作本地数据库,后操作ES,而且还需要把两个操作放到一个事务中:  在以上逻辑中,如果写数据库成功

    2024年04月28日
    浏览(30)
  • redis实战-缓存数据&解决缓存与数据库数据一致性

    缓存( Cache),就是数据交换的 缓冲区 ,俗称的缓存就是 缓冲区内的数据 ,一般从数据库中获取,存储于本地代码。防止过高的数据访问猛冲系统,导致其操作线程无法及时处理信息而瘫痪,这在实际开发中对企业讲,对产品口碑,用户评价都是致命的;所以企业非常重视缓存技术,

    2024年02月12日
    浏览(38)
  • 怎样保证数据库和redis里的数据一致性

    使用缓存更新策略:在更新数据库时,同时更新Redis中相应的数据。这可以通过编写代码来实现,在数据库更新操作完成后,同步更新Redis中对应的数据。这可以通过在代码中使用事务来保证更新的原子性,确保数据库和Redis中的数据保持一致。 使用消息队列:可以将数据库更

    2024年02月19日
    浏览(32)
  • Redis如何保证缓存和数据库一致性?

    现在我们在面向增删改查开发时,数据库数据量大时或者对响应要求较快,我们就需要用到Redis来拿取数据。 Redis:是一种高性能的内存数据库,它将数据以键值对的形式存储在内存中,具有读写速度快、支持多种数据类型、原子性操作、丰富的特性等优势。 优势: 性能极高

    2024年01月16日
    浏览(52)
  • Redis---数据库和缓存如何保证一致性?

    用「读 + 写」请求的并发的场景来分析: 假如某个用户数据在缓存中不存在,请求 A 读取数据时从数据库中查询到年龄为 20,在未写入缓存中时另一个请求 B 更新数据。它更新数据库中的年龄为 21,并且清空缓存。这时请求 A 把从数据库中读到的年龄为 20 的数据写入到缓存

    2024年01月24日
    浏览(40)
  • 怎么保证缓存与数据库的最终一致性?

    目录 零.读数据的标准操作 一.Cache aside Patten--旁路模式 二.Read/Write Through Pattern--读写穿透 三.Write Back Pattern--写回 四.运用canal监听mysql的binlog实现缓存同步 这里想说的是不管哪种模式读操作都是一样的,这是一种统一的规范: 但写操作和同步策略却有不同。 这个是最常见的

    2024年04月08日
    浏览(29)
  • Redis如何保障缓存与数据库的数据一致性问题?

    目录 一.最经典的数据库加缓存的双写双删模式 二. 高并发场景下的缓存+数据库双写不一致问题分析与解决方案设计 三、上面高并发的场景下,该解决方案要注意的问题 1.1 Cache Aside Pattern概念以及读写逻辑 (1)读的时候,先读缓存,缓存没有的话,那么就读数据库,然后取

    2023年04月21日
    浏览(33)
  • 深入理解数据库事务:确保数据完整性与一致性

    在现代信息系统中,数据是至关重要的资产之一。作为一名后端开发人员,与数据库的交道必不可少,为了确保数据的完整性、一致性和可靠性,数据库引入了事务的概念。本次将带您深入了解数据库事务的重要性、特性以及如何在应用程序中正确地使用事务来维护数据的稳

    2024年02月12日
    浏览(28)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包