MongoDB 软蛋一个,逮谁谁掐一下,咱能硬气点吗?
❝开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题,有需求都可以加群加群请联系 liuaustin3 ,(共3400人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 )(1 2 3 4 5 6 7 8群已经爆满 9群 为纯聊天群,默认不加入不得发广告,自己公众号文章链接等,发一次直接踢,默认加入8群,开10群PolarDB专业学习群115+)
昨天的文章炸了,真是见人品,有些厂商直接给另一个厂商贴标签,(正中我下怀,昨天我小号里面的那个营销策略,你们没学就会了)注意别猜了,和人家没关系,什么 K 什么 KS 我和人家关系好着呢? 不是要猜吗?今天咱们把谜面写出来,你们猜。
正文前还是那句话,人家这个数据库虽然有缺点,虽然昨天我们不太愉快,但是不能否认人家的技术水平,和产品功底,虽然宣传的方式有问题,但是那是通病。
今天就为MongoDB 正名一下,不是什么 都可以随便替代,部分场景兼容替换我们欢迎,就几张collection ,就几个JSON 当然可以换,要大量的,重应用换,我只有俩字,作死。
正文:猜吧
当XXX关系型数据库,通过兼容MongoDB协议的代理层宣称可以兼容文档型业务的时候,许多架构师面临一个特别诱人的选项,通过关系型数据库可以彻底代替MongoDB.
虽然这种通过代替,减少技术栈的思路听起来特别的美好,诱人,但对照MongoDB的核心特性,与优点在替换的时候,我们要有深度的反思。
1 完全的Schema-less,传统数据库替换MongoDB的底层本质上是使用了,MYSQL OR PostgreSQL的 JSON OR JSONB 等存储类型,虽然对JSON的字段的修改,局部的数据更改,是可以完成的,但在底层涉及数据的重新分配仍然与MongoDB 本身的数据写入机制是有区别的,
2 隐式类型转换,与对齐的风险,虽然关系型数据库可以兼容,但对于MongoDB每行的数据同样的KEY可以有不同VALUE的数据类型来说,这对于关系型数据库是致命的打击,这让传统关系型数据库在内部的计算,索引匹配,与统计,容易触发隐式转换的错误,或性能的消耗异常。
3 原生水平扩展与其他扩展方式
虽然MongoDB的分片方式有自己的问题,但是在高版本中成熟的分布式sharding架构与分片健的透明水平扩展还是可以的,而传统数据库中虽然可以达到100TB级别,但节点属于挂载形式,通常我们一般针对兼容MongoDB的方式小批量,非核心项目可以使用,但如果有大量的数据写入,节点依然面临写入瓶颈和传统分布式锁的问题与限制。
4 NoSQL专用引擎与MySQL传统兼容模式的问题
MongoDB WiredTiger引擎专为多写,写入追加优化,内存管理,无锁并发进行了专业的多年的工作,而传统数据库中沉重的日志,与锁机制,尤其针对更小页面的导致的锁冲突,与锁机制要提供更好的计算单元来弥补本身根本的构造问题,同时任何的写入依然要背负数据复制到内存的以及从磁盘再次读取数据的性能损耗。
高并发处理多文档读写,会带来远高于MongoDB的性能损耗。
5 聚合的处理的问题
通过代理层将MongoDB的聚合语法转移成本身的语法,对于简单的查询是非常的方便,但对于MONGODB 深入的使用尤其聚合,管道,深入的嵌套数组等,都无法完善的进行高效的转义和索引的利用。
同时基于MYSQL劣质的优化器,对于复杂JSON嵌套结构的代价估算远不如文档数据库成熟特别容易产生全表扫描等问题。
6 MySQL内存机制的劣根性
MySQL BUFFER POOL 缓存整夜数据,对于大JSON的文档容易导致页分裂和内存的空间的浪费,高并发大JSON通常会占用比MONGODB 更大的内存,最终导致频繁的进行换页操作,导致性能下架,如果在选择更低的磁盘产生,将叠加和放大性能缺损的情况。
建议,架构师和开发人员,针对自己的使用场景进行产品的选择,兼容很好,减少费用很好,但也要分清自己的使用情况,避免自己选的苦果,自己吃的结果。
最后在补充一点,这就和卖电子产品一样,有这个功能不说明你可以玩命的使用,比如强依赖主库读取的情况下,MongoDB是可以针对每条数据来进行数据的写入节点的选择和控制,这点MongoDB的灵活性毋庸置疑。当必要的数据写入可以进行过滤哪些是多节点落地,哪些是单节点逻辑通过本地日志快速落盘,至今没有传统数据库可以做到此功能。
当然传统数据库也有自己的特点和优势,合理的宣传和告知使用者使用范围,还是非常棒的一款DataBase的。
我和OceanBase集中式滚了4个月,其实OB想做的并不只是数据库
我和OceanBase集中式 滚了4个月回顾,MySQL兼容性的惊喜
PostgerSQL 14-17备份的变化 PG17更贴近商业数据库 与 实际命令
PostgreSQL 怎么用好高版本的PG调优--PG14-PG18
同学问 PG17 的备份比老的版本 好哪了? 你给总结总结 !!
算法领主与数据农奴:AI时代的不能说的问题-- 此文为AI临时工所做与公众号作者无关
从亚马逊 AGI 部门裁员看 AI 商业逻辑的必然转向 -- 资本不会给AGI 半点脸
比起简单的Skill技能,我更想建立Agent Skill的系统思维能力--- 感谢本书作者答疑解惑
MongoDB 全文索引 与 展示查询数据的一部分,提高性能
体现价值-我们靠PostgreSQL迁移PolarDB,给公司省下了100万 “巨款”
《告别迁移焦虑:OceanBase MySQL 模式能否兼容 DBA 的“祖传”运维 SQL?》
干数据库不是买白菜:光盯着License几毛钱,看不见300台机器的电费?
一个秘密,不是你 SQL 写对了,是优化器帮“擦了屁股” 客户问迁移后为什么快了--迁移到PolarDB后的故事
AI 引入后,MySQL 列权限控制,插入,更新,读取,删除 --有了AI 真是越帮越忙
PostgreSQL 大表改字段卡死的问题解决了吗? 解决了方案在此
AI 引入DBA 工作,造成工作量增加,忙不过来,根本忙不过来!!!
三无项目导致MongoDB 持续1406% CPU 问题解决