近实时搜索服务的优化方法
阅读：157发布：2023-02-27
专利汇可以提供近实时搜索服务的优化方法专利检索，专利查询，专利分析的服务。并且本 申请 公开了一种近实时搜索服务的优化方法，方法包括创建SolrCloud；设置热数据集；设置冷数据集；接收待索引的新数据；待索引的新数据被冷数据集处理并存储；当待索引的新数据在热数据集中时，则在热数据集中进行检索；当待索引的新数据不在热数据集中时，则在冷数据集中进行检索；当待索引的新数据部分在热数据集中时，则在热数据集和冷数据集中分别进行检索。本 发明 使用冷、热数据动态调整的模式，极大的提高了搜索速度，并提高了用户的体验和系统的搜索性能。通过在单台 服务器 上的每个磁盘中创建至少一个Solr实例，极大的提高了数据读取的速度，降低因读取数据而对整个搜索服务造成的耗时。，下面是近实时搜索服务的优化方法专利的具体信息内容。
1.一种近实时搜索服务的优化方法，其特征在于，包括步骤：
创建SolrCloud，包括步骤：
在服务器的每一块磁盘上创建至少一个Solr实例，其中，所述服务器数量至少为一个，所述Solr实例包括NRT模式的Solr实例和RAM模式的Solr实例；
对所述每一块磁盘上的每一个Solr实例进行命名，并分配内存；
设置热数据集：通过所述RAM模式的Solr实例，将热数据存储到所述热数据集指定的所述服务器内存中；
设置冷数据集：通过所述NRT模式的Solr实例，将冷数据存储到所述冷数据集指定的磁盘或固态硬盘中，同时自动将所述冷数据集中命中次数超过命中阈值的数据缓存到所述服务器内存中；
接收待索引的新数据；
所述待索引的新数据被所述冷数据集处理并存储；
当所述待索引的新数据在所述热数据集中时，则在所述热数据集中进行检索；
当所述待索引的新数据不在所述热数据集中时，则在所述冷数据集中进行检索；
当所述待索引的新数据部分在所述热数据集中时，则在所述热数据集和所述冷数据集中分别进行检索。
2.根据权利要求1所述的近实时搜索服务的优化方法，其特征在于，当所述冷数据集中的冷数据被搜索或命中的次数超过所述命中阈值时，则将所述冷数据从所述冷数据集中添加到所述热数据集中；
当所述热数据集中的热数据超过时间阈值还未被搜索、或者命中次数低于次数阈值时，则将所述热数据从所述热数据集中剔除。
3.根据权利要求1所述的近实时搜索服务的优化方法，其特征在于，在所述冷数据集中进行检索，进一步为，在所述冷数据集中定位所述待索引的新数据所在的子冷数据集，在所述子冷数据集中行检索。
4.根据权利要求1所述的近实时搜索服务的优化方法，其特征在于，所述热数据为被搜索或命中次数超过所述命中阈值的数据。
5.根据权利要求1所述的近实时搜索服务的优化方法，其特征在于，所述冷数据为低于所述时间阈值未被搜索、或者命中次数低于所述次数阈值的数据。
6.根据权利要求1所述的近实时搜索服务的优化方法，其特征在于，所述冷数据集为全量数据集，包括热数据集。
7.根据权利要求1所述的近实时搜索服务的优化方法，其特征在于，所述每一块磁盘的总内存相等。
近实时搜索服务的优化方法
技术领域
[0001] 本发明涉及计算机应用技术领域，尤其涉及一种近实时搜索服务的优化方法。
背景技术
[0002] 目前比较常见的搜索技术有Solr、Elasticsearch等，其原理和技术相对比较成熟，但在特定行业或特定业务场景中，普通的架构和方案已经不能满足对其性能的要求。
[0003] 普通系统或项目中的搜索服务，最早是由数据库的查询实现的，比较适合小数据集和简单业务场景，实现简单、成本较低。对于大数据集或业务稍微复杂的情况就会力不从心了，当数据量达到千万级以上，普通的查询或搜索已经耗时非常长，不能满足用户对系统的性能要求。
[0004] 目前比较流行的搜索技术有Solr、Elasticsearch(基于Lucence的企业级搜索应用服务器)等，其均基于Lucence(开放源代码的全文检索引擎的工具包)内核实现，能够提供快速的搜索服务并提供丰富的搜索接口。在数据规模在千万级时，能够实现毫秒级的搜索服务。随着数据的积累，索引文件越来越大，在全量数据中搜索数据耗时也会越来长。
[0005] 为减小单个服务器的压力，SolrCloud技术，实现了搜索服务的分布式搜索模式，将数据集均衡分布到多台服务器，从而减轻单台服务器的数据集大小，可实现数据的负载均衡、提高服务的数据容灾能力。但硬件资源不可能无限增加，单台服务器的数据集还是会逐渐增大。
[0006] 进一步的，有一种将Solr和HBase相结合的方案，通过HBase(分布式、面向列的开源数据库)存储元数据，Solr提供二级索引服务，从而减小Solr索引数据集的大小，降低搜索时服务器的内存压力，从而提高搜索速度。但随着数据集的持续增长，Solr索引数据还是会越来越大，达到亿级数据时，耗时之长还是让人无法忍受。数据的持续增长和快速搜索的矛盾得不到有效解决。
[0007] 以上多种方案，均不能解决数据持续增长与稳定搜索速度的矛盾问题。传统的思路和方案，在硬件资源一定的情况下，随着数据量的增大，必定会引起搜索性能的下降。
[0008] 究其原因存在以及几个问题：
[0009] 1、存在小范围检索，大范围筛选的情况。即大部分的搜索结果可能只在部分数据集中存储，在其设计的过程中未能有效分析此种情况，在全量数据集中索引，必定会耗费更多的内存等硬件资源。
[0010] 2、热数据与冷数据没有动态调整。即绝大多数的搜索结果数据可能只存在于最近的新索引数据或经常被搜索的数据集等热点数据中，未能有效筛选此类热数据，在搜索其它更大量的旧索引数据或不经常被搜索的数据集等冷数据时，也是会需要更多的时间和硬件资源。
[0011] 3、单服务器单服务。即常规的SolrCloud架构，在一台服务器上创建一个Solr实例，只能充分使用单块磁盘，而其它磁盘均处于闲置状态。随着大数据量的读取操作时，单块磁盘的读写性能成为搜索服务的一个瓶颈。
发明内容
[0012] 本发明公开了一种近实时搜索服务的优化方法，包括步骤：
[0013] 创建SolrCloud，包括步骤：
[0014] 在服务器的每一块磁盘上创建至少一个Solr实例，其中，所述服务器数量至少为一个，所述Solr实例包括NRT模式的Solr实例和RAM模式的Solr实例；
[0015] 对所述每一块磁盘上的每一个Solr实例进行命名，并分配内存；
[0018] 接收待索引的新数据；
[0019] 所述待索引的新数据被所述冷数据集处理并存储；
[0020] 当所述待索引的新数据在所述热数据集中时，则在所述热数据集中进行检索；
[0021] 当所述待索引的新数据不在所述热数据集中时，则在所述冷数据集中进行检索；
[0022] 当所述待索引的新数据部分在所述热数据集中时，则在所述热数据集和所述冷数据集中分别进行检索。
[0023] 优选地，当所述冷数据集中的冷数据被搜索或命中的次数超过所述命中阈值时，则将所述冷数据从所述冷数据集中添加到所述热数据集中；
[0024] 当所述热数据集中的热数据超过时间阈值还未被搜索、或者命中次数低于次数阈值时，则将所述热数据从所述热数据集中剔除。
[0025] 优选地，在所述冷数据集中进行检索，进一步为，在所述冷数据集中定位所述待索引的新数据所在的子冷数据集，在所述子冷数据集中行检索。
[0026] 优选地，所述热数据为被搜索或命中次数超过所述命中阈值的数据。
[0027] 优选地，所述冷数据为低于所述时间阈值未被搜索、或者命中次数低于所述次数阈值的数据。
[0028] 优选地，所述冷数据集为全量数据集，包括热数据集。
[0029] 优选地，所述每一块磁盘的总内存相等。
[0030] 与现有技术相比，本发明提供的近实时搜索服务的优化方法，达到如下有益效果：
[0031] 第一，本发明将冷数据集在逻辑上和物理上将其拆分成多个子冷数据集，在提供搜索服务时，可在逻辑上快速缩小待搜索集合的范围，将更多的计算资源用于较小的数据集，提高了搜索速度。
[0032] 第二，本发明使用冷、热数据动态调整的模式，将命中率高、被搜索次数多的热数据集存储到价格昂贵的且有限的内存中，提供了一个设计上的缓存，将长时间未命中或被搜索频率较低的冷数据集存放在价格廉价且搜索速度相对较慢的磁盘或硬盘当中，极大的提高了搜索速度，并提高了用户的体验和系统的搜索性能。
[0033] 第三，本发明通过在单台服务器上的每个磁盘中创建至少一个Solr实例，组成一个SolrCloud，充分利用了服务器的价格廉价的磁盘资源，将单块磁盘上的数据均分到多块磁盘上，在同样数据集的情况下，多块磁盘可同时进行磁盘读取操作，极大的提高了数据读取的速度，降低因读取数据而对整个搜索服务造成的耗时。
附图说明
[0035] 此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
[0036] 图1为本发明实施例1中近实时搜索服务的优化方法的数据索引图；
[0037] 图2为本发明实施例1中近实时搜索服务的优化方法的数据检索图；
[0038] 图3为本发明实施例2中近实时搜索服务的优化方法的SolrCloud创建流程图；
[0039] 图4为本发明实施例2中近实时搜索服务的优化方法的冷、热数据集存储流程图；
[0040] 图5为本发明实施例3中近实时搜索服务的优化方法的搜索服务的架构图；
[0041] 图6为本发明实施例3中近实时搜索服务的优化方法的搜索服务的流程图。
具体实施方式
[0042] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。应注意到，所描述的实施例实际上仅仅是本发明一部分实施例，而不是全部的实施例，且实际上仅是说明性的，决不作为对本发明及其应用或使用的任何限制。本申请的保护范围当视所附权利要求所界定者为准。
[0043] 实施例1：
[0044] 所示为本申请所述近实时搜索服务的优化方法的具体实施例，该方法包括：
[0045] 参见图1为数据索引图，包括步骤101-步骤105；
[0046] 步骤101、创建SolrCloud，包括步骤：
[0047] 在服务器的每一块磁盘上创建至少一个Solr实例，其中，所述服务器数量至少为一个，所述Solr实例包括NRT模式的Solr实例和RAM模式的Solr实例；所述Solr实例用于存储索引数据并提供搜索服务；
[0048] 对所述每一块磁盘上的每一个Solr实例进行命名，并分配内存；
[0049] 步骤102、设置热数据集：通过所述RAM模式的Solr实例，将热数据存储到所述热数据集指定的所述服务器内存中；
[0050] 步骤103、设置冷数据集：通过所述NRT模式的Solr实例，将冷数据存储到所述冷数据集指定的磁盘或固态硬盘中，同时自动将所述冷数据集中命中次数超过命中阈值的数据缓存到所述服务器内存中；
[0051] 步骤104、接收待索引的新数据；
[0052] 步骤105、所述待索引的新数据被所述冷数据集处理并存储；
[0053] 参见图2为数据检索图，包括步骤106-步骤108；
[0054] 步骤106、当所述待索引的新数据在所述热数据集中时，则在所述热数据集中进行检索；
[0055] 步骤107、当所述待索引的新数据不在所述热数据集中时，则在所述冷数据集中进行检索；
[0056] 步骤108、当所述待索引的新数据部分在所述热数据集中时，则在所述热数据集和所述冷数据集中分别进行检索。
[0057] 实施例2：
[0058] 本申请提供了近实时搜索服务的优化方法的另一个实施例，该方法包括：
[0059] 步骤201、创建SolrCloud，参见图3所示，包括步骤：
[0060] 在服务器的每一块磁盘上创建至少一个Solr实例，其中，所述服务器数量至少为一个，所述Solr实例包括NRT模式的Solr实例和RAM模式的Solr实例；
[0061] 对所述每一块磁盘上的每一个Solr实例进行命名，并分配内存，所述每一块磁盘的总内存相等；
[0062] 步骤202、设置热数据集：通过所述RAM模式的Solr实例，将热数据存储到所述热数据集指定的所述服务器内存中；
[0063] 步骤203、设置冷数据集：通过所述NRT模式的Solr实例，将冷数据存储到所述冷数据集指定的磁盘或固态硬盘中，同时自动将所述冷数据集中命中次数超过命中阈值的数据缓存到所述服务器内存中，参见图4所示；
[0064] 步骤204、接收待索引的新数据；
[0065] 步骤205、所述待索引的新数据被所述冷数据集处理并存储；
[0066] 步骤206、当所述待索引的新数据在所述热数据集中时，则在所述热数据集中进行检索；
[0067] 步骤207、当所述待索引的新数据不在所述热数据集中时，则在所述冷数据集中进行检索；
[0068] 步骤208、当所述待索引的新数据部分在所述热数据集中时，则在所述热数据集和所述冷数据集中分别进行检索。
[0069] 上述步骤203中，当所述冷数据集中的冷数据被搜索或命中的次数超过所述命中阈值时，则将所述冷数据从所述冷数据集中添加到所述热数据集中；所述冷数据为低于所述时间阈值未被经常搜索、或者命中次数低于所述次数阈值的数据；所述冷数据集为全量数据集，包括热数据集。
[0070] 上述步骤202中，当所述热数据集中的热数据超过时间阈值还未被搜索、或者命中次数低于次数阈值时，则将所述热数据从所述热数据集中剔除；所述热数据为被搜索或命中次数超过所述命中阈值的数据。
[0071] 上述步骤207中，在所述冷数据集中进行检索，具体方法为，在所述冷数据集中定位所述待索引的新数据所在的子冷数据集，在对应的子冷数据集中进行检索。
[0072] 所述命中阈值、所述时间阈值和所述次数阈值根据实际情况确定。
[0073] 实施例3：
[0074] 本实施例提供了近实时搜索服务的优化方法的一个实用型实施例，具体如下：
[0075] 提供两台服务器用于搭建搜索服务，每台服务器的配置均为64GB内存，两块1TB的硬盘。
[0076] 在第一台服务器的磁盘上创建两个NRT模式的Solr实例，并分别分配8GB的内存，命名为Solr1和Solr2；再创建一个RAM模式的Solr实例，并分配16GB的内存，命名为Solr3。同样的，在第二台服务器的磁盘上也同样创建两个NRT模式的Solr实例，分别分配8GB的内存，并命名为Solr4和Solr5；再创建一个RAM模式的Solr实例，并分配16GB的内存，命名为Solr6。
[0077] 创建多个用于存储全量数据(默认为冷数据)的ColdCollection集合，配置4个Shard，由Solr1、Solr2、Solr4和Solr5这四个NRT模式的Solr实例共同提供服务。创建一个用于存储热数据的集合，命名为HotCollection，配置2个Shard，有Solr3和Solr6这两个RAM模式的Solr实例共同提供服务。
[0078] 待索引数据为某地市的过车数据，包括唯一编号、车牌号码、过车时间、过车日期、车辆特征等，其对应的模式文件设置见表1所示。
[0079] 表1某地市的过车数据
[0080]序号 name type indexed stored 说明
1 Id string true true 编号
2 PlateNo string true false 车牌号码
3 PassDate pdate true false 过车日期
4 PassTime pTime true false 过车时间
5 IMGUrl string true false 图片地址
6 Address string true false 拍摄地址
7 Other string true false 其他特征
1 Id string true true 编号
2 PlateNo string true false 车牌号码
3 PassDate pdate true false 过车日期
4 PassTime pTime true false 过车时间
5 IMGUrl string true false 图片地址
6 Address string true false 拍摄地址
7 Other string true false 其他特征
[0081] 随着时间的推移，过车数据会持续不断的实时索引进Solr集合。相对来说，时间距离越近的过车数据对用户来说越有意义且搜索次数会越多，时间距离越远的过车数据被搜索的次数会越少。
[0082] 参见图5和图6所示，基于以上业务场景，将最近的一个月的数据动态存储到集合“HotCollection”中作为热数据提供搜索服务；将全量过车数据根据过车时间按月份别存储到不同的ColdCollection中。
[0083] 对于存放热数据的集合“HotCollection”，如果当前时间是2018年10月26日，那么2018年9月26日至2018年10月26日的过车数据作为热数据存储到“HotCollection”集合中，而且后续的过车数据会不断的索引到“HotCollection”集合。当时间到第二天即2018年10月27日时，集合中存储的热数据为2018年9月27日至2018年10月27日的过车数据，之前2018年10月26日的过车数据会从集合中剔除，以此类推。
[0084] 对于存放全量数据即冷数据的集合，如果当前时间是2018年10月份，那么该月份的所有过车数据均会被存放到命名为“ColdCollection201810”的冷集合中，当时间进入到2018年11月份时，过车数据会自动存放到命名为“ColdCollection201811”的冷集合中，以此类推。
[0086] 如果搜索条件的起止日期均在当前热数据集的日期范围内，则仅在热数据集中搜索数据并返回即可，否则需在冷数据集中搜索数据。例如：搜索条件的起止日期为2018年10月11日至2018年10月12日，而当前热数据集的日期为2018年9月26日至2018年10月26日，则在热数据集中搜索即可。
[0087] 如果搜索条件的起止日期未全部在当前热数据集的日期范围内，则需在对应的冷数据集中搜索数据。例如：搜索条件的起止日期为2018年9月20日至2018年10月5日，则需搜索的冷数据集为“ColdCollection201809”和“ColdCollection201810”。
[0088] 检索到的最终结果组成搜索结果集，将所述搜索结果集返回给用户作为最终的检索结果。
[0089] 通过以上各实施例可知，本申请存在的有益效果是：
[0090] 第一，本发明将冷数据集在逻辑上和物理上将其拆分成多个子冷数据集，在提供搜索服务时，可在逻辑上快速缩小待搜索集合的范围，将更多的计算资源用于较小的数据集，提高了搜索速度。
[0091] 第二，本发明使用冷、热数据动态调整的模式，将命中率高、被搜索次数多的热数据集存储到价格昂贵的且有限的内存中，提供了一个设计上的缓存，将长时间未命中或被搜索频率较低的冷数据集存放在价格廉价且搜索速度相对较慢的磁盘或硬盘当中，极大的提高了搜索速度，并提高了用户的体验和系统的搜索性能。
[0092] 第三，本发明通过在单台服务器上的每个磁盘中创建至少一个Solr实例，组成一个SolrCloud，充分利用了服务器的价格廉价的磁盘资源，将单块磁盘上的数据均分到多块磁盘上，在同样数据集的情况下，多块磁盘可同时进行磁盘读取操作，极大的提高了数据读取的速度，降低因读取数据而对整个搜索服务造成的耗时。
[0093] 上面通过附图和实施例，对本发明的技术方案做虽然已经通过例子对本发明的一些特定实施例进行了详细说明，但是本领域的技术人员应该理解，以上例子仅是为了进行说明，而不是为了限制本发明的范围。尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。本发明的范围由所附权利要求来限定。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 文本检索方法及系统 | 2020-05-11 | 785 |
| 相似文本的检索方法及其装置 | 2020-05-12 | 413 |
| 一种文本检索方法和装置 | 2020-05-12 | 827 |
| 检索相关超文本文件的超文本文件检索装置 | 2020-05-11 | 724 |
| 一种自适应文本检索方法 | 2020-05-13 | 860 |
| 文本检索装置及方法 | 2020-05-11 | 817 |
| 一种文本检索方法和装置 | 2020-05-12 | 414 |
| 一种基于文本图片检索的相似文本检测方法 | 2020-05-12 | 276 |
| 文本信息检索装置以及文本信息检索方法 | 2020-05-11 | 642 |
| 文本检索装置、文本检索方法以及计算机程序 | 2020-05-12 | 783 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
QQ群二维码
意见反馈
意见反馈