2021 年了 newsql or mysql 分库分表 ?

2021-05-04 11:41:14 +08:00
 wz497345846
2616 次点击
所在节点    数据库
19 条回复
dzdh
2021-05-04 13:07:26 +08:00
保守型:分库分表+中间件,有问题好查好解决。
激进型:NewSQL 搞起,可以接受非常极端情况下业务可能中断然后等社区给解决方案(中间你可能想要个传统 RDBMS 做热备临时顶上)
dzdh
2021-05-04 13:08:45 +08:00
有些小业务就用的 Single-Node Cockroachdb :doge:
wz497345846
2021-05-04 14:10:05 +08:00
@dzdh 非常极端情况下业务可能中断:会是什么原因呢?
dzdh
2021-05-04 16:04:58 +08:00
@wz497345846 比如某个特性不了解造成服务异常服务起不来啊、XXX 冲突啊啥的。总之就是不够了解。 :doge:
ch2
2021-05-04 16:06:42 +08:00
@wz497345846 #3 你选的技术没有经过同行大规模的踩坑,开源社区并不负责 7*24 小时给你解决 issue,遇到 bug 挂了你就只能干瞪眼求他们来修
gBurnX
2021-05-04 18:12:58 +08:00
1.MySQL 的特点是,开发与管理的工作效率低,其性能对于硬件与环境的投资来说性价比也非常一般,但优势是:
稳定 + 排错简单 + 全网有大量案例可循。

当你的团队里,没有花钱招聘昂贵的大牛,并且专注于业务开发时,建议选 Mysql 会更稳一些。

2.NewSQL,特别是 MongoDB 这种,特点正好相反。开发与管理工作效率高,承载硬件的性价比高。
但劣势是,刚出来不久,稳定性欠佳。团队里需要招聘高工资的大牛,天天研究这玩意,不然容易出事。

3.当你提出这个问题时,我建议你用 Mysql 。除非你自己有调试 MongoDB 源码与排错的能力,有对于大型在线系统进行实时备份与快速恢复的能力,不然不建议你上 NewSQL 。

以上拿 MongoDB 只是举个例子。
iyaozhen
2021-05-04 21:49:08 +08:00
@gBurnX 虽然你是拿 MongoDB 举例子,但 MongoDB 应该不是 NewSQL 吧

NewSQL 你公司没 DBA 团队就不要玩了,问题多多,当然解决了也很牛逼。具体还得看场景,1 亿行以下的数据量用 MySQL 完全没问题,又简单、又稳定、还便宜
gBurnX
2021-05-04 23:15:49 +08:00
@iyaozhen

MySQL 稳定、便宜,但不简单啊。比如面对复杂的数据结构,那种多层嵌套的数据结构,用 Mysql,得分解为很多张表,而且要保证数据正确性,在 CURD 时还要各种检查嵌套关系。

MongoDB 呢?直接丢进去就行了,开发效率不是一个级别的。
April5
2021-05-04 23:21:52 +08:00
@gBurnX noSQL 和 newSQL .....
gBurnX
2021-05-04 23:33:06 +08:00
@April5 谢谢提醒,我提 MongoDB ( nosql )只是纯粹举个例子。
ericsyh
2021-05-05 14:12:19 +08:00
我感觉有 2 个比较主要的参考维度:
1. 数据增量速度
分库分表和 newsql 都能解决数据库扩展的问题,但分库分表的数据扩展运维复杂而且对业务有一定程度的侵入性并不是太友好,相反 newsql 数据都是自动分片的增加新节点后自动进行数据重分布。如果数据处于快速增长阶段而且比较难预测的话,用 newsql 会对 DBA 来说要舒服一点。
2. 性能稳定性
由于 newsql 普遍使用 2PC 做事务模型,性能稳定上不如分库分表。如果业务上对请求稳定性要求比较高的话,newsql 测下来可能不算太理想,而分库分表表现相比而言更加稳定。
iyaozhen
2021-05-05 17:51:01 +08:00
@gBurnX 这里说的是 newsql 不是 nosql,你举的例子不对
目前 newsql 虽然底层还是 kv 存储,但对业务层来说还是有表的概念,协议上还是兼容 sql

“比如面对复杂的数据结构,那种多层嵌套的数据结构” 你这个业务如此复杂,用 nosql 不见得能解决什么问题,nosql 和 sql 的问题也讨论很多年了,但事实上很少见全面 nosql 的,MySQL+redis ( cache )的组合还是主流
gBurnX
2021-05-05 18:07:21 +08:00
@iyaozhen
“用 nosql 不见得能解决什么问题”
===============
能解决开发效率问题,在前面已经说了:开发效率不是一个级别的
iyaozhen
2021-05-05 18:50:26 +08:00
@gBurnX 我的意思是全面 nosql 的很少,场景复杂的很多问题解决不了,问题(需求)都解决不了,谈何效率。

其实吧,稍大型项目开发效率啥的不是第一位。(这也是 java 稳坐头把交椅的原因)

sql 和 nosql 是互补的,但 newsql 按目前发展是为了取代传统 sql
gBurnX
2021-05-05 22:47:39 +08:00
@iyaozhen sql 全面的就多了?场景复杂的很多问题就能都解决?很多场景开发效率就是刚需,开发效率都解决不了,谈何需求?

考虑问题要全面,你自己说的这话,互换一下词,不也说得通嘛?
iyaozhen
2021-05-05 23:10:21 +08:00
@gBurnX 额 可能我之前遇到的项目 开发效率不是第一位(能加人、加机器的问题就不是问题)。反而普适性、稳定性更重要。如果用了 MongoDB 是没 DBA 给维护的。DBA 也在推 newsql

所以更加均衡的 java spring + MySQL + redis 才选择的更多。
gBurnX
2021-05-05 23:16:10 +08:00
@iyaozhen 有些项目,客户催得急,而且开发团队成员都比较贵的情况下,开发效率就很比较重要了。

中国人多,不容易体现出来,你去国外看看,MongoDB 因为易用性,导致在榜单常年第一。
iyaozhen
2021-05-05 23:44:12 +08:00
@gBurnX 哦 那确实,除了国内、国外,还有产品的市场模式,比如 To C 的只需要和 PM 对接排期,还不用对应客户。

还有公司大了,稳定性极度重要,用 MongoDB 没 DBA 维护,需要开发自己维护,出问题了 leader 一句你为什么不用 MySQL 就哑口无言了。当然也不是说不能引入”新“技术,而是新技术要解决现有架构解决不了的场景问题。比如楼主提的分库分表和后续扩容的问题,更重要的还需要向前兼容(这也是 TiDB 在国内非常火的原因,兼容 MySQL )。还需要兼顾 OLTP 和 OLAP 场景
bthulu
2021-05-06 11:24:46 +08:00
mysql 呗, 出问题了不会怪你选型错误, 用户量上来了, 切换到阿里云 polardb 或 oceanbase, 无缝兼容 mysql.
总之就是不能让问题出在你这, 不然就等着追责降 kpi 吧.

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/774832

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX