sqltoy-orm-4.16.7 发版,针对部分功能和注释优化

2020年10月28日

致谢:

感谢网友的积极参与和反馈,对mssql的分页含top 场景进行了智能适配!

开源地址:

更新内容

1、针对sqlserver分页语句中的order by判断进行增强优化(top 子查询可以有order by),避免开发者手工增加order by
2、将save()、update()、query()等链式操作变为推荐使用

此版本为优化版本,不影响现有功能,开发者可以选择性升级

分析为什么sqltoy-orm是最值得拥有的!

您的痛点和诉求分析,我们将大多数人遇到的问题分成3个阶段:

  • 初级阶段诉求(单库,crud+一些较复杂查询)
  1. 希望拥有jpa式的对象操作的简洁舒畅,如:save(entity)\update\saveOrUpdate\saveAll\updateAll,loadById()等
  2. 希望简单的查询可以是对象链式操作模式
  3. 希望复杂的查询可以直接写sql便于sql优化,同时希望sql文件更新可以热更新
  4. 不希望有sql注入问题
  5. 希望可以方便分页
  • 中级阶段诉求(开始遇到一些复杂场景开始思辨,crud不再是重点,查询问题开始凸显)
  1. 提供诸如唯一性验证、取top记录、取随机记录现成的方法
  2. 遇到一些分布式、高并发场景,考虑主键生成策略诉求,比如传统jpa的update操作无法规避null覆盖则需要先加载后更新(高并发就易导致将别人已经更新后的内容又覆盖了)
  3. 遇到产品要适用多种数据库的诉求,希望一个sql可以跑在myql、oracle、mssql、postgres等,如树结构递归查询、group_concat等函数适配
  4. 随着业务的成熟,企业的管理开始注重数据,对查询和统计要求变高(但查询往往需求会多变),所以较长的动态条件sql比重越来越大。
  5. 遇到了一些复杂统计问题,比如数据旋转、同比环比,纯sql写起来过于复杂,且换数据库又不通用
  • 高级阶段诉求(ETL(跑批+流实时处理)+极致查询,这个阶段查询问题极为凸显,处理不好性能用户体验将极为糟糕)
  1. 因为数据规模的扩大,老套的表分区也难以支撑,需要分表、分库了
  2. 因为大数据和高并发,对查询性能提出了极致性要求
  3. 传统数据库无法适应大规模数据和业务多样性带来的要求,需要进行领域细分,引入mongodb、elastic、clickhouse等组合使用
  • sqltoy-orm就是上述过程的演绎
  1. sqltoy起初是hibernate jpa的补充,用于增强查询,后来因为不希望项目中引入太多技术,sqltoy实现了hibernate jpa的功能,同时将其不足之处进行了完善,正式称之为ORM框架!
  2. sqltoy是个人带团队给各个金融企业做项目过程中成长起来的,不同企业数据库不一样,而且金融企业数据规模基本上都是百万千万级,所以要求基础模块可以适用于不同数据库。
  3. sqltoy是经历个人负责拉卡拉支付集团数据团队时,单交易表日均1300万(2017年底),年均30亿规模的洗礼的,在大规模ETL(hive+spark跑批和流实时)的基础上结合oracle一体机、索引优化、表分区、内存表、分表分库、缓存翻译、极致分页等各种策略都难以支撑,通过融合mongo、elasticsearch、clickhouse进行组合专题化应用得以很好的解决。
  4. 从2018年sqltoy经历了目前公司erp复杂场景的洗礼,走向了成熟。
  5. 从2020年4月sqltoy对外开源推广,得到了大量的反馈,结合积极的响应和完善,sqltoy基本上完成了各种边缘场景的覆盖!
  • 简要介绍一下sqltoy的几个特点
  • sqltoy的jpa式增删改

都是基于类似于sqltoyLazyDao.save(entity)模式简洁操作,但sqltoy的update和saveOrUpdate、updateFetch等等都是在内里做了极致的优化,这里不做过多介绍!有优势但谈不上作为重点介绍。

  • sqltoy提供了最简洁的动态sql编写

我们对比一下mybatis的实现(从可阅读、可维护等视角看)

  • 缓存翻译,利用缓存减少关联查询,简化sql同时大幅提升效率

  • 极致分页优化

  • 并行查询
// 使用并行查询同时执行2个sql,条件参数是2个查询的合集
String[] paramNames = new String[] { "userId", "defaultRoles", "deployId", "authObjType" };
Object[] paramValues = new Object[] { userId, defaultRoles, DEPLOY_ID,GROUP };

List<QueryResult<TreeModel>> list = super.parallQuery(
		Arrays.asList(ParallQuery.create().sql("webframe_searchAllModuleMenus").resultType(TreeModel.class),
				ParallQuery.create().sql("webframe_searchAllUserReports").resultType(TreeModel.class)),
		paramNames, paramValues);
  • 数据旋转

  • 无限极分组统计(含汇总求平均),算法配置简单又跨数据库!
  • 同比环比

展开阅读全文
7 收藏
分享
加载中
最新评论 (28)
能翻译出缓存中的多个字段嘛?
2020-10-30 09:01
0
回复
举报
你说的问题其实都是sqltoy目前所支持的,第一、反向缓存检索默认最大是1000个,另外可以自己设置最大匹配量(超过1000当1000),第二、缓存翻译缓存里面可以是多列数据,翻译时有cache-index可以设置,默认为1不需设置;第三、缓存翻译支持对A,B,C式的拼接多个代码进行翻译得到名称A,名称B,名称C

其实从sqltoy的介绍里面应该可以体会到sqltoy的理念和严谨细腻,几乎每个人的担心的边缘问题发现都已经被考虑到!
2020-10-30 09:28
0
回复
举报
缓存查询 in 条件个数大于 1000 有处理嘛
2020-10-30 09:00
0
回复
举报
厉害👍
2020-10-29 18:19
0
回复
举报
😄,sqltoy是一个看简介好的不真实的框架!或者大家都没有看懂的框架!
2020-10-29 21:34
0
回复
举报
这个框架的境界,属于那种国学高级经典,懂得人奉若珍宝,不懂得人味如嚼蜡。
2020-10-30 09:34
0
回复
举报
主要还是大家对mybatis这些比较习惯,总是用历史的经验来审视sqltoy!实际上sqltoy上手极为简单,说的直接点还是认同问题,需要在一定数量的用户后才能逐步转变大家的看法,现在大多数人愿意用3天来深入研究mybatis也不会用半个小时来完成sqltoy的学习,因为现在sqltoy用户较少!
2020-10-30 09:46
0
回复
举报
加油吧,能发展到mp那样的程度就不差了
2020-11-02 10:25
0
回复
举报
我原以为sqltoy一亮,会很容易就击败mybatis(plus)这些,就算不能让大家转用sqltoy也会让大家惊叹sqltoy的效果!现在发现其实客观的说,大家根本就不懂动态查询方式改变带来的优势,更没有读懂缓存翻译带来sql的简化和性能的提升,更没有读懂分页极致优化带来的性能的提升,sqltoy将jpa式crud在开头就强调了跟大家对等甚至稍有超越!

就不知道大家脑子里面都是怎么思考问题的!
2020-11-02 17:02
0
回复
举报
回复 @zhongxuchen : 大佬提个意见,xml里的查询可以像mybatis一样直接写sql吗,把cdata标签去掉的话会不会更好
2020-11-03 10:18
0
回复
举报
回复 @Yoona520 : 不知道你们是如何思考问题,cdata只是为了便于增加注释(如果没有注释当然可以不用cdata了,xml又不是mybatis的专利),你让mybatis加一个注释试试,你知道在极致场景下/*+hint*/ 功能吗(搜索sql hint)?可以通过注释模式进行性能优化!不要纠结于cdata
2020-11-03 10:54
0
回复
举报
缓存能配置成redis嘛
2020-10-29 13:02
0
回复
举报
如果查询条件 是关联表的字段 能用缓存嘛?
2020-10-29 12:56
0
回复
举报
可以自己扩展,但这种缓存必须要用本地缓存,当然可以是本地+redis模式,要达到效率最高就需要本地缓存,避免每次都要有io
2020-10-29 13:16
0
回复
举报
缓存翻译其实就是这个意思呀
2020-10-29 13:21
0
回复
举报
我的意思是:人员表有个deptid字段,dept表作为缓存,deptname通过deptid到缓存去取。那如果查询条件中有deptname,deptname 能在缓存中查询?
2020-10-29 15:40
0
回复
举报
当然可以,反向条件检索!可以深入了解一下!
2020-10-29 15:43
0
回复
举报
其实文章的缓存翻译图里面就已经表达了,filters里面的cache-arg
2020-10-29 15:45
0
回复
举报
大家可以看这篇文章来理解分页和缓存翻译带来的效果
https://blog.csdn.net/zhongxu/article/details/105555803?utm_source=app
2020-10-29 08:45
0
回复
举报
有没有效率的跑分测试,新项目想换这个,想知道执行效率如何?
2020-10-28 23:43
0
回复
举报
你可能被常规的orm给忽悠了,常规的性能对比其实没有意义,那个对比的是java代码内部处理效率(除非水平太差这个才会有大差异),sqltoy在性能优化上走的路线不一样,在很多场景下可能性能是别的框架几倍甚至十倍的提升,因为是靠缓存翻译减少表关联查询(多表关联查询变单表岂能不快),还有你了解一下分页优化和快速分页,套路又不一样,先分页取十条去关联,减少了关联规模岂能不快。这些都是不在一个维度的竞争对比!就像不少人说的一样,sqltoy介绍的不像真的!这话是有道理的,等大家逐步了解sqltoy后感受到价值后,就会感叹sqltoy确实是灵魂之作!
2020-10-29 06:44
0
回复
举报
看了一下评论,哈哈,sqltoy发展不易呀,作者加油,sqltoy只有用过的人或者经历过不少项目的人才会体会!
2020-10-28 14:56
0
回复
举报
每次看这个简介都觉得好厉害
2020-10-28 14:09
0
回复
举报
哈哈,说明看到不少次数了,估计处于将信将疑状态,感觉吹嘘成分较大,但搞技术要有自己的判断!应该能够准确判断哪些是自己想要的,没有什么可以将信将疑的!
2020-10-28 14:47
0
回复
举报
很多人将焦点放在java代码中的对象crud,其实这些大家没有多少差异,但查询的高效性爆发一个问题就让你非常头疼,但大多数人偏偏不关注这方面!
2020-10-28 13:16
0
回复
举报
更多评论
28 评论
7 收藏
分享
返回顶部
顶部