`
brandNewUser
  • 浏览: 460978 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

一次压测情况下Solr部分性能调整

阅读更多
 
在将solr模糊词搜索从 copyfield方式修改为 qf(query function)之后,其query的性能降低不少。原来是采用将所有需要搜索的字段都copy至同一个字段中,最近要根据模糊匹配结果的权重分析,这种方式根本无法满足要求,所以就采用了query function,这样就能定义不同字段的权重了,例如我们qf可以如下定义:
 
 
product_name^2.0 category_name^1.5 category_name1^1.5
  
 
搜索出来的结果会根据不同匹配的评分进行相似度排序。
 
但在性能测试过程中,其非常耗费内存,在solr查询服务中,我们打开了solr的搜索日志 solr.log,搜索日志的格式大概如下:
 
2016-10-19 13:31:26.955 INFO  (qtp1455021010-596) [c:product s:shard1 r:core_node1 x:product] o.a.s.c.S.Request [product] webapp=/solr path=/select params={sort=salesVolume+desc&fl=product_id,salesVolume&start=0&q=brand_id:403+OR+category_id:141&wt=javabin&version=2&rows=100} hits=3098 status=0 QTime=3
2016-10-19 13:31:28.618 INFO  (qtp1455021010-594) [c:product s:shard1 r:core_node1 x:product] o.a.s.c.S.Request [product] webapp=/solr path=/select params={mm=100&facet=true&sort=psfixstock+DESC,salesVolume+DESC&facet.mincount=1&facet.limit=-1&wt=javabin&version=2&rows=10&fl=product_id&facet.query=price:[*+TO+500]&facet.query=price:[500+TO+1000]&facet.query=price:[1000+TO+2000]&facet.query=price:[2000+TO+5000]&facet.query=price:[5000+TO+10000]&facet.query=price:[10000+TO+*]&start=0&q=*:*+AND+(category_id:243+OR+category_path:243)+AND+-category_path:309+AND+brand_id:401+AND+good_stop:0+AND+product_stop:0+AND+is_check:1+AND+status:1&facet.field=category_id&facet.field=brand_id&facet.field=color_id&facet.field=gender&facet.field=ctype&qt=/select&fq=price:[1000+TO+*]&fq=psfixstock:[1+TO+*]} hits=17 status=0 QTime=5
2016-10-19 13:31:30.867 INFO  (qtp1455021010-614) [c:product s:shard1 r:core_node1 x:product] o.a.s.c.S.Request [product] webapp=/solr path=/select params={mm=100&facet=true&sort=price+ASC,goods_id+DESC&facet.mincount=1&facet.limit=-1&wt=javabin&version=2&rows=10&fl=product_id&facet.query=price:[*+TO+500]&facet.query=price:[500+TO+1000]&facet.query=price:[1000+TO+2000]&facet.query=price:[2000+TO+5000]&facet.query=price:[5000+TO+10000]&facet.query=price:[10000+TO+*]&start=0&q=*:*+AND+(category_id:10+OR+category_path:10)+AND+-category_path:309+AND+color_id:10+AND+gender:(0)+AND+good_stop:0+AND+product_stop:0+AND+is_check:1+AND+status:1&facet.field=category_id&facet.field=brand_id&facet.field=color_id&facet.field=gender&facet.field=ctype&qt=/select&fq=price:[5000+TO+*]&fq=psfixstock:[1+TO+*]} hits=9 status=0 QTime=7
2016-10-19 13:31:32.877 INFO  (qtp1455021010-594) [c:product s:shard1 r:core_node1 x:product] o.a.s.c.S.Request [product] webapp=/solr path=/select params={mm=100&facet=true&sort=psfixstock+DESC,salesVolume+DESC&facet.mincount=1&facet.limit=-1&wt=javabin&version=2&rows=10&fl=product_id&facet.query=price:[*+TO+500]&facet.query=price:[500+TO+1000]&facet.query=price:[1000+TO+2000]&facet.query=price:[2000+TO+5000]&facet.query=price:[5000+TO+10000]&facet.query=price:[10000+TO+*]&start=0&q=*:*+AND+(category_id:60+OR+category_path:60)+AND+-category_path:309+AND+brand_id:61+AND+gender:(0)+AND+good_stop:0+AND+product_stop:0+AND+is_check:1+AND+status:1&facet.field=category_id&facet.field=brand_id&facet.field=color_id&facet.field=gender&facet.field=ctype&qt=/select&fq=price:[*+TO+*]&fq=psfixstock:[1+TO+*]} hits=5 status=0 QTime=8
2016-10-19 13:31:42.896 INFO  (qtp1455021010-89) [c:product s:shard1 r:core_node1 x:product] o.a.s.c.S.Request [product] webapp=/solr path=/select params={mm=100&facet=true&sort=psfixstock+DESC,salesVolume+DESC&facet.mincount=1&facet.limit=-1&wt=javabin&version=2&rows=10&fl=product_id&facet.query=price:[*+TO+500]&facet.query=price:[500+TO+1000]&facet.query=price:[1000+TO+2000]&facet.query=price:[2000+TO+5000]&facet.query=price:[5000+TO+10000]&facet.query=price:[10000+TO+*]&start=0&q=*:*+AND+-category_path:309+AND+brand_id:323+AND+color_id:3+AND+good_stop:0+AND+product_stop:0+AND+is_check:1+AND+status:1&facet.field=category_id&facet.field=brand_id&facet.field=color_id&facet.field=gender&facet.field=ctype&qt=/select&fq=price:[*+TO+*]&fq=psfixstock:[1+TO+*]} hits=3 status=0 QTime=4
 
 
为了合理统计出query的QTime,编写了一个python脚本,用来在线分析每次solr查询的QTime和对应的查询条件:
 
 
import sys
 
if __name__ == '__main__':
    input_file = sys.argv[1]
 
    min_time = 0 if len(sys.argv) < 3 else int(sys.argv[2])
 
    try:
        with open(input_file) as file:
            while (1):
                line = file.readline().strip()
                if not line:
                    break
                splits = line.split(" ")
                if not splits[len(splits) - 1].startswith("QTime"):
                    continue
                q_time = int(splits[len(splits) - 1].replace('\n', '').replace('QTime=', ''))
                if q_time <= min_time:
                    continue
 
                date = splits[0]
                time = splits[1]
                params = splits[13].split("&")
 
                dict = {}
                for param in params:
                    keyValuePair = param.split("=")
                    dict[keyValuePair[0]] = keyValuePair[1]
 
                query = dict.get('q', None)
                if query:
                    print "%s - %s , QTime=% 5d, Query = %s" % (date, time, q_time, query)
    except IOError as error:
        print error
 
 
 
该脚本中可以分析solr.log中的日志并过滤出大于某端时间(毫秒)的QTime。经过分析发现此时的QTime大于1000ms的占据很大比例,说明我们配置的query function性能并不理想,至少相对于copy field来说。
 
通过jvisualvm监测发现full gc发生的频率非常高,cpu占用居高不下,请求响应时间发生抖动,且抖动的时候都是在该服务器的CPU使用率下降时发生的。
 
将线上的堆栈dump出来,经过JProfiler分析的hprof文件,占据大头的都是solr、lucene相关的类:
 



 
 
 
而且发现另外一个情况,老年代用400M左右常驻内存,而通常老年代涨到500M左右时就会发生一次Full GC(发生得非常频繁)。
 
需要我们调整JVM内部各个部分内存占用的比例,但收效甚微,接近10:1(MinorGC:FullGC)的GC,过多的FullGC次数使得应用程序的整体处理请求速度变慢:
 
 

 
 
初步分析觉得应该是Survivor的空间不足以存放某个大对象,使得新生代未被回收的对象直接晋升到老年代导致频繁GC,但是调高SurvivorRatio比例之后,发现该问题仍然没有得到解决。
 
当前solr的GC回收策略为CMSGC,据网上查找的该垃圾回收策略,可能会出现promotion failed和concurrent mode failure,经过我们查看当天的压测日志,确实这种情况非常多:
 
> grep "concurrent mode failure" solr_gc_log_20161018_* | wc -l
4919
> grep "promotion failed" solr_gc_log_20161018_* | wc -l
127
 
 
网上推荐的做法是:
 
http://blog.csdn.net/chenleixing/article/details/46706039 写道
promotion failed是在进行Minor GC时,survivor space放不下、对象只能放入老年代,而此时老年代也放不下造成的;concurrent mode failure是在执行CMS GC的过程中同时有对象要放入老年代,而此时老年代空间不足造成的(有时候“空间不足”是CMS GC时当前的浮动垃圾过多导致暂时性的空间不足触发Full GC)。
应对措施为:增大survivor space、老年代空间或调低触发并发GC的比率,但在JDK 5.0+、6.0+的版本中有可能会由于JDK的bug29导致CMS在remark完毕后很久才触发sweeping动作。对于这种状况,可通过设置-XX: CMSMaxAbortablePrecleanTime=5(单位为ms)来避免。
 
 
 
但经过综合考虑,没有能够正常调通该种策略,决定提升JVM的进程Heap内存至3.5G,并将原有响应式CMSGC替换成吞吐量优先的方式,减少FullGC次数和总体时间:
 
-Xmn2048m \
-XX:-UseAdaptiveSizePolicy \
-XX:SurvivorRatio=4 \
-XX:TargetSurvivorRatio=90 \
-XX:MaxTenuringThreshold=8 \
-XX:+UseParallelGC -XX:+UseParallelOldGC
  
 
经过这样调整后:Heap总体内存为3.5G,老年代1.5G,新生代总体2G,Eden区1.3G,两个Survivor区分别为300M。
 
但是空间提高之后也会出现其他的问题,发现老年代空间导致的一个重大问题就是,单次FullGC的时间会变得非常大,第一次gc时间居然超过5s,这也是由于单次回收的空间过高引起的:
 


 
 
原来总是以为是survivor区的空间不够大,当调大之后发现也不是这个问题,不过这种情况下运行一段时间后,总体还算是比较稳定,次数和时间也控制下来了,只不过进行FullGC时可能会发生STW(Stop The World),引起较长时间的停顿,如果是CMS方式就不会出现这种问题。
 
SurvivorRatio=2的设置也并不是非常合理,后续还是将其降低为4-5。
 


  
 
经过solr部分的测试,基本的结论还是比较符合预期的,相同条件下,对于analysed字段(进行分词操作的),其响应时间(Response Time)会比非analysed字段长很多,尤其是在压测条件下(图中最后一行就是模糊匹配,其他两个为精确匹配)。
 


  
 
SolrCloud导致的另外一些问题
 
经过solrCloud线上和测试环境对比验证,发现线上的多台服务性能居然要比单台要低,经过数据比对分析发现,我们当前的数据量还没有达到需要进行分片的要求,分片反而会导致性能下降,下面是我们当前的core部署结构,分成两个shard
 


 
 
在solr的debugQuery模式下,可以看到最终的QTime为两个QTime增加后的总和还要多一点,多出的时间应该是合并结果的时间。在数据量比较大的情况下,多分片会降低某一台服务器的负载。
 
如果将其做成单个shard,通过zookeeper连接solrCloud,增加replica的情况下,则只会将压力打到单台服务器上,这样做虽然比分片要快(在小数据集的情况下),但造成了服务资源的浪费。
 


 
 
我们决定采用折中方案,使用solrCloud来保证4台solr服务器的数据一致性(我们当前的数据变化不频繁),然后每台应用服务器选择一台solr服务器进行单机连接,这样也有一个问题就是损失了高可用性,但是在电商做活动期间,这样临时做是没有问题的,但需要保证每台服务器的其他core都是存在全面的数据,否则会出现某些节点没有对应core的错误。 
 
 
 
  • 大小: 31.7 KB
  • 大小: 73.8 KB
  • 大小: 92.2 KB
  • 大小: 13.8 KB
  • 大小: 107.2 KB
  • 大小: 12.1 KB
  • 大小: 9.8 KB
分享到:
评论

相关推荐

    elasticsearch实战及使用ppt,私有资源自己 看的

    调优包括调整内存分配、磁盘I/O、网络设置以及索引策略等,以确保最佳性能。 **源码分析** 深入源码分析有助于理解ES的工作机制,为解决复杂问题或定制功能提供帮助。 **组件监控** ES提供了内置的监控工具,可以...

    全流程重构京东服务市场系统

    为了应对高并发场景,京东服务市场引入了降级开关策略,例如参考Solr服务的降级实践,保障在服务故障情况下可以快速切换,确保核心功能的可用性。此外,读写分离和多级缓存策略的实施,比如将JVM缓存、JimDB缓存和...

    区块链_智能合约_Solidity_保险应用_基于以太坊的技_1744433266.zip

    区块链_智能合约_Solidity_保险应用_基于以太坊的技_1744433266

    【数据库管理】Mysql安装配置全流程:环境变量设置、服务安装与初始密码修改教程

    内容概要:本文档详细介绍了在Windows系统上安装MySQL数据库的具体步骤。首先,需要配置系统环境变量,包括新建MYSQL_HOME变量并将其添加到PATH中;其次,创建并编辑my.ini配置文件,设置MySQL的基本参数如端口、字符集、数据存放目录等;接着,在命令行工具中通过一系列指令完成MySQL的初始化、服务安装、启动以及root用户的密码设置和权限调整。整个流程涵盖了从环境搭建到最终确保MySQL服务正常运行的所有关键环节。 适合人群:适用于有一定计算机操作基础,尤其是对数据库管理有一定兴趣或需求的技术人员。 使用场景及目标:①帮助用户在本地机器上成功部署MySQL数据库环境;②确保用户能够掌握MySQL的基本配置与管理技能,如环境变量配置、服务安装与卸载、用户权限管理等。 其他说明:在安装过程中可能会遇到一些常见问题,例如由于之前版本残留导致的服务安装失败,此时可以通过命令行删除旧服务(sc delete mysql)来解决。此外,为了保证安全性,务必及时修改root用户的初始密码。

    【嵌入式系统】8051单片机启动文件STARTUP.A51代码解析:初始化堆栈指针与数据段及中断向量配置详解

    内容概要:`STARTUP.A51` 是 Keil C51 编译器自带的启动文件,用于初始化 8051 单片机的硬件和软件环境。该文件主要完成三个任务:初始化堆栈指针、清零内部数据存储器、跳转到主程序。文件中定义了内存模式(如 SMALL),并设置了堆栈指针的初始值为 0x60。接着通过循环将内部数据存储器的所有字节清零,确保程序开始时数据存储器的状态是确定的。此外,文件还列出了 8051 单片机的各个中断向量地址,并为每个中断提供占位符,实际的中断处理程序需要在其他文件中实现。最后,启动代码段初始化堆栈指针和数据段后,跳转到 `MAIN` 函数开始执行主程序。; 适合人群:对嵌入式系统开发有一定了解,尤其是使用 8051 单片机的开发者。; 使用场景及目标:①理解 8051 单片机启动文件的工作原理;②掌握如何初始化堆栈指针和数据段;③熟悉中断向量表的设置及其作用。; 其他说明:此文件为程序正常运行提供了必要的初始化操作,开发者可以根据具体需求修改该文件以适应不同的硬件和软件环境。

    【电力系统故障诊断】基于行波理论的输电线路故障诊断方法研究:三相电流信号分析与小波变换波头检测系统设计(含详细代码及解释)

    内容概要:该论文研究了一种基于行波理论的输电线路故障诊断方法。当输电线路发生故障时,故障点会产生向两侧传播的电流和电压行波。通过相模变换对三相电流行波解耦,利用解耦后独立模量间的关系确定故障类型和相别,再采用小波变换模极大值法标定行波波头,从而计算故障点距离。仿真结果表明,该方法能准确识别故障类型和相别,并对故障点定位具有高精度。研究使用MATLAB进行仿真验证,为输电线路故障诊断提供了有效解决方案。文中详细介绍了三相电流信号生成、相模变换(Clarke变换)、小波变换波头检测、故障诊断主流程以及结果可视化等步骤,并通过多个实例验证了方法的有效性和准确性。 适合人群:具备一定电力系统基础知识和编程能力的专业人士,特别是从事电力系统保护与控制领域的工程师和技术人员。 使用场景及目标:①适用于电力系统的故障检测与诊断;②能够快速准确地识别输电线路的故障类型、相别及故障点位置;③为电力系统的安全稳定运行提供技术支持,减少停电时间和损失。 其他说明:该方法不仅在理论上进行了深入探讨,还提供了完整的Python代码实现,便于读者理解和实践。此外,文中还讨论了行波理论的核心公式、三相线路行波解耦、行波测距实现等关键技术点,并针对工程应用给出了注意事项,如波速校准、采样率要求、噪声处理等。这使得该方法不仅具有学术价值,也具有很强的实际应用前景。

    光伏-混合储能微电网能量管理系统:基于滤波算法的功率分配与SOC优化

    内容概要:本文详细介绍了光伏-混合储能微电网能量管理系统的模型架构及其控制策略。首先探讨了光伏发电模块中的MPPT(最大功率点跟踪)控制,采用扰动观察法和改进型变步长策略来提高光伏板的发电效率。接着重点讲解了混合储能系统的功率分配,利用一阶低通滤波算法将功率需求分为低频和高频两部分,分别由蓄电池和超级电容处理。此外,文中还深入讨论了SOC(荷电状态)管理策略,确保电池和超级电容在不同工作状态下保持最佳性能。仿真结果显示,在光伏出力剧烈波动的情况下,系统能够有效地维持稳定的电压水平,并显著提高了储能设备的使用寿命。 适合人群:对光伏微电网、储能技术和能量管理系统感兴趣的科研人员、工程师和技术爱好者。 使用场景及目标:适用于研究和开发高效、可靠的光伏-混合储能微电网系统,旨在优化能量管理和提高系统稳定性。具体应用场景包括但不限于家庭光伏系统、小型微电网以及工业能源管理系统。 其他说明:文中提供了详细的代码实现和仿真结果,便于读者理解和复现实验。同时,模型设计采用了模块化思路,方便进行个性化修改和扩展。

    MATLAB与CVX平台下储能调峰调频联合优化模型的实现与应用

    内容概要:本文详细介绍了基于MATLAB和CVX平台实现的储能调峰调频联合优化模型。该模型不仅涵盖了储能的基本参数设定、负荷不确定性处理、充放电策略制定,还包括了调峰调频的联合调度、功率约束处理、鲁棒优化等方面的内容。通过构建考虑电池退化成本、充放电功率约束以及用户负荷不确定性的储能优化模型,展现了储能系统在电力系统中的高效协同工作。文中提供了详细的代码示例,解释了各个部分的功能和实现方法,强调了模型的深度与创新性。 适合人群:适用于具有一定编程基础和技术背景的研究人员、工程师以及希望深入了解储能系统优化的学生。 使用场景及目标:该模型主要用于电力系统中储能设备的优化调度,旨在提高储能系统的经济效益和社会效益。通过联合调峰调频,能够显著提升储能系统的收益,实现1+1>2的超线性增益效果。此外,该模型还可以用于教学和科研,帮助初学者理解和掌握储能优化的相关技术和理论。 其他说明:代码中包含了丰富的注释和模块化的子程序,使得整个模型易于理解和扩展。对于有经验的开发者,可以在现有基础上进一步改进和定制,以适应不同的应用场景。

    大模型技术白皮书2023版

    大模型技术白皮书2023版

    图像增广 PyTorch 版

    图像增广 PyTorch 版

    批量修改文件常用格式有TXT D0CX PDF 等办公软件里面附带使用教程

    批量修改文件名可以帮助用户节省大量时间,提高工作效率 里面附带使用教程

    《计算机应用基础》第2章--Windows-XP操作系统.ppt

    《计算机应用基础》第2章--Windows-XP操作系统.ppt

    基于单片机的红外密码锁设计(仿真+电路+程序)(51+1602+1838+24C02+JK+BZ+KEY16)#0407

    包括:源程序工程文件、Proteus仿真工程文件、电路原理图文件、配套技术手册、论文资料等 1、采用51/52单片机(通用)作为主控芯片; 2、采用1602液晶显示使用过程及状态,液晶屏亮度会随光线自动调整; 3、按键输入6位密码,输入密码正确则锁打开,显示open!输入密码错误次数超过3次,蜂鸣器报警并且锁定键盘; 4、密码可以自己修改,必须是锁打开时才能改密,为防止误操作,修改密码得输入两次; 5、采用24C02保存密码,掉电不丢失; 6、可通过红外遥控器输入密码操作锁的状态;

    2025年感知技术十大趋势深度分析报告总结述

    内容概要:本文深入剖析了2025年全球感知技术的十大发展趋势,涵盖多模态感知融合、3D感知与空间计算、脑机接口中的感知反馈技术、5G/6G赋能的超低延迟感知、语音与情感识别的高级化、生物感知与数字健康、环境感知与自适应智能、增强现实(AR)与触觉反馈技术、气味与化学感知、量子感知与极端条件测量。文章详细介绍了每项技术的技术原理、关键算法、实现方式、商业案例及未来前景,强调了感知技术在智慧城市、自动驾驶、智慧医疗、工业自动化等领域的深刻影响。报告指出,感知技术正从单一传感模式向多模态融合、从二维数据向三维空间重建、从传统网络通信向超低延迟和高可靠性网络升级,实现全场景、全维度的智能感知。; 适合人群:对感知技术感兴趣的科技爱好者、研究人员、决策者、企业管理层和投资人。; 使用场景及目标:①了解感知技术的最新进展和未来发展方向;②为技术研究提供全面、深入的参考;③为商业应用提供具体的案例和前景分析;④推动跨领域协同创新,构建开放共赢的产业生态。; 其他说明:报告基于近年来技术研发的最新进展、业界前沿的技术路线以及各大科技企业在商业落地方面的丰富实践。随着感知技术的不断成熟,数据隐私与安全保护问题也需高度重视,以确保技术进步与社会伦理和谐统一。未来,感知技术将成为推动社会进步和产业升级的重要力量,为实现万物互联、智慧决策和智能体验提供无限可能。

    基于Springboot+vue的校园新闻网站【源码+数据库+参考论文】

    本论文主要论述了如何使用JAVA语言开发一个校园新闻网站 ,本系统将严格按照软件开发流程进行各个阶段的工作,采用B/S架构,面向对象编程思想进行项目开发。在引言中,作者将论述校园新闻网站的当前背景以及系统开发的目的,后续章节将严格按照软件开发流程,对系统进行各个阶段分析设计。 校园新闻网站的主要使用者分为管理员和用户,实现功能包括管理员:首页、个人中心、用户管理、新闻类型管理、校园新闻管理、留言板管理、论坛交流、系统管理,用户前台:首页、校园新闻、论坛交流、留言反馈、个人中心、后台管理等功能。由于本网站的功能模块设计比较全面,所以使得整个校园新闻网站信息管理的过程得以实现。 本系统的使用可以实现本校园新闻网站管理的信息化,可以方便管理员进行更加方便快捷的管理,可以提高管理人员的工作效率。 基于Springboot+vue的校园新闻网站【源码+数据库+参考论文】 感兴趣自行下载学习!

    电力电子领域三相三电平PWM整流器的三电平SVPWM算法闭环控制策略解析

    内容概要:本文详细探讨了三相三电平PWM整流器的闭环控制策略及其核心技术——三电平SVPWM算法。文章首先介绍了三相三电平PWM整流器的基本概念和优势,如输出三种电平以降低谐波含量并减少滤波器体积和成本。接着阐述了闭环控制策略的重要性,强调了电压外环和电流内环的双闭环控制机制。随后,文章深入讲解了三电平SVPWM算法的工作原理,包括空间电压矢量的选择、扇区判断、矢量作用时间和死区补偿等关键技术环节。此外,还讨论了中点电位平衡的问题以及PI参数的整定方法。最后,通过示波器测试验证了系统的性能指标,如THD低于3%,直流电压纹波小于1%。 适合人群:从事电力电子领域的工程师和技术人员,尤其是对三相三电平PWM整流器及其控制策略感兴趣的读者。 使用场景及目标:适用于高压大功率场合,旨在提高整流器的性能,降低谐波含量,实现单位功率因数运行。通过合理设计闭环控制策略和优化SVPWM算法,确保整流器在各种工况下都能稳定、高效地工作。 其他说明:文中提供了大量MATLAB和C语言代码片段,帮助读者更好地理解和实现相关算法。同时,针对实际调试过程中遇到的问题给出了实用的解决方案,如中点电位平衡和死区补偿等。

    全新红娘本地交友系统定制版源码 相亲婚恋交友小程序源码.zip

    全新红娘本地交友系统定制版源码 相亲婚恋交友小程序源码

    【地图制图领域】基于DeepSeek的地图生成技术探索:融合AI与传统制图链的智能化地图生成系统设计了在AI时代

    内容概要:文章探讨了AI技术,特别是DeepSeek,如何驱动地图生成的变革。首先介绍了地图制图在AI时代的背景与挑战,强调了DeepSeek与地图融合的两种主要方式:嵌入地图制图链和研发地图语言自身的预训练模型。随后详细描述了DeepSeek在地图生成中的具体应用,包括智能化地图生成器DoMapAI的整体框架,地图制图链中的知识图谱推理路径,以及地图语言的Token化过程。最后,文章总结了AI时代地图制图的职业变化和技术变革,指出地图制图正经历“大变局”。 适合人群:从事地图制图及相关领域的研究人员、工程师,以及对AI与地图生成感兴趣的学者。 使用场景及目标:①理解AI技术在地图生成中的应用,特别是DeepSeek的作用;②掌握智能化地图生成器DoMapAI的工作原理及其应用场景;③学习地图语言Token化的方法及其在地图生成中的应用;④探索AI时代地图制图的职业发展方向和技术变革。 阅读建议:本文内容较为专业,建议读者先了解基本的AI技术和地图制图知识。重点关注DeepSeek与地图融合的具体方法和应用场景,理解智能化地图生成器DoMapAI的工作流程,以及地图语言Token化的实现过程。在阅读过程中,可以结合实际案例进行思考,以更好地理解AI技术对地图制图的影响。

    chromedriver-mac-arm64-135.0.7049.114.zip

    chromedriver-mac-arm64-135.0.7049.114.zip

    《网络布线与小型局域网搭建(第2版)》第3章-布线系统的设计.ppt

    《网络布线与小型局域网搭建(第2版)》第3章-布线系统的设计.ppt

Global site tag (gtag.js) - Google Analytics