性能与稳定
最后更新:2024-06-20 09:02:35
|
状态:未完成
-
关于性能
默认情况下AnyLine的性能是比较低的，这主要是指的DataSet/DataRow的性能
在分页情况下每页几十行数据没什么影响，但在一次性处理几十上百万行数据时会非常耗时。
原因是DataSet/DataRow要适配各种复杂的检索，如：
忽略大小写、驼峰与分隔符转换、正则表达式、排序、维度转换、截取、去重、方差、偏差、交集合集差集、分组、忽略大小写对比、行列转换、类SQL过滤筛选(like,eq,in,less,between...)、JSON、XML格式转换等
在每一次get/set操作中都有可能涉及这些情况，详细请点开DataRow的put/get方法看一下
在大多数情况下使用会比较方便，如
DataRow.get("user_id")/get("userId")/get("userID")都能获取到期望结果;
DataSet.get("NAME","张%");可以获取NAME以张开头的行
当然智能也意味着运行低效
通常在处理大数据时需要设置DataRow的KeyCases为SRC模式，或者返回Entity/Map格式的数据
把DataSet set = service.querys()换成List<Map> list = service.maps()
另外需要注意maps方法不检测总行数，除非在PageNavi或ConfigStore上调用total(true)才会查询总行数，因为List<Map>>结构没有存储总行数的属性，所以总行数存在了PageNavi.getTotalRows()中
参考【maps检测总行数】
【查询】
如果还需要再快， 可以启用流式查询方式，这样会保持一个较长的连接，并返回一个迭代器，而不是把数据一次性读取内存中。参考【流式查询】
除此之外，性能主要取决于数据库设计与应用。
从DataSet中查询也会比较慢，如果从几十几百行中查询还可以，但这个过程涉及情况太多，如果需要快请参考【DataSet查询性能】
【插入】
插入大批量数据时，不要用save,因为save会逐行检测是insert还是update
可以service.insert(int batch, String table, Object data) 这里的batch>1时会调用jdbc的批量操作 data可以是一个List<Map>，List<Entity>或DataSet(量大时这个就不要用了)
也可以手工拆分成多个List一次insert()跟jdbc批量效果类似,都是多条数据集中到一次命令中,与数据库交互一次。
数量比较大，又不需要处理时，可以直接根据SELECT插入，跳过了网络IO会比较快，参考【根据查询插入】
【更新、删除】也可以通过batch触发批量执行(不过这并没什么适用的场景,实际测试也并没有快多少)
批量插入和更新参考【批量执行】
【增量】在增量数据操作时可能会遇到数据覆盖的情况，参考【已存在则update或ignore，不存在则insert】
如果还是不够快，就是因为anyline在构造SQL时会执行各种检测耗时了(如检测数据类型)，这个耗时极少，如果这也不能接受的话
可以构造好SQL后调用execute(int batch, String sql, List<Object> values)或execute(int batch, String sql, List<List<Object>> values)
需要注意的是，批量执行需要保持每行SQL的参数一致，并且批量方执行时并不会触发全部的监听和拦截事件，也不准确的统计影响行数
-
关于稳定性
比较让人失望的是稳定性也很难保证，DML方面比较稳定已经很常时间没有新需求了，但DDL方面只实现了常用部分。
由于每天都有需的需求提出，所以代码每天都会更新，但测试用例有点跟不上节奏。
值得庆幸的是：每天都有众多的近一线人员在测试验证，特别是谁提出的需求，更会测到自己满意为止。很难有BUG能长期逍遥法外。
同时我们的响应速度也会非常快，只要不是涉及到结构变更的问题一般不会留到第二天。
