这是一个创建于 1356 天前的主题，其中的信息可能已经有所发展或是发生改变。
sql 的好处一点没沾着，坑全要踩一遍，传统 dbms 这么多功能就用了个事务，有人可能还不注意用不对…
第 1 条附言 · 2021-04-09 08:21:10 +08:00
我的标题不严谨，大家误会了，我是想说那些折腾分表分库的…至于 rdb 本身的类似 nosql 的特性，如 json，我也很喜欢用
第 2 条附言 · 2021-04-09 17:00:31 +08:00
突然发现被移到 nosql 节点了…
一开始的帖子正文的确很多话没有说清楚。
主要吐槽质疑的是：处于单表单库性能原因，同时不好利用数据库本身的分区机制规避性能问题，因此将本来属于一个集合的数据按哈希或是主键区域分布到多个表多个库的行为。
问题：破坏了关系型数据库的设计模式，导致数据库本身的检查、关联查询等功能全部报废…可以说除了一个事物，什么好处都没用到；至于运维，可能是我经验有限，我实在不认为这个规模的企业不能运维好一组 nosql
起初的帖子写的不够完整清晰的确失误
一开始的帖子正文的确很多话没有说清楚。
主要吐槽质疑的是：处于单表单库性能原因，同时不好利用数据库本身的分区机制规避性能问题，因此将本来属于一个集合的数据按哈希或是主键区域分布到多个表多个库的行为。
问题：破坏了关系型数据库的设计模式，导致数据库本身的检查、关联查询等功能全部报废…可以说除了一个事物，什么好处都没用到；至于运维，可能是我经验有限，我实在不认为这个规模的企业不能运维好一组 nosql
起初的帖子写的不够完整清晰的确失误
 |
1
Maboroshii 2021-04-08 19:03:37 +08:00  1
那楼主能分享下在项目中用了关系数据库的哪些好处呢
|
 |
2
neoblackcap 2021-04-08 19:05:50 +08:00 1
@Maboroshii 事务，联表查询，SQL 语法，维护简单
|
 |
3
iseki OP @Maboroshii 既然用不上 /用不了，那干脆就别用啊，非抱着 dbms，啥特性也不敢用，最后性能还是不够了得分库分表……折腾了有点
|
 |
4
wangyanrui 2021-04-08 19:11:20 +08:00 via iPhone 1
因为相对来说，这玩意大家掌握的更好一丢丢
|
 |
5
totoro52 2021-04-08 19:20:00 +08:00 1
不结合业务场景说这些太耍流氓了
|
 |
6
xiangyuecn 2021-04-08 19:41:19 +08:00
占楼问一下，java，spring 的 @Component 组件实现类的成员函数里面，怎么拿到当前调用本方法的 spring 代理对象？ this 肯定不能用的🐶
@Transactional 注解对小白来讲，说好听点就是真省事，说难听点就是反人类 目前我为了保证需要事务环境的方法一定可以开启事务，函数里面强制检查了一遍是否是在事务环境里面；当不需要事务的方法里面调用同一个类里面另一个会新开事务的方法，不需要事务的这个方法我就加一个 self 参数（当前类的接口类型，就是谁调的这个方法就把谁传进来），通过 self 来调用新开事务的方法，多加这个参数仅仅是为了获取代理对象，太难受了，人家的文档又看不懂😂 应该会有一个什么 SpingXXXUtils.currentBean() 之类的东西可以拿到当前这个类接口的代理对象吧，可惜我太菜🐶 求指点，指指点点也行 |
|
8
iseki OP 1
@xiangyuecn 自己注入自己试试
|
|
9
xiangyuecn 2021-04-08 19:50:32 +08:00
@iseki #8，没试过，下次试一下，原来还可以这样玩😁
|
 |
10
fkdog 2021-04-08 19:53:19 +08:00 2
|
|
11
xiangyuecn 2021-04-08 20:01:59 +08:00
@fkdog #10 跟传播不传播好像没有关系，代理对象上调用方法，和 this 调用方法，区别可不是一点。
当你发现 @Transactional 注解的新事务没有开启，应该回滚的被提交，应该提交的被回滚，那就会很奇怪。 最终还是注解的锅，脱离了代理对象，注解不一定能被 spring 处理；如果手动控制事务，想开启开启，想提交提交，想回滚回滚，只要没有提交就是回滚，这些问题都可以避免。用注解来实现事务管理真不是一个好的想法，只能说是省事 可惜手动控制事务，代码繁琐，浪费生命 |
 |
12
vencent 2021-04-08 20:23:41 +08:00 1
因为非 RDBMS 公司没人维护基础架构，所以。。。
|
 |
13
Jooooooooo 2021-04-08 20:37:34 +08:00
mysql 运维成熟, 稳定性高.
|
 |
14
ychost 2021-04-08 20:39:30 +08:00 1
@xiangyuecn AspectJ 的的 Gglib 模式 this 和 代理对象就一样了，在 EnableAspectJAutoProxy. proxyTargetClass 开启
|
 |
15
xuanbg 2021-04-08 20:39:36 +08:00 1
@xiangyuecn @Transactional 注解需要注意的就是调用的方法不要在同一个类，另外就是不要被同样有 @Transactional 注解的类调用或调用 @Transactional 的方法。这应该很容易做到
|
|
16
ychost 2021-04-08 20:40:44 +08:00
用其它数据库出了问题都找不到答案，用 RDBMS 资料这块至少很多，而且也提供 JSON 的支持
|
|
17
xuanbg 2021-04-08 20:43:47 +08:00
@iseki 我也很好奇那些怕性能问题不用 join 的，为啥不干脆用 nosql 算了。。。关系型数据库就是要联表的呀，不联表查询哪来的关系？不存在关系用的哪门子 sql ？
|
 |
18
geekboy 2021-04-08 20:52:19 +08:00 via Android
@xuanbg 不是不用 join，是不要 join 太多表，join 大表要建好索引，性能问题当然要引起重视。
|
 |
19
CRVV 2021-04-08 20:54:55 +08:00 1
原因之一是关系型数据库本身更可靠或者性能更好。
比如性能比较。当然这公司是搞 PostgreSQL 的，结果可能有偏差。 https://www.enterprisedb.com/blog/comparison-mongodb-vs-postgresql PostgreSQL 更可靠应该没什么悬念。 |
 |
20
ReferenceE 2021-04-08 20:56:18 +08:00 via Android
Transaction 不就一个要么不执行，要么全部执行么
|
|
21
fkdog 2021-04-08 21:10:58 +08:00 4
@xiangyuecn 跟注解没关系。我不知道你的需求是什么才会想到这么膈应人的方法。我提供一个场景不知道符不符合你的需求。
某一个 Service 提供 findByName 方法，findByName 出于某种原因里边有个需求，如果没有查询到某个 Name，那么就创建一条这样的记录，也就是说 findByName 需要调用同 service 下的 create 方法。但是由于通过 this.create 方法，是没有走 spring 的事务增强的，那么很容易导致问题。那么你的解决思路是通过 Spring 的 AopUtils 来获取 this 在 spring 容器中增强过的 bean 。 你的这个想法的确是可以解决你的需求，但是这不是一个好的解决思路。 我更倾向于 findByName 和 create 方法在某一层进行聚合，而不是在 findByName 里调用 create 方法。或者你不想加入聚合层，你可以直接在 Sevice 创建一个新方法 findOrCreat()来聚合这两个 findByName 和 create 方法，然后你在 findOrCreat 上边打上 @Transactional 注释来控制内部嵌套事务的传播性，方便你更细粒度的处理事务提交和回滚。而且 findByName 能更好的专注于方法名所提供的功能，因为其他人去调用你的 findByName 时他们是不清楚你里边还有调用了 create 方法，玩意他们调用了然后创新了一条新纪录可能也不是他们自己的本意。 |
 |
22
oneisall8955 2021-04-08 21:18:23 +08:00 via Android 1
@xiangyuecn springcontextutil
|
|
23
xiangyuecn 2021-04-08 22:00:09 +08:00
@fkdog #21 谢谢😁
|
 |
24
BeautifulSoap 2021-04-08 22:00:26 +08:00
那么既然 lz 这么懂的话，能不能回答下我这个帖子的需求，该用什么 nosql ？ mongodb 是不行的，孱弱的搜索和建索引能力
|
|
25
BeautifulSoap 2021-04-08 22:01:24 +08:00
|
 |
26
zjsxwc 2021-04-08 22:42:46 +08:00 via Android
除了不用外键、不用存储过程、对公业务不 join 多个表外，其他的特性我都用
|
 |
27
mtrec 2021-04-08 22:51:20 +08:00 via Android 1
cp 数据库跟 ap 数据库有什么好比的 哪个合适上哪个 没瓶颈别出错就行 架构都是慢慢演变的
|
 |
28
Rocketer 2021-04-09 00:52:47 +08:00 via iPhone
几年前的测试结果，拿 PostgreSQL 当 nosql 用，性能比 mongo 还好，也不知道这几年 mongo 提升了没有
|
 |
29
msg7086 2021-04-09 06:53:00 +08:00 via Android
因为有人运维啊，因为 ORM 现成的框架啊，因为万一要用到关系的时候不用推翻重来啊，等等。
|
|
30
iseki OP 然而我说的是那些折腾分表分库的，为什么不一步到位 nosql
|
 |
32
qwerthhusn 2021-04-09 08:59:13 +08:00
坏的医美，暴殄天物；好的医美，锦上添花，笔补造化。。
|
 |
33
uselessVisitor 2021-04-09 09:21:20 +08:00
@xiangyuecn 不知道你是怎么使用的，我这边只要加上注解，就算是同一个类中的调用，在各个地方用 Int i = 1/0;都是可以回滚的
|
 |
34
NULL2020 2021-04-09 09:27:08 +08:00 1
@xiangyuecn #6 AopContext.currentProxy()
|
 |
35
passerbytiny 2021-04-09 10:36:39 +08:00 via Android 2
看了楼主的主贴、追加、回复，不知道楼主再说啥。
大概有一点可以确定，楼主想用 nosql 替代 sql 。不要有这样的想法，会很惨的。第一，nosql 虽然叫 nosql，但它真得不是 sql 的反义词，而是补充（ RDBMS 的反义词是 ODBMS，这玩意有人尝试过，至今没有成功）。第二，事务，还真是具有一票否决权，目前只有 RDBMS 能够在性能期望内完全满足事务的所有原则。 最后再提醒一下，分库分表，这可是实实在在面向对象领域的事，sql 是实现它而不是决定它，你就算换了 ODBMS 或者全部使用 nosql，也是避免不了的。 |
 |
36
no1xsyzy 2021-04-09 10:38:38 +08:00
|
 |
37
hjosama 2021-04-09 11:22:05 +08:00
你好可爱哦，喜欢你
|
|
38
hjosama 2021-04-09 11:26:14 +08:00
看了你的博客，感觉真的好可爱！似乎像你喜欢 miku 那样，我也喜欢上你了呢，好可爱！
|
|
39
hjosama 2021-04-09 11:30:28 +08:00
iseki 我好喜欢你呢... 到底是个怎样的男孩子呢...
|
|
40
hjosama 2021-04-09 11:31:50 +08:00
iseki 酱在哪个城市呢... 想交朋友...
|
|
41
hjosama 2021-04-09 11:34:18 +08:00
原来可爱到如此程度的 iseki 酱是个买房了的中年大叔呢 爱情还没开始就凋零了...
|
 |
42
fengxianqi 2021-04-09 11:36:24 +08:00
楼上在干嘛。。
|
|
43
hjosama 2021-04-09 11:37:15 +08:00
我已经爱上 iseki 酱了 无法自拔了 等回复唔
|
|
44
hjosama 2021-04-09 11:55:35 +08:00
感觉喜欢热度稍微下降了一点点，因为十几分钟还没回复，大概是因为被 iseki 酱的可爱一时上头了呢
|
 |
45
Macolor21 2021-04-09 12:33:23 +08:00
@iseki
说实话我技术不够好，看不懂你的吐槽点，对我来说 NoSQL 一般键值对存储和文档存储？ 然后你说的分库分表，我司有个需求：一个 SaaS 系统，每一个客户拥有一套完整的数据库（用户，数据，分类，客户端 balabala 一堆表），每个客户存储的数据量不一（根据付费等级而定）。因为是 SAAS，所以应用程序是共用同一套，只是底层存储不一样。这种需求的话，如果不以客户分库（目前是 SELECT xx FROM client[xx].user ） 的话，我想不出来有什么更好的解决方案。（可能给行加个客户端列？那这样底层的数据聚集是应该以客户聚集，还是表本身呢？如果以表本身，那查一个客户德批量查询，估计的 N 多次寻道...） |
 |
47
JasonLaw 2021-04-09 12:35:31 +08:00 via iPhone
@passerbytiny #35 连自己想要表达的东西都说不清楚，但是却有那么多人回复，真是不懂。
|
|
48
JasonLaw 2021-04-09 12:37:51 +08:00 via iPhone
而且回复里面也掺杂了好多无关的东西，就不能自己新建个主题吗？
|
 |
49
namelosw 2021-04-09 12:49:31 +08:00
因为 Postgres 一把梭省事。
实在遭不住再换 Cassandra 之类暴力的，运维操蛋。 |
 |
50
tairan2006 2021-04-09 13:15:44 +08:00
现在不怎么谈 NoSQL 了吧，像一般的 MPP 数据库甚至 ElasticSearch 这种，现在都兼容 sql 了，大融合不可避免。
至于分库分表，现在还有这么搞的？ OLTP 就直接用 tidb 啊… |
 |
51
letking 2021-04-09 14:12:13 +08:00
请教楼主，折腾分表分库具体是指什么操作？如果数据到了需要分表的量级，那有什么 nosql 数据库可以更简单的处理呢？
|
 |
52
chenqh 2021-04-09 14:33:27 +08:00
因为 mysql 历经考验，用的人比 mongo 多
|
 |
53
Lemeng 2021-04-09 14:46:34 +08:00
前面几楼是什么东东
|
 |
54
ThanksSirAlex 2021-04-09 14:52:13 +08:00
我就是不喜欢用 mongodb，至少以目前的开发经验来说没有经历过哪家公司用的非常好的，就仗着人家没有固定的 schema 数据就 XJB 乱存，然后全在代码里面加各种操作，我宁可老老实实用关系型数据库，每个字段的意思给我写写清楚，当然，这里说的是工程代码，自己写的代码随便怎么玩都行。
|
 |
55
bthulu 2021-04-09 14:53:30 +08:00
mysql 出的早, 用的人多, 没动力换 mongo. 等 80 后 90 后这一批人都下岗了, 自然就都是 mongo 一把梭了
|
 |
56
cmai 2021-04-09 15:31:21 +08:00 1
@xiangyuecn 跟注解没有关系，同类调用不经过代理只是传播特性不生效而已，事务还是会展开的，但是你自定义的传播特性就会丢失，我这边如果没有特殊的业务需求需要用到自定义的传播特性是不管的，如果要用到自定义传播特性，那就在本类自己注入自己
|
 |
57
moen 2021-04-09 15:31:25 +08:00
用过 Postgres 的都说好
|
 |
58
EridanusSora 2021-04-09 15:49:03 +08:00 via Android
。。点进来发现要素过多
|
|
59
iseki OP 。。。一开始发帖时确实疏忽了…表达的很不准确，主要是吐槽分库分表，性能不够就分库分表，rdb 的功能废了大半。
|
|
60
iseki OP @passerbytiny 难道不是很多 rdb 出现单点的性能问题同时不好利用其本身的分布式分区机制才分库分表的吗？
既然这样为什么不去用本身把这些问题处理的很好的那部分 nosql，毕竟分完表，rdb 的 r 很多也都废了 事物的问题，我一开始确实没有深入考虑，的确目前没有现成的，像现有 sql 数据库那样好用的… |
|
61
iseki OP @Macolor21 显然我吐槽的不是你说的这种分库的场景…每个客户端数据没啥关系分成多个非常合理
|
 |
62
Nillouise 2021-04-09 18:16:39 +08:00
用过 aws 的 dynamodb，确实自带的分区功能就不错了，之后看看 dynamodb 能不能蚕食 mysql 吧。
如果 mysql 的优势只是在事务的话，那应该有机会被取代的。 |
 |
63
stabc 2021-04-09 19:04:57 +08:00
分区就变 NOSQL 了？什么逻辑？ NOSQL 本身也分区啊
|
 |
64
astkaasa 2021-06-30 14:45:00 +08:00
@xiangyuecn key word: spring bean unwrap
|
Select Language