为什么你们要把 sql 当 nosql 用？

[iseki]

sql 的好处一点没沾着，坑全要踩一遍，传统 dbms 这么多功能就用了个事务，有人可能还不注意用不对…

我的标题不严谨，大家误会了，我是想说那些折腾分表分库的…至于 rdb 本身的类似 nosql 的特性，如 json，我也很喜欢用

突然发现被移到 nosql 节点了…
一开始的帖子正文的确很多话没有说清楚。
主要吐槽质疑的是：处于单表单库性能原因，同时不好利用数据库本身的分区机制规避性能问题，因此将本来属于一个集合的数据按哈希或是主键区域分布到多个表多个库的行为。
问题：破坏了关系型数据库的设计模式，导致数据库本身的检查、关联查询等功能全部报废…可以说除了一个事物，什么好处都没用到；至于运维，可能是我经验有限，我实在不认为这个规模的企业不能运维好一组 nosql

起初的帖子写的不够完整清晰的确失误

[Maboroshii]

那楼主能分享下在项目中用了关系数据库的哪些好处呢

[neoblackcap]

@Maboroshii 事务，联表查询，SQL 语法，维护简单

[iseki]

@Maboroshii 既然用不上 /用不了，那干脆就别用啊，非抱着 dbms，啥特性也不敢用，最后性能还是不够了得分库分表……折腾了有点

[wangyanrui]

因为相对来说，这玩意大家掌握的更好一丢丢

[totoro52]

不结合业务场景说这些太耍流氓了

[xiangyuecn]

占楼问一下，java，spring 的 @Component 组件实现类的成员函数里面，怎么拿到当前调用本方法的 spring 代理对象？ this 肯定不能用的🐶

@Transactional 注解对小白来讲，说好听点就是真省事，说难听点就是反人类

目前我为了保证需要事务环境的方法一定可以开启事务，函数里面强制检查了一遍是否是在事务环境里面；当不需要事务的方法里面调用同一个类里面另一个会新开事务的方法，不需要事务的这个方法我就加一个 self 参数（当前类的接口类型，就是谁调的这个方法就把谁传进来），通过 self 来调用新开事务的方法，多加这个参数仅仅是为了获取代理对象，太难受了，人家的文档又看不懂😂

应该会有一个什么 SpingXXXUtils.currentBean() 之类的东西可以拿到当前这个类接口的代理对象吧，可惜我太菜🐶

求指点，指指点点也行

[iseki]

@totoro52 u1s1，qs

[iseki]

@xiangyuecn 自己注入自己试试

[xiangyuecn]

@iseki #8，没试过，下次试一下，原来还可以这样玩😁

[fkdog]

@xiangyuecn 解决的路子不对。
针对事务嵌套事务的处理，spring 有专门的事务传播机制可以选择。
可以在 @Transactional 注解里设置传播机制。

[xiangyuecn]

@fkdog #10 跟传播不传播好像没有关系，代理对象上调用方法，和 this 调用方法，区别可不是一点。

当你发现 @Transactional 注解的新事务没有开启，应该回滚的被提交，应该提交的被回滚，那就会很奇怪。

最终还是注解的锅，脱离了代理对象，注解不一定能被 spring 处理；如果手动控制事务，想开启开启，想提交提交，想回滚回滚，只要没有提交就是回滚，这些问题都可以避免。用注解来实现事务管理真不是一个好的想法，只能说是省事

可惜手动控制事务，代码繁琐，浪费生命

[vencent]

因为非 RDBMS 公司没人维护基础架构，所以。。。

[Jooooooooo]

mysql 运维成熟, 稳定性高.

[ychost]

@xiangyuecn AspectJ 的的 Gglib 模式 this 和 代理对象就一样了，在 EnableAspectJAutoProxy. proxyTargetClass 开启

[xuanbg]

@xiangyuecn @Transactional 注解需要注意的就是调用的方法不要在同一个类，另外就是不要被同样有 @Transactional 注解的类调用或调用 @Transactional 的方法。这应该很容易做到

[ychost]

用其它数据库出了问题都找不到答案，用 RDBMS 资料这块至少很多，而且也提供 JSON 的支持

[xuanbg]

@iseki 我也很好奇那些怕性能问题不用 join 的，为啥不干脆用 nosql 算了。。。关系型数据库就是要联表的呀，不联表查询哪来的关系？不存在关系用的哪门子 sql ？

[geekboy]

@xuanbg 不是不用 join，是不要 join 太多表，join 大表要建好索引，性能问题当然要引起重视。

[CRVV]

原因之一是关系型数据库本身更可靠或者性能更好。

比如性能比较。当然这公司是搞 PostgreSQL 的，结果可能有偏差。
https://www.enterprisedb.com/blog/comparison-mongodb-vs-postgresql

PostgreSQL 更可靠应该没什么悬念。

[ReferenceE]

Transaction 不就一个要么不执行，要么全部执行么

[fkdog]

@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 方法，玩意他们调用了然后创新了一条新纪录可能也不是他们自己的本意。

[oneisall8955]

@xiangyuecn springcontextutil

[xiangyuecn]

@fkdog #21 谢谢😁

[BeautifulSoap]

那么既然 lz 这么懂的话，能不能回答下我这个帖子的需求，该用什么 nosql ？ mongodb 是不行的，孱弱的搜索和建索引能力

[BeautifulSoap]

帖子忘贴了

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

除了使用 sql 预留字段或者 json，请问上面这需求还有什么解决办法？

[zjsxwc]

除了不用外键、不用存储过程、对公业务不 join 多个表外，其他的特性我都用

[mtrec]

cp 数据库跟 ap 数据库有什么好比的 哪个合适上哪个 没瓶颈别出错就行 架构都是慢慢演变的

[Rocketer]

几年前的测试结果，拿 PostgreSQL 当 nosql 用，性能比 mongo 还好，也不知道这几年 mongo 提升了没有

[msg7086]

因为有人运维啊，因为 ORM 现成的框架啊，因为万一要用到关系的时候不用推翻重来啊，等等。

[iseki]

然而我说的是那些折腾分表分库的，为什么不一步到位 nosql

[LokiSharp]

@iseki NoSQL 综合性能不如 SQL

[qwerthhusn]

坏的医美，暴殄天物；好的医美，锦上添花，笔补造化。。

[uselessVisitor]

@xiangyuecn 不知道你是怎么使用的，我这边只要加上注解，就算是同一个类中的调用，在各个地方用 Int i = 1/0;都是可以回滚的

[NULL2020]

@xiangyuecn #6 AopContext.currentProxy()

[passerbytiny]

看了楼主的主贴、追加、回复，不知道楼主再说啥。

大概有一点可以确定，楼主想用 nosql 替代 sql 。不要有这样的想法，会很惨的。第一，nosql 虽然叫 nosql，但它真得不是 sql 的反义词，而是补充（ RDBMS 的反义词是 ODBMS，这玩意有人尝试过，至今没有成功）。第二，事务，还真是具有一票否决权，目前只有 RDBMS 能够在性能期望内完全满足事务的所有原则。

最后再提醒一下，分库分表，这可是实实在在面向对象领域的事，sql 是实现它而不是决定它，你就算换了 ODBMS 或者全部使用 nosql，也是避免不了的。

[no1xsyzy]

因为 SQL 搞了很久，优化也都做得很足

@BeautifulSoap 我先盲猜一个图数据库和一个 redis （
不过，我觉得这不是数据库的事儿。

[hjosama]

你好可爱哦，喜欢你

[hjosama]

看了你的博客，感觉真的好可爱！似乎像你喜欢 miku 那样，我也喜欢上你了呢，好可爱！

[hjosama]

iseki 我好喜欢你呢... 到底是个怎样的男孩子呢...

[hjosama]

iseki 酱在哪个城市呢... 想交朋友...

[hjosama]

原来可爱到如此程度的 iseki 酱是个买房了的中年大叔呢 爱情还没开始就凋零了...

[fengxianqi]

楼上在干嘛。。

[hjosama]

我已经爱上 iseki 酱了 无法自拔了 等回复唔

[hjosama]

感觉喜欢热度稍微下降了一点点，因为十几分钟还没回复，大概是因为被 iseki 酱的可爱一时上头了呢

[Macolor21]

@iseki
说实话我技术不够好，看不懂你的吐槽点，对我来说 NoSQL 一般键值对存储和文档存储？
然后你说的分库分表，我司有个需求：一个 SaaS 系统，每一个客户拥有一套完整的数据库（用户，数据，分类，客户端 balabala 一堆表），每个客户存储的数据量不一（根据付费等级而定）。因为是 SAAS，所以应用程序是共用同一套，只是底层存储不一样。这种需求的话，如果不以客户分库（目前是 SELECT xx FROM client[xx].user ） 的话，我想不出来有什么更好的解决方案。（可能给行加个客户端列？那这样底层的数据聚集是应该以客户聚集，还是表本身呢？如果以表本身，那查一个客户德批量查询，估计的 N 多次寻道...）

[magese]

@hjosama ???

[JasonLaw]

@passerbytiny #35 连自己想要表达的东西都说不清楚，但是却有那么多人回复，真是不懂。

[JasonLaw]

而且回复里面也掺杂了好多无关的东西，就不能自己新建个主题吗？

[namelosw]

因为 Postgres 一把梭省事。

实在遭不住再换 Cassandra 之类暴力的，运维操蛋。

[tairan2006]

现在不怎么谈 NoSQL 了吧，像一般的 MPP 数据库甚至 ElasticSearch 这种，现在都兼容 sql 了，大融合不可避免。

至于分库分表，现在还有这么搞的？ OLTP 就直接用 tidb 啊…

[letking]

请教楼主，折腾分表分库具体是指什么操作？如果数据到了需要分表的量级，那有什么 nosql 数据库可以更简单的处理呢？

[chenqh]

因为 mysql 历经考验，用的人比 mongo 多

[Lemeng]

前面几楼是什么东东

[ThanksSirAlex]

我就是不喜欢用 mongodb，至少以目前的开发经验来说没有经历过哪家公司用的非常好的，就仗着人家没有固定的 schema 数据就 XJB 乱存，然后全在代码里面加各种操作，我宁可老老实实用关系型数据库，每个字段的意思给我写写清楚，当然，这里说的是工程代码，自己写的代码随便怎么玩都行。

[bthulu]

mysql 出的早, 用的人多, 没动力换 mongo. 等 80 后 90 后这一批人都下岗了, 自然就都是 mongo 一把梭了

[cmai]

@xiangyuecn 跟注解没有关系，同类调用不经过代理只是传播特性不生效而已，事务还是会展开的，但是你自定义的传播特性就会丢失，我这边如果没有特殊的业务需求需要用到自定义的传播特性是不管的，如果要用到自定义传播特性，那就在本类自己注入自己

[moen]

用过 Postgres 的都说好

[EridanusSora]

。。点进来发现要素过多

[iseki]

。。。一开始发帖时确实疏忽了…表达的很不准确，主要是吐槽分库分表，性能不够就分库分表，rdb 的功能废了大半。

[iseki]

@passerbytiny 难道不是很多 rdb 出现单点的性能问题同时不好利用其本身的分布式分区机制才分库分表的吗？
既然这样为什么不去用本身把这些问题处理的很好的那部分 nosql，毕竟分完表，rdb 的 r 很多也都废了
事物的问题，我一开始确实没有深入考虑，的确目前没有现成的，像现有 sql 数据库那样好用的…

[iseki]

@Macolor21 显然我吐槽的不是你说的这种分库的场景…每个客户端数据没啥关系分成多个非常合理

[Nillouise]

用过 aws 的 dynamodb，确实自带的分区功能就不错了，之后看看 dynamodb 能不能蚕食 mysql 吧。

如果 mysql 的优势只是在事务的话，那应该有机会被取代的。

[stabc]

分区就变 NOSQL 了？什么逻辑？ NOSQL 本身也分区啊

[astkaasa]

@xiangyuecn key word: spring bean unwrap