性能与稳定

最后更新: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能长期逍遥法外。
    同时我们的响应速度也会非常快,只要不是涉及到结构变更的问题一般不会留到第二天。
首页 最近更新 搜索 提交 回复