A Cross-Database Access Method and System
Through the cross-base query server splitting and scheduling query requests, combined with virtual nodes and hashing algorithms, the problems of timely data acquisition and load balancing in cross-base query in multi-data centers are solved, and efficient data analysis and stable database access are achieved.
Patent Information
- Application Number
- CN202211157874.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-09-22
- Publication Date
- 2025-07-08
- Estimated Expiration
- 2042-09-22
AI Technical Summary
In the cross-base query scenarios of multiple data centers, the existing technology has poor timely data acquisition, which affects the progress of middle-end data analysis and has a great impact on the association query and summary calculation of the original business system.
The query request splitting mechanism based on insertion position prediction is adopted. By a cross-base query server, a query request set with sequence execution order is formed, and the query request is scheduled to the database server for execution in real time, load balancing is achieved by combining the hashing method of virtual nodes and approximate algorithms.
It ensures the parallelism and load balancing of cross-base access, improves the timeliness of data acquisition, and ensures the stability of the database server and dynamic adjustment of computing capabilities.
Smart Images

Figure CN115576985B_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of database access, and particularly relates to a cross-database access method and system.
Background Art
[0002] With the continuous development of science and technology, the application of big data technology is becoming increasingly widespread. Along with the use of big data technology in various industries, different styles of data are usually stored in different types of databases. A single data center is difficult to solve bottleneck problems such as ultra-large data storage, overloaded computing, and ultra-high concurrent throughput, so multiple data centers have emerged. Each data center in multiple data centers can deploy one or more databases such as MySQL, ODPS (Open Data Processing Service), or Hive. Among them, MySQL is a relational database management system, ODPS is a fast and fully managed data warehouse solution, and Hive is a data warehouse tool capable of data extraction, transformation, and loading. The real-time data of a general business system is usually stored in a relational database built in the oracle database style or MySQL database style, while the historical data of the general business system is stored in a non-relational database built in the HBase database style or Hive database style.
[0003] In terms of data application, with the construction of the data middle platform, master data is centrally managed and stored. According to database performance limitations and business characteristics, master data is divided into seven business domains such as equipment and customers, and is stored in seven database clusters respectively. A typical cross-database query business scenario description: For the list of project start-up approval to be reported, it is necessary to display the start-up approval documents that the current handler needs to report. The list shows relevant data in the project center, contract center, and project business, and needs to query according to some fields in the project center, contract center, and project business. In this case, it is necessary to separately query data from each database, and only after obtaining the desired data from each database can the overall analysis of the data be realized. However, this data acquisition method has the problem of weak timeliness of data acquisition, which affects the implementation progress of middle platform data analysis. Based on the master data sharing service platform, it will also have a greater impact on various business operations such as related queries and summary calculations in the original business system.
[0004] The present invention maximally guarantees the parallelism of access; proposes a query request splitting mechanism based on insertion position prediction, providing a quantitative basis for the parallelism of access requests; realizes load balancing that can be dynamically adjusted and randomly allocated and maintained, and at the same time guarantees the stability of the database server.
Summary of the Invention
[0005] To solve the above problems in the prior art, the present invention proposes a cross-database access method and system, and the method includes:
[0006] Step S1: The business front end issues a list query request; the list query request is a query request for multiple databases;
[0007] Step S2: The cross-database query server receives the list query request, parses and splits the list query request to form one or more query requests with a sequential execution order; sorts the one or more query requests according to the sequential dependency relationship of the execution order to form a first sequence including a set of query requests with a sequential order; inserts the first sequence into the query request queue; the query request queue contains one or more sets of query requests with a sequential scheduling relationship order and a sequential dependency relationship order; the sequential scheduling relationship order reflects the possible scheduling order of the query requests in the set, and the basic principle is that the earlier ones are scheduled first and the later ones are scheduled later; the sequential dependency relationship order reflects the data dependency relationship of the query requests in the execution order; the later query requests need to wait until the earlier query requests are executed before they can be executed; there is no relationship including a sequential scheduling relationship and a sequential dependency relationship between the query requests within the set, and the existing relationship is the relationship between the sets;
[0008] Step S3: The cross-database query server encapsulates the query requests in the query request queue into database query requests and schedules them to the database server in real time; specifically: sequentially obtains the sets of query requests in the query request queue, and after encapsulating the query requests in the set of query requests for the database server, distributes them to one or more database servers for execution;
[0009] Step S4: The database server receives the scheduled database access request and executes the database access request;
[0010] Step S5: Return the query result to the business front end.
[0011] Further, the list query request is a list query request for the list of project start-up approval to be reported.
[0012] Further, the business front end issues a list query request through the cross-database query interface provided by the cross-database query server; accesses the cross-database query interface through the cross-database query application.
[0013] Further, the multiple databases are respectively set in one or more database servers.
[0014] Further, step S3 specifically includes the following steps:
[0015] Step S31: The cross-database query server reads the cache information in real time to obtain the status of the database server; if there is a database server with idle working nodes, then go to Step S32, otherwise, return to Step S31 to re-execute the status reading;
[0016] Step S32: Obtain the query request set at the head of the query request queue;
[0017] Step S33: When the number of elements in the obtained query request set is greater than or equal to the number of idle database server working nodes, go to Step S34; otherwise, go to Step S35;
[0018] Step S34: Select from the obtained query request set the same number of query requests as the number of working nodes in the idle database server, delete the selected query requests from the obtained query request set and retain the unselected query requests; when the set is not empty, put the query request set after the deletion and retention processing back to the head of the query request queue; go to Step S36;
[0019] Step S35: Take all the query requests in the query request set as the selected query requests;
[0020] Step S36: Convert the selected query requests based on the query service mode of the idle database server, and encapsulate the query requests for the same database server working node into a database access request; schedule the database access request obtained after encapsulation to the idle database server.
[0021] A cross-database access system for implementing the above method, including: the system includes a cross-database query server and multiple database servers.
[0022] Further, it also includes a cross-database supervision server, which is used to monitor the load situation of each database server in real time and perform load balancing on the database servers based on the monitoring results.
[0023] Further, the database server is a database server capable of executing parallel queries.
[0024] A computer-readable storage medium, including a program, which when running on a computer, enables the computer to execute the cross-database access method.
[0025] A big data server, characterized in that the big data server is configured to execute the cross-database access method.
[0026] The beneficial effects of the present invention include:
[0027] (1) Set the query request management method for the set sequence. While ensuring the order of the sequence of query requests and the order of dependencies, the parallelism of access is maximally ensured through the method of sequence insertion; propose a query request splitting mechanism based on the prediction of insertion positions to provide a quantitative basis for the parallelism of access requests;
[0028] (2) Set up a mapping relation table to realize the multi-effect expression of information during the access process. While reflecting the computing power of the working nodes, the node status information is also expressed. The higher the computing power of a node, the higher the probability of being assigned a query request. Through the dynamic setting of the mapping relation, the processing ability of the working ability can be reflected. That is to say, this random assignment realizes a complex balance based on computing power while maintaining randomness; with randomness comes security;
[0029] (3) By setting up virtual nodes and a hash method based on an approximation algorithm, a circular virtual space is formed; in the case where the processing time length of query requests varies greatly and the cross-database access system is not busy, a load balance that can be dynamically adjusted and maintained with random assignment is realized, while also ensuring the stability of the database server.
Description of the Drawings
[0030] The drawings described herein are used to provide a further understanding of the present invention and form a part of this application, but do not constitute an improper limitation to the present invention. In the drawings:
[0031] Figure 1 It is a schematic diagram of the cross-database access method provided by the present invention.
[0032] Figure 2 It is a schematic diagram of the cross-database access system related to the embodiment of the present invention.
[0033] Figure 3 It is a schematic diagram of the circular hashing and approximate mapping method provided by the present invention.
Detailed Embodiment
[0034] The present invention will be described in detail below in conjunction with the drawings and specific embodiments. The illustrative embodiments and descriptions are only used to explain the present invention and do not limit the present invention;
[0035] As shown in the attached Figure 1 A cross-database access method provided by the present invention includes the following steps:
[0036] Step S1: The business front-end sends out a list query request; the list query request is a query request for multiple databases;
[0037] Preferably: the list query request is a list query request for the list of project start-up approval to be reported;
[0038] Preferably, the service front-end sends a list query request through the cross-database query interface provided by the cross-database query server; accesses the cross-database query interface through the cross-database query application;
[0039] Preferably, the multiple databases are respectively set in one or more database servers;
[0040] Preferably, the cross-database query service provided by the cross-database query server is based on the Presto component. The Presto component provides services such as discovery, registration, and query of database servers, and on this basis, a cross-database query interface is encapsulated to support parallel list query requests for multiple databases;
[0041] Step S2: The cross-database query server receives the list query request, parses and splits the list query request to form one or more query requests with a sequential execution order; arranges the one or more query requests according to the sequential dependency relationship in the execution order to form a first sequence containing a set of query requests with a sequential order; inserts the first sequence into the query request queue; the query request queue contains one or more sets of query requests with a sequential scheduling relationship order and a sequential dependency relationship order; the sequential scheduling relationship order reflects the possible scheduling order of the query requests in the set, and the basic principle is that the earlier ones are scheduled first and the later ones are scheduled later; the sequential dependency relationship order reflects the data dependency relationship of the query requests in the execution order; the later query requests need to wait until the earlier query requests are executed before they can be executed; there is no sequential scheduling relationship and sequential dependency relationship between the query requests within the set, but there is such a relationship between the sets; the query request queue is the scheduling queue of the cross-database query server. Therefore, it is necessary to maintain various order relationships to achieve efficient cross-database access on the basis of ensuring that the query requests are satisfied;
[0042] The parsing and splitting of the list query request to form one or more query requests with a sequential execution order are specifically as follows: Estimate the request size based on the attribute information of the list query request; if the estimated request size exceeds the preset size and the request is splittable, then further split until the size of the split query request is less than or equal to the preset size, and then stop splitting; one or more query requests can be obtained through continuous splitting; this splitting is based on the parameters of the list query request. For example, it is split based on the list type targeted, split for the database, etc.;
[0043] The attribute information includes query request parameters, such as one or more of the database, table, field, task name, keyword, query parameter, search type, request type, etc. targeted by the query; the request size is the size of the query result obtained by the query request or the time length for executing the query request;
[0044] Preferably, a correspondence table between the combination of one or more pieces of attribute information and the request size is preset and stored, and the request size is obtained by querying the correspondence table; the correspondence table can be obtained by fitting historical data;
[0045] Preferably, a neural network model is constructed, and the neural network model is trained based on a sample set including attributes and request sizes, and the request size predicted by the model is obtained by inputting the attributes;
[0046] Inserting the first sequence into the query request queue; specifically includes the following steps:
[0047] Step SC1: Obtain a query request set from the head of the first sequence;
[0048] Step SC2: Calculate the number of positions of the expected insertion position in the query request queue; specifically: calculate the number of positions using the following formula Where: Nq i is the number of elements q i,j in the i-th query request set Q i in the query request queue ({q i,j}); Lq is the length of the query request queue, that is, the number of sets; P is the number of query requests that a database server can execute simultaneously under the minimum parallelism; that is to say, the expected insertion positions are distributed at the set positions of one or more queues, and the scheduling orders corresponding to different insertion positions are different; the number of positions here is the position where the query request server can insert query requests to meet the minimum parallelism and avoid wasting computing resources;
[0049] The above calculation method is based on the premise that there is no data dependency between the query requests in the first sequence and the query requests in the query request queue; if there is a possibility of data dependency, use the following formula to calculate the number of positions NI = ∑ i (P - Nq i ), where: i is the number of the set that has no data dependency with the elements q i in the query request set Q i,j ; for example: when a database server includes 1 coordinator and 3 worker nodes, the minimum parallelism is 3;
[0050] Step SC3: If the number of positions is greater than or equal to the number of elements in the obtained query request set, insert the query requests in the query request set into the expected insertion positions respectively; otherwise, insert the query request set into the tail of the query request queue;
[0051] Step SC4: Determine whether there is still an acquirable query request set in the first sequence. If so, return to Step SC1; if not, end.
[0052] Step S3: The cross-database query server encapsulates the query requests in the query request queue into database query requests and schedules them to the database server in real time. Specifically: sequentially acquire the query request sets in the query request queue, and after encapsulating the query requests in the query request sets for the database server, allocate them to one or more database servers for execution.
[0053] The specific steps of Step S3 are as follows:
[0054] Step S31: The cross-database query server reads the cache information in real time to obtain the status of the database server. If there is a database server with idle working nodes, enter Step S32; otherwise, return to Step S31 to re-execute the status reading.
[0055] Preferably: The cross-database query server obtains the status of the database server and its working nodes by reading the mapping relation table. After a working node is scheduled or released, it records the change in the working status of the working node by rewriting the mapping relation table. It also obtains the computing power of the working node through the mapping relation table. The more virtual working nodes corresponding to a real working node, the more it accounts for in the mapping relation table.
[0056] Step S32: Obtain the query request set at the head of the query request queue.
[0057] Step S33: When the number of elements in the obtained query request set is greater than or equal to the number of idle database server working nodes, enter Step S34; otherwise, enter Step S35.
[0058] Step S34: Select the same number of query requests as the number of working nodes in the idle database server from the obtained query request set, delete the selected query requests in the obtained query request set and retain the unselected query requests. When the set is not empty, put the query request set after the deletion and retention process back to the head of the query request queue. Enter Step S36.
[0059] The selection of the same number of query requests as the number of working nodes in the idle database server from the obtained query request set is specifically: read the mapping relation table to obtain the computing power of the working node, and select the working node according to the complexity of the query request so that the complexity of the query request is adapted to the computing power of the working node. A relatively simple method is to sort the query requests according to the complexity and sort the working nodes according to the computing power, and make a corresponding adaptation according to the sorting results.
[0060] Alternative: Select the same number of query requests as the number of worker nodes in the idle database server from the obtained set of query requests. Specifically: Select worker nodes according to the splitting of the query requests so that the splitting relationship of the query requests is adapted to the communication distance of the worker nodes. Here, the splitting relationship refers to whether the splitting requests come from the same list query request during the splitting in step S2. If so, there is a splitting relationship; otherwise, there is no splitting relationship. And the communication distance between multiple worker nodes in the same database server is the smallest. In this way, the query requests from the same list query request are allocated to the same database server, thereby reducing the overhead of combining query result data in the later stage.
[0061] Alternative: Consider the above two methods simultaneously and combine them through a weighted summation method.
[0062] Step S35: Take all the query requests in the set of query requests as the selected query requests.
[0063] Preferred: Select worker nodes from the idle worker nodes that are adapted to the selected query requests. The selection method is similar to that in step S34.
[0064] Step S36: Convert the selected query requests based on the query service mode of the idle database server, and encapsulate the query requests for the worker nodes of the same database server into a database access request. Schedule the obtained database access request after encapsulation to the idle database server. Support heterogeneous database servers through the conversion of the query server mode, thereby supporting database sources with different access modes. The database server can access multiple data sources and support cascaded queries across data sources.
[0065] Preferred: The database server is registered in the cross-database query server through caching. Therefore, the status of the database server and its internal nodes can be effectively discovered in a timely manner. By regularly obtaining the status in the cache, the status of the database server and its internal nodes can be discovered, and further request scheduling and load balancing can also be performed.
[0066] Step S4: The database server receives the scheduled database access request and executes the database access request. The database server is a database server capable of performing parallel queries.
[0067] Preferably, the database server consists of a coordinator node and multiple worker nodes; where: after receiving a database access request, the coordinator node dynamically parses it into multiple query requests and assigns them to multiple worker nodes for parallel computing. After the worker nodes complete the tasks, they notify the coordinator to end the query request and send the query result data to the coordinator node; as shown in the attachment Figure 2 As shown in the figure, taking 4 database servers, each database server contains 3 worker nodes and 1 coordinator node as an example, the system includes: coordinator nodes C100 to C400, worker nodes W101 to W403, which are respectively deployed on 4 different servers, and the worker nodes are also respectively deployed on 4 different servers;
[0068] By setting virtual nodes and using a hash method based on an approximation algorithm, a circular virtual space is formed; in the case where the processing time length of query requests varies greatly, dynamic adjustment and random allocation-preserved load balancing are achieved, while also ensuring the stability of the database server; specifically including:
[0069] Step SA1: Set a status table on the coordinator node, and each bit in the status table corresponds to recording the working status of a real worker node; where: the working status includes busy, idle, and faulty;
[0070] Preferably, the status table is a mapping relationship table, and the working status of each real worker node is recorded through the mapping relationship table; the mapping relationship table is stored on the coordinator node of the database server and / or the cross-database query server;
[0071] Step SA2: Set VN virtual nodes for each coordinator node;
[0072] Preferably, VN is a preset value;
[0073] Preferably, the VN = 2 m*(m-1) ; m is the number of nodes in the database server;
[0074] Alternatively, the VN = 2 2*m ; m is the number of nodes in the database server;
[0075] Step SA3: Set the mapping relationship between the real worker node identifier and the virtual node identifier, so that multiple virtual nodes are mapped to one worker node;
[0076] Preferably, the VN is positively correlated with the total computing power of the nodes (coordinator nodes and worker nodes) in the database server and the number of worker nodes; the mapping relationship between the real worker node and the virtual node is set according to the computing power of the worker node, so that U kA mapping relationship is formed between the \(i\)-th virtual node and the \(k\)-th real working node; and \(U\) k ∝CP k ; where: CP k is the computing power of the \(k\)-th real working node; that is, the higher the computing power of a node, the higher the probability of being assigned a query request. Through the dynamic setting of the mapping relationship, the processing ability of the working ability can be reflected. That is to say, this random assignment realizes complex balance based on computing power while maintaining randomness; with randomness comes security;
[0077] Step SA4: The database server receives a database query request, the coordination node randomly generates an internal query request identifier key1, and calculates the hash value k1 of the internal query request identifier key1; k1 = hash(key1). Through an approximation algorithm, the virtual node identifier closest to the hash value k1 is obtained, and the corresponding real node identifier is obtained by querying the mapping relationship based on the closest virtual node identifier;
[0078] Step SA5: The query request is assigned to the real node corresponding to the real node identifier, and the corresponding bit in the status table / mapping relationship table is set to the busy state; when the real node completes the query request task, the corresponding bit in the status table is set to the idle state; when the real state node fails, the corresponding bit in the status table / mapping relationship table is set to the failure state; when the corresponding bit is in the busy state or the failure state, the virtual node identifier corresponding to the real node identifier is set to invalid;
[0079] Preferably: \(U\) is set by setting the mapping relationship table k A mapping relationship is formed between the \(i\)-th virtual node and the \(k\)-th real working node; the virtual node identifier is made to disappear invalid by setting the real node identifier and its corresponding virtual node identifier in the mapping relationship table to invalid;
[0080] In this way, when a real node crashes, after calculating the hash value, the closest virtual node identifier that might originally be obtained through the approximation algorithm cannot be obtained because it is invalid. At this time, the approximation algorithm will obtain a relatively far virtual node identifier, and the query of the mapping relationship will fall on other virtual nodes at this time; that is to say, when the completion time of the query request is unknown, in this way, a load balance with dynamic node changes is formed within the existing node range; as shown in the appendix Figure 3 As shown, when the real node Real1 crashes, the v100 and v101 nodes will also be invalid. Similarly, the query approximation algorithm gets k1 and will automatically fall on the virtual node v301, and the corresponding real node is Real3, so that the query request is assigned to the node Real3;
[0081] Further: It is said that the method further includes: the cross-database supervision server monitors the load conditions of each database server in real time, and performs load balancing on the database servers based on the monitoring results; the monitoring results include: node number, node address, data source connector, node type, version, service update time, and current and historical information of CPU load and memory load.
[0082] Further: The method further includes step S5: returning the query result to the business front end; specifically: after the database server completes the database query request, it writes the query result into the cache space of the cross-database query server; after all the query requests in the first sequence are executed, the cross-database query server returns the query result in the cache space to the business front end.
[0083] Preferably: The cache is located in the database server and / or the cross-database query server.
[0084] The terms "cross-database query server" and "database server" include all kinds of devices, equipment, and machines for processing data, for example, programmable processors, computers, system-on-chips, or a plurality of the above or combinations thereof. The device can include dedicated logic circuits, such as FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit). In addition to hardware, the device can also include code to create an execution environment for the computer program, for example, code constituting processor firmware, protocol stack, database management system, operating system, cross-platform runtime environment, virtual machine, or a combination of one or more of the above. The device and the execution environment can implement various different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.
[0085] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including assembly or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may or may not correspond to a file in the file system. The program can be stored as part of a file that holds other programs or data (such as one or more scripts in a markup language document), in a single file dedicated to the program, or in multiple cooperating files (such as files storing one or more modules, subroutines, or code portions). A computer program can be deployed to execute on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.
[0086] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) that contain computer-usable program code.
[0087] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to the processors of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, so that the instructions executed by the processors of the computer or other programmable data processing devices generate means for implementing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.
[0088] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate a manufactured article including instruction means, and the instruction means implements the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.
[0089] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.
[0090] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to the above embodiments, those of ordinary skill in the art should understand that: still can modify the specific implementation manners of the present invention or make equivalent replacements, and any modification or equivalent replacement that does not depart from the spirit and scope of the present invention shall be covered by the protection scope of the claims of the present invention.
Claims
1. A cross-library access method, characterized in that, The method includes: Step S1: The business front end sends a list query request; the list query request is a query request for multiple databases. Step S2: The cross-database query server receives the list query request, parses and splits the list query request to form one or more query requests with a sequential execution order. Organize the one or more query requests according to the sequential dependency relationship of the execution order to form a first sequence including a set of query requests with a sequential order; insert the first sequence into the query request queue; the query request queue contains one or more sets of query requests with a sequential scheduling relationship order and a sequential dependency relationship order; the sequential scheduling relationship order reflects the possible scheduling order of the query requests in the set, and the basic principle is that the earlier ones are scheduled first and the later ones are scheduled later; the sequential dependency relationship order reflects the data dependency relationship of the query requests in the execution order; the later query requests need to wait until the earlier query requests are executed before they can be executed; there is no relationship including a sequential scheduling relationship and a sequential dependency relationship among the query requests within the set, and the existing relationship is the relationship between the sets. Step S3: The cross-database query server encapsulates the query requests in the query request queue into database query requests and schedules them to the database server in real time; specifically: sequentially obtain the sets of query requests in the query request queue, and after encapsulating the query requests in the set of query requests for the database server, allocate them to one or more database servers for execution. Step S5: The database server receives the scheduled database access request and executes the database access request. Step S6: Return the query result to the business front end.
2. The cross-library access method according to claim 1, wherein The list query request is a list query request for the list of project start-up approval to be reported.
3. The cross-library access method according to claim 2, wherein The business front end sends the list query request through the cross-database query interface provided by the cross-database query server; accesses the cross-database query interface through the cross-database query application.
4. The cross-database access method according to claim 3, characterized in that The multiple databases are respectively set in one or more database servers.
5. The cross-library access method according to claim 4, characterized in that, Step S3 specifically includes the following steps: Step S31: The cross-database query server reads the cache information in real time to obtain the status of the database server; if there is a database server with idle working nodes, then go to Step S32, otherwise, return to Step S31 to re-execute the status reading. Step S32: Obtain the set of query requests at the head of the query request queue. When the number of elements in the obtained set of query requests is greater than or equal to the number of idle working nodes of the database server, go to Step S34. Otherwise, go to Step S35. Step S34: Select from the obtained set of query requests the same number of query requests as the number of working nodes in the idle database server, delete the selected query requests in the obtained set of query requests and retain the unselected query requests; when the set is not empty, put the set of query requests after the deletion and retention process back to the head of the query request queue. Go to Step S36. Step S35: Regard all the query requests in the set of query requests as the selected query requests. Step S36: Select query requests based on the query service mode conversion of the idle database server, encapsulate query requests for the same database server working node into one database access request; schedule the database access request obtained after encapsulation to the idle database server.
6. A cross-library access system for implementing the method according to any one of claims 1-5, characterized in that, Including: The system includes a cross-database query server and multiple database servers.
7. The cross-library access system according to claim 6, wherein It further includes a cross-database supervision server for real-time monitoring of the load conditions of each database server and performing load balancing on the database servers based on the monitoring results.
8. The cross-library access system according to claim 7, wherein The database server is a database server capable of executing parallel queries.
9. A computer-readable storage medium, characterized in that, Including a program which, when running on a computer, causes the computer to execute the cross-database access method according to any one of claims 1-5.
10. A big data server, characterized in that, The big data server is configured to execute the cross-database access method according to any one of claims 1-5.
Citation Information
Patent Citations
Database content combination method and device
CN105320681A
Performance analysis method and performance analysis apparatus for at least one execution unit
KR1020140030660A