MongoDB 存储普通数据, MySQL 存储重要/敏感数据, 这样设计合理吗?
hzzhzzdogee · 2023-07-14 21:55:54 +08:00 · 3141 次点击这是一个创建于 496 天前的主题，其中的信息可能已经有所发展或是发生改变。
二者存储的数据实际是同一业务的. MongoDB 会存储如用户信息这类数据, MySQL 会存储如金额,充值等数据.
我的问题:
-
这样设计是否合理?
-
这样跨库事务如何做合适呢?
小弟不才, 刚入业界不久, 还望不吝赐教.
 |
1
makelove 2023-07-14 22:11:48 +08:00
为什么不说出于什么理由不都存 mysql?
|
 |
2
hzzhzzdogee OP |
 |
3
roundgis 2023-07-14 22:32:25 +08:00 via Android
全部用 mysql 也沒問題
|
 |
4
me1onsoda 2023-07-14 22:42:29 +08:00  1
@hzzhzzdogee 你凭什么认为“重要/敏感的数据”数据库字段就不会变更？
|
 |
5
XCFOX 2023-07-14 22:44:41 +08:00
MongoDB 有什么不好，为什么不全放 MongoDB ？还望不吝赐教.
|
 |
6
dreasky 2023-07-14 22:56:17 +08:00
建议用 postgres ε=ε=ε=┏(゜ロ゜;)┛
|
 |
8
version 2023-07-14 23:04:59 +08:00 1
技术老大说用啥就用啥.crud 不带变得.没必要抢风头留坑.部门统一风格就好
自己外包自己业余钻研的可以用 mongodb..是真无敌.开发效率是提升 500% |
 |
9
richangfan 2023-07-14 23:40:58 +08:00 3
用 MySQL ，8.0 版本支持 json 类型，嫌慢就上 redis ，mongoDB 没有存在必要
|
 |
10
wangkun025 2023-07-14 23:49:42 +08:00
不合理。
|
 |
11
dream4ever 2023-07-15 00:02:07 +08:00
我觉得自己熟悉哪个用哪个就可以，新入职员工把业务和一个数据库搞熟再说，贪多嚼不烂。
|
 |
12
clf 2023-07-15 00:09:13 +08:00
关联性较多的数据建议存储到 mysql ，或者是 postgres
单文件查询为主，且明确的文件多变，变动结构不存在查询统计需求的，那么存 mongo 也是可以的。 mysql 目前我感觉到的最大优点其实是大部分和数据库有关系的工具都会适配它，尤其在你需要引入 clickhouse 做数据统计甚至不用数据同步。引入一些其他的工具的时候，支持的数据库里基本都有 mysql 。 |
 |
13
zoharSoul 2023-07-15 00:48:02 +08:00
全用 MySQL 就挺好的
|
 |
14
Maboroshii 2023-07-15 01:11:33 +08:00 via Android
听说 mongodb 单表性能上限比较高，不用考虑分表啥的， 自带 shard
|
 |
15
ugpu 2023-07-15 01:19:19 +08:00
没必要 没依据这么做
mongo 对比 mysql： 速度快 拓展缺省的字段强 非关系型 数据随便存取 现在大多数人用这个基本当日志用了. mysql： 对大多数人来说 关系行数据库 方便连表查询. 以及 行锁的出现... 按照你这个需求 和疑问？ 全用 mysql 统一战线. 大不了分库 分表 |
|
16
hzzhzzdogee OP @me1onsoda 那么您的建议是?
|
|
17
hzzhzzdogee OP @XCFOX 不敢赐教. 我是因为对 MongoDB 没有那么熟悉, 只是处于对 Schemaless 的好感
|
|
18
hzzhzzdogee OP @dreasky 合情合理
|
|
19
hzzhzzdogee OP @clf 是的, 我也差不多这个看法. 团队对数据库的了解程度, 以及生态方面, MySQL 还是优势明显.
|
|
20
hzzhzzdogee OP @ugpu 感谢大佬的建议.
|
 |
21
yrj 2023-07-15 01:57:08 +08:00
过度优化是万恶之源，当然如果有足够的理由当我没说
|
 |
22
pindleskin 2023-07-15 02:04:58 +08:00
其实没有特别多要求的话，postgress 可能是好的选择，少一个系统就不少麻烦，没有很多数据量的话，postgress 实际上都能存，当业务有这么多数据量的时候，你也已经不需要来这种地方问了。另外，mongo 按照我的理解是有些坑，schemaless 开始是没问题的，但上线了有业务量不定期可能就会因为各种原因（比如突然的数据增长，比如上线了某个功能去查询了一个有大量数据的表）导致查询没有索引的大表让数据库 100%cpu 后挂掉，这时候你不得不在压力下（因为系统重启后会继续挂掉不可用）看慢查询，然后建索引，这个过程可能需要一两个小时甚至半天，为什么不一开始就设计 schema 建好索引呢，所以我个人是认为能不用 mongo 就不用。
|
 |
23
kkwa56188 2023-07-15 02:39:52 +08:00
确定是 不重要的 可以放 MongoDB, 典型的 例如 用户 对 一件商品的 评价/打分/赞.
其余的, 统统, 包括拿不准的, 一律放 关系数据库 MySQL. |
 |
24
dayeye2006199 2023-07-15 03:05:45 +08:00
什么魔鬼设计？
2023 年了，多看看新版本的 PG 和 mySQL ，需要 schemaless 用 json 字段就行。 话说大部分业务，需要 schemaless 的，可以再想想是自己管理混乱+需求不清，还是真的是个技术问题 |
 |
25
kkocdko 2023-07-15 03:30:58 +08:00
尊重祝福，不作评价。
|
 |
26
zhuangzhuang1988 2023-07-15 08:17:15 +08:00
折腾。
|
 |
27
bthulu 2023-07-15 08:53:28 +08:00
@dayeye2006199 mysql 的 json 列, 貌似不支持纯数组
|
 |
28
jenlors 2023-07-15 09:32:05 +08:00
增加了系统复杂性，如果没有非用不可的理由建议不要用
|
 |
29
winglight2016 2023-07-15 10:20:57 +08:00
离谱的设计和离谱的设计理由。你不管选 mysql 或者 mongodb 都可以实现业务，但是两个一起用到底图个啥呢？考虑过关联查询怎么做了吗？事务处理支持两阶段提交吗？报表能不能跨库查询？
另外，mysql 单表记录数支持有上限，分库分表不支持外键。mongodb 我没有在生产中用过，但是优势在于 nosql ，而不是什么业务数据类型。 |
|
31
hzzhzzdogee OP @pindleskin 感谢指导和建议
|
|
32
hzzhzzdogee OP @winglight2016 好的, 感谢兄弟的建议和指导
|
 |
34
slzcz 2023-07-16 14:16:53 +08:00
主要还是看团队技术选型吧，mongodb 在需求经常调整字段多变的情况下确实很爽。
|
Select Language