Distributed database connection management method and database connection management method

Abstract

The invention relates to a distributed database connection management method and a database connection management method. The method comprises the following steps: receiving a database connection request which is sent by a client and carries a target user identifier, a target database identifier and a starting parameter, searching available connections of the client based on the target user identifier, the target database identifier and the starting parameter, and distributing the searched available connections to the client, a trained connection use prediction model is called, the life cycle of the connection maintained in the connection pool of each database is predicted, a prediction result is obtained, and the connection use prediction model is obtained through training based on historical connection behavior feature data and historical system state data of different databases; and adjusting the connection retention condition of the connection pool of each database based on the prediction result. By adopting the method, the occupation of invalid connections on system resources can be remarkably reduced, and the execution efficiency of the database is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of distributed database, and particularly relates to a distributed data connection management method and device, computer equipment, computer readable storage medium and computer program product, and a database connection management method and device, computer equipment, computer readable storage medium and computer program product. BACKGROUND

[0002] In a distributed database, connection management between nodes generally uses a connection pool to implement. Taking a distributed database based on postgresql as an example, because postgresql itself is multi-process, and different users, different databases and different start parameters, postgresql uses different processes to maintain these connections, and the connection pool needs to maintain connections for different combinations of users and databases.

[0003] However, when the number of users and databases is large, the demand for maintaining connections in the connection pool will also be large, and in some cases, there will be a certain amount of idle connections occupying system resources, so that the process to be executed will not have enough resources, thereby causing data query errors and affecting the efficiency of database execution. SUMMARY

[0004] Therefore, it is necessary to provide a distributed data connection management method and device, computer equipment, computer readable storage medium and computer program product capable of improving the efficiency of database execution, and a database connection management method and device, computer equipment, computer readable storage medium and computer program product.

[0005] In a first aspect, the present application provides a distributed data connection management method, comprising:

[0006] receiving a database connection request sent by a client, wherein the database connection request carries a target user identifier, a target database identifier and a start parameter;

[0007] based on the target user identifier, the target database identifier and the start parameter, finding out available connections of the client;

[0008] allocating the found available connections to the client;

[0009] calling a trained connection use prediction model to predict the life cycle of the connections maintained in the connection pool of each database to obtain a prediction result, wherein the connection use prediction model is trained based on historical connection behavior feature data and historical system state data of different databases;

[0010] The connection retention status of each database's connection pool is adjusted based on the prediction results.

[0011] Secondly, this application also provides a database connection management method applied to a client, the method comprising:

[0012] Send a database connection request to the server, the database connection request carrying the target user identifier, the target database identifier, and startup parameters;

[0013] The server receives an available connection allocated by the server based on the target user identifier, the target database identifier, and the startup parameters. The available connection is obtained by the server through the steps described in the distributed database connection management method above.

[0014] The trained connections are invoked to use the prediction model to predict the activity of the available connections, and the activity prediction results are obtained.

[0015] Based on the activity prediction results, determine whether to retain or release the available connections.

[0016] Thirdly, this application also provides a distributed database connection management device, deployed on a server, comprising:

[0017] Deployed on a server-side platform, the server communicates with multiple clients. The device includes:

[0018] The data receiving module is used to receive database connection requests sent by the client, wherein the database connection request carries the target user identifier, the target database identifier, and startup parameters;

[0019] The data lookup module is used to find available connections for the client based on the target user identifier, the target database identifier, and the startup parameters.

[0020] The data allocation module is used to allocate the found available connections to the client;

[0021] The data prediction module is used to call the trained connection usage prediction model to predict the lifecycle of the connections maintained in the connection pools of each database and obtain the prediction results. The connection usage prediction model is trained based on historical connection behavior feature data and historical system state data of different databases.

[0022] The data adjustment module is used to adjust the connection retention status of the connection pools of each database based on the prediction results.

[0023] Fourthly, this application also provides a database connection management device, deployed on a client, the device comprising:

[0024] The request sending module is used to send a database connection request to the server. The database connection request carries the target user identifier, the target database identifier, and startup parameters.

[0025] The data receiving module is used to receive available connections allocated by the server based on the target user identifier, the target database identifier, and the startup parameters. The available connections are obtained by the server through the steps in the distributed database connection management method described above.

[0026] The activity prediction module is used to call the trained connection and use the prediction model to predict the activity of the available connection, and obtain the activity prediction result;

[0027] The connection processing module is used to determine whether to retain or release the available connection based on the activity prediction result.

[0028] Fifthly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described distributed database connection management method embodiment or the database connection management method embodiment.

[0029] Sixthly, this application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the above-described distributed database connection management method embodiments or database connection management method embodiments.

[0030] In a seventh aspect, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described distributed database connection management method embodiment or the database connection management method embodiment.

[0031] The aforementioned distributed database connection management method, apparatus, computer equipment, computer-readable storage medium, and computer program products, by uniformly managing connection resources on the server side and combining a connection usage prediction model trained based on historical connection behavior characteristics, achieve intelligent prediction and dynamic control of the lifecycle of connections in the connection pools of each database. On the one hand, the server can accurately match or reuse existing connections based on the target user identifier, target database identifier, and startup parameters in the client request, reducing connection redundancy caused by the explosion of user, database, and parameter combinations in traditional solutions. On the other hand, by predicting the future usage activity of each database connection through the model, the server can proactively release idle connections corresponding to long-term low-activity or non-critical business at precise times, significantly reducing the occupation of system resources by invalid connections and effectively improving database execution efficiency.

[0032] The aforementioned database connection management methods, devices, computer equipment, computer-readable storage media, and computer program products deploy a connection usage prediction model on the client side, trained based on historical connection metadata, timestamp information, connection usage behavior, and load status data. This enables the client to predict the active status of allocated available connections and intelligently decide whether to retain or release the connection. Compared to traditional client practices that immediately release connections after a transaction or rely on fixed timeout mechanisms, this reduces network overhead and latency jitter caused by frequent connection requests and reconstructions in high-frequency business scenarios, while preventing low-frequency or temporary connections from occupying local and server resources for extended periods. The entire solution achieves adaptive optimization of connection holding strategies on the client side without manual intervention or static configuration, effectively improving local connection reuse efficiency, reducing server connection pool pressure, and collaborating with the server to achieve efficient utilization of global resources and improved overall system response performance. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 This is a diagram illustrating the application environment of a distributed database connection management method and a database connection management method in one embodiment.

[0035] Figure 2 This is a flowchart illustrating a distributed database connection management method in one embodiment;

[0036] Figure 3 This is a flowchart illustrating the steps for finding available connections in one embodiment;

[0037] Figure 4 This is a flowchart illustrating the steps for adjusting the connection retention status of a connection pool in one embodiment;

[0038] Figure 5 This is a flowchart illustrating a distributed database connection management method in another embodiment;

[0039] Figure 6 This is a flowchart illustrating a database connection management method in one embodiment;

[0040] Figure 7 This is a flowchart illustrating the steps for predicting the activity of available connections in one embodiment;

[0041] Figure 8This is a structural block diagram of a distributed database connection management device in one embodiment;

[0042] Figure 9 This is a structural block diagram of a database connection management device in one embodiment;

[0043] Figure 10 This is a structural block diagram of the database connection management device in another embodiment;

[0044] Figure 11 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0046] The terms "comprising" and "having," and any variations thereof, as used in this application, are intended to cover non-exclusive inclusion. The term "multiple" as used in this application refers to two or more. The term "and / or" as used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0047] The distributed database connection management method for servers or the database connection management method for terminals provided in this application can be applied to, for example... Figure 1 In the application environment shown, multiple clients 102 communicate with the database server (hereinafter referred to as the server) 104 via a network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated onto the server 104 or placed on the cloud or other network servers. The server 104 is equipped with a connection usage prediction model trained based on historical connection behavior feature data and historical system state data from different databases. This connection usage prediction model is a multi-task output model that can be used to predict connection activity, next usage time, and resource release priority.

[0048] Specifically, client 102 can send a database connection request to server 102 carrying a target user identifier, a target database identifier, and startup parameters. Server 102 can receive the database connection request sent by client 102, which carries the target user identifier, target database identifier, and startup parameters. Based on the target user identifier, target database identifier, and startup parameters, available connections for the client can be found and allocated to the client. A trained connection usage prediction model can be invoked to predict the lifecycle of connections maintained in the connection pools of each database, obtaining prediction results. The connection usage prediction model is trained based on historical connection behavior feature data and historical system state data of different databases. Based on the prediction results, the connection retention status of the connection pools of each database can be adjusted. Client 102 receives the available connections allocated by server 104, invokes the trained connection usage prediction model to predict the activity level of the available connections, obtaining activity prediction results. Based on the activity prediction results, it can be determined whether to retain or release the available connections.

[0049] The client 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. The server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0050] In one exemplary embodiment, such as Figure 2 As shown, a distributed database connection management method is provided, which can be applied to... Figure 1 Taking server 104 as an example, the explanation includes the following steps 200 to 210. Wherein:

[0051] Step 202: Receive a database connection request sent by the client. The database connection request carries the target user identifier, the target database identifier, and startup parameters.

[0052] In this embodiment, the target user identifier refers to the database user identifier that sends the connection request, including but not limited to the user name and database address. The target database identifier refers to the identifier of the specific database to be connected to, including but not limited to the database name and database address. Startup parameters are components of the connection request and are data used to control the behavior of a single database session, including but not limited to the search path for a specified object, the maximum execution time of a single SQL statement, and the timezone of the current database session. In connection management scenarios (especially connection pooling or connection reuse), different startup parameters can lead to inconsistent connection behavior under the same user / database. For example, if connection A and connection B have different search paths, the same SQL statement may access different data tables.

[0053] Taking PostgreSQL as an example of a distributed database, the process can involve the server listening on a network port to receive database connection requests from clients, carrying the target user, target database identifier, and startup parameters. The server then parses the authentication and session initialization information, extracting the target user identifier, target database identifier, and startup parameters. Furthermore, the extracted information can undergo format and validity checks, such as verifying the user's existence and permissions. If the validity check passes, the process proceeds to the next step; otherwise, a verification failure message is pushed to the client.

[0054] Step 204: Based on the target user identifier, target database identifier, and startup parameters, find available connections for the client.

[0055] In this embodiment, an available connection refers to a backend connection process (or connection thread) that is currently idle and can be reused. For ease of explanation, all connections mentioned below refer to connection processes.

[0056] In practical applications, the server maintains connection pools for different database users. Each connection pool maintains information on all connection processes, including information on occupied and idle connections. For example, each connection record contains a snapshot of its current user, database, and startup parameters. Upon receiving a database connection request from a client, the server first attempts to precisely match an idle connection in the target user's connection pool that perfectly matches the target user's identifier, target database identifier, and startup parameters. If no match is found, the server iterates through the connections of other users and selects an allocatable idle connection as the available connection.

[0057] Step 206: Assign the found available connections to the client.

[0058] Specifically, the server can remove the found connection from the list of idle connections, update its status to "active", record the association between the connection and the client session (such as session ID, allocation timestamp), and establish a mapping between the network communication channel of the connection and the client's network connection, so that subsequent SQL requests from the client can be correctly forwarded to the database backend through the connection.

[0059] Step 208: Call the trained connection usage prediction model to predict the lifecycle of the connections maintained in the connection pools of each database and obtain the prediction results. The connection usage prediction model is trained based on historical connection behavior feature data and historical system state data of different databases.

[0060] In this embodiment, historical connection behavior feature data includes, but is not limited to, the connection metadata (user, database, startup parameters), timestamps (connection time / usage duration / release time), and usage behavior (query frequency, duration) of each database. Historical system state data refers to time-series records of observable indicators related to resource consumption, performance, and operating environment collected from the database system within a certain historical time period. The connection usage prediction model is a deep learning model pre-trained based on historical connection behavior features and historical system state features. This model is a multi-task output model that can be used to predict the usage activity and idle duration of connections in their future lifecycle. The prediction result refers to the quantitative indicators output by the connection usage prediction model that characterize the intensity of future connection demand for each database, including but not limited to activity level, expected access frequency, and release priority.

[0061] For example, the training process of the connection usage prediction model can be based on real user connection behavior data. Multidimensional logs are continuously collected through monitoring probes embedded in the connection pool or proxy layer, including connection metadata (user, database, startup parameters), timestamps (connection / usage / release time), usage behavior (query frequency, duration), and system status data (CPU, memory, global connection count), etc. Subsequently, the collected data can be processed by feature engineering using tree convolution to construct static identification features, time-series statistical features within a sliding window (such as the number of queries in the past hour, average interval, trend changes), and system load features. These features are then vectorized through normalization, embedding, and periodic encoding. The model adopts a hybrid architecture, combining a fully connected network to process static features, a TCN or lightweight Transformer to capture temporal dependencies, and introducing multi-task output heads to predict connection activity, next usage time, and resource release priority, respectively. During the training phase, samples are generated using a rolling time window. Positive and negative samples are defined according to actual usage behavior, and a weighted loss function is used to balance classification, regression, and ranking objectives. The quality of model iteration is ensured through daily offline training and testing. Finally, the trained model can be deployed on the online inference engine for real-time access by the first-level client local management module and the second-level server connection pool maintenance module.

[0062] In practice, the server can periodically collect connection usage behavior data and system status data from each database maintained in the connection pool. Feature data is extracted from this data to construct feature vectors. These feature vectors are then input into a trained connection usage prediction model to predict the activity status of connection processes maintained in each database's connection pool, yielding prediction results. Specifically, the prediction results include whether a connection will be used again within a certain timeframe from the current moment, or its expected idle time, used to determine whether it should be retained or released.

[0063] Step 210: Adjust the connection retention status of each database's connection pool based on the prediction results.

[0064] In practice, after obtaining the above prediction results, the server can dynamically adjust the resource strategy of the corresponding connection pool of each database based on the prediction results. This includes operations such as releasing idle connections, maintaining the minimum number of connections, or freezing newly created connections. This ensures that databases with high predicted activity maintain sufficient connection buffers, while databases with low activity reduce or even clear the reserved connections, thereby achieving dynamic optimization of connection resources.

[0065] The aforementioned distributed database connection management method achieves intelligent prediction and dynamic control of the lifecycle of connections in the connection pools of each database by uniformly managing connection resources on the server side and combining a connection usage prediction model trained based on historical connection behavior characteristics. On the one hand, the server can accurately match or reuse existing connections based on the target user identifier, target database identifier, and startup parameters in the client request, reducing connection redundancy caused by the explosion of user, database, and parameter combinations in traditional solutions. On the other hand, by predicting the future usage activity of each database connection through the model, the server can proactively release idle connections corresponding to long-term low-activity or non-critical business at precise times, significantly reducing the occupation of system resources by invalid connections and effectively improving database execution efficiency.

[0066] In one exemplary embodiment, such as Figure 3 As shown, step 204 includes steps 224 to 264, wherein:

[0067] Step 224: Search the connection hash table of the target user for an available connection that matches the target user identifier, the target database identifier, and the startup parameters. The target user is the user corresponding to the target user identifier.

[0068] Step 244: If no matching available connection is found, look up reusable connections from the connection hash tables of users other than the target user.

[0069] Step 264: Reset the reusable connection, and determine the reset reusable connection as the available connection for the client. The reset reusable connection is adapted to the target user identifier, target database identifier and startup parameters.

[0070] The connection hash table for a target user is an index structure maintained by the server for each database user. It uses the connection context (such as database identifier or startup parameter hash value) as the key and a list of idle connections as the value. This structure is used to quickly retrieve reusable connections for that user. Reusable connections refer to idle connections belonging to other users that can be used to serve new users.

[0071] In practice, the server first locates the connection hash table of the target user based on the target user identifier in the database connection request. Then, it combines the target database identifier with startup parameters to generate a composite key (e.g., calculating the hash value after sorting the startup parameters). Using this key, it searches the target user's connection hash table for a matching idle connection. If an idle connection is found, it selects one as the available connection. If no available connection is found in the target user's connection hash table, it is determined that no matching available connection was found. Next, the server iterates through the connection hash tables of all other users except the target user. For each user's idle connection, it checks whether it meets the reuse prerequisites (e.g., not bound to a non-migratable temporary object, not in a transaction, etc.). Once a matching idle connection is found, the iteration stops, and that connection is selected as a reusable connection. This selection process can use a preset strategy (e.g., least recently used, random selection, or sorted by resource cost) to select the optimal candidate, ensuring reuse efficiency and security.

[0072] After selecting reusable connections, the server can perform reset operations on the selected reusable connections in sequence. The reset operation may include clearing the original session state and reinitializing the connection context through database native protocol commands or internal extended instructions, including configuring user information and startup parameters.

[0073] In other embodiments, resetting a reusable connection includes: switching the user corresponding to the reusable connection to the target user, and modifying the startup parameters of the process corresponding to the reusable connection.

[0074] Specifically, it can be done as follows: First, switch the user identity of the current session using the native PostgreSQL command `set role`, and switch the user of the connection to the target user; second, send a series of startup parameter modification commands to the connection to make its startup parameters match the startup parameters in the request, verify whether the connection has correctly pointed to the target database, and after completing the above reset operation, mark the connection as "assigned", remove it from the original user hash table, associate it with the current client session, and finally return it as an available connection.

[0075] In this embodiment, a hierarchical lookup and dynamic reset mechanism is constructed to achieve efficient connection reuse across users and parameters. The server first attempts to accurately match the connection of the target user to improve reuse efficiency; when no match is found, it actively searches for reusable resources from the global connection pool and ensures context consistency through a standardized reset process. This mechanism significantly reduces connection redundancy caused by a sudden increase in the combination of users, databases, and startup parameters, and avoids a large number of idle connections occupying system resources for a long time. At the same time, since the behavior of reusing connections is completely equivalent to creating new connections, it not only ensures the correctness of business operations but also reduces the overhead of connection creation and destruction, improving system throughput and response stability, and is particularly suitable for multi-tenant, high-concurrency distributed database scenarios.

[0076] like Figure 4 As shown, in some exemplary embodiments, step 210 includes steps 212 to 214, wherein:

[0077] Step 212: Based on the prediction results, identify databases whose activity level is below a preset activity level threshold, and release the idle connections maintained in the connection pool of the identified databases.

[0078] Step 214: Based on the prediction results, identify and release connections that have exceeded their lifecycle.

[0079] The activity threshold is a pre-configured numerical threshold used to determine whether the database is in a "low-activity" state (e.g., activity < 0.2). Lifetime is the maximum time a model expects a single connection to be safely retained from the current moment, or its "effective lifetime."

[0080] In practice, the server can iterate through all databases and their corresponding activity values ​​based on the activity prediction results of each database. Each activity value is compared with a preset activity threshold, and all databases below the threshold are selected. For each selected database, the server accesses its corresponding connection list in the connection pool, iterates through all idle connections, performs connection termination operations in sequence, and removes the relevant records from the connection pool index. At the same time, the minimum number of reserved connections for the database can be updated to zero or a lower priority configuration to prevent new connections from being created unnecessarily.

[0081] In addition, when performing periodic connection maintenance tasks, the server can also read the "last used timestamp" and the "predicted lifespan" assigned to it by the model (e.g., "to be retained for a maximum of 30 minutes") from the metadata of each idle connection in the connection pool, calculate the difference between the current time and the last used time, and mark the connection as "overdue" if the difference is greater than the predicted lifespan. Subsequently, the server collects all overdue connections in batches, performs release operations, and completely removes these connections from all hash indexes to ensure that system resources are released in a timely manner.

[0082] In this embodiment, by combining a coarse-grained release strategy at the database level and a fine-grained release strategy at the connection individual level, a dual "macro + micro" control mechanism is formed to jointly improve the level of precision in connection management.

[0083] In some exemplary embodiments, step 210 further includes:

[0084] Step 216: When the system resource load meets the preset release trigger conditions, determine the release priority of each database based on the prediction results, and release the connections maintained in the connection pool of each database according to the release priority of each database.

[0085] Release priority is a numerical ranking metric assigned to each database based on the prediction results. The higher the priority (or the lower the value, depending on the definition), the more likely the connection to that database should be released. The preset release trigger condition refers to one or more pre-configured judgment rules used to determine whether the system has entered a state of resource stress, such as "CPU utilization exceeds 80% for 1 minute" or "total number of connections reaches 90% of the limit".

[0086] In practical applications, in addition to performing the maintenance operations mentioned in the above embodiments, the server can continuously monitor system resource load indicators during operation and determine in real time whether they meet the preset release trigger conditions. When the release trigger conditions are met, the server calls the deployed connection prediction model to obtain the current prediction results for each database. Subsequently, it sorts all databases according to the prediction results and generates a connection release priority sequence. For example, the database with the lowest predicted activity or the longest expected idle time is assigned the highest release priority. Then, the server accesses the connection pool of the corresponding database in descending order of priority, traverses the idle connections, and performs connection termination operations, including closing the backend process, releasing file descriptors and memory resources, and synchronously updating the connection pool index structure. It can be understood that this release process can continue until the system resource load falls below the release trigger conditions, or all releasable connections have been processed.

[0087] In this embodiment, not only are low-activity connections identified from the database perspective, but also the lifecycle of individual connections is judged to have expired. Combined with the system load status, hierarchical control is carried out, so that resource release decisions have both macro-level coordination and micro-level precision.

[0088] like Figure 5 As shown, in some exemplary embodiments, the method further includes:

[0089] Step 220: For each connection maintained in the database connection pool, collect connection event data and system status data throughout the connection's lifecycle. Based on the collected connection event data and system status data, update the connection usage prediction model.

[0090] Connection event data consists of structured logs generated during the connection's lifecycle that are directly related to connection behavior. This includes connection creation time, start and end timestamps for each use, number of queries, single execution duration, transaction commit / rollback status, and release time. System status data refers to overall system performance metrics at the time of connection behavior, such as CPU utilization, memory usage, total active connections, I / O load, and network throughput.

[0091] In practice, the server can monitor each connection instance. Whenever a critical event occurs in the connection instance (such as allocation, query start, query end, return, or destruction), the server automatically records the event type, timestamp, and related metadata (such as user identifier, database identifier, and startup parameter snapshot). At the same time, the server synchronously collects the current system status data at a fixed frequency (such as per second) or through event triggering. Through a time window alignment mechanism, the system status data is bound to the connection event data to form a complete behavioral trajectory organized by connection ID, which is used for subsequent model training and updates.

[0092] In practice, the server can periodically (e.g., at midnight every day or during periods of low resource availability) initiate a model update task. Specifically, it first reads recently accumulated connection event data and system status data, and constructs training samples according to preset rules. Each sample contains features within a historical window (e.g., query frequency in the past 6 hours, average idle interval, average system load) and corresponding labels (e.g., "whether it has been used again within 24 hours"). Subsequently, the samples are input into the connection usage prediction model, and new model parameters are generated using offline batch training or online incremental learning methods to update the model. After the new model is validated, it replaces the previous connection usage prediction model, achieving seamless hot updates.

[0093] In this embodiment, by collecting connection event data and system status data and then updating the model, a closed-loop feedback mechanism is formed, enabling the continuous self-evolution of the connection management strategy. On the one hand, the refined collection of data throughout the entire lifecycle ensures that the model training has a high-fidelity, multi-dimensional input foundation; on the other hand, the regular updates of the model enable the predictive capability to dynamically adapt to changes in business access patterns (such as new tenants, periodic batch processing, sudden traffic surges, etc.).

[0094] like Figure 6 As shown, in another embodiment, this application also provides a database connection management method applied to a client, the method including steps 102 to 108, wherein:

[0095] Step 102: Send a database connection request to the server. The database connection request carries the target user identifier, the target database identifier, and startup parameters.

[0096] Step 104: Receive available connections allocated by the server based on the target user identifier, target database identifier, and startup parameters.

[0097] Step 106: Use the trained connection prediction model to predict the activity of available connections and obtain the activity prediction results.

[0098] Step 108: Based on the activity prediction results, determine whether to retain or release available connections.

[0099] In specific implementation, the client may first send a database connection request to the server, explicitly carrying the target user identifier, the target database identifier, and a set of startup parameters. Subsequently, the receiving server, based on the above three pieces of information, uses the method described in the distributed database management embodiment to find an available connection. The server then allocates the available connection to the client, establishing a connection between them. After obtaining the connection, the client may, after executing the current query, invoke a trained connection prediction model to assess the likelihood of the current connection being reused in the near future and output an activity prediction result. Then, based on this prediction result, the client decides whether to continue holding the connection or release it, returning the connection to the connection pool. Specifically, in other embodiments, the client may compare the predicted activity level with a preset activity threshold. If the predicted activity level is greater than or equal to the preset activity threshold, it is determined to be highly active, and the connection is held for subsequent reuse. If the predicted activity level is lower than the preset activity threshold, it is determined to be low active, and the connection is actively released and returned to the server's connection pool.

[0100] The aforementioned database connection management method deploys a connection usage prediction model on the client side, trained based on historical connection metadata, timestamps, connection usage behavior, and load status data. This allows the client to predict the active status of allocated available connections and intelligently decide whether to retain or release them. Compared to traditional client-side practices that immediately release connections after a transaction or rely on fixed timeout mechanisms, this reduces network overhead and latency jitter caused by frequent connection requests and reconstructions in high-frequency business scenarios. It also prevents low-frequency or temporary connections from consuming local and server resources for extended periods. The entire solution achieves adaptive optimization of connection holding strategies on the client side without manual intervention or static configuration, effectively improving local connection reuse efficiency, reducing server connection pool pressure, and collaborating with the server to achieve efficient utilization of global resources and improved overall system response performance.

[0101] likeFigure 7 As shown, in an exemplary embodiment, step 106 includes:

[0102] Step 126: Collect available connection usage behavior data and load status data for the target database corresponding to the target database identifier.

[0103] Step 146: Extract features from the connection usage behavior data and load status data to obtain feature vector data.

[0104] Step 166: Input the feature vector data into the trained connection using the prediction model. The prediction model predicts the activity of available connections, and the activity prediction result is obtained.

[0105] In practical applications, during the period when a client holds an available connection (the entire lifecycle), it can continuously record the connection's operational behavior data to the target database (i.e., connection usage behavior data). For example, whenever an SQL query or transaction is executed, the query count of the connection within the current session period is updated. At the same time, the time interval from the initiation to the end of each query or transaction is recorded as the duration of a single use. In addition, the client can periodically sample local system resource indicators (such as CPU utilization and memory usage) or receive global load information (such as connection pool pressure and response latency) from the server as load status data.

[0106] Next, the client performs feature engineering on the collected connection usage behavior data. For example, it converts query frequency into request rate per unit time (e.g., average number of queries per minute over the past 5 minutes); it aggregates single usage duration into statistical features, such as the average, maximum, or trend of the most recent N uses; and it normalizes or smooths the load status data using a sliding window. Then, these processed values ​​are combined with the connection's static metadata (e.g., target user identifier, target database identifier) ​​and concatenated in a preset order into a fixed-dimensional numerical array, i.e., feature vector data. This feature vector data is then input into a trained connection usage prediction model to perform inference calculations. The model outputs a value between 0 and 1 based on the input features, serving as a probability estimate of the connection's re-use within a preset time window, i.e., the activity prediction result. This result is then used in subsequent decision-making logic regarding whether to retain the connection. Furthermore, the client can also feed back the connection usage behavior data and load status data collected during the connection holding period to the server, allowing the server to update the connection usage prediction model online.

[0107] In this embodiment, the client achieves real-time and accurate perception of connection activity status through a closed loop from data collection to feature extraction and then to activity prediction.

[0108] In another embodiment, this application provides a distributed database multi-level connection management system, which includes: multiple clients and a server, wherein:

[0109] The client is used to send database connection requests to the server. The database connection request carries the target user identifier, the target database identifier, and startup parameters. The client receives the available connections allocated by the server, calls the trained connection to use the prediction model to predict the activity of the available connections, obtains the activity prediction results, and determines whether to retain or release the available connections based on the activity prediction results.

[0110] The server receives database connection requests from clients. Based on the target user identifier, target database identifier, and startup parameters, it uses the steps described in the distributed database connection management method embodiment above to find available connections for the client, allocates available connections to the client, calls a trained connection usage prediction model to predict the lifecycle of connections maintained in the connection pools of each database, obtains prediction results, and adjusts the connection retention status of the connection pools of each database based on the prediction results. The connection usage prediction model is trained based on historical connection behavior feature data and historical system state data of different databases.

[0111] It is understood that the specific connection management processes for both the client and server sides can be found in the descriptions of the above embodiments, and will not be repeated here. The client, acting as the primary connection manager, precisely controls the timing of releasing connections back to the connection pool based on the prediction results of the connection usage prediction model. Simultaneously, it collects information such as the frequency of user queries and the duration of each query, feeding this information back to the connection usage prediction model for retraining, thus making the model's predictions more accurate. If the process remains active, the connection will be held as a long-lived connection, reducing the overhead of connection release and acquisition.

[0112] The server acts as a secondary connection manager, treating all database connection pools as a single, unified connection pool and maintaining the minimum number of connections required for this pool. Based on connection usage predictions from a model, it manages the connection pools for different databases. If a database remains unused for an extended period, or under heavy system load, the online model intelligently identifies this and calculates the release priority for connections in each database. This priority-based approach allows for precise control over connections, minimizing resource consumption.

[0113] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0114] Based on the same inventive concept, embodiments of this application also provide a distributed database connection management device for implementing the distributed database connection management method described above, and a database connection management device for implementing the database connection management method described above. The solution provided by this device is similar to the solution described in the above method. Therefore, the specific limitations in the one or more distributed database connection management device embodiments provided below can be found in the limitations of the distributed database connection management method described above, and will not be repeated here.

[0115] In one exemplary embodiment, such as Figure 8 As shown, a distributed database connection management device 800 is provided, including: a data receiving module 810, a data searching module 820, a data distribution module 830, a data prediction module 840, and a data adjustment module 850, wherein:

[0116] The data receiving module 810 is used to receive database connection requests sent by the client. The database connection request carries the target user identifier, the target database identifier, and startup parameters.

[0117] The data lookup module 820 is used to find available connections for the client based on the target user identifier, the target database identifier, and the startup parameters.

[0118] The data allocation module 830 is used to allocate the found available connections to the client.

[0119] The data prediction module 840 is used to call the trained connection usage prediction model to predict the lifecycle of the connections maintained in the connection pools of each database and obtain the prediction results. The connection usage prediction model is trained based on historical connection behavior feature data and historical system state data of different databases.

[0120] The data adjustment module 850 is used to adjust the connection retention status of each database's connection pool based on the prediction results.

[0121] In some exemplary embodiments, the data lookup module 820 is further configured to look up an available connection that matches the target user identifier, the target database identifier, and the startup parameters in the connection hash table of the target user, where the target user is the user corresponding to the target user identifier. If no matching available connection is found, a reusable connection is looked up from the connection hash table of users other than the target user, the reusable connection is reset, and the reset reusable connection is determined as an available connection for the client. The reset reusable connection is adapted to the target user identifier, the target database identifier, and the startup parameters.

[0122] In some exemplary embodiments, the data lookup module 820 is further configured to switch the user corresponding to the reusable connection to the target user and modify the startup parameters of the process corresponding to the reusable connection.

[0123] In some exemplary embodiments, the data adjustment module 850 is configured to perform at least one of the following:

[0124] Based on the prediction results, databases with activity levels below a preset activity threshold are identified, and idle connections maintained in the connection pool of the identified databases are released.

[0125] Based on the prediction results, identify and release connections that have exceeded their lifecycle.

[0126] In some exemplary embodiments, the data adjustment module 850 is further configured to determine the release priority of each database based on the prediction results when the system resource load meets the preset release trigger conditions, and release the connections maintained in the connection pool of each database according to the release priority of each database.

[0127] like Figure 9 As shown, in some exemplary embodiments, the apparatus further includes a model update module 860, which is used to collect connection event data and system status data of each connection maintained in the connection pool of the database throughout the connection's lifecycle, and update the connection's prediction model based on the collected connection event data and system status data.

[0128] In one exemplary embodiment, such as Figure 10As shown, a database connection management device 900 is provided, deployed on a client, including: a request sending module 910, a data receiving module 920, an activity prediction module 930, and a connection processing module 940, wherein:

[0129] The request sending module 910 is used to send a database connection request to the server. The database connection request carries the target user identifier, the target database identifier, and startup parameters.

[0130] The data receiving module 920 is used to receive available connections allocated by the server based on the target user identifier, the target database identifier, and the startup parameters. The available connections are found by the server through the steps in any of the above-mentioned distributed database connection management method embodiments.

[0131] The activity prediction module 930 is used to call the trained connection and use the prediction model to predict the activity of available connections, and obtain the activity prediction result.

[0132] The connection processing module 940 is used to determine whether to retain or release available connections based on the activity prediction results.

[0133] In an exemplary embodiment, the activity prediction module 930 is further configured to collect connection usage behavior data and load status data of available connections corresponding to the target database identifier, extract features from the connection usage behavior data and load status data to obtain feature vector data, input the feature vector data into the trained connection usage prediction model, and the prediction model predicts the activity of available connections to obtain the activity prediction result.

[0134] In an exemplary embodiment, the connection processing module 940 is further configured to retain available connections if the activity prediction result indicates that the available connections are highly active, and to release available connections if the activity prediction result indicates that the available connections are low active.

[0135] In an exemplary embodiment, the apparatus further includes a data update module 950, which is used to collect connection usage behavior data and load status data of available connections to a target database throughout the entire lifecycle of available connections, and feed the connection usage behavior data and load status data back to the server to update the connection usage prediction model.

[0136] The modules in the aforementioned distributed database connection management and database connection management device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0137] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 11 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores connection usage data, load status data, and prediction results. The I / O interfaces are used for information exchange between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a distributed database connection management method and a database connection management method.

[0138] Those skilled in the art will understand that Figure 11 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0139] In one exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of any of the above embodiments of the distributed database connection management method or the database connection management method.

[0140] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of any of the above embodiments of the distributed database connection management method or the database connection management method.

[0141] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of any of the above embodiments of the distributed database connection management method or the database connection management method.

[0142] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0143] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0144] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0145] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A distributed database connection management method, characterized in that, Applied to the server side, the server communicates with multiple clients, and the method includes: Receive a database connection request sent by the client, the database connection request carrying the target user identifier, the target database identifier and startup parameters; Based on the target user identifier, the target database identifier, and the startup parameters, the available connections of the client are identified; The identified available connections are assigned to the client. The trained connection is invoked to use a prediction model to predict the lifecycle of the connection maintained in the connection pool of each database, and the prediction result is obtained. The connection is trained using the prediction model based on historical connection behavior feature data and historical system state data of different databases. The connection retention status of each database's connection pool is adjusted based on the prediction results.

2. The method according to claim 1, characterized in that, Based on the target user identifier, the target database identifier, and the startup parameters, the available connections for the client are determined, including: The system searches the connection hash table of the target user for an available connection that matches the target user identifier, the target database identifier, and the startup parameters. The target user is the user corresponding to the target user identifier. If no matching available connection is found, a reusable connection is retrieved from the connection hash table of users other than the target user. The reusable connection is reset, and the reset reusable connection is determined as the available connection of the client. The reset reusable connection is adapted to the target user identifier, the target database identifier, and the startup parameters.

3. The method according to claim 2, characterized in that, The reset operation for the reusable connection includes: Switch the user corresponding to the reusable connection to the target user, and modify the startup parameters of the process corresponding to the reusable connection.

4. The method according to claim 1, characterized in that, The adjustment of connection retention status of each database's connection pool based on the prediction results includes at least one of the following methods: Based on the prediction results, databases with activity levels below a preset activity threshold are identified, and idle connections maintained in the connection pool of the identified databases are released. Based on the prediction results, connections that have exceeded their lifecycle are identified and released.

5. The method according to claim 1, characterized in that, The adjustment of connection retention status of each database's connection pool based on the prediction results includes: When the system resource load meets the preset release triggering conditions, the release priority of each database is determined based on the prediction results, and the connections maintained in the connection pool of each database are released according to the release priority of each database.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: For each connection maintained in the database connection pool, collect connection event data and system status data throughout the entire lifecycle of that connection; Based on the collected connection event data and system status data, the connection prediction model is updated.

7. A database connection management method, characterized in that, Applied to a client, the method includes: Send a database connection request to the server, the database connection request carrying the target user identifier, the target database identifier, and startup parameters; The server receives an available connection allocated by the server based on the target user identifier, the target database identifier, and the startup parameters. The available connection is obtained by the server through the steps in the distributed database connection management method as described in any one of claims 1 to 6. The trained connection is invoked to use a prediction model to predict the activity of the available connection, and the activity prediction result is obtained. The connection is trained using the prediction model based on historical connection behavior feature data and historical system state data from different databases. Based on the activity prediction results, determine whether to retain or release the available connections.

8. The database connection management method according to claim 7, characterized in that, The process of calling the trained connection uses a prediction model to predict the activity of the available connection, obtaining the activity prediction result, including: Collect connection usage behavior data and load status data of the available connections for the target database corresponding to the target database identifier; Feature vector data is obtained by extracting features from the connection usage behavior data and the load status data. The feature vector data is input into the trained connection using a prediction model, which predicts the activity of the available connections, thus obtaining the activity prediction result.

9. The database connection management method according to claim 7, characterized in that, The step of determining whether to retain or release the available connection based on the activity prediction result includes: If the activity prediction result indicates that the available connection is highly active, the available connection will continue to be retained. If the activity prediction result indicates that the available connection has low activity, the available connection is released.

10. The database connection management method according to any one of claims 7 to 9, characterized in that, The method further includes: Throughout the entire lifecycle of the available connection, collect connection usage behavior data and load status data of the available connection for the target database; The connection usage behavior data and the load status data are fed back to the server to update the connection usage prediction model.

11. A distributed database connection management device, characterized in that, Deployed on a server-side platform, the server communicates with multiple clients. The device includes: The data receiving module is used to receive database connection requests sent by the client, wherein the database connection request carries the target user identifier, the target database identifier, and startup parameters; The data lookup module is used to find available connections for the client based on the target user identifier, the target database identifier, and the startup parameters; The data allocation module is used to allocate the found available connections to the client; The data prediction module is used to call the trained connection usage prediction model to predict the lifecycle of the connections maintained in the connection pools of each database and obtain the prediction results. The connection usage prediction model is trained based on historical connection behavior feature data and historical system state data of different databases. The data adjustment module is used to adjust the connection retention status of the connection pools of each database based on the prediction results.

12. A database connection management device, characterized in that, Deployed on the client side, the device includes: The request sending module is used to send a database connection request to the server. The database connection request carries the target user identifier, the target database identifier, and startup parameters. The data receiving module is used to receive an available connection allocated by the server based on the target user identifier, the target database identifier, and the startup parameters, wherein the available connection is obtained by the server through the steps in the distributed database connection management method as described in any one of claims 1 to 6; The activity prediction module is used to call the trained connection and use the prediction model to predict the activity of the available connection, and obtain the activity prediction result; The connection processing module is used to determine whether to retain or release the available connection based on the activity prediction result.

13. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6 or 7 to 10.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6 or 7 to 10.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6 or 7 to 10.

Images