MongoDB “升级项目” 大型连续剧(4)-- 与开发和架构沟通与扫尾

开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题,有需求都可以加群群内有各大数据库行业大咖,可以解决你的问题。加群请联系 liuaustin3 ,(共2800人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9)(1 2 3 4 5 6 7群均已爆满,开8群约300 9群 100+)

这是升级MongoDB从4.X到6.X的第四集了,这集我们需要聚焦到此次收益的点,在一个项目往后就需要开始讲故事,我们的工作的意义是什么,一个项目如果讲不出 3个故事,那你这个项目干的还真是意义不大。

今天我们就开始讲其中的一个故事,升级版本的意义,优势与差异,这些信息是要提供给开发部门的。

首先迁移中,优化的点

1 在操控MongoDB的中,一些如python ,java ,Node.js早期的驱动中使用了 op_insert协议,这个协议的缺点就是性能差。性能差的根本原因是格式较为冗余,效率底下。

之前MongoDB4.0是兼容这个方式插入数据的,而到了6.0则禁止了这个协议,而强制采用op_msg的方式来进行数据的插入,采用了更集中的BSON编码,减少了信息的大小,简化了协议的教书,同时还支持了事务的压缩等。

升级MongoDB 会强制淘汰这些老的数据驱动协议,倒逼开发升级程序的驱动也MONGODB进行交互,提高数据的操作中的性能。

相同的这里也强制针对 op_delete等操作的协议一并强制下架。

2 升级到 mongodb中的第二个有点 ,在之前的版本中无法利用多线程来对数据查询中的scan进行并行查询,而到了MongoDB 6.0我们可以采用更新的并行的方式来对MongoDB进行并行查询。同时对于聚合阶段的数据处理也可以进行并行操作。如  sort 等,对于更多的CPU,MongoDB可以进行有效的利用。

对于开发来说收益的地方在

1 高频 find() 查询带复杂过滤条件。 2 聚合管道中早期使用  project 过滤数据。

下推优化 :将 match 尽可能下推到存储引擎层,减少内存中处理的文档数量。例如,在分片集群中,$match 可在分片节点提前执行,仅返回匹配结果到协调节点。

索引辅助过滤:若管道中存在  project,MongoDB 会尝试利用索引直接过滤或投影字段,避免全文档读取。

$sort 内存与磁盘管理

增量排序优化:对已部分排序的数据(如通过索引有序返回的文档),$sort 阶段会复用已有顺序,减少内存占用和排序时间。

并行归并排序:对于大数据集,6.0 支持多线程归并排序,利用多核 CPU 加速排序过程。

3 聚合功能上的变化 --- 这里单独开一期说。

4  对于运维方面的优化的点

1 MongoDB 在初始化节点的时候,使用了文件拷贝初始化的模式,提高了新节点加入副本的速度。

5  聚合查询更新省略查询的步骤

在之前4.X要更新数据,必须先查出后,在进行更新,如在MongoDB 4.X撰写的语句如

db.products.find({ price: { $exists: true } }).forEach(function(doc) {
  db.products.updateOne(
    { _id: doc._id },
    { $set: { priceWithTax: doc.price * 1.08 } }
  );
});

可以直接改写为

// 6.0 更新时可以直接用聚合表达式
db.products.updateMany(
  { price: { $exists: true } },
  [{ $set: { priceWithTax: { $multiply: ["$price", 1.08] } } }]
);

在数据删除的中deleteMany的条件表达也更加的丰富。在4.0时无法使用正则和聚合后的数据删除,必须先查询在删除,需要两步。所以在6.0删除数据条件变得更丰富了。

// 删除所有包含嵌套数组中任意元素匹配正则的文档
db.logs.deleteMany({
"metadata.tags": {
    $regex: /^error_/, // 匹配以 error_ 开头的标签
    $options: "i"
  },
"created_at": { $lt: ISODate("2022-01-01") }
});

// 结合聚合表达式删除(需 6.0+)
db.logs.deleteMany({
$expr: {
    $and: [
      { $gte: ["$price", 1000] },
      { $in: ["$status", ["cancelled", "failed"]] }
    ]
  }
});

同时6.0支持在语句中,添加注释,方便复杂的代码进行后期的读取。

// 查询价格大于 100 的商品,并添加注释
db.products.find(
  { 
    price: { $gt: 100 } 
  },
  { 
    $comment: "DEBUG: Find expensive products for sales report" 
  }
);

// 通过 explain 查看注释(输出中会显示 $comment)
db.products.find({ price: { $gt: 100 } }).explain("executionStats");

除此以外,MongoDB在6.0支持时序性的数据,如一些监控或者设备的数据可以写入到MongoDB中处理。如

db.createCollection("sensor_data", {
  timeseries: {
    timeField: "timestamp",
    metaField: "metadata",
    granularity: "seconds"
  }
});
db.sensor_data.createIndex({ timestamp: 1 });

这条命令用于在 MongoDB 中创建一个名为 sensor_data 的时间序列集合。与普通集合不同,时间序列集合针对时间序列数据的存储和查询进行了优化

timeField: "timestamp":  指定文档中哪个字段用于表示时间戳。 metaField: "metadata": 指定文档中哪个字段用于存储与时间序列数据相关的元数据。 granularity: "seconds": 指定时间序列数据的时间粒度。这里设置为 "seconds"

最后我们还可以创建针对MONGODB 时序性的索引,提高处理的速度时间序列索引的优化: 对于时间序列集合,MongoDB 的索引机制会进行特殊优化,以便更高效地处理时间范围查询。当你查询特定时间段的数据时,这个索引能够帮助 MongoDB 快速定位到相关的数据块,而无需扫描整个集合。

db.sensor_data.find({
  "metadata.sensor_id": "sensor_001",
  timestamp: { $gte: ISODate("2023-01-01"), $lt: ISODate("2023-01-02") }
});

查询的时候 "metadata.sensor_id": "sensor_001": 这个条件用于筛选 metadata 文档中 sensor_id 字段值为 "sensor_001" 的数据。这表示我们只想查询来自特定传感器(ID 为 sensor_001)的数据。 timestamp: {  lt: ISODate("2023-01-02") }: 这个条件用于筛选 timestamp 字段在指定时间范围内的数据。

利用 metadata 上的索引(如果存在): 虽然我们只在 timestamp 上创建了索引,但如果你的查询模式经常根据 metadata 中的字段进行筛选,你可能也会在 metadata.sensor_id 上创建索引 (db.sensor_data.createIndex({ "metadata.sensor_id": 1 }))。如果有这个索引,MongoDB 会首先利用它快速定位到与 "sensor_001" 相关的文档。

利用 timestamp 上的时间序列专用索引: 找到符合 sensor_id 条件的文档后,MongoDB 会利用 timestamp 字段上的时间序列索引,高效地筛选出落在 2023-01-01 到 2023-01-02 之间的数据。由于时间序列索引的特殊优化,这个时间范围查询会比在普通集合上进行范围查询更快。

实际上写到这里还有MongoDB6.0中的$setWindowsFields的功能也没有说,后面有机会写吧,到这里把升级的对于开发的好处和影响都说一说,有利于开发和架构推进MongoDB的升级项目。

置顶

      现代数据库的必要组件--数据库代理都能做什么

     和架构师沟通那种“一坨”的系统,推荐只能是OceanBase,Why ?

DBA 怎么变得更强-应对架构师提出高并发问题?

鸿门宴讲PostgreSQL --  被拉去央企救场一天

       美国知名大学开授China数据库理论,你没看错!

       DBA 会架构,实际案例分析--“IT流氓”得下跪

搞 PostgreSQL多才多艺的人--赵渝强 《PG数据库实战派》

追逐太阳的男人--林春 《金融数据库转型实战》

打破DBA局限:像架构师一样思考,提升你的技术价值-- 访蚂蚁金服P9 朱春茂

MongoDB 相关文章

MongoDB  大俗大雅,上来问分片真三俗 -- 4 分什么分

MongoDB 大俗大雅,高端知识讲“庸俗” --3 奇葩数据更新方法

MongoDB 学习建模与设计思路--统计数据更新案例

MongoDB  大俗大雅,高端的知识讲“通俗” -- 2 嵌套和引用

MongoDB  大俗大雅,高端的知识讲“低俗” -- 1 什么叫多模

MongoDB 合作考试报销活动 贴附属,MongoDB基础知识速通

MongoDB 年底活动,免费考试名额 7个公众号获得

MongoDB 使用网上妙招,直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)

MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模

MongoDB  双机热备那篇文章是  “毒”

MongoDB   会丢数据吗?在次补刀MongoDB  双机热备

MONGODB  ---- Austindatabases  历年文章合集

OceanBase 相关文章

OceanBase 单机版可以大批量快速部署吗? YES

OceanBase 6大学习法--OBCA视频学习总结第六章

OceanBase 6大学习法--OBCA视频学习总结第五章--索引与表设计

OceanBase 6大学习法--OBCA视频学习总结第五章--开发与库表设计

OceanBase 6大学习法--OBCA视频学习总结第四章 --数据库安装

OceanBase 6大学习法--OBCA视频学习总结第三章--数据库引擎

OceanBase 架构学习--OB上手视频学习总结第二章 (OBCA)

OceanBase 6大学习法--OB上手视频学习总结第一章

没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛

OceanBase  送祝福活动,礼物和幸运带给您

跟我学OceanBase4.0 --阅读白皮书 (OB分布式优化哪里了提高了速度)

跟我学OceanBase4.0 --阅读白皮书 (4.0优化的核心点是什么)

跟我学OceanBase4.0 --阅读白皮书 (0.5-4.0的架构与之前架构特点)

跟我学OceanBase4.0 --阅读白皮书 (旧的概念害死人呀,更新知识和理念)

聚焦SaaS类企业数据库选型(技术、成本、合规、地缘政治)

OceanBase 学习记录-- 建立MySQL租户,像用MySQL一样使用OB

PolarDB 相关文章

MySQL 和 PostgreSQL 可以一起快速发展,提供更多的功能?

这个MySQL说“云上自建的MySQL”都是”小垃圾“

        PolarDB MySQL 加索引卡主的整体解决方案

“PostgreSQL” 高性能主从强一致读写分离,我行,你没戏!

PostgreSQL 的搅局者问世了,杀过来了!

在被厂商围剿的DBA 求生之路 --我是老油条

POLARDB  添加字段 “卡” 住---这锅Polar不背

PolarDB 版本差异分析--外人不知道的秘密(谁是绵羊,谁是怪兽)

在被厂商围剿的DBA 求生之路 --我是老油条

PolarDB 答题拿-- 飞刀总的书、同款卫衣、T恤,来自杭州的Package(活动结束了)

PolarDB for MySQL 三大核心之一POLARFS 今天扒开它--- 嘛是火

PostgreSQL 相关文章

PostgreSQL  无服务 Neon and Aurora 新技术下的新经济模式 (翻译)

PostgreSQL的"犄角旮旯"的参数捋一捋

PostgreSQL逻辑复制槽功能

PostgreSQL 扫盲贴 常用的监控分析脚本

“PostgreSQL” 高性能主从强一致读写分离,我行,你没戏!

PostgreSQL  添加索引导致崩溃,参数调整需谨慎--文档未必完全覆盖场景

PostgreSQL 的搅局者问世了,杀过来了!

PostgreSQL SQL优化用兵法,优化后提高 140倍速度

PostgreSQL 运维的难与“难”  --上海PG大会主题记录

PostgreSQL 什么都能存,什么都能塞 --- 你能成熟一点吗?

PostgreSQL 迁移用户很简单 ---  我看你的好戏

PostgreSQL 用户胡作非为只能受着 --- 警告他

全世界都在“搞” PostgreSQL ,从Oracle 得到一个“馊主意”开始
PostgreSQL 加索引系统OOM 怨我了--- 不怨你怨谁

PostgreSQL “我怎么就连个数据库都不会建?” --- 你还真不会!

病毒攻击PostgreSQL暴力破解系统,防范加固系统方案(内附分析日志脚本)

PostgreSQL 远程管理越来越简单,6个自动化脚本开胃菜

PostgreSQL 稳定性平台 PG中文社区大会--杭州来去匆匆

PostgreSQL 如何通过工具来分析PG 内存泄露

PostgreSQL  分组查询可以不进行全表扫描吗?速度提高上千倍?

POSTGRESQL --Austindatabaes 历年文章整理

PostgreSQL  查询语句开发写不好是必然,不是PG的锅

PostgreSQL  字符集乌龙导致数据查询排序的问题,与 MySQL 稳定 "PG不稳定"

PostgreSQL  Patroni 3.0 新功能规划 2023年 纽约PG 大会 (音译)

PostgreSQL   玩PG我们是认真的,vacuum 稳定性平台我们有了

PostgreSQL DBA硬扛 垃圾 “开发”,“架构师”,滥用PG 你们滚出 !(附送定期清理连接脚本)

DBA 失职导致 PostgreSQL 日志疯涨

MySQL相关文章

MySQL SQL优化快速定位案例 与 优化思维导图

"DBA 是个der" 吵出MySQL主键问题多种解决方案

MySQL 怎么让自己更高级---从内存表说到了开发方式

MySQL timeout 参数可以让事务不完全回滚

MySQL 让你还用5.7 出事了吧,用着用着5.7崩了

MySQL 的SQL引擎很差吗?由一个同学提出问题引出的实验

用MySql不是MySQL, 不用MySQL都是MySQL 横批 哼哼哈哈啊啊

MYSQL  --Austindatabases 历年文章合集

临时工访谈系列

没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛

ETL 行业也够卷,云化ETL,ETL 软件不过了

SQL SERVER 系列

SQL SERVER维保AI化,从一段小故事开始

SQL SERVER 如何实现UNDO REDO 和PostgreSQL 有近亲关系吗

SQL SERVER 危险中,标题不让发,进入看详情(译)

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值