仿中国加盟网站源码,办网站需要备案吗,嵌入式开发学什么,建立企业网站多少钱目录 前言 一、一些缘由 1、性能分析 二、插入方式调整 1、批量插入的实现 2、MP的批量插入实现 3、日志的配置 三、默认处理方式 1、基础程序代码 2、执行情况 四、提升调试日志等级 1、在logback中进行设置 2、提升后的效果 五、总结 前言 在现代软件开发中#xff0c;性能优… 目录 前言 一、一些缘由 1、性能分析 二、插入方式调整 1、批量插入的实现 2、MP的批量插入实现 3、日志的配置 三、默认处理方式 1、基础程序代码 2、执行情况 四、提升调试日志等级 1、在logback中进行设置 2、提升后的效果 五、总结 前言 在现代软件开发中性能优化是一个永恒的话题尤其是在处理大规模数据时如何提升数据库操作的效率成为了一个关键问题。在数据库操作中批量插入空间矢量数据是一个常见的需求尤其是在地理信息系统(GIS)和空间数据分析领域。调试日志是软件开发中不可或缺的工具它帮助开发者追踪程序的运行状态定位问题和异常。然而日志记录本身是一个资源密集型的操作尤其是在生产环境中过多的日志记录可能会对性能产生负面影响。对于空间矢量数据的批量插入操作这种影响尤为明显因为这类操作通常涉及大量的I/O操作和数据库交互。 尽管调试日志对于开发和问题排查至关重要但在生产环境中它们可能会成为性能瓶颈。每次日志记录都会涉及到I/O操作这会占用CPU时间和磁盘I/O资源。在批量插入空间矢量数据时如果日志记录过于频繁可能会导致以下问题 降低I/O效率日志记录会占用磁盘I/O资源这可能会与数据库操作竞争资源导致整体性能下降。增加延迟日志记录可能会引入额外的延迟尤其是在高并发情况下这会直接影响到批量插入操作的响应时间。资源竞争日志记录和数据库操作可能会竞争有限的系统资源如CPU和内存这可能会导致性能瓶颈。 调试日志是一把双刃剑它在帮助开发者解决问题的同时也可能对生产环境的性能产生影响。在处理空间矢量数据的批量插入时合理控制和优化日志记录是提升性能的关键。本文通过在MybatisPlus中调整插入SQL的输出对比前后的耗时与内存的占用最大限度地减少对性能的负面影响。本文将深入探讨这些策略的具体实现和最佳实践以期为Java开发者提供实用的指导和建议。 一、一些缘由 其实在日常工作当中空间矢量数据的数据量都是非常大。不仅是范围大属性数据也尤其多不仅属性列多而且数据行数也可能非常多。那么我们在使用ORM框架在操作这些数据的时候在进行空间数据入库的时候尤其需要注意性能的影响。有一些程序需要追求高性能尤其是一些需要快速计算的场景用户需要尽快的将数据入库好开展后续的业务。 之前有一个朋友给发了私信说他们在处理线上的生产数据时数据的规模大约是几十W的规模。在使用GeoTools读取Shapefile后然后调用Mybatis-Plus来进行数据入库。它的整体性能不高耗时比较久然后就找到博主聊了一下。原始聊天截图就不放出来了。分享其中遇到的一些问题 1、这位朋友在进行批量数据入库的时候使用循环来进行调用没有使用批量操作。 2、系统的日志级别开的比较低为了方便监控程序系统的日志级别在生产环境上也是Debug。 3、服务器在空间数据库入库时内存占用较高。 1、性能分析 在了解了一些程序的执行细节之后我也做了一个对照实验。实验的主要目的是对比应用程序中调试日志的输出对性能影响 主要方法就是在程序执行时打开和关闭系统日志通过观察打开前后的应用程序执行消耗时间和使用Java VisualVM监控的CPU和内存消耗情况来对比。 二、插入方式调整 为了首先将应用程序的插入调整到一个比较好的执行状态我们先把原来的循环插入的方式进行了修改改成批量插入的形式。因此这里有必要对批量插入的具体实现进行一个简单的介绍。 1、批量插入的实现 在我们的代码中使用的ORM框架是Mybatis-Plus熟悉这个框架的小伙伴们一定知道。在MP中除了有单个插入的方法还提供了一个批量插入的实现。因此如果您是使用了MP这种的增强框架那么改造起来还是比较快的否则就需要大家自己去实现批量插入的方法。在MP中需要调用service提供的saveBatch(List,Size)即可。在在我的示例代码中实现批量插入的关键代码如下所示 登录后复制 Long s3 System.currentTimeMillis();
if(dataList.size() 0) {placeService.saveBatch(dataList, 600);
}
Long e3 System.currentTimeMillis();
System.out.println(空间入库耗时: (e3 - s3) 毫秒); 1.2.3.4.5.6. 2、MP的批量插入实现 上一节中对Mp的批量插入的方法进行了调用这里我们依然对saveBatch方法进行简单的介绍好让大家对saveBatch有一个直观的印象。我们可以打开ServiceImpl的实现类中的以下代码 登录后复制 /*** 批量插入* param entityList ignore* param batchSize ignore* return ignore*/Transactional(rollbackFor Exception.class)Overridepublic boolean saveBatch(CollectionT entityList, int batchSize) {String sqlStatement getSqlStatement(SqlMethod.INSERT_ONE);return executeBatch(entityList, batchSize, (sqlSession, entity) - sqlSession.insert(sqlStatement, entity));} 1.2.3.4.5.6.7.8.9.10.11.12. 这里的方法表示首先获取sql的Statement对象然后调用批量执行的方法。被调用的方法如下 登录后复制 /*** 执行批量操作** param entityClass 实体类* param log 日志对象* param list 数据集合* param batchSize 批次大小* param consumer consumer* param E T* return 操作结果* since 3.4.0*/
public static E boolean executeBatch(Class? entityClass, Log log, CollectionE list, int batchSize, BiConsumerSqlSession, E consumer) {Assert.isFalse(batchSize 1, batchSize must not be less than one);return !CollectionUtils.isEmpty(list) executeBatch(entityClass, log, sqlSession - {int size list.size();int idxLimit Math.min(batchSize, size);int i 1;for (E element : list) {consumer.accept(sqlSession, element);if (i idxLimit) {sqlSession.flushStatements();idxLimit Math.min(idxLimit batchSize, size);}i;}});
} 1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28. 来看一下insert方法的处理逻辑最终的执行update的方法如下 登录后复制 Override
public int doUpdate(MappedStatement ms, Object parameterObject) throws SQLException {final Configuration configuration ms.getConfiguration();final StatementHandler handler configuration.newStatementHandler(this, ms, parameterObject, RowBounds.DEFAULT, null, null);final BoundSql boundSql handler.getBoundSql();final String sql boundSql.getSql();final Statement stmt;if (sql.equals(currentSql) ms.equals(currentStatement)) {int last statementList.size() - 1;stmt statementList.get(last);applyTransactionTimeout(stmt);handler.parameterize(stmt);// fix Issues 322BatchResult batchResult batchResultList.get(last);batchResult.addParameterObject(parameterObject);} else {Connection connection getConnection(ms.getStatementLog());stmt handler.prepare(connection, transaction.getTimeout());handler.parameterize(stmt); // fix Issues 322currentSql sql;currentStatement ms;statementList.add(stmt);batchResultList.add(new BatchResult(ms, sql, parameterObject));}handler.batch(stmt);return BATCH_UPDATE_RETURN_VALUE;} 1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26. 当然大家在使用这个类的时候还是非常方便的只要调用相应的方法即可实现分批导入。 3、日志的配置 在实例的应用开发过程中日志的输出与管理我们使用Logback组件。在最开始的时候在对比实验中首先我们采用默认的方式即对应的ORM处理组件中的日志级别使用默认方法。具体如何在Logback中进行日志的设置请大家结合互联网相关资料进行查询这些都是比较成熟的。 三、默认处理方式 对比实验的第一种实现方法就是采用默认的方法即使用默认的日志级别。但是在最开始时我们还是给出测试的代码的全部。如果您也感兴趣可以替换相应的文件来进行验证这个过程。测试结果可能随着数据量的不同数据属性字段的不同而有所不同。 1、基础程序代码 为了还原网友提出的问题也能尽快的找到原因。我们这里就以之前的全球主要城市为例重点讲解如何进行数据的处理和融合以及最终如何进入到数据库中。实例代码如下 登录后复制 Test
/*** * throws Exception*/
public void shp2PostGIS() throws Exception {Long startTime System.currentTimeMillis();File file new File(SHP_FILE);if (!file.exists()) {System.out.println(文件不存在);}ShapefileDataStore store new ShapefileDataStore(file.toURI().toURL());store.setCharset(Charset.defaultCharset());// 设置中文字符编码// 获取特征类型SimpleFeatureType featureType store.getSchema(store.getTypeNames()[0]);CoordinateReferenceSystem crs featureType.getGeometryDescriptor().getCoordinateReferenceSystem();Integer epsgCode CRS.lookupEpsgCode(crs, true);ListHashMapString, Object mapList new ArrayListHashMapString,Object();ModelMapper modelMapper new ModelMapper();//设置忽略字段PropertyMapHashMapString,Object, Ne10mPopulatedPlaces propertyMap new PropertyMapHashMapString,Object, Ne10mPopulatedPlaces() {protected void configure() {skip(destination.getPkId());}};modelMapper.addMappings(propertyMap);//忽略大小写modelMapper.getConfiguration().setMatchingStrategy(MatchingStrategies.STRICT);// 设置命名约定将下划线转换为驼峰modelMapper.getConfiguration().setSourceNameTokenizer(NameTokenizers.UNDERSCORE).setDestinationNameTokenizer(NameTokenizers.CAMEL_CASE);//设置忽略模式modelMapper.getConfiguration().setSkipNullEnabled(true);Long s1 System.currentTimeMillis();ListNe10mPopulatedPlaces dataList new ArrayListNe10mPopulatedPlaces();SimpleFeatureSource featureSource store.getFeatureSource();// 执行查询SimpleFeatureCollection simpleFeatureCollection featureSource.getFeatures();SimpleFeatureIterator itertor simpleFeatureCollection.features();// 遍历featurecollectionwhile (itertor.hasNext()) {HashMapString, Object map new HashMapString, Object();SimpleFeature feature itertor.next();CollectionProperty p feature.getProperties();IteratorProperty it p.iterator();// 遍历feature的propertieswhile (it.hasNext()) {Property pro it.next();if (null ! pro null ! pro.getValue()) {String field pro.getName().toString();String value pro.getValue().toString();map.put(field, value);}}// 获取空间字段org.locationtech.jts.geom.Geometry geometry (org.locationtech.jts.geom.Geometry) feature.getDefaultGeometry();// 创建WKTWriter对象WKTWriter wktWriter new WKTWriter();// 将Geometry对象转换为WKT格式的字符串String wkt wktWriter.write(geometry);String geom SRID epsgCode ; wkt;//拼接srid实现动态写入map.put(geom, geom);mapList.add(map);}Long e1 System.currentTimeMillis();System.out.println(解析shp (e1 - s1) 毫秒);Long s2 System.currentTimeMillis();for(HashMapString, Object map : mapList) {Ne10mPopulatedPlaces places modelMapper.map(map, Ne10mPopulatedPlaces.class);dataList.add(places);}Long e2 System.currentTimeMillis();System.out.println(转化shp (e2 - s2) 毫秒);store.dispose();System.out.println(dataList.size());Long endTime System.currentTimeMillis();Long time endTime - startTime;System.out.println(程序运行耗时 time 毫秒);Long s3 System.currentTimeMillis();if(dataList.size() 0) {placeService.saveBatch(dataList, 600);}Long e3 System.currentTimeMillis();System.out.println(空间入库耗时: (e3 - s3) 毫秒);
} 1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49.50.51.52.53.54.55.56.57.58.59.60.61.62.63.64.65.66.67.68.69.70.71.72.73.74.75.76.77.78.79.80.81.82.83.84.85. 在不关闭执行SQL日志的情况我们来看一下它的相关性能指标。 2、执行情况 在默认情况下这段程序在执行过程中会输出大量的调试日志如下图所示 在我们的控制台中有许多的插入日志同时可以看到整个空间数据入库的时间为29512毫秒即将近30秒。除了时间的消耗我们再来看一内存方面的消耗。 可以很直观的看到在进行大量的日志输出时内存的使用量还是比较大同时根据不同的批次呈现一个比较有规律的上升和下降而最大的内存使用接近1000MB左右。 接下来我们再来看一下关闭日志输出后的效果。 四、提升调试日志等级 为了实现在运行时将这个插入SQL的日式调试等级我们在Logback中进行相应的配置。以此来验证在提升SQL调试日志的等级后这个批量插入的方法是不是有一个性能的提升。 1、在logback中进行设置 在系统中我们采用logback来进行日志的配置因此我们首先需要在logback中进行相应的设置。将日志的级别从debug提升到error只有在发生错误的时候才进行输出。设置的关键代码如下所示 登录后复制 !-- Ne10mPopulatedPlacesMapper 关闭调试日志 add by 夜郎king in 2024-11-26 --
logger namecom.yelang.project.extend.earthquake.mapper.Ne10mPopulatedPlacesMapper levelerror/ 1.2. 请注意这里的com.yelang.project.extend.earthquake.mapper.Ne10mPopulatedPlacesMapper标识我们需要关闭的ORM类的全名。我们将他的日志级别提升到了error。 2、提升后的效果 在将输出日志关闭之后在控制台中首先就没有了sql的调试日志说明配置成功。 可以看到控制台很干净调试的SQL日志已经被清理掉。同时注意耗时情况变成了7046也就是7秒的时间就完成了处理。在来后台看一下是不是真的处理成功。在数据库进行相应的数据查询。 可以看到数据的总条数也是7342条。因此可以判断关闭sql调试日志后对时间的消耗降低了很多从30秒优化到了7秒 大概提升76%再来看一下内存的占用情况。 相对于默认的处理情况而言提升了日志等级的处理方式其内存占用更加平稳波动小。同时最大的内存占用在700MB左右更多是500MB以下。从侧面也说明了优化的效果。 五、总结 以上就是本文的主要内容本文通过在MybatisPlus中调整插入SQL的输出对比前后的耗时与内存的占用最大限度地减少对性能的负面影响。文章通过对照实验对比了开启调试日志和关闭调试日志后的数据插入性能从对比实验结果可以看到。关闭调试日志后我们的应用程序耗时更短同时内存的占用也更低。如果在生产环境中进行使用尤其是新手同志为了观察参数就留下了很多调试信息这样反而加大了系统的负担。所以要请大家一定综合理性的评估关闭不必要的调试日志让应用程序的性能最大。行文仓库定有许多不足之处如有不足在此恳请各位专家在评论区批评指出不胜感激。
