Business query method and device, equipment, medium and program product

Abstract

The invention provides a business query method and device, equipment, a medium and a program product, relates to the technical field of computers, and can solve the problems of low data synchronization efficiency and low overall resource utilization rate of a system during business query. According to the specific technical scheme, the method comprises the steps of storing structured service data of a service system in a target database; periodically initiating query to a target database through a data synchronization service in the business system to obtain the changed structured business data to obtain change information; packaging the change information into preset format data through data synchronization service, and sending the preset format data to a target search engine; updating an unstructured business data index in the target search engine according to the preset format data; and through the target search engine, based on the updated unstructured business data index, querying to obtain a business data record set corresponding to a query request of the client, and returning the business data record set to the client. The method is used for performing fuzzy query on service data.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a business query method, apparatus, device, medium, and program product. Background Technology

[0002] With the increasing informatization of housing provident fund services, the amount of business data accumulated by provident fund centers across the country has grown dramatically. This data includes not only core account information for individuals and business entities, but also frequent records of deposits, withdrawals, and loans. Against this backdrop, the portal and internal search functions of the provident fund system, especially its ability to quickly perform fuzzy and associative searches for key information such as individual account numbers and business entity names, have become crucial for improving business processing efficiency and user experience.

[0003] Currently, there is a technical solution that combines a MySQL database with the Elastic Search engine to address such query needs. This solution typically stores business data in a MySQL database, while using middleware such as Kafka to asynchronously synchronize the data to Elastic Search, leveraging its inverted index mechanism to achieve efficient full-text search and fuzzy matching.

[0004] However, due to the limitations of MySQL's binary log format and synchronization mechanism, its architecture is relatively complex and the data flow path is long when synchronizing data with Elastic Search through middleware, affecting the efficiency and real-time performance of data synchronization. Secondly, when facing specific business scenarios, such as a housing provident fund center with small data volumes or low update frequencies, the relatively complex middleware architecture introduces unnecessary resource overhead and operational costs, resulting in low overall system resource utilization.

[0005] Therefore, existing business query solutions suffer from low data synchronization efficiency and low overall system resource utilization. Summary of the Invention

[0006] This application provides a business query method, apparatus, device, medium, and program product, which can improve the data synchronization efficiency and overall system resource utilization during business queries.

[0007] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: Firstly, a business query method is provided, comprising: storing structured business data from a business system in a target database, the structured business data including a customer account information table and a business entity information table, the customer account information table including fields for account type, account number, account unique identifier, account change value, and account cumulative value; periodically initiating queries to the target database through a data synchronization service in the business system to obtain the changed structured business data and obtain change information; encapsulating the change information into data of a predetermined format through the data synchronization service and sending the data of the predetermined format to a target search engine; updating the unstructured business data index stored in the target search engine according to the data of the predetermined format; receiving a query request from a client and routing the query request to the target search engine; and querying the set of business data records corresponding to the query request through the target search engine based on the updated unstructured business data index, and returning the set of business data records to the client.

[0008] In the business query method of this application embodiment, a simplified data synchronization link is constructed by directly obtaining data changes through a lightweight data synchronization service combined with a timed polling mechanism. This eliminates the need for complex middleware and improves data synchronization efficiency. By converting structured business data into unstructured business data indexes in the target search engine, millisecond-level full-text retrieval is achieved, improving the performance of database fuzzy queries. Through an intelligent routing mechanism, query requests are accurately distributed, directing computationally intensive query tasks to the search engine while reserving precise queries in the database. This achieves precise separation of the dual-engine computing load and optimal resource allocation, thus improving the overall data synchronization efficiency and system resource utilization during business queries.

[0009] In one possible implementation of the first aspect, the above-mentioned method of periodically initiating queries to the target database through the data synchronization service in the business system to obtain the changed structured business data and obtain change information includes: periodically sending query statements to the target database through the data synchronization service, the query statements being used to retrieve data records that have changed since the previous query period; and obtaining the structured business data whose data record version number or update timestamp has changed from the target database as change information.

[0010] In this way, by retrieving records that have changed since the previous period through query statements and accurately capturing them based on the data record version number or update timestamp, an efficient incremental data acquisition is achieved. This avoids the performance waste caused by comparing the entire dataset and ensures that the data synchronization service only processes the smallest granular set of changes each time, further refining and improving the efficiency of data synchronization, while reducing the query load on the target database.

[0011] In another possible implementation of the first aspect, the above method further includes: when the data synchronization service starts or after an abnormal connection with the target database is detected, constructing the current full amount of business data in the target database into an initial unstructured business data index and storing it in the target search engine.

[0012] In this way, by performing a full data synchronization to build the initial index after startup or connection failure, the integrity and availability of data in the target search engine are ensured, which facilitates subsequent incremental synchronization and precise querying, and improves the robustness of the system.

[0013] In another possible implementation of the first aspect, the aforementioned unstructured business data index includes a full index of customer information and a full index of business entity information. The full index of customer information is obtained by associating, merging, and serializing data from multiple different customer information association tables in the target database. The full index of business entity information is obtained by associating, merging, and serializing data from multiple different business entity information association tables in the target database.

[0014] In this way, by linking, merging, and serializing data from multiple related tables to build a full index, the structured relationships in the database are transformed into a flat, query-optimized data model in the search engine. This allows a single query to retrieve complete business entity information, avoids multiple cross-table join queries, and improves query response efficiency in complex business scenarios.

[0015] In another possible implementation of the first aspect, the above-mentioned routing of the query request to the target search engine includes: parsing the query request and determining the query type of the query request; if the query type of the query request is the target query type, then routing the query request to the target search engine, wherein the target query type includes fuzzy query, autocomplete query, or search suggestion query.

[0016] In this way, by parsing the query type and accurately routing queries such as fuzzy queries, autocomplete queries, or search suggestion queries, intelligent distribution of query tasks is achieved, ensuring that the most suitable engine handles the most suitable task, thereby achieving load separation and optimizing the overall resource utilization.

[0017] In another possible implementation of the first aspect, the above method further includes: if the query type of the query request is not the target query type, or the complexity of the query request is greater than or equal to a first threshold, then the query request is routed to the target database.

[0018] In this way, by judging complexity (such as the number of query conditions and the depth of join tables), it is possible to accurately identify and distinguish those requests that appear to be fuzzy queries but are executed more efficiently in relational databases due to their extremely high complexity, and then route them a second time. This dynamic load balancing strategy can more precisely prevent the search engine from causing performance bottlenecks due to processing such complex queries, thereby further ensuring the overall high performance and operational stability of the system.

[0019] In another possible implementation of the first aspect, the above-mentioned data synchronization service encapsulates the change information into data in a predetermined format, including: using the data synchronization service, according to the pre-configured business rules, obtaining target business data that conforms to the business rules from the change information, and encapsulating the target business data into a predetermined format to obtain data in the predetermined format; wherein the above-mentioned business rules are: account information whose synchronization status is valid, or account information that has changed within a preset time period.

[0020] In this way, by filtering synchronized data through pre-configured business rules, intelligent data filtering is achieved, such as synchronizing only valid accounts or accounts with recent changes, reducing the total amount of data that needs to be synchronized and indexed. This reduces the resource consumption of the synchronization process itself, as well as the storage and computing overhead of the search engine, improving synchronization efficiency and system resource utilization.

[0021] In another possible implementation of the first aspect, before routing the query request to the target search engine, the method further includes: obtaining the most recent update timestamp of the data index related to the query request in the target search engine; obtaining the last change timestamp of the original data table in the target database that serves as the source of the data index; calculating the difference between the most recent update timestamp and the last change timestamp; and if the difference is greater than a second threshold, incrementally synchronizing the data in the original data table that has changed since the most recent update timestamp through a data synchronization service.

[0022] In this way, by comparing timestamps before querying and triggering incremental synchronization when the difference is too large, the strong real-time performance and high accuracy of query results are ensured. The on-demand and lightweight approach makes up for the delay that may exist in periodic synchronization. While ensuring data quality, it avoids the huge waste of resources caused by frequent full synchronization and achieves a balance between data consistency and system performance.

[0023] Secondly, a business query device is provided, comprising: a storage module, a processing module, a sending module, and a receiving module; the storage module is used to store structured business data of a business system in a target database; the processing module is used to periodically initiate queries to the target database through a data synchronization service in the business system to obtain changed structured business data and obtain change information; the processing module is also used to encapsulate the change information into data of a predetermined format through the data synchronization service; the sending module is used to send the data of the predetermined format to a target search engine; the processing module is also used to update the unstructured business data index stored in the target search engine according to the data of the predetermined format; the receiving module receives query requests from clients; the sending module is also used to route the query requests to the target search engine; the processing module is also used to query the set of business data records corresponding to the query request through the target search engine based on the updated unstructured business data index; the sending module is also used to return the set of business data records to the client.

[0024] It should be noted that the beneficial effects of the business query device can be found in the relevant description of the beneficial effects of the business query method mentioned above, and will not be repeated here to avoid repetition.

[0025] Thirdly, an electronic device is provided, the method comprising: a memory and at least one processor. The memory is communicatively connected to the processor. The memory is used to store computer program code, the computer program code including computer instructions. When the processor executes the computer instructions, it causes the electronic device to perform the method as described in the first aspect and any possible implementation thereof.

[0026] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer instructions. When executed by a processor, these computer instructions are used to implement the method described in the first aspect and any possible implementation thereof.

[0027] Fifthly, embodiments of this application provide a computer program product that, when run on a computer or executed by a computer's processor, implements the method described in the first aspect and any possible design thereof. The computer may be the electronic device described in the third aspect and any possible implementation thereof.

[0028] It is understood that the beneficial effects achieved by the apparatus of the second aspect, the electronic device of the third aspect, the computer-readable storage medium of the fourth aspect, and the computer program product of the fifth aspect provided above can be referred to as the beneficial effects of the first aspect and any possible implementation thereof, which will not be repeated here. Attached Figure Description

[0029] Figure 1 A flowchart illustrating a business query method provided in an embodiment of this application; Figure 2 A schematic diagram of a database model provided in an embodiment of this application; Figure 3 This application provides a schematic diagram of the structure of personal information as an embodiment of the present application. Figure 4 A schematic diagram of an Elastic Search-based access architecture provided for an embodiment of this application; Figure 5 A flowchart illustrating another business query method provided in this application embodiment; Figure 6 This is a schematic diagram of the structure of a business query device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0031] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0032] The technical solutions provided in this application, including the collection, storage, use, processing, transmission, provision, and disclosure of financial data or user data, comply with relevant laws and regulations and do not violate public order and good morals.

[0033] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0034] The terms / concepts involved in the embodiments of this application are explained below.

[0035] MySQL: A relational database management system (RDBMS) that operates based on SQL (Structured Query Language). MySQL is an open-source project released under the General Public License.

[0036] TiDB is an open-source distributed relational database that supports Hybrid Transactional and Analytical Processing (HTAP).

[0037] Kafka is a distributed stream processing platform that can be used to build real-time data pipelines and streaming applications.

[0038] Housing Provident Fund Center: A housing provident fund management and operation agency established by relevant departments.

[0039] Elastic Search is an open-source search engine that provides a distributed, multi-tenant full-text search engine. It features an HTTP web interface and schema-less JSON documents.

[0040] Fuzzy search is a search engine and database query technology that allows users to find relevant results even if the search terms they enter are not entirely accurate or contain errors.

[0041] Associative search: This refers to the ability of a search engine or database to automatically provide a series of possible complete or similar search terms when a user enters part of a query, helping the user quickly find the information they want.

[0042] The following description, in conjunction with the accompanying drawings, explains the business query device and the business query method applicable to the business query device provided in this application through specific embodiments and application scenarios.

[0043] The business query method, apparatus, device, medium, and program products provided in this application can be applied to various information system scenarios that require efficient and accurate fuzzy queries on massive amounts of structured business data, and are particularly suitable for fields with complex business data models, diverse query needs, and high requirements for response speed. Specifically, they include, but are not limited to, the following scenarios: 1. Financial and government public service scenarios The Housing Provident Fund Management System needs to process information on millions of individual accounts and business entity accounts. When staff or users perform fuzzy searches on the front-end interface using incomplete names, ID numbers, or business entity names, this solution can achieve sub-second rapid response, accurately locating the target account, greatly improving business processing efficiency and user experience.

[0044] Social insurance inquiry system: This system contains a massive amount of data on insured individuals and business entities. This solution supports quick queries of individual insurance records and business entity payment status via fuzzy input.

[0045] Core banking system: In the customer management module, account managers need to quickly find target customers based on incomplete customer names, phone numbers, or address fragments. This solution can effectively replace the inefficient querying of traditional databases.

[0046] 2. Enterprise Resource Planning and Customer Relationship Management Scenarios Large-scale Enterprise Resource Planning (ERP) system: The system contains massive amounts of material information, service provider information, and customer information. Using this solution, users can quickly associate and search information in procurement, sales, and other processes by using partial information from the material name or the first letter of the service provider's name in pinyin, improving operational efficiency.

[0047] Customer Relationship Management System: When following up with clients, sales personnel often need to quickly retrieve client contact information based on fragments of memory. This solution's fast fuzzy and associative search capabilities seamlessly support this high-frequency need.

[0048] 3. E-commerce and logistics supply chain scenarios E-commerce product search system: Although the front-end search has been highly optimized, this solution can support merchants to perform efficient fuzzy management queries on product numbers, inventory quantities, entity names, etc. when managing a massive product database in the back-end.

[0049] Intelligent logistics warehousing system: When managing tens of thousands of warehouse materials, warehouse staff can use this solution to quickly locate material inventory information based on partial material names or codes, enabling efficient inbound, outbound, and inventory operations.

[0050] 4. Healthcare and Education Management Scenarios Hospital Information System: Doctors or nurses need to quickly access patient medical records. By inputting partial characters or pinyin of a patient's name, this solution can instantly suggest and list matching patients, saving valuable time for diagnosis and treatment.

[0051] Large-scale educational institution student registration management system: manages information on tens of thousands or even hundreds of thousands of students. Counselors or academic affairs staff can quickly find target students by using fuzzy names or student IDs to query and maintain student registration information.

[0052] In supporting and developing the informatization and diversification of housing provident fund and public rental housing services, the data volume of many local housing provident fund centers' systems is rapidly increasing. Currently, the various business models involving housing provident fund contributions and adjustments are constantly evolving, coupled with the complex situation of virtualized users such as subsidy recipients and self-paying users in each housing provident fund center. The increasing volume of data involved in these business operations places demands on the portal search and the system's own search capabilities. To improve the search efficiency of the housing provident fund system, establish high-performance, fast fuzzy search capabilities, and meet the requirements for database usage, this paper proposes a method for building a fast fuzzy search function for the housing provident fund system based on Tidb and Elastic Search. This aims to further enhance and improve the business processing capabilities of the housing provident fund system and promote the construction of housing provident fund information.

[0053] MySQL and TiDB both fall under the category of database service products. Correspondingly, fast fuzzy search capabilities can be built on MySQL databases. Both solutions can utilize Elastic Search for fast fuzzy searches and Kafka for asynchronous capabilities and data governance.

[0054] For existing industry-standard housing provident fund systems, a fast fuzzy query solution based on a MySQL database and related middleware infrastructure has the following shortcomings: 1. It does not conform to the directions supported, encouraged, and required by current regulations and guidelines. According to relevant industry development requirements and construction guidelines, various departments and related institutions should advance certain processes and improve the system's independent construction capabilities. Therefore, for the construction of the existing housing provident fund system, not conforming to the directions supported, encouraged, and required by current regulations and guidelines is a significant shortcoming.

[0055] 2. Some housing provident fund centers do not require a complex infrastructure to handle their large data volumes, thus avoiding unnecessary construction and maintenance costs. For some centers, using a MySQL database to build a fast fuzzy search system might introduce and use too many middleware components, most of which are not very efficient relative to the development capabilities of the housing provident fund system.

[0056] Currently, due to limitations in the Binlog log format and synchronization mechanism of MySQL databases, the architecture for data synchronization with Elastic Search via middleware is relatively complex, resulting in a long data flow path and impacting data synchronization efficiency and real-time performance. Secondly, when facing specific business scenarios, such as a housing provident fund center with small data volumes or low update frequencies, the relatively complex middleware architecture introduces unnecessary resource overhead and operational costs, leading to low overall system resource utilization. Therefore, existing business query solutions suffer from low data synchronization efficiency and low overall system resource utilization.

[0057] The technical solution of this application adopts a fast fuzzy search system for the housing provident fund based on Tidb and Elastic Search to fulfill relevant requirements, promote management decision-making, and comply with the relevant requirements of current regulations. It builds relevant fast fuzzy search capabilities to empower corresponding businesses, shorten the query time for corresponding business operations, and improve the user experience. For specific business and application scenarios, it optimizes architecture costs and reduces unnecessary operational burdens. Specifically, by using Tidb as the core business database, a data synchronization program based on a timed polling mechanism is introduced to directly obtain data changes and then synchronize them to Elastic Search to build a retrieval index. This eliminates the need for dependence on complex middleware such as Canal and Kafka, simplifying the system architecture and reducing the complexity and cost of system construction and maintenance. Secondly, compared to traditional log parsing and monitoring solutions, the timed polling mechanism is simpler and more reliable in application scenarios like the housing provident fund where data change frequency is not extremely high. This effectively avoids resource waste caused by complex architectures and significantly improves the system's resource utilization efficiency. Finally, based on ElasticSearch's powerful full-text search capabilities, this solution provides the housing provident fund system with high-performance fuzzy and associative search functions, significantly reducing the response time of such queries from seconds to sub-seconds, improving business processing efficiency and end-user interaction experience, thereby strengthening the search capabilities of the housing provident fund system, improving data synchronization efficiency and overall system resource utilization during housing provident fund business queries.

[0058] This application provides a business query method, which can be applied to a business query device or electronic device. The following illustration uses a business query device executing the business query method as an example. Figure 1 As shown, the business query method may include the following steps 201 to 206.

[0059] Step 201: The business query device stores the structured business data of the business system in the target database.

[0060] In some embodiments of this application, the structured business data includes a customer account information table and a business entity information table. The customer account information table includes fields for account type, account number, unique account identifier, account change value, and account cumulative value.

[0061] In some embodiments of this application, the target database may be a relational database, such as Tidb. Tidb is a distributed relational database that is compatible with the MySQL protocol, possesses strong consistency and high availability, and is suitable as a storage medium for core business data.

[0062] In some embodiments of this application, the aforementioned structured business data refers to data organized according to a predefined data model (such as a two-dimensional table).

[0063] In some embodiments of this application, the aforementioned business entity information table refers to a database table that stores basic information about business entities, organizations, and other business entities, including but not limited to fields such as entity number, entity name, entity type, and registered address.

[0064] For example, taking the aforementioned business system as a housing provident fund management system, the relevant uses of the housing provident fund system include major business functions such as search and query, involving the use and statistics of relevant accounts and business entity information opened by the housing provident fund center, taking customer accounts (i.e., personal accounts or personal business accounts) as an example. Personal business accounts may contain many important associated identifying information, such as account type, account number, customer code, and corresponding contribution amount, contribution balance, and other business information. When building a fast fuzzy query for the housing provident fund system based on Tidb, as a basic step in the Tidb-based construction, this information will be distributed and stored in the corresponding Tidb database tables. For example... Figure 2 The diagram shown illustrates a database model provided in an embodiment of this application, depicting three interconnected table structures: a personal business information table, a personal account information table, and a personal associated key information table. Each table lists its included fields and indicates its primary key (PK). The specific details are as follows: Personal Business Information Form: PK: Personal account, center number; The fields also include: business entity account, customer number, individual contribution base, and monthly contribution amount.

[0065] Personal Account Information Form: PK: Personal account, center number; The fields also include: business entity account, management department number, account type, and account status.

[0066] Personal Associated Key Information Table: PK: Customer ID, Center ID; The fields also include: name, ID number, ID type, and creation timestamp.

[0067] Thus, the three tables mentioned above are interconnected through fields such as personal account, center number, and customer number, forming a complete information system structure.

[0068] As can be seen, taking personal information as an example, the housing provident fund system contains a lot of business information. In the TiDB database, this is represented by multiple related structured data tables. These structured data tables together form the corresponding business domain model information. Besides personal information, there is also related business data such as business entity information, which are also stored in TiDB. These will not be elaborated upon here.

[0069] In some embodiments of this application, after completing business operations such as account opening, deposit, and withdrawal, the aforementioned business system writes the generated business data, such as personal account information and business entity information, into the corresponding tables in the Tidb database through standard database write operations. These tables are interconnected through primary and foreign key relationships, together forming a complete business data model.

[0070] Step 202: The business query device periodically initiates queries to the target database through the data synchronization service in the business system to obtain the changed structured business data and obtain the change information.

[0071] In some embodiments of this application, the aforementioned data synchronization service is an independent background process or service that does not rely on the binary logs of the database but discovers changes through active querying.

[0072] In some embodiments of this application, the aforementioned change information refers to the set of changed data records captured during data synchronization.

[0073] In some embodiments of this application, in the context of housing provident fund business, performing corresponding associative or fuzzy searches on such structured data related to housing provident fund business stored in Tidb is difficult to implement and incurs significant time costs. Specifically, it requires substantial database resources and a long query time to complete a single association. This is unacceptable from a business implementation perspective. Therefore, it is necessary to synchronize the data to a dedicated search engine.

[0074] In some embodiments of this application, step 202 can be specifically implemented by the following steps 202a and 202b.

[0075] Step 202a: The business query device periodically sends query statements to the target database through the data synchronization service.

[0076] In some embodiments of this application, the above query statement is used to retrieve data records that have changed since the previous query period.

[0077] In some embodiments of this application, the purpose of the above query statement is to accurately locate data records that have changed since the last check, achieving incremental capture and avoiding full table scans. The data synchronization service internally maintains a timer; at each execution cycle, the data synchronization service sends a preset SQL query statement to the Tidb database.

[0078] Step 202b: The business query device retrieves structured business data from the target database whose data record version number or update timestamp has changed, as change information.

[0079] In some embodiments of this application, the aforementioned data record version number refers to a field used to identify the version of the data record, which automatically increments each time the data is updated. The aforementioned update timestamp refers to a field recording the last modified time of the data.

[0080] In some embodiments of this application, each record in the target database may contain an auto-incrementing version number or a timestamp field that is automatically refreshed when the data is updated. The query statement filters out changed records based on filtering conditions (i.e., changes in the data record version number or update timestamp). After the data synchronization service executes the SQL query, the Tidb database returns a result set that meets the conditions; this result set represents the change information that needs to be processed within the current period.

[0081] In this way, by retrieving records that have changed since the previous period through query statements and accurately capturing them based on the data record version number or update timestamp, an efficient incremental data acquisition is achieved. This avoids the performance waste caused by comparing the entire dataset and ensures that the data synchronization service only processes the smallest granular set of changes each time, further refining and improving the efficiency of data synchronization, while reducing the query load on the target database.

[0082] Step 203: The business query device encapsulates the change information into data in a predetermined format through the data synchronization service and sends the data in the predetermined format to the target search engine.

[0083] In some embodiments of this application, the aforementioned change information is structured row data retrieved from the database, which needs to be converted into a format that the search engine can accept and process.

[0084] In some embodiments of this application, the aforementioned target search engine refers to a search system used to provide full-text search services, such as Elastic Search.

[0085] In some embodiments of this application, the step 203 above, "the business query device encapsulates the change information into a predetermined format data through the data synchronization service", can be specifically implemented through the following step 203a.

[0086] Step 203a: The business query device obtains target business data that conforms to the business rules from the change information through the data synchronization service, according to the pre-configured business rules, and encapsulates the target business data into a predetermined format to obtain data in the predetermined format.

[0087] In some embodiments of this application, the above business rule is: synchronize account information with a valid status identifier, or synchronize account information that has changed within a preset time period.

[0088] In some embodiments of this application, in the housing provident fund business scenario, the business data accessed by the housing provident fund system generally consists of personal information and business entity information, with business entity information as an example. Most business entity information typically experiences very low data volume and frequency of modification and addition. Furthermore, for some housing provident fund centers, the number of users and business entities is also small, resulting in similarly low data volume and frequency of modification and addition. In this case, excessive deployment of machines and maintenance would only add unnecessary costs. Therefore, selective synchronization can be performed through business rules.

[0089] In some embodiments of this application, the data synchronization service loads pre-configured rules (such as from a configuration center or local files). These rules may be defined as synchronizing only accounts with valid status or only data that has changed within the last 30 days. The data synchronization service filters the change information according to these rules to obtain the target business data. Subsequently, this data is assembled into a format supported by a search engine; the aforementioned predetermined format is a JSON document format, thus completing the encapsulation.

[0090] In this way, by filtering synchronized data through pre-configured business rules, intelligent data filtering is achieved, such as synchronizing only valid accounts or accounts with recent changes, reducing the total amount of data that needs to be synchronized and indexed. This reduces the resource consumption of the synchronization process itself, as well as the storage and computing overhead of the search engine, improving synchronization efficiency and system resource utilization.

[0091] Step 204: The business query device updates the unstructured business data index stored in the target search engine according to the predetermined format data.

[0092] In some embodiments of this application, the aforementioned unstructured business data index includes a full index of customer information and a full index of business entity information. The full index of customer information is obtained by associating, merging, and serializing data from multiple different customer information association tables in the target database. The full index of business entity information is obtained by associating, merging, and serializing data from multiple different business entity information association tables in the target database.

[0093] For example, in the housing provident fund business scenario, Elastic Search, as a system and tool for fast indexing and retrieval, employs a reverse lookup sorting data storage and indexing method compared to traditional databases, making it very suitable for retrieving and associating unstructured data. Therefore, using Elastic Search to synchronously store and index relevant business information in the housing provident fund system requires establishing corresponding unstructured data. Taking personal information as an example, such as... Figure 3 The diagram shown is a structural illustration of personal information provided in an embodiment of this application. It consists of multiple data blocks, each connected by a personal account as a related field. The entire structure can be understood as an integrated data view or index built around the personal account. The specific details are as follows: The personal business information index includes the following fields: personal account, business entity account, center number, and personal contribution base.

[0094] The full index of personal information includes the following fields: personal account, center number, management department number, account type, personal contribution base, business entity account, customer number, account status, and monthly contribution amount.

[0095] The aforementioned data indexing system integrates data from multiple dimensions, including personal business (such as business entity account and center number), account attributes (such as management department number, account type, and status), and deposit information (such as deposit base and monthly deposit amount), which together constitute a complete full-volume index of personal information.

[0096] It's understandable that data stored in Elastic Search becomes unstructured, such as document data in JSON format. To better adapt to business query needs, in addition to the original corresponding information tables (e.g., a personal business information table with a corresponding personal business information index), a full index of personal information is also stored. This allows for quick location of all information about a specific individual even with only vague personal account information or other details. This significantly improves the retrieval capabilities of relevant business information. From a business perspective, different views allow for rapid location of specific users or business entities, facilitating faster and better business construction and empowerment of the housing provident fund business system.

[0097] In some embodiments of this application, the data synchronization service sends encapsulated JSON data units to the Elastic Search cluster via an Elastic Search client using an index API (such as an index request or a bulk request). Upon receiving the data, Elastic Search's internal engine automatically performs tokenization and builds an inverted index to update the index of the unstructured business data. This index can be a full index of personal information or a full index of business entity information, constructed by merging data from multiple database tables.

[0098] Step 205: The business query device receives the query request from the client and routes the query request to the target search engine.

[0099] In some embodiments of this application, the "routing the query request to the target search engine" in step 205 above can be specifically implemented through steps 205a and 205b below.

[0100] Step 205a: The business query device parses the query request and determines the query type of the query request.

[0101] In some embodiments of this application, after receiving a client request, the business query device (usually an API gateway or backend service) parses the query string or request parameters and determines the query intent by analyzing keywords, matching preset patterns, or calling a natural language processing library.

[0102] Step 205b: If the query type of the query request is the target query type, the business query device will route the query request to the target search engine.

[0103] In some embodiments of this application, the target query type includes fuzzy query, autocomplete query, or search suggestion query.

[0104] In some embodiments of this application, if the query type of the query request is a target query type, the business query device can modify the destination of the request, and instead send the query originally sent to the business database to initiate a search request to the Elastic Search cluster through the Elastic Search client API.

[0105] In this way, by parsing the query type and accurately routing queries such as fuzzy queries, autocomplete queries, or search suggestion queries, intelligent distribution of query tasks is achieved, ensuring that the most suitable engine handles the most suitable task, thereby achieving load separation and optimizing the overall resource utilization.

[0106] In some embodiments of this application, the above-described business query method further includes the following step 205c.

[0107] Step 205c: If the query type of the query request is not the target query type, or the complexity of the query request is greater than or equal to the first threshold, the business query device will route the query request to the target database.

[0108] In some embodiments of this application, the business query device may preset a complexity calculation rule (such as the number of query conditions, the number of fields involved, etc.). When the complexity score exceeds the threshold, even if it is a fuzzy query, it will be routed back to the Tidb database for execution.

[0109] In this way, by judging complexity (such as the number of query conditions and the depth of join tables), it is possible to accurately identify and distinguish those requests that appear to be fuzzy queries but are executed more efficiently in relational databases due to their extremely high complexity, and then route them a second time. This dynamic load balancing strategy can more precisely prevent the search engine from causing performance bottlenecks due to processing such complex queries, thereby further ensuring the overall high performance and operational stability of the system.

[0110] Step 206: The business query device uses the target search engine to query the set of business data records corresponding to the query request based on the updated unstructured business data index, and returns the set of business data records to the client.

[0111] In some embodiments of this application, the business query device can observe the changes in system capabilities after the construction of a corresponding fast fuzzy search system by comparing business call time and capabilities.

[0112] For example, as shown in Table 1, the differences in key performance indicators of the housing provident fund business system under the two systems of not using and using the Elastic Search search solution are compared, intuitively demonstrating the improvement in system capabilities brought about by the introduction of professional search technology.

[0113] Table 1

[0114] The specific comparison of the scheme systems in Table 1 above is as follows: (1) No Elastic Search integration solution used Does the system support predictive search? Explicitly “No.” The system does not have the ability to predict and suggest based on user input.

[0115] Fuzzy search support: Requires application-specific extension. This means the feature is not natively supported and requires the business application layer to invest additional development resources to implement it, with uncertainties regarding the effectiveness and performance.

[0116] Query response time: Slow response, ranging from 1.5s to 20s. Such delays of several seconds or even twenty seconds will seriously affect user experience and system efficiency.

[0117] (2) Using a solution that integrates Elastic Search Does it support predictive search? Explicitly "Support". The system provides intelligent input suggestions and completion functions, greatly improving the convenience and user-friendliness of searching.

[0118] Fuzzy search support: Explicitly "Supported". This feature is a powerful native feature of Elastic Search, available out of the box, requiring no complex and difficult-to-maintain self-implementation at the application layer.

[0119] Query response time: Response speed has been greatly improved, stabilizing between 0.5s and 0.8s. Compared to the unused solution, performance has been improved by several to tens of times, achieving near real-time response.

[0120] After using Elastic Search to build relevant search capabilities for the housing provident fund business system, the system's capacity and response time have improved. Upon receiving a query request, Elastic Search performs rapid matching, scoring, and sorting in its inverted index, ultimately returning a response containing matching documents (i.e., a set of business data records). The business query device receives this response, may perform simple format conversion, and finally returns it to the client, completing an efficient fuzzy search.

[0121] Thus, by comparing business call times and core capabilities (associative search and fuzzy search), the value of building a fast fuzzy search system based on Elastic Search is fully demonstrated. After introducing ElasticSearch into the housing provident fund business system, the system capabilities have been comprehensively and significantly enhanced (from not supported to supported, from requiring manual implementation to native support), while the query response time has also been greatly shortened, optimized from second-level latency to sub-second level, improving system performance and user experience.

[0122] In some embodiments of this application, Elastic Search is also used for access. However, the solution based on TiDB and Elastic Search differs from the traditional solution based on MySQL and Elastic Search, as follows: Figure 4 The diagram shown illustrates an Elastic Search-based access architecture provided in this application embodiment. It compares three technical architecture solutions for building fast fuzzy search capabilities for the housing provident fund business system. The core focus is on how to synchronize changed data from the database to Elastic Search. A detailed comparison of the three solutions is as follows: (1) such as Figure 4 As shown in (a), this is a traditional access solution based on MySQL and Elastic Search. The data source is a MySQL database. The Canal middleware monitors and parses the MySQL binary log (binlog), and Canal sends the parsed data change events to the Kafka message queue. The housing provident fund business system or consumer service consumes this data from Kafka and ultimately synchronizes or updates the data to Elastic Search to provide fast fuzzy query capabilities, serving the housing provident fund business system. For example, the housing provident fund business system can initiate fast fuzzy query requests to Elastic Search without accessing the source database.

[0123] (2) For example Figure 4 As shown in (b), this is a typical access scheme based on Tidb and Elastic Search. The data source is changed to the Tidb database. Since Tidb's binlog parsing mechanism is different from MySQL, the Tidb-specific change data capture tool Ticdc is used here. Ticdc sends data change events to the Kafka message queue. The data is eventually synchronized to Elastic Search via Kafka. The provident fund business system directly queries Elastic Search to obtain a high-performance search experience.

[0124] (3) such as Figure 4 As shown in (c), this solution presents a simplified access architecture designed to optimize costs in the housing provident fund business scenario. This architecture eliminates message middleware such as Kafka, forming a highly simplified data synchronization link, as detailed below: In this architecture, the housing provident fund business system itself undertakes the responsibility of driving data synchronization. Instead of monitoring database logs in a streaming manner, it synchronizes data from the Tidb database to Elastic Search through direct data access and invocation. The housing provident fund business system then queries Elastic Search to perform fuzzy searches. Synchronizing data from Tidb to Elastic Search can typically be achieved in two ways: First, within the business system's code logic, after completing a data insertion or update operation in Tidb, a write operation to Elastic Search is immediately executed within the same transaction context (or via an asynchronous task). Second, the business system schedules a separate timed task to periodically (e.g., every minute) scan Tidb for recently changed data and synchronize it in batches to Elastic Search.

[0125] This architecture reduces system complexity and operational costs, saving the overhead of deploying and maintaining Kafka clusters and data acquisition components such as Ticdc / Canal. It is particularly suitable for public housing fund centers with low data change frequency and small data volume. For master data such as business entity information, or scenarios with a small user base, this lightweight solution is sufficient to meet the requirements.

[0126] Thus, the three different access structure schemes mentioned above will result in different ways for TiDB and MySQL databases to access middleware such as Kafka, because TiDB's binlog parsing and opening methods are different from MySQL's, which will not be elaborated on in this article.

[0127] Regarding the common Tidb access method, namely Figure 4 (b) in this solution is also specifically applied. The business data accessed by the housing provident fund system generally consists of personal information and business entity information, with business entity information as an example. Most business entity information typically has a very small volume and frequency of modification and addition. For some housing provident fund centers, the number of users and business entities is also small, resulting in similarly low volume and frequency of modification and addition. In this case, excessive deployment and maintenance of machines would only add unnecessary costs. By modifying the corresponding program, the relevant application access architecture can be degraded to... Figure 4 The architecture shown in (c) significantly reduces the corresponding costs and usage.

[0128] This solution builds the capability for fast fuzzy queries in the housing provident fund system by modifying Tidb and Elastic Search, along with related middleware or programs, which greatly improves the response speed and business support capabilities of the corresponding business.

[0129] In the business query method of this application embodiment, a simplified data synchronization link is constructed by directly obtaining data changes through a lightweight data synchronization service combined with a timed polling mechanism. This eliminates the need for complex middleware and improves data synchronization efficiency. By converting structured business data into unstructured business data indexes in the target search engine, millisecond-level full-text retrieval is achieved, improving the performance of database fuzzy queries. Through an intelligent routing mechanism, query requests are accurately distributed, directing computationally intensive query tasks to the search engine while reserving precise queries in the database. This achieves precise separation of the dual-engine computing load and optimal resource allocation, thus improving the overall data synchronization efficiency and system resource utilization during business queries.

[0130] In some embodiments of this application, the above-described business query method further includes the following step 301.

[0131] Step 301: When the data synchronization service starts or after an abnormal connection with the target database is detected, the business query device constructs an initial unstructured business data index from the current full amount of business data in the target database and stores it in the target search engine.

[0132] In some embodiments of this application, when the data synchronization service starts, or after a connection error with Tidb is detected and successfully reconnected during its operation, the data synchronization service performs a full data fetch. The data synchronization iterates through all business tables that need to be synchronized, synchronizing all existing data to Elastic Search at once to build a complete initial index.

[0133] In this way, by performing a full data synchronization to build the initial index after startup or connection failure, the integrity and availability of data in the target search engine are ensured, which facilitates subsequent incremental synchronization and precise querying, and improves the robustness of the system.

[0134] In some embodiments of this application, before "routing the query request to the target search engine" in step 205 above, the business query method provided in this application embodiment further includes the following steps 302 to 305.

[0135] Step 302: The business query device obtains the most recent update timestamp of the data index related to the query request in the target search engine.

[0136] In some embodiments of this application, the business query device obtains the last update timestamp of the target index by querying the metadata information of the Elastic Search index.

[0137] Step 303: The business query device obtains the last change timestamp of the original data table in the target database, which serves as the source of the data index.

[0138] In some embodiments of this application, the business query device obtains the last change timestamp of the source data table through an SQL query statement.

[0139] Step 304: The business query device calculates the difference between the most recent update timestamp and the last change timestamp.

[0140] In some embodiments of this application, the business query device calculates the time difference between two timestamps in seconds or milliseconds.

[0141] Step 305: If the difference is greater than the second threshold, the business query device will incrementally synchronize the data that has changed since the most recent update timestamp in the original data table through the data synchronization service.

[0142] In some embodiments of this application, the business query device performs a data verification before routing the query request to the target search engine. Specifically, the business query device first queries Elastic Search for the last update timestamp of the target index, which records the moment the index was most recently successfully built or updated. Simultaneously, the business query device queries the Tidb database for the last change timestamp of the original business table that serves as the source of the index data, i.e., the time when all records in that table were most recently modified. By calculating the difference between these two timestamps, it can be determined whether there is a significant lag between the data in the search engine and the authoritative data in the database. If the time difference exceeds a preset tolerance threshold (e.g., 2 seconds, which can be adjusted according to the business's requirements for data real-time performance), it is determined that the data may be outdated, and a data synchronization service is immediately triggered to perform an emergency incremental synchronization of data that has changed since the last update timestamp of the index, ensuring the accuracy of the query results. After the synchronization operation is confirmed, the query request is then routed to the target search engine index, which has been updated to the latest state.

[0143] In this way, by comparing timestamps before querying and triggering incremental synchronization when the difference is too large, the strong real-time performance and high accuracy of query results are ensured. The on-demand and lightweight approach makes up for the delay that may exist in periodic synchronization. While ensuring data quality, it avoids the huge waste of resources caused by frequent full synchronization and achieves a balance between data consistency and system performance.

[0144] In some embodiments of this application, such as Figure 5 The diagram shown is a flowchart of another business query method provided in this application embodiment. It illustrates the entire implementation process of the business query method. This method integrates the Tidb database and the Elastic Search search engine to build an efficient and fast provident fund business query system. The overall execution process includes stages such as system initialization, data synchronization and business query, specifically including the following steps 21 to 31.

[0145] Step 21: Business Data Storage: After processing individual account opening, business entity account opening, monthly contributions, and other business transactions, the housing provident fund business system will persistently store the generated structured business data (such as individual account information tables, business entity information tables, and their related tables) in the Tidb database.

[0146] Step 22, Full Index Initialization: When the data synchronization service starts for the first time, or after detecting and recovering from a connection error with the Tidb database during its operation, the data synchronization service will perform a full data synchronization, reading all the current business data in the Tidb database at once, building an initial unstructured business data index (including a full index of personal information and a full index of business entity information), and storing it in Elastic Search.

[0147] Step 23, Periodic Incremental Synchronization: The data synchronization service is based on a timed polling mechanism, which periodically (e.g., every 30 seconds) initiates queries to the Tidb database. By sending specific SQL query statements, it retrieves data records whose version number or update timestamp has changed since the last polling cycle and obtains the change information.

[0148] Step 24, Data Filtering and Encapsulation: The data synchronization service filters the acquired change information according to pre-configured business rules (such as only synchronizing accounts with normal status, or only synchronizing data that has changed in the last month) to obtain the target business data, and then encapsulates this data into JSON document format.

[0149] Step 25, Index Update: The data synchronization service sends the encapsulated JSON document formatted data to Elasticsearch. After receiving this data, Elasticsearch updates its internal unstructured business data index in real time to ensure that the index data is synchronized with the changes in the Tidb database.

[0150] Step 26: Receive query request: The client of the housing provident fund system (such as the operation interface of business personnel or the personal online hall) initiates a query request, and the business query device (such as the backend service) receives the query request.

[0151] Step 27, Parsing and Routing Decision: The business query device parses the query request and determines its query type. If the query request is a fuzzy query, auto-complete query, or search suggestion query, a real-time data consistency check is performed. If the query request is an exact query, or its complexity is extremely high (such as a complex fuzzy query involving multiple deeply related tables), the request is directly routed to the Tidb database for querying and the results are returned.

[0152] Step 28, Real-time Data Consistency Verification: For critical businesses requiring extremely high real-time performance, the business query device can perform a real-time verification before routing the query to Elastic Search: obtain the last update timestamp of the relevant index in Elastic Search and compare it with the last change timestamp of the source data table in the Tidb database. If the time difference exceeds a preset threshold (e.g., 2 seconds), the data synchronization service will be immediately triggered to perform an incremental synchronization.

[0153] Step 29: Execute search engine query: The business query device routes the query request to Elastic Search. Based on its latest, updated unstructured business data index, Elastic Search performs efficient full-text search and fuzzy matching, completing the query in milliseconds.

[0154] Step 30: Return query results: Elastic Search returns the set of business data records matched by the query to the business query device.

[0155] Step 31: Return the results to the client: The business query device returns the received set of business data records to the client that initiated the query. The user interface is then refreshed to display the query results, completing a fast and accurate business query.

[0156] It should be noted that for a detailed explanation of each step in this embodiment, please refer to the description in the above embodiments, which will not be repeated here.

[0157] The technical solution of this application begins with the storage of business data in TiDB. A lightweight, periodic data synchronization service continuously and efficiently synchronizes data changes to Elastic Search to build a full index. When a user initiates a query, an intelligent routing mechanism guides the appropriate query type to Elastic Search for execution, thereby improving database performance. Ultimately, this achieves sub-second-level fast fuzzy queries on massive amounts of housing provident fund business data, improving business processing efficiency and system resource utilization.

[0158] Figure 6 This is a schematic diagram of the structure of a business query device provided in an embodiment of this application, as shown below. Figure 6 As shown, the service query device 100 includes: a storage module 101, a processing module 102, a sending module 103, and a receiving module 104.

[0159] The storage module 101 stores structured business data from the business system in the target database. The processing module 102 periodically queries the target database through a data synchronization service in the business system to obtain changed structured business data and change information. The processing module 102 also encapsulates the change information into data in a predetermined format through the data synchronization service. The sending module 103 sends the data in the predetermined format to the target search engine. The processing module 102 also updates the index of unstructured business data stored in the target search engine based on the data in the predetermined format. The receiving module 104 receives query requests from the client. The sending module 103 routes the query request to the target search engine. The processing module 102 retrieves the set of business data records corresponding to the query request through the target search engine based on the updated index of unstructured business data. The sending module 103 returns the set of business data records to the client.

[0160] In some embodiments of this application, the processing module 102 described above is specifically used to: periodically send query statements to the target database through a data synchronization service, the query statements being used to retrieve data records that have changed since the previous query period; and obtain structured business data from the target database whose data record version number or update timestamp has changed, as change information.

[0161] In some embodiments of this application, the processing module 102 is further configured to construct an initial unstructured business data index from the current full amount of business data in the target database and store it in the target search engine when the data synchronization service starts or after an abnormal connection with the target database is detected.

[0162] In some embodiments of this application, the aforementioned unstructured business data index includes a full index of customer information and a full index of business entity information. The full index of customer information is obtained by associating, merging, and serializing data from multiple different customer information association tables in the target database. The full index of business entity information is obtained by associating, merging, and serializing data from multiple different business entity information association tables in the target database.

[0163] In some embodiments of this application, the sending module 103 is specifically used to: parse the query request and determine the query type of the query request; if the query type of the query request is a target query type, then route the query request to the target search engine, the target query type including fuzzy query, auto-complete query or search suggestion query.

[0164] In some embodiments of this application, the sending module 103 is further configured to route the query request to the target database if the query type of the query request is not the target query type, or the complexity of the query request is greater than or equal to a first threshold.

[0165] In some embodiments of this application, the processing module 102 is specifically used to: obtain target business data that conforms to the business rules from the change information through the data synchronization service according to the pre-configured business rules, and encapsulate the target business data into a predetermined format to obtain data in the predetermined format; wherein, the above-mentioned business rules are: account information whose synchronization status is valid, or account information that has changed within a preset time period.

[0166] In some embodiments of this application, the above-described apparatus further includes: an acquisition module; the acquisition module is configured to acquire the most recent update timestamp of the data index related to the query request in the target search engine before the sending module 103 routes the query request to the target search engine; acquire the last change timestamp of the original data table in the target database that serves as the source of the data index; the processing module 102 is further configured to calculate the difference between the most recent update timestamp and the last change timestamp; if the difference is greater than a second threshold, incremental synchronization is performed on the data in the original data table that has changed since the most recent update timestamp through a data synchronization service.

[0167] It should be noted that the explanation of the business query device 100 can be found in the relevant description of the business query device in the above embodiments, and will not be repeated here to avoid repetition. The business query device provided in this application embodiment can achieve the same effect as the above-described business query method. The effect of the business query method can be found in the relevant description of the effect of the above-described embodiments of the business query method, and will not be repeated here to avoid repetition.

[0168] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 7 As shown, the electronic device 500 includes: a memory 501, a transceiver 502, and at least one processor 503.

[0169] Transceiver 502 is used to interact with other devices to send and receive data.

[0170] The memory 501 is used to store computer program code, which includes computer instructions. These computer instructions run in the aforementioned electronic device to implement the method shown in the above-described method embodiments. For example, the memory may include high-speed random access memory (RAM), and may also include non-volatile memory (NVM), such as at least one disk storage device, or a USB flash drive, portable hard drive, read-only memory, magnetic disk, or optical disk, etc.

[0171] Processor 503 can be a general-purpose processor, including a Central Processing Unit (CPU), a network processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Processor 503 can also be other general-purpose processors. The general-purpose processor can be a microprocessor or any conventional processor.

[0172] The memory 501, transceiver 502, and processor 503 are communicatively connected. For example, the memory 501 and transceiver 502 can be connected to the processor 503 via a system bus and communicate with each other. The system bus can be a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, an industry standard architecture (ISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the figure, but this does not mean that there is only one bus or one type of bus.

[0173] Optionally, the memory 501 can be either standalone or integrated with the processor 503. When the memory 501 is set up independently, it is connected to the processor 503 via a system bus.

[0174] This application also provides a chip for executing instructions, which is used to execute the technical solution of the business query method in the above embodiments.

[0175] This application also provides a computer-readable storage medium storing computer instructions. When these computer instructions are executed by a processor, they are used to implement the technical solution of the business query method described in the above embodiments. Specifically, when the computer instructions are executed by a processor, the electronic device can execute the technical solution of the business query method described in the above embodiments.

[0176] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and when the at least one processor executes the computer program, it can implement the technical solution of the business query method in the above embodiments.

[0177] The aforementioned computer-readable storage media can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The computer-readable storage media can be any available medium accessible to a general-purpose or special-purpose computer.

[0178] An exemplary computer-readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the computer-readable storage medium can also be a component of the processor. The processor and the computer-readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the computer-readable storage medium can exist as discrete components in an electronic control unit or main control device; this application does not limit this.

[0179] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0180] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs.

[0181] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0182] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0183] It should be understood that the steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

[0184] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0185] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A business query method, characterized in that, include: The structured business data of the business system is stored in the target database. The structured business data includes a customer account information table and a business entity information table. The customer account information table includes fields for account type, account number, unique account identifier, account change value, and account cumulative value. Through the data synchronization service in the business system, queries are periodically initiated to the target database to obtain the changed structured business data and obtain change information; The change information is encapsulated into data in a predetermined format through the data synchronization service, and the data in the predetermined format is sent to the target search engine. Update the unstructured business data index stored in the target search engine according to the predetermined format data; Receive query requests from clients and route the query requests to the target search engine; Using the target search engine, based on the updated unstructured business data index, a set of business data records corresponding to the query request is obtained, and the set of business data records is returned to the client.

2. The business query method according to claim 1, characterized in that, The process involves periodically initiating queries to the target database through the data synchronization service in the business system to obtain changed structured business data and acquire change information, including: Through the data synchronization service, query statements are periodically sent to the target database. These query statements are used to retrieve data records that have changed since the previous query period. From the target database, obtain structured business data whose data record version number or update timestamp has changed, as the change information.

3. The business query method according to claim 1, characterized in that, The method further includes: When the data synchronization service starts or after an abnormal connection with the target database is detected, the current full amount of business data in the target database is used to construct an initial unstructured business data index and stored in the target search engine.

4. The business query method according to any one of claims 1 to 3, characterized in that, The unstructured business data index includes a full index of customer information and a full index of business entity information. The full index of customer information is obtained by associating, merging, and serializing data from multiple different customer information association tables in the target database. The full index of business entity information is obtained by associating, merging, and serializing data from multiple different business entity information association tables in the target database.

5. The business query method according to claim 1, characterized in that, The step of routing the query request to the target search engine includes: The query request is parsed to determine the query type. If the query type of the query request is a target query type, the query request will be routed to the target search engine. The target query type includes fuzzy query, autocomplete query, or search suggestion query.

6. The business query method according to claim 5, characterized in that, The method further includes: If the query type of the query request is not the target query type, or the complexity of the query request is greater than or equal to the first threshold, then the query request will be routed to the target database.

7. The business query method according to claim 1, characterized in that, The process of encapsulating the change information into data of a predetermined format through the data synchronization service includes: Through the data synchronization service, target business data that conforms to the pre-configured business rules is obtained from the change information according to the pre-configured business rules, and the target business data is encapsulated into a predetermined format to obtain the predetermined format data; The business rule is as follows: synchronize account information with a valid status identifier, or synchronize account information that has changed within a preset time period.

8. The business query method according to claim 1, characterized in that, Before routing the query request to the target search engine, the method further includes: Obtain the most recent update timestamp of the data index related to the query request in the target search engine; Obtain the last change timestamp of the original data table in the target database that serves as the source of the data index; Calculate the difference between the most recent update timestamp and the last change timestamp; If the difference is greater than the second threshold, then the data synchronization service is used to incrementally synchronize the data in the original data table that has changed since the most recent update timestamp.

9. A business query device, characterized in that, include: Storage module, processing module, sending module, and receiving module; The storage module is used to store the structured business data of the business system in the target database. The structured business data includes a customer account information table and a business entity information table. The customer account information table includes fields for account type, account number, unique account identifier, account change value, and account cumulative value. The processing module is used to periodically initiate queries to the target database through the data synchronization service in the business system to obtain the changed structured business data and obtain change information. The processing module is also used to encapsulate the change information into data in a predetermined format through the data synchronization service; The sending module is used to send the data in the predetermined format to the target search engine; The processing module is also used to update the unstructured business data index stored in the target search engine according to the predetermined format data; The receiving module receives query requests from the client; The sending module is also used to route the query request to the target search engine; The processing module is further configured to use the target search engine to query a set of business data records corresponding to the query request based on the updated unstructured business data index; The sending module is also used to return the set of business data records to the client.

10. An electronic device, characterized in that, include: The electronic device includes a memory and at least one processor; the memory is communicatively connected to the processor; the memory is used to store computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, the electronic device performs the business query method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions, which, when executed by a processor, are used to implement the business query method as described in any one of claims 1-8.

12. A computer program product, characterized in that, When the computer program product is run on a computer / executed by the computer's processor, it implements the business query method as described in any one of claims 1-8.

Images