基于分布式的公共设施综合管理平台设计方案.docx

上传人:b****5 文档编号:8029810 上传时间:2023-01-28 格式:DOCX 页数:19 大小:2.23MB
下载 相关 举报
基于分布式的公共设施综合管理平台设计方案.docx_第1页
第1页 / 共19页
基于分布式的公共设施综合管理平台设计方案.docx_第2页
第2页 / 共19页
基于分布式的公共设施综合管理平台设计方案.docx_第3页
第3页 / 共19页
基于分布式的公共设施综合管理平台设计方案.docx_第4页
第4页 / 共19页
基于分布式的公共设施综合管理平台设计方案.docx_第5页
第5页 / 共19页
点击查看更多>>
下载资源
资源描述

基于分布式的公共设施综合管理平台设计方案.docx

《基于分布式的公共设施综合管理平台设计方案.docx》由会员分享,可在线阅读,更多相关《基于分布式的公共设施综合管理平台设计方案.docx(19页珍藏版)》请在冰豆网上搜索。

基于分布式的公共设施综合管理平台设计方案.docx

基于分布式的公共设施综合管理平台设计方案

 

基于分布式的公共设施综合管理平台

设计方案

 

第1章绪论

1.1研究背景

随着国家信息化建设的不断推进,我国在公共设施信息化方面发展迅速,并取得丰硕成果,公共设施在办公管理过程中产生的数据量日益增大,由于纸质信息资源具有易损坏、无法再生等问题,企业内信息资源逐渐由纸质化转向数字化,大多以数字化信息的形式存储在电脑中。

经过研究分析,这些信息主要具有以下特点:

第一,文件格式多样化。

存储在计算机中的文件形式多样,不仅有传统数据库这样的结构化数据,更多的是半结构化数据和非结构化数据,如办公过程中的办公文档、文本文件、报表信息、网页信息等,以及各式各样的终端设备采集的图片、音频和视频等。

第二,数据多为非结构化数据。

由于非结构化数据难以统一数据标准,且难以理解,所以处理起来有一定的难度。

第三,数据量日益增多,数据共享需求日益迫切。

由于非结构化数据需要以文件方式上传、下载的方式实现信息共享。

但由于传统的单机服务器管理数据的方式,存在数据不易迁徙和系统扩展性不好的问题,己经不能满足公共设施管理用户的需求。

另外,由于信息化建设的推进,每年各地方政府都有大批的市政公共设施管理信息系统开展建设或进行系统升级扩展l3],建立了一批公共设施数据库及公共设施信息管理系统。

在公共设施信息化建设过程中,出现了重建设轻维护、重硬轻软、信息孤岛、信息转载等问题,这是由于公共设施行业的特殊性决定的,不仅会导致数据过于分散,而且不利于管理部门之间相互协作,综合管理。

最后,传统公共设施信息管理平台,主要是建立公共设施基础信息管理平台,主要管理公共设施的基本信息,部分公共设施管理系统会有隐患管理功能。

由日常的人工巡检来发现公共设施运行中出现的问题,这限制于巡检人员的经验与技术和测试设备的性能,人为因素比较多,具有不可预测性。

而且由于数据的共享程度低等原因,消隐流程不透明,不符合智慧城市的要求。

智慧城市则是以物联网基础设施、云计算基础设施等新一代信息技术来实现新的公共设施管理。

即通过物联网监测公共设施,获得公共设施的各种指标,建立公共设施数据集,使用数据挖掘算法对其各种监测指标数据进行挖掘,发现公共设施隐患与各项检测指标之间的关联关系,建立隐患预测模型,进而根据监测数据及时预警,采取有效措施消隐,将事故扼杀,对于保障城市正常运行,人民的生

命财产安全具有重要的意义。

基于分布式的公共设施管理系统搭建一个分布式的平台用于解决管理数据日益多样性带来难以处理的问题,利用主题爬虫整合相关行业信息,满足用户的信息获取和管理的需求。

旨在让公共设施管理平台用户更好利用积累的管理数据资源和互联网上的行业信息,为办公和决策提供数据支持,具有一定的现实意义。

1.2国内外研究现状 

Google在2003-2004年发表了三篇关于大数据分析和处理的问题的论文,分别阐述Google的三驾马车:

GFS,MapReduce和BigTable,开启了关于分布式处理的时代。

GFS提供了海量非结构化信息存储平台,并提供了冗余备份、负载均衡、失效检测等分布式存储功能,是其他相关技术的基石。

BigTable则是一种建立在GFS上的数据存储结构。

MapReduce是一种针对分布式批量处理计算模型,它将计算任务根据分布式计算特点将任务认为Map和Reduce两个阶段,简化了分布式编程。

以DougCutting为代表的技术人员根据这三篇论文的思想实现了Hadoop这一开源分布式系统框架Hadoop实现了一个类似GFS的分布式文件系统HDFS,HDFS具有高容错性,适合存储大文件并为之提供高吞吐量顺序读写,适合大量数据集。

HBase是模仿BigTable实现的一种分布式、面向列的数据库,适合非结构化数据存储。

Hadoop还实现了一个分布式计算架构Map/Reduce为大量数据提供计算。

当然,Hadoop还有Hive,Common,Avro,Chukwa,Hbase,pig等子项目,使得Hadoop提供了更多功能。

目前,很多Hadoop得到十分广泛的应用。

在国外,Yahoo将Hadoop的分布式计算技术应用于其公司的网页搜索和广告业务;Twitter将Hadoop的分布式存储和备份技术用于管理数据存储;FaceBook将Hadoop技术应用在机器学习上。

在国内,BAT都利用了Hadoop的技术在其领域,阿里利用Hadoop进行电商大规模数据存储和处理,并对Hadoop开源贡献很多;XX将Hadoop应用在其搜索及其他领域;中国移动研究院利用Hadoop技术对内利用数据分析提供决策,对外提供云计算服务。

1.3研究内容

本文拟研究设计并实现一个基于分布式的公共设施管理平台,通过该管理平台,管理公共设施的基本信息,能够实现公共设施的综合管理,优化数据管理方式。

首先根据内部的实际业务应用以及流程和相关的管理规范梳理公共设施综合管理平台的功能性需求,并进行功能分类整理,根据部门业务关注点,将需求进行拆散重组装,以求适应多角度用户的需要。

其次设计基于分布式的公共设施管理平台关键功能模块的流程,以及系统的主要功能模块实现。

最后实现设计的系统,实现隐患上报、隐患评估、制定消隐计划和消隐反馈的隐患流程。

1.4研究意义

本次设计研究主要针对传统公共设施管理系统在数据管理和获取方面的不足的解决方案进行探索。

公共设施就是为了满足公众需求而建设的,能够为公众提供可供休闲或使用的公共产品,分布在城市的各个角落,科学管理保证其安全运行,对于维护城市正常运行,保证人民生命财产安全具有重要意义。

首先,我国推进信息化建设取得成果显著,公共设施在业务处理过程中累计了大量的数据,不再是传统公共设施管理系统中的存储在数据库二维数据,更多的是非结构化的文本、图片、音频、视频等。

根据互联网数据中心统计,办公中产生的非结构化数据占总数据的80%,这标志着信息化时代的到来带来的更多的是半结构化和非结构化的数据。

因此,随着非结构化数据的增多以及重要性的提高,如何对越来越多的结构样式多样的数据进行管理,是现在公共设施管理者们必须面对的一个问题。

其次,信息化建设成功显著不仅体现在数据的积累上,各地在推进信息化建设的过程中,建立了很多信息管理系统,其中公共设施的管理系统建设成果显著。

各地都有市政公共信息系统,桥梁和管线等信息系统。

建设信息系统是为了更好的管理信息和信息共享,但是信息系统的增多却带来了信息孤岛问题,因为信息过于分散,这不利于公共设施管理者去获取需要的信息。

而且获取行业信息方式的不便,不利于进行行业交流或者统计分析。

因此,本文很重要的一部分工作就是对公共设施的行业信息进行资源整合,由于积累的资源种类繁多,样式多样,并且重复率高,利用主题爬虫技术将用户需要的信息抓取下来,并对信息进行清洗、去重之后,最终装载到数据库,以便满足用户对行业信息的需求。

最后,近年来公共设施事故依然不断发生,给人们的生命财产安全带来巨大伤害。

如果能及时发现隐患并进行隐患管理,消除隐患,有助于避免或减少事故发生的可能性,这对于保障公共设施安全运行具有一定的现实意义。

 

第2章系统需求分析

2.1可行性分析

在进行需求分析前,首先需要对系统建设的开展以及初步方案进行可行性分析:

从业务需求来说,目前公共设施综合管理平台用户对信息的需求主要有:

桥梁管理用户对桥梁的信息进行管理,管线管理用户对管线的信息进行管理,隐患评级人员对隐患类别和等级进行检查认定等,明确的显示建立一个适应需求的公共设施综合管理平台是十分必要的。

从技术角度来说,开发公共设施综合管理平台的相关技术己经非常成熟。

硬件方面,高配置的服务器己经十分普遍,容量大,处理速度较高,是系统运行的必要基础。

软件方面,使用分布式的平台搭建系统也是可行的。

既提高了准确性和效率,同时也有了辅助决策的相关功能。

有了这些软硬件技术的支持,开发一个成熟的系统在这些方面没有技术风险,可行。

2.2系统需求介绍

通过对现状的调查,本系统将以城市典型的公共设施建设运行、维护、管理

的最优化为目标,主要满足城市管理中心对城市公共设施的协同管理。

实现城市公共设施管理的电子化、平台化、集成化。

我们将系统的需求细化如下:

首先,系统的目标使用用户大致包括四类:

桥梁管理用户,管线管理用户,隐患评级人员和系统管理员。

桥梁管理用户和管线管理用户分别对桥梁和管线的信息进行管理。

隐患评级人员主要是对隐患类别和等级进行检查认定,而系统管理人员主要是具有一些系统管理功能。

其次,经过多地调研发现,公共设施综合管理平台用户对信息的需求主要有以下三个方面:

第一,中小型企业和研究单位十分重视国家政策信息。

行业的发展往往需要政府的支撑,政府对于一个行业的支撑通常体现在对该行业的相关政策法规的制定上,公共设施是国家基础设施建设工程,往往更加需要关注了解国家政策。

第二,中小型企业和研究单位对行业会议信息也十分重视。

行业的发展需要进行交流,公共设施更是一个需要进行交流的行业。

企业需要通过参加会议展示自己企业技术的实力和产品,研究单位需要了解行业最近的研究成果,需要了解行业会议信息。

第三,中小型企业和研究单位,对于新闻上公共设施事故信息的获取也十分需要。

事故信息能反应公共设施管理中的不足,通过对事故信息的统计,对于了解一个地区的公共设施管理情况和易发事故类型有及其重要的意义。

第四,中小型企业和研究单位用户,对于招标信息也有十分迫切的需求。

用户企业可以在招标信息模块,找到适合其企业的招标信息进行投标。

最后,随着国家信息化建设的不断推进,我国在公共设施信息化方面得到了快速的发展,公共设施管理者在管理办公过程中累积了丰富的数据,如:

office文档、pdf,网页,以及各种终端设备采集多媒体文件。

传统公共设施管理者多是通过系统中的文件上传功能将这些文件上传到公共设施管理平台的服务器上,然后将文件路径存放在数据库中,来实现用户管理其办公文件的需求。

但是随着时间的推移,数据量日益增长,这种存储管理方式己经不能满足公共设施管理者的需要,因为传统系统多是针对单机设计,扩展性极差,数据迁移十分复杂。

因此,如何对这些不断增长的多样办公管理数据进行存储和管理,是公共设施管理平台迫切需要解决的问题。

通过对需求的介绍,我们明确了基于分布式的公共设施综合管理平台涵盖两大部分,三大功能。

两大部分指的是:

桥梁和地下管线;三大功能指的是:

基础信息管理功能、信息抓取功能、分布式存储功能。

其他还有一些譬如统计分析、简报生成、结果导出等功能。

力求满足管理者的管理需求,使城市公共设施管理更加便捷化。

为了提高网络的可靠性和网络骨干宽带,各接入交换机可以采用多个千兆端口上联到核工业民交换机。

目前多数交换机支持端口聚合技术,可以将多条链路聚合为一组干路,成倍地提高网络带宽,从而大提高网络的可靠性和性能。

核心交换机可以采用双电源、双引擎的度提高核心设备本身的可靠性。

2.3 分布式技术介绍

本文用到分布式技术框架主要是Hadoop,Hadoop实现了一个类似GFS的分布式文件系统HDFS,HDFS具有高容错性,适合存储大文件并为之提供高吞吐量顺序读写,适合大量数据集。

HBase是模仿BigTable实现的一种分布式、面向列的数据库,适合非结构化数据存储。

Hadoop还实现了一个分布式计算架构Map/Reduce,为大量数据提供计算。

Hadoop具有以下特点:

(1)成本低。

不需要高配置的机器,使用数台普通PC就可以搭建Hadoop集群。

(2)高效。

Hadoop集群可由大规模商业PC构建而成,集群中的服务器可对数据进行并行处理,考虑到服务器节点之间的负载均衡,大量的数据可以在集群服务器之间进行传输。

(3)容错能力强。

随着集群节点数量的增加,集群节点故障率也会提高,一旦一个或多个机器出现故障,对集群会造成严重后果。

Hadoop通过多地备份、自动迁移复制等特性,来达到集群的高可用性和容错性。

(4)扩展性强。

集群搭建完成之后,在实际应用中数据量增长速度与累积的数量会越来越大,现有的集群很有可能会不再满足使用需求。

而基于Hadoop集簇的设计理念,其增减机器会十分方便。

接下来,我们对Hadoop的核心技术进行介绍。

MapReduce并行计算模型对外接口相对比较简便,对于大数据量的运算任务而言,输入时按照一定的规则将其构造为信息对,提交给集群中不同的服务器。

运算任务结束时,同样按照K-V数据对进行输出。

开发者在使用该计算模型的时候只需要编写对应的Map和Reduce逻辑,便可以进行大数据量的运算,极大的提高了并行程序开发的速度。

Map函数以的数据作为输入,将输入数据经过业务逻辑计算产生若干仍为形式的中间数据。

MapReduce计算框架会自动将中间数据中具有相同key值的数据聚合在一起,形成<形式的数据,并将数据传送给Reduce函数作为其输入值。

Reduce收到Map阶段传来的某个key值及其若干value值等中间数据,然后进行累加,过滤,转换等操作,生成形式的数据作为最终的业务计算结果

HDFS是Hadoop的另外一项核心技术,是一种具有高容错性的大规模分布式的文件系统。

HDFS的数据节点分为两类:

(1)元数据存储节点NameNode.SecondaryNameNode;

(2)数据存储节点DataNodeo

NameNode负责管理整个分布式文件系统的元数据,因此它是一个中心服务器,负责管理文件系统的名字空间(Namespace)及客户端对文件的访问。

SecondaryNameNode的职责并非是NameNode的热备机,它定期从NameNode上拉取fsimage和editlog文件合并后形成新的fsimage文件返回给NameNode。

这样做可以减轻NameNode的压力,NameNode本身并不做这种合并操作。

所以其本质是个检查点功能服务的服务器。

集群中一个节点一般只会启动一个DataNode实例,对其所在节点的存储和读取进行管理,在HDFS上存储的文件,实际上被分成一个或者多个数据块,这些块可以存储在一组DataNode上,HDFS客户端通过与NameNode通信获取所需读/写文件的元数据,实际的读写都是和DataNode直接通信完成的。

2.4系统设计原则

通过总结,公共设施综合管理平台的设计应遵循如下的原则:

1、实用性

系统能否顺利运行以及是否能够发挥其预期的作用就是系统实用性的具体体现。

主要表现在系统的功能与设施管理的日常业务工作要求相互吻合,功能性较强;系统操作易于掌握,用户界面友好,使用起来相对简单明了,信息充实。

系统的配置方面,可维护性较高,较为灵活;系统的反应速度在用户的可容忍范围内;通过系统界面可对系统的相关参数进行配置,无需进行经常性的代码更新。

2、安全可靠性

在系统运行过程中,能否保证系统的安全性、可靠性以及数据完整性也是十分关键的问题。

应当在网络层面、硬件层面以及软件方面防止系统被不良操作入侵,同时使用备份、容灾等技术保证在自然灾害下的数据恢复完整性。

同时对操作人员的操作、数据库中的存储信息严格控制,及时纠错,从而保证数据的可用性。

3、可扩展性

系统在开发的过程中,应当满足模块性开发,并保留相应的接口和存储空间,系统应留有一定的接口和空间,以便支持在未来的业务扩展过程中的功能调整或新功能的增加,可以通过接口对接即可实现,并且能够满足在未来较长的运行时间内的数据量增长。

4、技术先进性

在软件设计方案和硬件、使用技术选择上,在满足目前业务需求的基础上,尽量让系统具有一定的先进性,使系统不会在短期内被新技术淘汰,同时也要考虑当前技术与未来新技术之间的平稳过渡。

5、标准性

系统在设计和实现的过程中,对于核心数据和业务,应当设定统一、规范的标准,做到软件体系统一化、功能模块化、数据标准化以及相关文档规范化,在用户操作界面、报表打印生成等方面应采用统一的格式和风格,以便于用户的学习、掌握。

2.5系统功能性需求分析

通过对公共设施综合管理平台所涉及到的诸多业务部门进行调研和分析,对系统的实现进行了初步的需求分析,可暂将系统分为三大功能模块,系统的总体需求图如下图2-1所示:

图2-1功能模块分析

三大功能分别指的是:

基础信息管理功能、信息抓取功能、分布式存储功能。

其他还有一些譬如统计分析、简报生成、结果导出等功能。

力求满足管理者的管理需求,使城市公共设施管理更加便捷化。

 

第3章系统概要设计

3.1系统总体设计

本分布式的公共设施综合管理平台总的设计目标是:

搭建一个分布式平台,用于存储管理办公过程中日益增长的各式各样的数据,并且用户可以通过Web管理平台进行管理;建立以桥梁,管线为基础的公共设施数据库,实现桥梁,管线的管理、分析、评估等信息化管理;利用网络爬虫技术从相关网站上获桥梁、管线等公共设施的相关数据,并进行转换、装载、处理,形成行业信息模块。

3.2系统总体架构设计

图3-1系统总体架构设计图示

如图3-1所示,我们需要搭建一个基于Hadoop的分布式管理平台,用来存储日益增多的办公数据,用户可以通过Web管理平台对数据进行上传、删除和查找等操作。

平台的管理者除了进行公共设施的健康状况的查看外还可以进行公共设施的基本信息的管理,包括公共设施的日常养护和巡查信息的记录。

系统中整合了网络爬虫技术,对相关的公共设施网站进行信息的抓取、整合,以供平台使用者进行日常的查看。

系统还提供了一系列的统计功能,是使用者能够直观的了解辖区内的公共设施的状况,极大的方便了公共设施的日常管理。

3.3系统功能模块介绍

图3-2系统功能模块图

系统按照功能可以分为三大模块:

公共设施(桥梁,管线)基础信息管理模块、相关网站公共设施采集模块和大数据接口模块。

其中公共设施基础信息模块是面向桥梁和管线的管理用户,他们可以登录系统,分别根据自己的权限进行基础信息的操作,功能可细化为公共设施基本信息管理、公共设施隐患信息管理,公共设施统计分析。

相关网站公共设施信息采集模块是所有用户共享爬虫模块,平台用户可以用它来采集公共设施相关的网络信息。

而大数据接口则是我们进行数据存储和隐患预测的接口。

3.4系统功能模块设计

本系统主要目的是建立以桥梁,管线为基础的公共设施数据库,实现桥梁,管线的管理、分析、评估等信息化管理;利用网络爬虫技术从相关网站上爬取桥梁、管线等公共设施用户需要的四类信息进行抓取,并进行处理,形成行业信息模块;搭建一个分布式平台,用于存储管理办公过程中产生的各式各样的数据,并且用户可以通过Web管理平台进行管理。

图3-3系统功能模块设计

综合管理平台的功能模块主要分为四大部分:

桥梁管理、管线管理、爬虫管理和数据管理。

桥梁管理和管线管理是公共设施平台中对桥梁和管线进行信息管理的模块。

信息管理包括的有桥梁管线基本信息、巡查信息、隐患信息、养护维修信息和信息统计显示。

基本信息管理是桥梁或者管线的基本信息,如:

设施编号、所在运营区间、结构形式、桥跨组合等信息进行管理。

巡检信息管理模块,是对巡查信息的展示和管理,信息包括桥梁编号、巡查单位、负责人、巡查周期、巡查时间、巡查记录、桥梁状况指数。

管理员可以进行查看桥梁巡检的详细信息,对桥梁巡检信息进行编辑,删除桥梁巡检信息的操作。

这是管理员对巡检信息进行操作的渠道。

养护维护信息模块,是对养护维修信息的管理,信息包括桥梁编号,养护区段,养护单元,负责人,最近是否大修,设计单位,施工单位,竣工时间。

管理员可以进行查看养护的详细信息,对养护信息进行编辑,删除桥梁养护信息的操作,这是管理员对巡检信息进行操作的渠道。

行业信息管理模块是平台的主要功能模块,它又包括数据采集、信息抽取、数据存储和前台展现四个模块。

系统管理模块主要是对能够进行系统登录的用户进行管理。

包括新建账户、编辑账户和查询账户等功能。

文件管理模块主要是有文件上传和文件管理功能。

用户可以通过Web管理平台上传这些办公中产生的非结构化数据,以及对其进行查询、删除、更新等操作。

第4章系统详细设计

4.1主题爬虫模块详细设计

行业信息整合模块,主要是利用是主题爬虫不断地从互联网上采集桥梁管线领域的行业信息。

我们在第二章对爬虫技术进行过简要的介绍,一般的主题爬虫主要有以下几个部分的工作:

网页信息抓取,网页信息抽取,主题模型的构建和子链的预判。

由于网页去重也需要进行信息抽取和特征选择,因此特地加入网页去重模块。

经过优化后的主题爬虫主要有种子站点初始化,对于主题爬虫设计的流程图3-3所示。

由图3-3可知,主题爬虫大致分为种子站点初始化、网页下载、网页解析、网页去重、主题相关性计算和链接控制块五大模块。

首先,种子站点初始化模块将种子站点的URL加入待爬取URL队列,初始化爬虫。

网页下载模块则是不断地从待爬取队列中取出待爬取链接下载网页。

网页解析模块是从抓取的网页中抽取用户需要的信息,并将抽取的网页正文和标题送到主题相关性计算模块计算网页与主题相关性,将网页上新链接送到链接权值计算模块计算链接的主题相关性。

网页去重模块则是将与主题相关的网页正文进行中文分词、去除停用词等步骤形成网页的特征词集进行网页相似度计算,去除重复网页。

链接权值计算模块,则是计算从网页中提取链接与主题的相关度,将与主题相关的子链接插入到待爬取队列。

图4-1主题爬虫模块设计

4.2主题相关度计算模块设计

计算主题相关性的方法主要有三种,它们的特点如下:

布尔模型是一个二元模型,优点是检索结果简单明了,缺点是不能计算文档相关度大小,只能将文档判定为相关不相关;并且实际应用中,用户很难将查询需求转换为布尔表达式,因此,没有得到广泛应用。

概率模型虽然具有成熟的理论一贝叶斯决策理论,但是它没有计算词在文档中出现的整体频率,而是根据相关文档和不相关文档分别计算的概率。

向量空间模型是选取文档特征词,并为特征词赋权值(可以用多种方法),将文档转化为特征向量形式。

因此,可以通过计算余弦夹角距离来计算文档之间的相似度,因为方法明了,实现简单,在实际的应用中得到了广泛的应用。

主题基准模型,在判断与主题是否相关的时候,需要将从爬取的网页提取出的关键词,与原有的主题关键词组成的向量空间模型比较计算相关性。

这需要事先从主题相关网页中提取关键词,得到关键词库,然后用新抓取的网页中的词组与主题词库进行相关度计算。

根据以上设计主题模型流程如图3-4所示。

图4-2主题相关度计算模块设计

4.3文件管理模块设计

文件管理模块是管理公共设施管理者办公过程中出现的各式各样的非结构化文件。

其主要功能包括上传文件、删除文件、文件检索,主要的设计点在于文件上传和文件检索。

文档上传模块关键在于对小文件的处理。

经过第二章的介绍,我们知道Hadoop的HDFS是针对大文件存储进行设计的,上传到HDFS上的文件会将文件到数据块Block的映射关系存储到名称节点上,一般会占用名称节点1SOByte左右的内存空间,所以在本系统上上传小文件过多会导致命名节点的内存占用量快速增长,并且会降低Hadoop读取速度,降低系统性能。

所以本文在文档上传时根据文档大小采取不同的策略:

大与64M就存放BigFiles下,小于64M的就存放在SmallFiles下,然后对SmallFiles下的文件进行归档合并以提高系统性能。

文档查询我们是通过lucene对上传文档建立索引,然后搭建了一个简单的Solr服务器来为用户上传的文件提供文件检索功能。

本文对于一些非结构化数据如office文档、网页文件、可扩展语言标记文件等文件的标题和内容进行索引,然后提供索引服务;对于图片、音频、视频、压缩包等二进制文件主要采取对标题索引和检索。

综合上面两点所述,本

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 总结汇报 > 学习总结

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1