CN110990401B - 一种酒店搜索方法及系统 - Google Patents

一种酒店搜索方法及系统 Download PDF

Info

Publication number
CN110990401B
CN110990401B CN201911152801.9A CN201911152801A CN110990401B CN 110990401 B CN110990401 B CN 110990401B CN 201911152801 A CN201911152801 A CN 201911152801A CN 110990401 B CN110990401 B CN 110990401B
Authority
CN
China
Prior art keywords
hotel
data
search
new
price
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
Application number
CN201911152801.9A
Other languages
English (en)
Other versions
CN110990401A (zh
Inventor
李伟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Joyu Culture Communication Co ltd
Original Assignee
Shanghai Joyu Culture Communication Co ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Shanghai Joyu Culture Communication Co ltd filed Critical Shanghai Joyu Culture Communication Co ltd
Priority to CN201911152801.9A priority Critical patent/CN110990401B/zh
Publication of CN110990401A publication Critical patent/CN110990401A/zh
Application granted granted Critical
Publication of CN110990401B publication Critical patent/CN110990401B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2358—Change logging, detection, and notification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24552—Database cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/12—Hotels or restaurants
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Health & Medical Sciences (AREA)
  • Computational Linguistics (AREA)
  • Economics (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明涉及一种酒店搜索方法，该方法包括以下步骤：步骤S1：数据监控组件监控数据库中的酒店数据变动；步骤S2：变动的酒店数据存储于缓存中间件；步骤S3：计算组件从缓存中间件得到变动的酒店数据，计算新的酒店数据；步骤S4：信息推送组件推送新的酒店数据至搜索引擎，酒店数据中的酒店价格数据在搜索引擎中以数组形式存储；步骤S5：基于新的酒店数据和搜索引擎，完成酒店搜索。与现有技术相比，能有效地在小成本、大数据量的情况下准确提供酒店信息的搜索方案；且充分考虑了横向扩展性。

Description

一种酒店搜索方法及系统
技术领域
本发明涉及电子商务领域，尤其是涉及一种酒店搜索方法及系统。
背景技术
随着电子商务的发展，越来越多的企业都会引入互联网工具，用于提升企业的效率，目前在OTA(在线旅游)、酒店行业，企业都会提供一个网站或者APP供用户预订酒店，而在酒店预订的整个流程中，搜索作为第一步，也是最重要的一步。具体搜索的实现，每家企业根据自身的规模、数据量等，都会有各自的解决方案。
现有大部分OTA或在线酒店预订网站，关于酒店搜索，或使用自建倒排索引、或使用数据库直接查询、或使用开源的全文搜索引擎等方案来完成，但这些方案均有比较显著的缺陷，比如某著名OTA，就是使用自建倒排索引的方法，确定能够在大数据量下做到信息的实时和准确性，且搜索速度很快，但这种手段，需要上百台高内存服务器，成本太高，一年的成本需要突破千万；而一些小的酒店，因为只售卖自己品牌的酒店，直接使用数据库查询的方式，在酒店数量扩充后，会有很大的性能问题；还有一些中型公司或OTA，使用单一的开源的全文搜索引擎来解决，这种方案虽然在数据量大的时候，可以保持较好性能的问题，但对于数据的准确性，根本无法保证，因为全文搜索引擎一般是用来做静态数据存储的，对于酒店这种包含n个房型，且每房型价格1天n变的情况，根本无法支持。
发明内容
本发明的目的就是为了克服上述现有技术存在的缺陷而提供一种酒店搜索方法及系统。
本发明的目的可以通过以下技术方案来实现：
一种酒店搜索方法，该方法包括以下步骤：
步骤S1：数据监控组件监控数据库中的酒店数据变动；
步骤S2：变动的酒店数据存储于缓存中间件；
步骤S3：计算组件从缓存中间件得到变动的酒店数据，计算新的酒店数据；
步骤S4：信息推送组件推送新的酒店数据至搜索引擎，酒店数据中的酒店价格数据在搜索引擎中以数组形式存储；
步骤S5：基于新的酒店数据和搜索引擎，完成酒店搜索。
所述的数组大小为5400。
所述酒店价格数据P为：
P＝p真/1000000+(d-1)*30+I
其中，p真为酒店价格真实数据，I为住宿天数，d为入住日期与当前日期的天数差。
从所述的数组中存取酒店价格数据时下标的计算公式为：
(day*30+I-1)％5400
其中，day为入住日期与1970-01-01的天数差。
所述的步骤S1和步骤S2包括：
数据监控组件监控数据库中的酒店数据变动；
数据监控组件提取变动的酒店数据并判断缓存中间件中是否存在变动的酒店数据的数据类型，若不存在，数据监控组件生成该数据类型，使缓存中间件增加该数据类型并存储变动的酒店数据，若存在，使缓存中间件更新该数据类型的数值。
所述的步骤S3包括：
步骤S31：计算组件从缓存中间件得到一个变动的酒店数据；
步骤S32：判断该数据是否存在关联酒店数据，若存在，计算新的关联酒店数据和该变动的酒店数据的新的酒店数据，并更新新的关联酒店数据和新的酒店数据至搜索引擎，若不存在，得到该变动的酒店数据的新的酒店数据，并更新新的酒店数据至搜索引擎；
步骤S33：判断是否还存在变动的酒店数据，若存在，重复步骤S31至S33，若不存在，计算组件休眠1分钟后执行步骤S33。
所述的缓存中间件为非关系型数据库，所述计算组件的计算资源匮乏时，监控组件对相同数据类型的变动的酒店数据进行合并，且仅保留时间点最近的变动的酒店数据。
所述的搜索引擎为Elasticsearch。
所述的非关系型数据库为Redis。
一种实现所述的酒店搜索方法的酒店搜索系统，包括
数据监控组件：用于监控数据库中的酒店数据变动；
缓存中间件：用于存储酒店数据计算过程中的数据，以及变动的酒店数据；
计算组件：用于计算新的酒店数据；
信息推送组件：用于推送新的酒店数据至搜索引擎；
搜索引擎：用于供客户端进行酒店搜索。
与现有技术相比，本发明具有以下优点：
(1)使用搜索引擎+数据库+缓存中间件+特定算法(特定存储方法)等多种技术，能有效地在小成本、大数据量(酒店数量超过100万)的情况下准确提供酒店信息的搜索方案；且充分考虑了横向扩展性，当数据量再进一步增大时，只需要对计算组件的服务器进行横向扩充即可，无需再做进一步的调整和设计。
(2)酒店数据中的酒店价格数据在搜索引擎中以数组形式存储，数组大小为5400，结合酒店价格实际数据到存储数据的转换以及下标的计算，有效解决了实际中酒店价格的变动、住宿时长的不确定以及存储、排序等问题。
(3)缓存中间件为非关系型数据库，可利用非关系型数据库的存储方式进行合并存储。
附图说明
图1为本发明的流程图；
图2为本发明酒店数据计算的架构；
图3为本发明酒店数据计算的流程图；
图4为本发明监控组件的工作流程图；
图5为本发明计算组件的工作流程图；
图6为本发明推送组件的工作流程图；
图7为本发明的总体架构图。
具体实施方式
下面结合附图和具体实施例对本发明进行详细说明。本实施例以本发明技术方案为前提进行实施，给出了详细的实施方式和具体的操作过程，但本发明的保护范围不限于下述的实施例。
实施例
A、本实施例提供一种酒店搜索方法，如图1所示，包括以下步骤：
步骤S1：数据监控组件监控数据库中的酒店数据变动；
步骤S2：变动的酒店数据存储于缓存中间件；
步骤S3：计算组件从缓存中间件得到变动的酒店数据，计算新的酒店数据；
步骤S4：信息推送组件推送新的酒店数据至搜索引擎，酒店数据中的酒店价格数据在搜索引擎中以数组形式存储；
步骤S5：基于新的酒店数据和搜索引擎，完成酒店搜索。
B、本实施例还提供一种实现酒店搜索方法的酒店搜索系统，其架构为：
该架构主要由两部分组成，酒店数据计算和酒店搜索服务(见图7)，其中：
1.酒店数据计算
用于监控数据库中酒店价格、房态、信息等酒店数据的变动，然后将变动的酒店数据进行整合与计算，推送至酒店搜索服务，酒店数据计算总共包括4个组件构件，如图2所示，其中每个组件的作用分别如下：
201数据监控组件：用于监控实际数据库中的酒店数据变动；
202缓存中间件，本实施例采用Redis存储：用于存储酒店数据计算过程中的数据，以及变动的酒店数据；
203计算组件：用于计算新的酒店数据，重新组装数据；
204信息推送组件：推送具体计算完的新的酒店数据，包含酒店价格、房态、信息等去酒店搜索服务。
2.酒店搜索服务
负责存储最新的酒店数据，然后提供搜索接口，供APP或PC等具体的客户端调用，提供实时准确的价格、房态等酒店数据，本实施例的酒店搜索服务基于ElasticSearch搜索引擎。
C、具体而言，本实施例提供的酒店搜索方法有两个关键点：
本实施例酒店搜索服务采用ElasticSearch搜索引擎，ElasticSearch是一个分布式、高扩展、高实时的搜索与数据分析引擎，它能很方便地对大量数据进行搜索、分析和探索。使用Elasticsearch做为基础框架，将所有的酒店数据存放在Elasticsearch中，对外提供搜索服务。
但因为酒店价格数据和房态数据存在以下情况，所以不能简单的使用Elasticsearch直接存储：
1)酒店的价格每天是不一致的，比如一个标准间，1天后卖200块，2天后卖230。
2)根据入住日期、入住时长不一样，要求搜索列表上出现的价格，是根据当前搜索的日期计算出最低的平均价和房态，还是上述这个标准间，如果搜索1天后入住时长为1天，列表应该显示200元，搜索1天后住2天，列表应该显示215元，计算过程为(200+230)/2。
3)需要在2)的基础上，支持按价格筛选和排序。
ElasticSearch作为搜索引擎，自身无法在搜索时对每一天的酒店价格进行实时计算并提供结果，按200万家酒店计，每家酒店平均有10个房型，每房型平均有10种价格的情况下，则一天的价格计算量就需要20亿条数据才能得出结果并排序，多天的价格计算量就更大，所以，酒店价格数据存储与计算均需要做特殊设计才能满足实时和准确的要求。
首先介绍第一个关键点，酒店搜索服务搜索引擎中的酒店价格数据存储。
酒店价格和一般商品的价格有很大区别，一般商品只会有一个价格，但酒店价格存在着多种可能性，为了保证酒店的入住率，酒店的销售人员会随时对同一个房型的价格做出调，一个标准间，可能上午卖300，下午卖200，到晚上又卖280，并且入住天数不一样，价格也会随之变化，比如n天后入住同一个房型，住1天、住2天、住5天的价格都有可能存在不同，故不能像一般的商品一样，针对于每个酒店只存储一个酒店价格数据。
表1酒店价格数据的数组形式
酒店行业同时有约定，在网上预定时，最大可以预定180日内入住，且连续入住的时间段不超过30天，按此约定计算出一个集合，数量为：180*30＝5400，故将酒店价格数据采用数组形式存放，数组大小为5400，每个数组存放n天后住n天的最低价，存储方式如表1所示。
这样，如果需要搜索3天后入住，住20天的价格，直接将天数带入下面的公式，得出下标，就可以取出此条件的最低价：
d*30+I-1
其中d为入住日期与当前日期的天数差，I为住宿天数。
但是，Elasticsearch的数组存储时是按数据大小排序的，这种形式直接存入后，会导致实际想取的数据不是存在对应下标的位置，上面的数据存在Elasticsearch中，会变成如表2所示顺序：
表2未处理时存储在Elasticsearch中的酒店价格数据
298 298 …… 350 …… 370
所以，需要对存储在Elasticsearch中的酒店价格数据P做以下处理：
P＝p真/1000000+(d-1)*30+I
其中，1000000是考虑到酒店最高单日价小于10万，且保留2位小数的精度，p真为酒店价格真实数据。
用上述公式计算后，存储在Elasticsearch中的酒店价格数据如表3所示：
表3处理后存储在Elasticsearch中的酒店价格数据
1.0000300 2.0000298 …… 5369.0000350 …… 5399.0000370
这样，取出数据时再将整数部分去除1000000，即可以得到真正的酒店价格数据。
但是，上述方式会有一个严重的问题：
当所有酒店价格数据都按数组格式存储好后，到了第二天，原本标记为1天后入住的数据就完全无用了，且新的第180天入住的酒店价格数据已经无处可存，此时不停扩充数组长度行不通，但如果将所有的酒店价格数据在数组中往前移一位，又会导致移动过程中的临界点问题(比如酒店1已经移了新的1天后入住的价格，酒店2还没有移，旧的1天后入住的价格还在数组中，这时程序将无法处理)。
这里，需要对取下标公式进行改进，将数组作为循环链表使用，最终，存取数的下标计算公式如下：
(day*30+I-1)％5400
其中day为入住日期与1970-01-01减完的天数差。
同理，其他根据入住、离店日期不同，导致结果不同的数据，也按同样的方式存储，这样，就解决了使用Elasticsearch存储的问题，Elasticsearch只要直接按搜索条件输出结果，就是一个完全准确的结果。
下面，介绍第二个关键点，酒店数据计算。
在酒店价格数据存储的问题解决之后，计算组件只要负责快速准确地计算出新的酒店数据，然后推送至搜索服务即可，如前所述，酒店数据计算包含4个组件，其中：
Redis存储的作用在于存储计算过程中各组件所需要的临时数据，以及实现各组件的数据交换。此处之所以使用Redis而非其他缓存中间件(比如消息队列)，主要是出于以下方面的考虑：
酒店变价频率较高，同一家酒店每天可能变好几次，使用消息队列，如果处理速率跟不上，那消息的积压会导致恶性循环(处理的都是无效、无时的变价消息)，使用Redis可以对相同数据类型的数据变动进行合并，节约处理时间，提升效率。因此，Redis本身作为酒店信息的高速缓存，有其必要性，再使用消息队列的话，增加系统复杂性的同时，会降低可靠性。
整个酒店数据计算的工作流程如图3所示：
301数据监控组件负责监控数据库中的酒店数据变动，变动的酒店数据存储于Redis；
302计算组件从Redis拿到变动的酒店数据后，对酒店的价格等信息进行重新计算，然后将计算完成的新的酒店数据，告知推送组件；
303推送组件负责将最新的酒店数据推送给搜索引擎。
因为此处使用了Redis做数据交换和存储，所以当出现以下情况时，会和一般的系统出现很大的差异：
酒店A10:00价格由200变为300，10:02价格由300变成220，10:05价格由220变成250，……。
一般系统在这时候，无论计算资源足够与否，都需要在每次变动时重新计算所有价格，如果有大量这种价格在等待计算，那么机器当前计算的可能全是已经无效的价格，一般系统的计算过程如下：
计算10:00变价所有影响的价格；
计算10:02变价所有影响的价格；
计算10:05变价所有影响的价格；
……。
而利用Redis，在机器充足，计算量足够时，与一般机器无异，而当计算资源不足时，监控组件会利用Redis的存储优势做自动合并，自动抛弃前面已经失效的价格，只计算一次最新的价格，即仅计算10:05变价所有影响的价格。
图4描述了监控组件的工作流程：
401数据监控组件监控数据库中的酒店数据变动；
402当有变动时，数据监控组件提取变动的酒店数据，根据变动的酒店数据的类型判断，具体变动了哪些数据类型；
403根据402的计算结果，判断如果Redis中没有已存在的该数据类型，数据监控组件生成新的对应的数据类型，使Redis增加该数据类型并存储变动的酒店数据；根据402的计算结果，判断如果Redis中已存在该数据类型，则使Redis更新该数据类型的数值，防止计算组件做重复计算。
图5描述了计算组件的工作流程：
监控组件对酒店数据进行监控之后，任何新的酒店数据的具体计算，就由计算组件来负责完成，具体的执行流程如下：
501计算组件先从Redis中拿出一个变动的酒店数据；
502判断此数据是否需要计算关联数，当价格信息变化时，比如10号的价格变动了，会影响一堆数据，如8号住2天的，9号住1天的，10号住1天的等等，根据搜索引擎的存储设计(见下文搜索引擎中的酒店价格数据存储)，价格数据变化，会导致前后60个数据的变化，故这60个数据全部需要重新计算。但有一些信息，如酒店电话、地址等变化时，不会影响到价格，故不需要重新计算，只需要对这些信息做简单的更新即可；
503如果是一个需要计算关联数据的变动的酒店数据，根据具体数据变化的日期，会计算出一个变化窗口，按照502所述，这个窗口的大小是前后60天；
504分别对60天的数据进行重新计算；
505如果是一个不需要计算关联数据的变动的酒店数据，则对单个酒店数据做更新；
506将计算完成的数据进行存储，如果是有关联数据的，数据的存储形式请参见搜索引擎的存储方式。如果无关联数据，得到单个新的酒店数据，并更新新的酒店数据至搜索引擎；
507记录一条待推送数据；
508判断是否还有变动的酒店数据存在，如果有的话，继续回到501，再次循环流程；
509如果没有变动的酒店数据存在，则程序休眠1分钟，回到508继续判断，等待1分钟是因为防止程进入空转死循环，对系统造成负担。
图6描述了推送组件的工作流程：
601推送组件首先取出一条待推送数据；
602推送至搜索服务，然后等待搜索服务响应推送结果；
603判断推送结果是否成功，如果成功，则进行604；
604推送成功后，会将此条数据从待推送数据中删除，防止重复推送；
605如果603的结果是推送不成功，会在此处做错误记录，当错误记录数达到一定阈值后，通知相关人员处理，然后再回到601，继续取下一条数据推送。
本方法中的缓存中间件和搜索引擎在具体实施过程中还可以使用其他的开源产品来替代，比如搜索引擎可以换成Lucene、Solr、Katta、Compass等搜索引擎，而Redis存储也可以使用其他的缓存中间件代替，如memcached等，甚至可以用Mongodb等数据库代替，不会影响到本方法的实际效果。
本实施例的酒店搜索方法具有以下优势：
能够有效解决大数据量下(100万酒店数量以上)根据不同入住、离店时间搜索时，无法展示出准确实时的酒店房态、价格等问题，并且充分考虑了横向扩展性，当数据量再进一步增大时，只需要对计算组件的服务器进行横向扩充即可，无需再做进一步的调整和设计，本公司的酒店搜索目前正在依据本方法进行改造，在内部测试中，已经达到了令人满意的效果，并准备上线使用。

Claims (7)

1.一种酒店搜索方法，其特征在于，该方法包括以下步骤：
步骤S1：数据监控组件监控数据库中的酒店数据变动；
步骤S2：变动的酒店数据存储于缓存中间件；
步骤S3：计算组件从缓存中间件得到变动的酒店数据，计算新的酒店数据；
步骤S4：信息推送组件推送新的酒店数据至搜索引擎，酒店数据中的酒店价格数据在搜索引擎中以数组形式存储；
步骤S5：基于新的酒店数据和搜索引擎，完成酒店搜索；
所述的数组大小为5400；
所述酒店价格数据P为：
P＝p真/1000000+(d-1)*30+I
其中，p真为酒店价格真实数据，I为住宿天数，d为入住日期与当前日期的天数差；
从所述的数组中存取酒店价格数据时下标的计算公式为：
(day*30+I-1)％5400
其中，day为入住日期与1970-01-01的天数差。
2.根据权利要求1所述的一种酒店搜索方法，其特征在于，所述的步骤S1和步骤S2包括：
数据监控组件监控数据库中的酒店数据变动；
数据监控组件提取变动的酒店数据并判断缓存中间件中是否存在变动的酒店数据的数据类型，若不存在，数据监控组件生成该数据类型，使缓存中间件增加该数据类型并存储变动的酒店数据，若存在，使缓存中间件更新该数据类型的数值。
3.根据权利要求1所述的一种酒店搜索方法，其特征在于，所述的步骤S3包括：
步骤S31：计算组件从缓存中间件得到一个变动的酒店数据；
步骤S32：判断该数据是否存在关联酒店数据，若存在，计算新的关联酒店数据和该变动的酒店数据的新的酒店数据，并更新新的关联酒店数据和新的酒店数据至搜索引擎，若不存在，得到该变动的酒店数据的新的酒店数据，并更新新的酒店数据至搜索引擎；
步骤S33：判断是否还存在变动的酒店数据，若存在，重复步骤S31至S33，若不存在，计算组件休眠1分钟后执行步骤S33。
4.根据权利要求1所述的一种酒店搜索方法，其特征在于，所述的缓存中间件为非关系型数据库，所述计算组件的计算资源匮乏时，监控组件对相同数据类型的变动的酒店数据进行合并，且仅保留时间点最近的变动的酒店数据。
5.根据权利要求1所述的一种酒店搜索方法，其特征在于，所述的搜索引擎为Elasticsearch。
6.根据权利要求4所述的一种酒店搜索方法，其特征在于，所述的非关系型数据库为Redis。
7.一种实现权利要求1-6任一所述的酒店搜索方法的酒店搜索系统，其特征在于，包括
数据监控组件：用于监控数据库中的酒店数据变动；
缓存中间件：用于存储酒店数据计算过程中的数据，以及变动的酒店数据；
计算组件：用于计算新的酒店数据；
信息推送组件：用于推送新的酒店数据至搜索引擎；
搜索引擎：用于供客户端进行酒店搜索。
CN201911152801.9A 2019-11-22 2019-11-22 一种酒店搜索方法及系统 Active CN110990401B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911152801.9A CN110990401B (zh) 2019-11-22 2019-11-22 一种酒店搜索方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911152801.9A CN110990401B (zh) 2019-11-22 2019-11-22 一种酒店搜索方法及系统

Publications (2)

Publication Number Publication Date
CN110990401A CN110990401A (zh) 2020-04-10
CN110990401B true CN110990401B (zh) 2023-07-28

Family

ID=70085751

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911152801.9A Active CN110990401B (zh) 2019-11-22 2019-11-22 一种酒店搜索方法及系统

Country Status (1)

Country Link
CN (1) CN110990401B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113628003A (zh) * 2021-07-22 2021-11-09 上海泛宥信息科技有限公司 酒店匹配方法、系统、终端及存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1734469A2 (de) * 2005-06-14 2006-12-20 Travel Tainment AG Verfahren zur Auswahl von Datensätzen
CN105279158A (zh) * 2014-06-04 2016-01-27 同程网络科技股份有限公司 基于复杂查询条件下的酒店价格排序方法
CN106021528A (zh) * 2016-05-25 2016-10-12 北京京东尚科信息技术有限公司 数据处理方法和装置
CN107463687A (zh) * 2017-08-10 2017-12-12 中国民航信息网络股份有限公司 多酒店平台查询方法和系统
CN109933589A (zh) * 2019-03-15 2019-06-25 北京计算机技术及应用研究所 用于数据汇总的基于ElasticSearch聚合运算结果的数据结构转换方法
CN109948963A (zh) * 2017-12-20 2019-06-28 北京京东尚科信息技术有限公司 订单服务提供方法及其系统、计算机系统
CN110020063A (zh) * 2017-07-18 2019-07-16 北京京东尚科信息技术有限公司 垂直搜索方法和系统

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090030743A1 (en) * 2007-07-24 2009-01-29 Las Vegas Central Reservation Corp. Intelligent Hotel Reservation System and Method

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1734469A2 (de) * 2005-06-14 2006-12-20 Travel Tainment AG Verfahren zur Auswahl von Datensätzen
CN105279158A (zh) * 2014-06-04 2016-01-27 同程网络科技股份有限公司 基于复杂查询条件下的酒店价格排序方法
CN106021528A (zh) * 2016-05-25 2016-10-12 北京京东尚科信息技术有限公司 数据处理方法和装置
CN110020063A (zh) * 2017-07-18 2019-07-16 北京京东尚科信息技术有限公司 垂直搜索方法和系统
CN107463687A (zh) * 2017-08-10 2017-12-12 中国民航信息网络股份有限公司 多酒店平台查询方法和系统
CN109948963A (zh) * 2017-12-20 2019-06-28 北京京东尚科信息技术有限公司 订单服务提供方法及其系统、计算机系统
CN109933589A (zh) * 2019-03-15 2019-06-25 北京计算机技术及应用研究所 用于数据汇总的基于ElasticSearch聚合运算结果的数据结构转换方法

Also Published As

Publication number Publication date
CN110990401A (zh) 2020-04-10

Similar Documents

Publication Publication Date Title
CN108416620B (zh) 一种基于大数据的画像数据的智能社交广告投放平台
CN108320171B (zh) 热销商品预测方法、系统及装置
US10956422B2 (en) Integrating event processing with map-reduce
US20150213109A1 (en) System and method for providing big data analytics on dynamically-changing data models
US20080195430A1 (en) Data quality measurement for etl processes
US9443208B2 (en) Bottom-up optimized search system and method
US20120296889A1 (en) Net change notification based cached views with linked attributes
CN109933514B (zh) 一种数据测试方法和装置
CN111339073A (zh) 实时数据处理方法、装置、电子设备及可读存储介质
CN109961198B (zh) 关联信息生成方法和装置
US10191947B2 (en) Partitioning advisor for online transaction processing workloads
CN112632405B (zh) 一种推荐方法、装置、设备及存储介质
US20120022916A1 (en) Digital analytics platform
US20150332316A1 (en) System and method for unifying user-level data across different media platforms
US20210082026A1 (en) Content-recommendation method and apparatus, electronic device, and system
CN112686418A (zh) 一种履约时效预测方法和装置
CN114461644A (zh) 一种数据采集方法、装置、电子设备及存储介质
CN110990401B (zh) 一种酒店搜索方法及系统
CN109299089A (zh) 一种画像标签数据的计算及存储方法和计算及存储系统
CN113342843A (zh) 大数据在线分析方法和系统
CN106294090A (zh) 一种数据统计方法和装置
US20190065987A1 (en) Capturing knowledge coverage of machine learning models
CN114549125A (zh) 物品推荐方法及装置、电子设备和计算机可读存储介质
CN114186555A (zh) 需求识别方法、装置、电子设备、介质和计算机程序
CN109656981B (zh) 一种数据统计方法及系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
PP01 Preservation of patent right
PP01 Preservation of patent right

Effective date of registration: 20231107

Granted publication date: 20230728