CN105550180B - 数据处理的方法、装置及系统 - Google Patents
数据处理的方法、装置及系统 Download PDFInfo
- Publication number
- CN105550180B CN105550180B CN201410594676.8A CN201410594676A CN105550180B CN 105550180 B CN105550180 B CN 105550180B CN 201410594676 A CN201410594676 A CN 201410594676A CN 105550180 B CN105550180 B CN 105550180B
- Authority
- CN
- China
- Prior art keywords
- file
- subset
- data
- retrieval request
- caching
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本发明公开了一种数据处理的方法、装置及系统,涉及信息技术领域,为解决检索请求大量占用系统内存的问题而发明。本发明的方法包括:对检索请求涉及的文件集合进行分组,获得多个文件子集;为第一个文件子集分配缓存,以读取第一个文件子集中的数据;在第一个文件子集中的数据读取完毕后,释放第一个文件子集的缓存,并为下一文件子集分配缓存,以读取下一文件子集中的数据;在读取到各个文件子集的数据后,对所有文件子集的数据进行合并,得到向客户端返回的用户数据。本发明主要应用于基于分布式存储系统的数据检索过程中。
Description
技术领域
本发明涉及信息技术领域,尤其涉及一种数据处理的方法、装置及系统。
背景技术
Cassandra是一种无中心节点的存储系统,根据哈希Hash算法将数据均等的分散到不同的节点中。与传统的集中式存储系统相比,分布式存储系统可以改善数据集中存储导致的系统性能受限的问题,能够提高数据存储、数据查询及数据处理的效率,更加适应大规模数据存储的场景。
MemTable是在分布式节点内存中分配的一定大小的空间,用来存放用户写入的数据。当用户向节点写入数据时,写入的数据会直接追加到节点内存中的MemTable中。当MemTable数据写满后,节点会将MemTable中的所有数据转存储(dump)到磁盘上,形成一个有序字符串表(Sorted String Table,简称SSTable)文件,从而完成对写入数据的存储,也就是说,数据是以SSTable文件格式存储在节点磁盘上的。通常,节点中的每个SSTable文件都会存储一组任意有序的键值(Key)对,Key作为SSTable文件的关键值,用于对SSTable文件中的数据进行标识(在客户端层面上,可以将Key简单理解为存储或查找数据的关键词)。对于每个Key而言,用户可以在同一时刻向节点写入同一Key值的多列(Column)信息,也可以在不同时刻向节点写入同一Key的多列Column。由于MemTable会在内存写满后转储SSTable文件,因此同一Key在不同时刻写入到MemTable中的Column会被持久化到不同的SSTable文件中,由此使得同一个Key会对应到不同的SSTable文件里。此外,客户端对对应某一Key数据的不定期修改也会导致同一个Key会分散到不同的SSTable文件中。
目前对于Cassandra这种分布式存储系统而言,当客户端检索某个Key的数据时,系统首先要找到所有包含该Key的SSTable文件,然后从这些文件中读取该Key的所有相关数据到缓存中,并对这些数据进行合并后返回给客户端。
在上述检索数据的过程中,发明人发现现有技术中至少存在如下问题:系统需要为每个SSTable文件分配一段缓存空间,以存储该SSTable文件中与Key相关的数据。实际应用中,当某个检索请求涉及的SSTable文件数量较少时,系统的缓存开销相对较少,但是随着时间的推移,同一个key的相关数据会分散到越来越多的SSTable文件中去,因此在进行检索请求时,系统会为SSTable文件分配大量的缓存。由于缓存的分配是以系统内存为支持的,因而分配过多缓存会占用大量的系统内存,使得检索请求的并发吞吐量急剧下降。
发明内容
鉴于上述问题,本发明提供了一种数据处理的方法、装置及系统,能够解决检索请求大量占用系统内存的问题。
为解决该技术问题,本发明第一方面提供了一种数据处理的方法,包括:
对检索请求涉及的文件集合进行分组,获得多个文件子集;
为第一个文件子集分配缓存,以读取第一个文件子集中的数据;
在第一个文件子集中的数据读取完毕后,释放第一个文件子集的缓存,并为下一文件子集分配缓存,以读取下一文件子集中的数据;
在读取到各个文件子集的数据后,对所有文件子集的数据进行合并,得到向客户端返回的用户数据。
本发明第二方面提供了一种数据处理的装置,包括:
分组单元,用于对检索请求涉及的文件集合进行分组,获得多个文件子集;
分配单元,用于为分组单元划分的第一个文件子集分配缓存;
读取单元,用于从分配单元分配的缓存中读取分组单元划分的第一个文件子集中的数据;
分配单元,还用于在第一个文件子集中的数据读取完毕后,释放第一个文件子集的缓存,并为分组单元划分的下一文件子集分配缓存;
读取单元,还用于从分配单元分配的缓存中读取分组单元划分的下一文件子集中的数据;
处理单元,用于在读取单元读取到各个文件子集的数据后,对读取单元读取的所有文件子集的数据进行合并,得到向客户端返回的用户数据。
本发明第三方面提供了一种数据处理的系统,包括:客户端及存储节点,其中,存储节点包括如上第二方面所指的装置。
借由上述技术方案,本发明提供的数据处理的方法、装置及系统,能够对检索请求涉及的文件集合进行分组,对分组后的多个文件子集先后分配缓存读取数据,并将各个文件子集中读取的数据进行合并从而获得返回客户端用户数据。与现有技术中同时为所有文件分配缓存相比,本发明能够将一个完整的检索过程分解为多个子检索过程进行先后执行,从而实现对缓存需求的时序分解。由于将空间维度中的缓存需求分解到了时间维度上,因此检索请求在某个时刻上所占用的系统内存大大缩小,这种“并行”转“串行”的方式可以使系统内存同时支持更多的检索请求,由此提高系统的并发吞吐量。
上述说明仅是本发明技术方案的概述,为了能够更清楚了解本发明的技术手段,而可依照说明书的内容予以实施,并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂,以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述,各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的,而并不认为是对本发明的限制。而且在整个附图中,用相同的参考符号表示相同的部件。在附图中:
图1示出了本发明实施例中一种数据处理的方法流程图;
图2示出了本发明应用场景中一种数据处理的流程图;
图3示出了本发明实施例中一种数据处理的装置的结构示意图;
图4示出了本发明实施例中另一种数据处理的装置的结构示意图;
图5示出了本发明实施例中一种数据处理的系统示意图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
为了节省Cassandra存储系统的内存资源,以使Cassandra系统可以同时支持更多的检索请求,本发明实施例提供了一种数据处理的方法。如图1所示,该方法包括:
101、对检索请求涉及的文件集合进行分组,获得多个文件子集。
Cassandra存储系统中的任何节点都可以作为接入节点,即接收、转发客户端检索请求,汇总并反馈检索结果。而同一个关键值KEY的数据SStable在分布式存储系统上会存在多个数据节点之上,每个节点都会负责从自己所管辖的文件集合中进行检索,检索结果会反馈给接入节点。接入节点汇总处理后反馈给客户端。
如前所述,一个检索请求中的关键值往往会涉及众多文件,换言之,分布式存储系统中的多个文件均包含关键值的数据,因此,一个检索请求往往涉及多个文件,本实施例将一条检索请求涉及的多个文件以文件集合的方式进行表述。
示例性的,当检索条件中包含关键词“专利”时,系统会从各个存储节点中查找所有包含关键词“专利”的文件,包括文档、表格、音视频等文件,获得由这些文件组成的文件集合。
与现有技术不同的是,在获得文件集合后,系统会对文件集合进行分组,将其划分为多个文件子集。本实施例中,对文件集合进行分组的目的在于,将检索过程分解为多个子过程,以便后续对多个子过程先后进行执行。
本实施例中文件集合分组的依据可以由网管人员决定并配置到系统中,也可以由系统自行设置。对于后者实现方式,系统自行设置分组依据的标准又可以分为两方面:一方面,系统可以根据获取的系统参数制定分组依据;另一方面,系统也可以根据文件的内容或属性信息制定分组依据。对于第一方面,系统可以参考的系统参数包括但不限于是内存大小、传输带宽、请求数量、文件数量及节点数量;而对于第二方面,系统则可以根据文件编号、文件哈希值、文件名称、文件版本号、文件类型、文件大小或文件所属节点等因素制定分组依据,本实施例不对分组依据的指定标准进行限制。
102、为第一个文件子集分配缓存,以读取第一个文件子集中的数据。
在获得多个文件子集后,系统依次从每个文件子集中读取与关键值相关的数据。具体的,系统首先为第一个文件子集分配缓存,以读取第一个文件子集中的数据。与现有技术不同的是,在读取当前文件子集的数据时,系统不向其他文件子集分配缓存。其他文件子集按照一定顺序依次等待数据读取。
本实施例中,文件子集的排序规则可以但不限于是:按照包含的文件数量进行排序、按照数据量大小进行排序、按照文件权重值之和进行排序、按照文件编号之和进行排序等。文件子集的排序顺序决定了数据读取的先后顺序。
而在一种更加便于实施的方式中,系统也可以对文件子集进行随机排序,或者按照分解的先后顺序进行排序。本实施例对文件子集的排序规则及排序顺序不做限制。
103、在第一个文件子集中的数据读取完毕后,释放第一个文件子集的缓存,并为下一文件子集分配缓存,以读取下一文件子集中的数据。
在第一个文件子集中的数据读取完毕后,系统为下一个文件子集分配缓存。本实施例中,由于各文件子集的缓存是先后进行分配的,因此在为下一个文件子集分配缓存前,系统需要对前一个文件子集的缓存进行释放。
在读取完下一个文件子集的数据后,系统重复执行步骤103,释放其缓存并继续依次对第三个、第四个文件子集分配缓存,进行数据读取,直至所有文件子集都完成数据读取为止。
104、在读取到各个文件子集的数据后,对所有文件子集的数据进行合并,得到向客户端返回的用户数据。
系统可以对读取的各个数据进行汇总式的合并,得到返回给客户端的用户数据。
进一步的,在对数据进行合并时,系统还可以对数据进行去重处理,将不同存储节点提供的相同数据进行去重,由此对检索结果进行优化。
现有技术中,当获得文件集合时,系统会为每个文件分配一段缓存,在该缓存中将文件中涉及关键值的数据抽取出来,并对抽取的各个数据进行合并得到响应检索请求的用户数据。通常,检索请求涉及的文件数量较为庞大,为一个检索请求的所有文件同时分配缓存会占用大量的系统内存。示例性的,假设系统中可服务与检索请求的内存大小为2G,某个检索请求的关键值在1000个文件中存在。如果一个文件的数据抽取需要分配32K的缓存,则为1000文件同时分配缓存就会产生32K*1000共32M的缓存开销,即一个检索请求会占用32M内存。对于2G大小的系统内存而言,最多只能同时支持64个检索请求,这样的并发吞吐量显然不能满足实际网络部署环境的需求。
而本发明实施例所提供的数据处理的方法,能够对一个检索请求涉及的所有文件进行分组,并对获得的多个文件子集依次进行缓存分配。由于同一时刻上处理的文件数量减少了,因此缓存的占用比例也会对应降低,系统可以空出更多的内存资源对其他的检索请求同时进行处理。同样以上述数据为例,假设将1000个文件划分为100个文件子集,那么每个文件子集中的文件数量为10个。如果一个文件的数据抽取需要分配32K的缓存,则同一时刻上该检索请求仅产生32K*10共320K的缓存开销,即一个检索请求只会占用320K内存。同样对于2G大小的系统内存而言,其并行吞吐量则可以扩展到6400个检索请求,与现有技术相比,能够将系统的并行吞吐量扩大100倍。
进一步的,作为对图1步骤101的细化,在本发明的另一个实施例中,还可以在检索请求和系统内存资源之间建立联动机制。系统可以根据当前系统的内存占用情况确定每个检索请求的分组系数,并通过确定的分组系数以及每个检索请求涉及文件集合中的文件总数,对文件集合进行分组。
本实施例中,分组系数用于决定分组后文件子集的数量,分组系数的确定应当使得当前内存占用比例与文件子集数量之间呈正相关关系,即当前系统内存的占用比例越高(系统内存越紧张),分组后的文件子集数量越多。建立两者正相关关系的目的在于,在系统内存紧张时,提高文件子集的数量,降低每个文件子集的缓存占用,从而提高系统的并行吞吐量;而在系统内存空闲时,降低文件子集的数量,增加每个文件子集的缓存占用,从而加快检索请求的响应时间,由此实现系统内存与检索请求之间的联动。
实际应用中,可以在每次接收到检索请求后,针对当前的系统内存情况为当前接收的检索请求确定分组系数。此外,系统还可以根据一段时间内的内存变化趋势制定分组系数,该时段内接收的检索请求均使用该分组系数进行文件分组。再或者,系统还可以允许网络管理人员根据系统内存的变化手动设置分组系数,本实施例不对分组系数获取方式进行限制。
进一步的,本实施例中所述分组系数可以但不限于是子集文件数量、集合占比和子集数量。下面本实施例将分别依据不同的分组系数对文件集合的分组进行介绍:
1)分组系数为子集文件数量
子集文件数量是指分组后每个文件子集所包含的文件数量。例如,系统确定的子集文件数量可以是:5、10、30、50、85、100、150等。子集文件数量与当前内存占用比例之间呈负相关关系,即当前内存占用比例越高子集文件数量越小。结合实际应用的情况,子集文件数量的确定区间适宜为[2,10000]。该子集文件数量由系统根据当前系统内存占比或人工设置确定得到。
示例性的,假设某个检索请求涉及的文件集合包含1500个文件,子集文件数量为30,则系统可以计算出划分的文件子集数量为1500/30共50个,其中,每个文件子集中的文件数量为30个。
需要说明的是,本实施例中不限制子集文件数量必须能够整除文件总数,当子集文件数量无法整除文件总数时,除余的文件可以单独建立一个文件子集保存。例如当文件总数除以子集文件数量得m余n时(n小于子集文件数量),则分组后的文件子集数量为m+1个。
2)分组系数为集合占比
集合占比是指文件子集的文件数量与文件总数之比,该比例值实际上可以反映出划分出的文件子集的数量。例如,当集合占比为20%时表示将文件集合划分为5个文件子集,每个文件子集包含文件总数1/5的文件。集合占比与当前内存占用比例之间呈负相关关系,即当前内存占用比例越高集合占比越小。与1)中类似的,该子集合占比同样可以由系统根据当前系统内存占比或人工设置确定得到。
实际应用中,集合占比可以被设置为5%、10%、12%、36%、65%、80%或94%,集合占比较为适宜的取值区间为[0.001%,50%]。
同样,本实施例中设置集合占比同样不必限制划分出的文件子集数为整数,当文件子集数为浮点数值时,划分的文件子集数量为整数部分加1。
3)分组系数为子集数量
较为直观的,子集数量直接用于对分组后的文件子集数量进行限制。文件子集数量与当前内存占用比例之间呈正相关关系,即当前内存占用比例越高子集数量越大。系统可以根据当前系统内存占比或人工设置直接对子集数量进行确定。
实际应用中,子集数量的取值范围为2至正无穷的正整数,与前述1)和2)不同的是,子集数量的取值不能为浮点数据。
以上仅是对分参数及分组方式进行的示例性说明,实际应用中系统还可以使用其他参数作为文件集合分组的依据,本实施例对系统可使用的具体参数不再作一一介绍。
进一步的,在本发明的另一实施例中,为进一步减少检索请求对系统内存的占用,系统还可以对相同的检索请求进行合并。一种可行的实现方式为:在执行图1步骤101之前,系统可以对多个检索请求的关键值进行分析,并将关键值相同的多个检索请求进行归一化处理,将多个相同的检索请求合并为一个检索请求,然后从步骤101开始顺序执行图1所示流程,对合并后的检索请求进行处理。在完成检索后,系统将用户数据分别反馈给发送检索请求的各个客户端,由此一次性实现对多个检索请求的响应。
再进一步的,在本发明的另一个实施例中,为减少文件调用次数过多对系统内存造成的占用,系统还可以对关联的检索请求进行合并。所谓关联的检索请求是指关键值包含于同一个文件中的多个检索请求。对于这样的文件,系统可以在一次文件调用过程中将其中涉及不同关键值的数据全部进行抽取,由此可以减少对同一文件的重复调用,继而节省调用该文件的缓存开销。
进一步的,在本发明的另一个实施例中,当存在多个检索请求时,系统可以优先为第一优先级的检索请求分配缓存。在接收到客户端的检索请求时,系统首先为检索请求分配优先级,分配优先级的依据可以但不仅限于为:检索请求的紧急程度、检索请求的来源分类、检索请求涉及的文件总数、检索请求涉及的文件子集数以及检索请求中文件子集的文件数。
其中,检索请求的紧急程度可以由客户端根据需求自行选定,紧急程度的分级由系统统一制定,可以包括“不紧急”、“一般”、“较紧急”、“十分紧急”等,紧急程度高的检索请求优先级更高;检索请求的来源分类主要是对客户端的分类,包括“员工终端”、“负责人终端”、“经理终端”及“管理员终端”等,系统可以通过检索请求的源IP地址对客户端进行识别,通常情况下管理员的请求级别最高,其余人员按照行政级别的高低划分优先级;检索请求涉及的文件总数是指文件集合中的文件数量,在接收到检索请求后,系统可以首先根据其中的关键值向存储节点获取文件,然后对获取的文件进行统计,按照文件数量的多少对检索请求进行分级,文件数量越多的请求优先级越高;与文件数类似的,检索系统还可以对检索请求涉及的文件子集数进行统计并分级,文件子集数量越多的请求优先级越高;检索请求中文件子集的文件数是指每个文件子集中的文件数量,通常该文件数量越多的请求优先级越高。
本实施例中,系统优先为第一优先级的检索请求分配缓存具有两层含义:第一,当系统内存不足时,优先处理第一优先级的检索请求,其他检索请求按优先级高低入队等待处理;第二,在同时处理不同多个检索请求时,当系统内存出现空闲时(例如某个检索请求处理完毕后释放缓存),对于正在处理的剩余检索请求,系统可以对高优先级请求中等待处理的文件子集优先分配缓存。
在上述各实施例中,系统在时序上对检索请求进行分批处理,一次仅处理一个文件子集,剩余文件子集等待处理。进一步的,为提高系统内存的使用效率,在本发明的另一实施例中,系统还可以在内存出现空闲时,为同一检索请求的至少两个文件子集同时分配缓存,以进行并行处理。例如,当某个检索请求处理完毕释放缓存时,系统可以从正在处理的检索请求中选择一个或多个检索请求(按优先级选择或随机选择等),为选择的检索请求中等待处理的一个或多个文件子集分配缓存进行处理,由此,这些检索请求就会有至少两个文件子集在同时处理。再例如,当某个检索请求处理完毕释放缓存时,系统还可以对新的检索请求进行处理,并同时对该请求中的至少两个文件子集分配缓存。
为了进一步减少系统内存的占用,在本发明的最后一个实施例中,系统还可以对重复的检索请求进一步做去重处理。在前述对检索请求去重的实施例中,系统主要针对同时发起的多个相同请求进行去重,而在本实施例中,系统可以对一段时间内先后发起的多个相同请求进行处理,由此进一步节省数据检索对系统内存的开销。实际生活中,客户端可能会对同一个关键值进行重复检索,或者在一段时间内不同客户端会对同一个关键值先后进行检索。对于此种情况,系统可以在首次处理检索请求后,对检索出的用户数据进行缓存,当下次接收向关键值相同的检索请求时,系统可以直接读取缓存中的用户数据返回给客户端。需要说明的是,存储节点中存储的数据通常会存在一定程度的动态更新,因此本实施例提供的实现方式需要对重复的检索请求进行时段限制,例如限定对于4小时或一天之内的重复请求进行上述处理,以减小数据变动的概率。此外,对于缓存的用户数据,系统还可以在空闲时段(例如夜间)对其重新进行检索,获得更新的用户数据并进行缓存,以便响应后续的相同请求。
实际应用中,上述各实施例可以应用于各种分布式存储系统中,分布式存储系统又可以为关系型数据库和非关系型数据库。下面,本发明将以Cassandra系统为例,给出本发明的一个应用场景,以实现上述各方法实施例在Cassandra系统中的应用。Cassandra系统是一种典型的无中心节点的环形结构的分布式存储系统,由众多存储节点组成,这些存储节点同时具有数据存储功能以及请求接入功能。每个存储节点都可以独立响应客户端的检索请求。Cassandra系统通过哈希(Hash)算法将数据散布存储在各个存储节点中。每个存储节点负责管理环形存储结构上的某一块连续范围(Range)的数据。数据以SSTable文件的格式存储在存储节点中。在进行数据存储时,客户端可以向系统内存中的Memtable写入若干列(Column)涉及关键值Key的数据。当Memtable写满后,系统会将Memtable中的数据转储到存储节点的磁盘上,形成SSTable文件。
如图2所示,基于上述的系统架构及存储特性,本场景中进行数据检索的流程包括:
201、存储节点接收客户端发送的检索请求。
Cassandra系统中的每个存储节点都独立具有请求接入功能,本方案中以众多存储节点中的一个存储节点为例进行说明。其中,存储节点接收的检索请求中携带有关键值Key。
202、存储节点根据内存中的文件索引查找所有包含Key数据的SSTable文件,得到SSTable文件集合。
这些SSTable文件可以为存储节点自身存储的SSTable文件,也可以为其他存储节点中存储的SSTable文件。
203、存储节点对SSTable文件集合进行分组,得到多个SSTable文件子集。
示例性的,SSTable文件集合包含2000个SSTable文件,存储节点将SSTable文件集合划分为100个SSTable文件子集,每个文件子集包括20个SSTable文件。
204、存储节点为一个SSTable文件子集中的20个SSTable文件分别分配缓存,打开各个SSTable文件将其中的数据读取到对应的缓存中。
示例性的,存储节点为每个SSTable文件分配32K的缓存,为第一个SSTable文件子集分配的缓存共为640K。
205、存储节点对该SSTable文件子集中读取的数据进行合并。
存储节点将从20个SSTable文件中抽取的数据反序列化为Column数据,并进行合并得到对应该SSTable文件子集的中间数据。同时,存储节点关闭20个SSTable文件,释放其缓存。
在执行完步骤205后,存储节点重复执行204和步骤205,抽取第2个、第3个直至第100个SSTable文件子集的中间数据。
206、存储节点对获得的100个中间数据进行合并,获得最终的用户数据。
存储节点将获得的用户数据反馈给客户端,结束数据检索流程。
在本场景中,任意时刻上一个检索请求占用的缓存为640K,对于2G内存而言,一个存储节点可以同时支持3200个检索请求,大大提高了Cassandra系统的并行吞吐量。
进一步的,作为对上述各实施例所述方法的实现,本发明还提供了一种数据处理的装置,该装置可以位于分布式存储系统中的存储节点中,或独立于存储节点并与存储节点之间具有数据交互关系,用于对上述各实施例所述的方法进行实现。如图3所示,该装置包括:分组单元31、分配单元32、读取单元33以及处理单元34,其中,
分组单元31,用于对检索请求涉及的文件集合进行分组,获得多个文件子集;
分配单元32,用于为分组单元31划分的第一个文件子集分配缓存;
读取单元33,用于从分配单元32分配的缓存中读取分组单元31划分的第一个文件子集中的数据;
分配单元32,还用于在第一个文件子集中的数据读取完毕后,释放第一个文件子集的缓存,并为分组单元31划分的下一文件子集分配缓存;
读取单元33,还用于从分配单元32分配的缓存中读取分组单元31划分的下一文件子集中的数据;
处理单元34,用于在读取单元33读取到各个文件子集的数据后,对读取单元33读取的所有文件子集的数据进行合并,得到向客户端返回的用户数据。
进一步的,如图4所示,分组单元31,包括:
确定模块311,用于根据当前的内存占用情况确定分组系数;
划分模块312,用于通过确定模块311确定的分组系数以及文件集合中的文件总数,对文件集合进行分组;
其中,当前内存占用比例与分组后的文件子集数量之间呈正相关关系。
进一步的,确定模块311确定的分组系数为每个文件子集中的文件数量,文件数量与当前内存占用比例之间呈负相关关系。
进一步的,确定模块311确定的分组系数为文件子集对文集集合的集合占比,集合占比与当前内存占用比例之间呈负相关关系。
进一步的,确定模块311确定的分组系数为文件子集数量,文件子集数量与当前内存占用比例之间呈正相关关系。
进一步的,如图4所示,该装置进一步包括:
合并单元35,用于当存在多个检索请求时,在分组单元31对对检索请求涉及的文件集合进行分组之前,对检索对象相同的检索请求进行归一化处理。
进一步的,分配单元32,用于当存在多个检索请求时,优先为第一优先级的检索请求分配缓存;
其中,第一优先级检索请求的划分依据包括:
检索请求的紧急程度、检索请求的来源分类、检索请求涉及的文件总数、检索请求涉及的文件子集数以及检索请求中文件子集的文件数。
进一步的,分配单元32,用于当内存空闲时,为同一检索请求的至少两个文件子集同时分配缓存。
进一步的,如图4所示,该装置还包括:
写入单元36,用于对请求超过预设频率阈值或预设次数阈值的检索请求,在读取单元33读取其用户数据之后,将读取单元33读取的用户数据写入缓存;
处理单元34,用于当再次接收到同一检索请求时,从缓存中获取用户数据。
实际应用中,上述图3或图4所示的装置可以位于Cassandra系统中的存储节点中,或独立于存储节点并与存储节点之间具有数据交互关系,用于对上述各实施例所述的方法进行实现。
本发明实施例提供的数据处理的装置,能够对检索请求涉及的文件集合进行分组,对分组后的多个文件子集先后分配缓存读取数据,并将各个文件子集中读取的数据进行合并从而获得返回客户端用户数据。与现有技术中同时为所有文件分配缓存相比,本发明实施例提供的数据处理的装置,能够将一个完整的检索过程分解为多个子检索过程进行先后执行,从而实现对缓存需求的时序分解。由于将空间维度中的缓存需求分解到了时间维度上,因此检索请求在某个时刻上所占用的系统内存大大缩小,这种“并行”转“串行”的方式可以使系统内存同时支持更多的检索请求,由此提高系统的并发吞吐量。
进一步的,作为对上述各实施例所述方法的实现,本发明还提供了一种数据处理的系统,用以对上述各实施例所述的方法进行实现。如图5所示,该系统包括:客户端51及存储节点52,其中,存储节点52包括如前述图3或图4所示的装置,或与前述图3或图4所示的装置之间具有数据交互关系。
实际应用中,上述各存储节点52所组成的存储系统可以为Cassandra系统,其中每个存储节点52均可以独立响应自身接入的客户端51所发送检索请求。
本发明实施例提供的数据处理的系统,能够对检索请求涉及的文件集合进行分组,对分组后的多个文件子集先后分配缓存读取数据,并将各个文件子集中读取的数据进行合并从而获得返回客户端用户数据。与现有技术中同时为所有文件分配缓存相比,本发明实施例提供的数据处理的系统,能够将一个完整的检索过程分解为多个子检索过程进行先后执行,从而实现对缓存需求的时序分解。由于将空间维度中的缓存需求分解到了时间维度上,因此检索请求在某个时刻上所占用的系统内存大大缩小,这种“并行”转“串行”的方式可以使系统内存同时支持更多的检索请求,由此提高系统的并发吞吐量。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
可以理解的是,上述方法及装置中的相关特征可以相互参考。另外,上述实施例中的“第一”、“第二”等是用于区分各实施例,而并不代表各实施例的优劣。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述,构造这类系统所要求的结构是显而易见的。此外,本发明也不针对任何特定编程语言。应当明白,可以利用各种编程语言实现在此描述的本发明的内容,并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。
类似地,应当理解,为了精简本公开并帮助理解各个发明方面中的一个或多个,在上面对本发明的示例性实施例的描述中,本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说,如下面的权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外,本领域的技术人员能够理解,尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如,在下面的权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现,或者以在一个或者多个处理器上运行的软件模块实现,或者以它们的组合实现。本领域的技术人员应当理解,可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的发明名称(如确定网站内链接等级的装置)中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如,计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上,或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到,或者在载体信号上提供,或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制,并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中,不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
Claims (19)
1.一种数据处理的方法,其特征在于,所述方法包括:
对检索请求涉及的文件集合进行分组,获得多个文件子集;
为第一个文件子集分配缓存,以读取所述第一个文件子集中的数据;
在所述第一个文件子集中的数据读取完毕后,释放所述第一个文件子集的缓存,并为下一文件子集分配缓存,以读取所述下一文件子集中的数据;
在读取到各个文件子集的数据后,对所有文件子集的数据进行合并,得到向客户端返回的用户数据;
所述对检索请求涉及的文件集合进行分组,包括:
根据当前的内存占用情况确定分组系数;
通过分组系数以及所述文件集合中的文件总数,对所述文件集合进行分组。
2.根据权利要求1所述的方法,其特征在于,
当前内存占用比例与分组后的文件子集数量之间呈正相关关系。
3.根据权利要求2所述的方法,其特征在于,所述分组系数为每个文件子集中的文件数量,所述文件数量与所述当前内存占用比例之间呈负相关关系。
4.根据权利要求2所述的方法,其特征在于,所述分组系数为文件子集对所述文件集合的集合占比,所述集合占比与所述当前内存占用比例之间呈负相关关系。
5.根据权利要求2所述的方法,其特征在于,所述分组系数为文件子集数量,所述文件子集数量与所述当前内存占用比例之间呈正相关关系。
6.根据权利要求1所述的方法,其特征在于,在所述对检索请求涉及的文件集合进行分组之前,所述方法进一步包括:
当存在多个检索请求时,对检索对象相同的检索请求进行归一化处理。
7.根据权利要求1所述的方法,其特征在于,所述方法进一步包括:
当存在多个检索请求时,优先为第一优先级的检索请求分配缓存;
其中,所述第一优先级检索请求的划分依据包括:
检索请求的紧急程度、检索请求的来源分类、检索请求涉及的文件总数、检索请求涉及的文件子集数以及检索请求中文件子集的文件数。
8.根据权利要求1所述的方法,其特征在于,当内存空闲时,所述方法进一步包括:
为同一检索请求的至少两个文件子集同时分配缓存。
9.根据权利要求1所述的方法,其特征在于,对请求超过预设频率阈值或预设次数阈值的检索请求,在读取其用户数据之后,所述方法进一步包括:
将所述用户数据写入缓存;
当再次接收到同一检索请求时,从所述缓存中获取所述用户数据。
10.一种数据处理的装置,其特征在于,所述装置包括:
分组单元,用于对检索请求涉及的文件集合进行分组,获得多个文件子集;
分配单元,用于为所述分组单元划分的第一个文件子集分配缓存;
读取单元,用于从所述分配单元分配的缓存中读取所述分组单元划分的所述第一个文件子集中的数据;
所述分配单元,还用于在所述第一个文件子集中的数据读取完毕后,释放所述第一个文件子集的缓存,并为所述分组单元划分的下一文件子集分配缓存;
读取单元,还用于从所述分配单元分配的缓存中读取所述分组单元划分的所述下一文件子集中的数据;
处理单元,用于在所述读取单元读取到各个文件子集的数据后,对所述读取单元读取的所有文件子集的数据进行合并,得到向客户端返回的用户数据;
所述分组单元,包括:
确定模块,用于根据当前的内存占用情况确定分组系数;
划分模块,用于通过所述确定模块确定的所述分组系数以及所述文件集合中的文件总数,对所述文件集合进行分组。
11.根据权利要求10所述的装置,其特征在于,
当前内存占用比例与分组后的文件子集数量之间呈正相关关系。
12.根据权利要求11所述的装置,其特征在于,所述确定模块确定的所述分组系数为每个文件子集中的文件数量,所述文件数量与所述当前内存占用比例之间呈负相关关系。
13.根据权利要求11所述的装置,其特征在于,所述确定模块确定的所述分组系数为文件子集对所述文件集合的集合占比,所述集合占比与所述当前内存占用比例之间呈负相关关系。
14.根据权利要求11所述的装置,其特征在于,所述确定模块确定的所述分组系数为文件子集数量,所述文件子集数量与所述当前内存占用比例之间呈正相关关系。
15.根据权利要求10所述的装置,其特征在于,所述装置进一步包括:
合并单元,用于当存在多个检索请求时,在所述分组单元对所述对检索请求涉及的文件集合进行分组之前,对检索对象相同的检索请求进行归一化处理。
16.根据权利要求10所述的装置,其特征在于,所述分配单元,用于当存在多个检索请求时,优先为第一优先级的检索请求分配缓存;
其中,所述第一优先级检索请求的划分依据包括:
检索请求的紧急程度、检索请求的来源分类、检索请求涉及的文件总数、检索请求涉及的文件子集数以及检索请求中文件子集的文件数。
17.根据权利要求10所述的装置,其特征在于,所述分配单元,用于当内存空闲时,为同一检索请求的至少两个文件子集同时分配缓存。
18.根据权利要求10所述的装置,其特征在于,所述装置还包括:
写入单元,用于对请求超过预设频率阈值或预设次数阈值的检索请求,在所述读取单元读取其用户数据之后,将所述读取单元读取的所述用户数据写入缓存;
所述处理单元,用于当再次接收到同一检索请求时,从所述缓存中获取所述用户数据。
19.一种数据处理的系统,其特征在于,所述系统包括客户端及存储节点,其中,所述存储节点包括如上述权利要求10至18中任一项所述的装置。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410594676.8A CN105550180B (zh) | 2014-10-29 | 2014-10-29 | 数据处理的方法、装置及系统 |
CN201811617963.0A CN109634933A (zh) | 2014-10-29 | 2014-10-29 | 数据处理的方法、装置及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410594676.8A CN105550180B (zh) | 2014-10-29 | 2014-10-29 | 数据处理的方法、装置及系统 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811617963.0A Division CN109634933A (zh) | 2014-10-29 | 2014-10-29 | 数据处理的方法、装置及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN105550180A CN105550180A (zh) | 2016-05-04 |
CN105550180B true CN105550180B (zh) | 2019-02-12 |
Family
ID=55829369
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811617963.0A Pending CN109634933A (zh) | 2014-10-29 | 2014-10-29 | 数据处理的方法、装置及系统 |
CN201410594676.8A Active CN105550180B (zh) | 2014-10-29 | 2014-10-29 | 数据处理的方法、装置及系统 |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811617963.0A Pending CN109634933A (zh) | 2014-10-29 | 2014-10-29 | 数据处理的方法、装置及系统 |
Country Status (1)
Country | Link |
---|---|
CN (2) | CN109634933A (zh) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10884980B2 (en) | 2017-07-26 | 2021-01-05 | International Business Machines Corporation | Cognitive file and object management for distributed storage environments |
US10817515B2 (en) | 2017-07-26 | 2020-10-27 | International Business Machines Corporation | Cognitive data filtering for storage environments |
CN109240607B (zh) * | 2018-08-21 | 2022-02-18 | 郑州云海信息技术有限公司 | 一种文件读取方法和装置 |
CN109783523B (zh) * | 2019-01-24 | 2022-02-25 | 广州虎牙信息科技有限公司 | 一种数据处理方法、装置、设备和存储介质 |
CN111444023A (zh) * | 2020-04-13 | 2020-07-24 | 中国银行股份有限公司 | 一种数据的处理方法、装置、设备及可读存储介质 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103259745A (zh) * | 2013-05-31 | 2013-08-21 | 东蓝数码股份有限公司 | 一种用于网络编程中提高缓冲区内存使用率的设计方法 |
CN103744628A (zh) * | 2014-01-27 | 2014-04-23 | 北京奇虎科技有限公司 | SSTable文件存储方法及装置 |
CN104360824A (zh) * | 2014-11-10 | 2015-02-18 | 北京奇虎科技有限公司 | 一种数据合并的方法和装置 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5408652A (en) * | 1990-08-31 | 1995-04-18 | Fujitsu Limited | Method and apparatus for heterogenous database access by generating different access procedures for different database data structures |
CN102929929B (zh) * | 2012-09-24 | 2016-09-14 | 深圳市网信联动通信技术股份有限公司 | 一种数据汇总方法和装置 |
CN103559244B (zh) * | 2013-10-28 | 2016-08-24 | 东软集团股份有限公司 | 基于mbx格式的邮件正文的获取方法及系统 |
-
2014
- 2014-10-29 CN CN201811617963.0A patent/CN109634933A/zh active Pending
- 2014-10-29 CN CN201410594676.8A patent/CN105550180B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103259745A (zh) * | 2013-05-31 | 2013-08-21 | 东蓝数码股份有限公司 | 一种用于网络编程中提高缓冲区内存使用率的设计方法 |
CN103744628A (zh) * | 2014-01-27 | 2014-04-23 | 北京奇虎科技有限公司 | SSTable文件存储方法及装置 |
CN104360824A (zh) * | 2014-11-10 | 2015-02-18 | 北京奇虎科技有限公司 | 一种数据合并的方法和装置 |
Also Published As
Publication number | Publication date |
---|---|
CN109634933A (zh) | 2019-04-16 |
CN105550180A (zh) | 2016-05-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6263364B1 (en) | Web crawler system using plurality of parallel priority level queues having distinct associated download priority levels for prioritizing document downloading and maintaining document freshness | |
US6351755B1 (en) | System and method for associating an extensible set of data with documents downloaded by a web crawler | |
CN105550180B (zh) | 数据处理的方法、装置及系统 | |
CN102831120B (zh) | 一种数据处理方法及系统 | |
US8543596B1 (en) | Assigning blocks of a file of a distributed file system to processing units of a parallel database management system | |
CN110291518A (zh) | 合并树无用单元指标 | |
US6772163B1 (en) | Reduced memory row hash match scan join for a partitioned database system | |
Cheng et al. | Efficient query processing on graph databases | |
CN110162528A (zh) | 海量大数据检索方法及系统 | |
CN106294352B (zh) | 一种文件处理方法、装置和文件系统 | |
CN107025243A (zh) | 一种资源数据的查询方法、查询客户端和查询系统 | |
CN106354434A (zh) | 日志数据的存储方法及系统 | |
US7917495B1 (en) | System and method for processing query requests in a database system | |
JP2014142940A (ja) | 記憶側記憶要求管理 | |
KR101744892B1 (ko) | 시계열 계층 인덱싱을 이용한 데이터 검색 시스템 및 데이터 검색 방법 | |
US11308066B1 (en) | Optimized database partitioning | |
CN110245134B (zh) | 一种应用于搜索服务的增量同步方法 | |
CN109033462A (zh) | 在大数据存储的存储设备中确定低频数据项的方法及系统 | |
CN113590332B (zh) | 内存管理方法、装置及内存分配器 | |
US7509461B1 (en) | Method and apparatus for intelligent buffer cache pre-emption | |
CN106649385B (zh) | 基于HBase数据库的数据排序方法和装置 | |
CN109117426A (zh) | 分布式数据库查询方法、装置、设备及存储介质 | |
JP5371656B2 (ja) | ファイル検索システム | |
CN108197275A (zh) | 一种分布式文件列存储索引方法 | |
US7406461B1 (en) | System and method for processing a request to perform an activity associated with a precompiled query |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
TR01 | Transfer of patent right | ||
TR01 | Transfer of patent right |
Effective date of registration: 20220803 Address after: Room 801, 8th floor, No. 104, floors 1-19, building 2, yard 6, Jiuxianqiao Road, Chaoyang District, Beijing 100015 Patentee after: BEIJING QIHOO TECHNOLOGY Co.,Ltd. Address before: 100088 room 112, block D, 28 new street, new street, Xicheng District, Beijing (Desheng Park) Patentee before: BEIJING QIHOO TECHNOLOGY Co.,Ltd. Patentee before: Qizhi software (Beijing) Co.,Ltd. |