Database keep-alive method, device and equipment, readable storage medium and program product
By dynamically adjusting the keep-alive strategy based on the execution rate and request rate of users and data patterns when database resources are in a bottleneck state, the business interruption problem caused by database resource bottlenecks is solved, and the smoothness of business is improved.
Patent Information
- Application Number
- CN202511762361.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-27
- Publication Date
- 2026-02-27
AI Technical Summary
Existing databases are prone to lag and OOM (Out of Memory) issues when under resource bottleneck conditions, leading to business interruptions. Furthermore, existing keep-alive strategies can disrupt business processes or even cause them to be interrupted.
By identifying target users and data patterns, calculating execution rate and request rate, determining keep-alive execution strategies based on keep-alive levels, and dynamically adjusting resource usage to prioritize important requests and avoid resource exhaustion.
It improved the smoothness of business operations under resource bottleneck conditions, ensured the smooth operation of important business, and reduced resource waste and the risk of interruption.
Smart Images
Figure CN121579446A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of database technology, and in particular to a database keep-alive method, apparatus, device, readable storage medium, and program product. Background Technology
[0002] A database is a system used to store and manage data. The physical resources a database can use are limited, especially in public cloud database products, which are deployed based on virtualization technology and have fixed instance specifications. If improper business usage exceeds the allocated resources, issues such as lag and unresponsiveness can occur, and in severe cases, Out Of Memory (OOM) errors and restarts can happen. This phenomenon leads to long business interruptions and creates difficulties for DBAs (Database Administrators), with a wide-ranging impact.
[0003] However, current database keep-alive strategies require business rate limiting or repeated instance switching, which leads to less smooth business processes and even business interruptions. Summary of the Invention
[0004] Therefore, it is necessary to provide a database keep-alive method, device, equipment, readable storage medium, and program product that can improve business smoothness in response to the above-mentioned technical problems.
[0005] Firstly, this application provides a database keep-alive method, including:
[0006] If the target database accessed by the current access request is in a resource bottleneck state, determine the target access user and target data pattern associated with the current access request. The target data pattern is used to manage the data in the target database.
[0007] The execution rate of the current access request is determined based on the user information of the target accessing user and the category information of the target data pattern.
[0008] The request rate of the current access request is determined based on the historical request volume for the target data pattern.
[0009] Based on the execution rate, the request rate, and the keep-alive level corresponding to the resource bottleneck state, determine the keep-alive execution strategy for the current access request.
[0010] In one embodiment, determining the execution rate of the current access request based on the user information of the target accessing user and the category information of the target data pattern includes:
[0011] Determine the priority of users who match the user information;
[0012] Determine the library priority that matches the category information;
[0013] The execution rate of the current access request is determined based on the first priority parameter corresponding to the user priority and the second priority parameter corresponding to the library priority.
[0014] In one embodiment, determining the request rate of the current access request based on the historical request volume for the target data pattern includes:
[0015] Determine the number of requests executed for the target data pattern within a historical time window;
[0016] Based on the historical request volume for the target data pattern, the ratio of the request execution volume to the historical request volume is used as the request rate of the current access request.
[0017] In one embodiment, determining the keep-alive execution strategy for the current access request based on the execution rate, the request rate, and the keep-alive level corresponding to the resource bottleneck state includes:
[0018] If the keep-alive level is the first level and the request rate is less than the execution rate, the keep-alive execution strategy for the current access request is determined to be to execute the current access request.
[0019] If the keep-alive level is the second level, the execution rate is greater than the preset first execution rate threshold, and the request rate is less than the execution rate, then the keep-alive execution strategy for the current access request is determined to be to execute the current access request.
[0020] If the keep-alive level is level three and the execution rate is less than a preset second execution rate threshold, an active access request with an execution rate less than the execution rate of the current access request is identified, and the keep-alive execution strategy for the current access request is determined to be to terminate the active access request.
[0021] The resource bottleneck status corresponding to the first level, the second level, and the third level increases sequentially.
[0022] In one embodiment, before determining the target user and target data pattern associated with the current access request when the target database accessed by the current access request is in a resource bottleneck state, the method further includes:
[0023] When the target database receives the current access request, obtain the current resource usage information of the target database;
[0024] If the resource occupancy value represented by the current resource occupancy information is greater than the resource occupancy threshold corresponding to the first level, the target database is determined to be in a resource bottleneck state.
[0025] In one embodiment, after determining the keep-alive execution strategy for the current access request based on the execution rate, the request rate of the current access request, and the keep-alive level corresponding to the resource bottleneck state, the method further includes:
[0026] If the current access request is determined to be executed, record the resource consumption information of the current access request;
[0027] Based on the resource consumption information, the resource bottleneck status of the target database is updated.
[0028] Secondly, this application also provides a database keep-alive device, comprising:
[0029] The user mode determination module is used to determine the target access user and target data mode associated with the current access request when the target database accessed by the current access request is in a resource bottleneck state. The target data mode is used to manage the data in the target database.
[0030] The execution rate determination module is used to determine the execution rate of the current access request based on the user information of the target access user and the category information of the target data pattern;
[0031] The request rate determination module is used to determine the request rate of the current access request based on the historical request volume for the target data pattern.
[0032] The execution strategy determination module is used to determine the keep-alive execution strategy for the current access request based on the execution rate, the request rate, and the keep-alive level corresponding to the resource bottleneck state.
[0033] Thirdly, 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 perform the following steps:
[0034] If the target database accessed by the current access request is in a resource bottleneck state, determine the target access user and target data pattern associated with the current access request. The target data pattern is used to manage the data in the target database.
[0035] The execution rate of the current access request is determined based on the user information of the target accessing user and the category information of the target data pattern.
[0036] The request rate of the current access request is determined based on the historical request volume for the target data pattern.
[0037] Based on the execution rate, the request rate, and the keep-alive level corresponding to the resource bottleneck state, determine the keep-alive execution strategy for the current access request.
[0038] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:
[0039] If the target database accessed by the current access request is in a resource bottleneck state, determine the target access user and target data pattern associated with the current access request. The target data pattern is used to manage the data in the target database.
[0040] The execution rate of the current access request is determined based on the user information of the target accessing user and the category information of the target data pattern.
[0041] The request rate of the current access request is determined based on the historical request volume for the target data pattern.
[0042] Based on the execution rate, the request rate, and the keep-alive level corresponding to the resource bottleneck state, determine the keep-alive execution strategy for the current access request.
[0043] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:
[0044] If the target database accessed by the current access request is in a resource bottleneck state, determine the target access user and target data pattern associated with the current access request. The target data pattern is used to manage the data in the target database.
[0045] The execution rate of the current access request is determined based on the user information of the target accessing user and the category information of the target data pattern.
[0046] The request rate of the current access request is determined based on the historical request volume for the target data pattern.
[0047] Based on the execution rate, the request rate, and the keep-alive level corresponding to the resource bottleneck state, determine the keep-alive execution strategy for the current access request.
[0048] The aforementioned database keep-alive method, apparatus, device, readable storage medium, and program product, when the target database accessed by the current access request is in a resource bottleneck state, determine the target access user and target data pattern associated with the current access request. The target data pattern is used to manage data in the target database. Based on the user information of the target access user and the category information of the target data pattern, the execution rate of the current access request is determined. Based on the historical request volume for the target data pattern, the request rate of the current access request is determined. Based on the execution rate, request rate, and keep-alive level corresponding to the resource bottleneck state, the keep-alive execution strategy for the current access request is determined. By monitoring the resource occupancy status of the target database, the keep-alive process is initiated when the resource bottleneck state is reached. The execution rate can represent the ratio of current access request execution, the request rate can represent the request frequency for the target data pattern, and different keep-alive levels can represent the bias of the keep-alive execution strategy under different resource bottleneck states, thereby obtaining a targeted keep-alive execution strategy, adapting to different business usage scenarios, and improving business smoothness under resource bottleneck states. Attached Figure Description
[0049] 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.
[0050] Figure 1 This is a diagram illustrating the application environment of a database keep-alive method in one embodiment.
[0051] Figure 2 This is a flowchart illustrating a database keep-alive method in one embodiment;
[0052] Figure 3 This is a flowchart illustrating the process of determining the keep-alive execution strategy for the current access request based on the execution rate, request rate, and keep-alive level corresponding to the resource bottleneck state in one embodiment.
[0053] Figure 4 This is a schematic diagram illustrating the process of updating the resource bottleneck status of a target database in one embodiment.
[0054] Figure 5 This is a flowchart illustrating the database keep-alive method in another embodiment;
[0055] Figure 6 This is a structural block diagram of a database keep-alive device in one embodiment;
[0056] Figure 7This is an internal structural diagram of a computer device in one embodiment;
[0057] Figure 8 This is a diagram of the internal structure of a computer device in another embodiment. Detailed Implementation
[0058] 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.
[0059] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.
[0060] To address the issue of limited database resources, relevant technologies consider adding database keep-alive strategies to middleware products or access proxies, such as rate limiting for business operations or switching over when an instance fails. However, rate limiting is often difficult to be precise; setting too low a threshold wastes user resources, while setting too high a value can overwhelm underlying database nodes. Switching to a new instance after an instance fails is also a stopgap measure, as the switched instance easily encounters the same problem, leading to a poor user experience due to repeated switching. Furthermore, the middleware layer struggles to obtain accurate real-time data on database node resource consumption and thus finds it difficult to make appropriate policy decisions.
[0061] The database keep-alive method provided in this application embodiment can be applied to, for example, Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or placed on a cloud or other network server. When terminal 102 initiates a current access request, if the target database accessed by the current access request is in a resource bottleneck state, server 104 determines the target user and target data pattern associated with the current access request. The target data pattern is used to manage the data in the target database. Based on the user information of the target user and the category information of the target data pattern, the execution rate of the current access request is determined. Based on the historical request volume for the target data pattern, the request rate of the current access request is determined. Based on the execution rate, request rate, and the keep-alive level corresponding to the resource bottleneck state, the keep-alive execution strategy for the current access request is determined. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, and tablets. 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.
[0062] In one exemplary embodiment, such as Figure 2 As shown, a database keep-alive method is provided, which can be applied to... Figure 1 The following steps, from step 202 to step 206, will be used as an example to illustrate the process.
[0063] Step 202: If the target database accessed by the current access request is in a resource bottleneck state, determine the target access user and target data pattern associated with the current access request. The target data pattern is used to manage the data in the target database.
[0064] The target database refers to the database accessed by the current access request. Resource bottleneck status refers to the critical state where the target database's resource consumption is approaching the total available resources; this can be used as a criterion for determining whether to enter the target database's keep-alive process. The current access request refers to a request sent from outside to the target database at the current moment to query, modify, or perform other operations on the data stored in the target database. The target access user refers to the user who initiated the current access request. One or more data schemas can be defined in the target database to manage different data organizational structures. These structures can be divided according to their relationships; for example, the target data schema of the target database may include system databases, configuration databases, business databases, historical databases, etc. The target data schema is the data schema pointed to by the current access request. It can be understood that each data schema may include multiple data tables and the relationships between different data tables. Each data table contains multiple predefined fields for storing data of the corresponding type.
[0065] For example, the current access request is obtained, and the user identifier and data pattern identifier are extracted from the current access request. The target access user corresponding to the user identifier and the target data pattern corresponding to the data pattern identifier are determined. Access to the target database can be subject to certain restrictions. For example, the user needs to log in to the relevant account to obtain access rights before initiating an access request. The relevant information of the target access user and the target data pattern can then be recorded in the current access request.
[0066] Step 204: Determine the execution rate of the current access request based on the user information of the target accessing user and the category information of the target data pattern.
[0067] The user information for the target user can include predefined user-related information from the target database, as well as information recording the user's current state. For example, the target database can predefine access permissions for different user categories, with different access permissions allowing access to different data patterns. Another example is that the user information can record the user account's usage and activity status.
[0068] The category information of the target data pattern can record its organizational structure category, and data in different organizational structure categories can be used for different purposes. For example, access to system libraries can be used by DBA troubleshooting and monitoring tools. The execution rate is used to characterize the percentage of current access requests that are executed; the higher the execution rate value, the greater the probability that the current access request will be executed.
[0069] For example, access permission information is extracted from user information, and the execution rate of the current access request is determined based on the access permission information and category information. The access permission information can record the permission levels of different users for different categories of data patterns, and each permission level can also have a corresponding execution rate preset. The higher the permission level, the greater the execution rate for the target data pattern.
[0070] In one embodiment, the execution rate of the current access request is determined based on the user information of the target accessing user and the category information of the target data pattern, including: determining the user priority that matches the user information; determining the library priority that matches the category information; and determining the execution rate of the current access request based on the first priority parameter corresponding to the user priority and the second priority parameter corresponding to the library priority.
[0071] User priority distinguishes the importance of different users accessing the target database. Database priority distinguishes the importance of different data schemas within the target database. User and database priorities can be configured flexibly and with fine granularity according to actual business usage scenarios. The first priority parameter represents the percentage of the access request associated with the user that can be executed. The second priority parameter represents the percentage of the access request associated with the data schema that can be executed. The values of both the first and second priority parameters can range from 0 to 1; a higher value indicates a greater probability of the request being executed, with 1 representing 100% execution.
[0072] In one implementation, the execution rate can be calculated by multiplying the first priority parameter corresponding to the user priority and the second priority parameter corresponding to the library priority.
[0073] In another implementation, the first priority parameter can be weighted according to the set user weight, and the second priority parameter can be weighted according to the set library weight. The weighted results of the two can be added together, and the sum is used as the execution rate.
[0074] In setting user priorities, administrator and monitoring users can be given high priority, followed by business users. Business users can be further subdivided into different types to correspond to different business needs, thus assigning varying priorities. Table 1 below provides an example of user priority settings.
[0075] Table 1
[0076]
[0077] In scenarios where database priority is set, access to system databases is crucial, as they are needed for DBA troubleshooting and monitoring tools. A maximum priority of 1 can be set for these. Alternatively, priorities can be differentiated based on the business's self-built schema, such as configuration databases, business databases, and historical databases, each with varying degrees of importance. Table 2 below provides an example of database priority settings.
[0078] Table 2
[0079]
[0080] This embodiment sets different priorities based on the importance of users and data patterns, allowing for flexible and fine-grained configuration to meet the needs of actual business scenarios, maintain access requirements for high-importance users and data patterns, and ensure the smooth operation of important businesses.
[0081] Step 206: Determine the request rate of the current access request based on the historical request volume for the target data pattern.
[0082] Historical request volume refers to the number of requests initiated against a target data pattern within a certain past time period. Request rate characterizes the frequency of current access requests to the target data pattern. A target data pattern can receive multiple requests within a certain time period; these requests can be initiated by the same or different users. Requests initiated by the same user can be grouped into similar categories to calculate the request rate for that type of request. The time period included in historical request volume can be determined by pre-setting a fixed-length sliding time window.
[0083] For example, the total number of requests to the target database within a sliding time window is obtained. From this total number of requests, the historical request volume for the target data pattern is determined. Based on this historical request volume, the request rate for the current access request is calculated. A request volume statistics module can be set up in the target database to aggregate request volumes from the dimensions of users and data patterns, obtaining the total request volume. From the total request volume data, the historical request volume for the target data pattern can be filtered out, and the request rate is obtained based on the ratio of the target user of the current access request to the historical request volume.
[0084] In one embodiment, determining the request rate of the current access request based on the historical request volume for the target data pattern includes: determining the request execution volume of the target data pattern within a historical time window; and using the ratio of the request execution volume to the historical request volume as the request rate of the current access request based on the historical request volume for the target data pattern.
[0085] A historical time window is a sliding window used to count the number of requests executed by a target data pattern. The request execution volume refers to the number of historical access requests of the same type as the current access request executed by the target data pattern. Historical access requests of the same type as the current access request belong to the same accessing user. It's understandable that a target user can initiate access requests to the target data pattern multiple times, but the target data pattern doesn't necessarily execute them every time. Dividing the request execution volume by the historical request volume yields the request rate, which represents the proportion of such requests executed by the target data pattern within the historical time window.
[0086] This embodiment combines the request execution volume to determine the request rate, which can reflect the request frequency of the current access request and serve as the basis for determining the keep-alive execution strategy. It makes a more accurate strategy selection based on the difference in request frequency between different services.
[0087] Step 208: Determine the keep-alive execution strategy for the current access request based on the execution rate, request rate, and keep-alive level corresponding to the resource bottleneck status.
[0088] Keep-alive levels indicate the tendency of keep-alive execution strategies under different resource bottleneck conditions. Keep-alive execution strategies indicate the execution status of current access requests. It's understandable that even when the target database's resource consumption is already high under resource bottleneck conditions, it can still be segmented, and by differentiating tendencies, combined with execution rate and request rate, the keep-alive requirements of different scenarios can be adapted.
[0089] For example, based on the keep-alive level corresponding to the resource bottleneck state, request execution conditions are determined. If the execution rate and request rate meet the request execution conditions, the keep-alive execution policy for the current access request is determined to be "execute." If the execution rate and request rate do not meet the request execution conditions, the keep-alive execution policy for the current access request is determined to be "reject." Different keep-alive levels can correspond to different request execution conditions, used to limit the relationship between the execution rate and request rate, or the relationship with a set threshold. For example, request execution conditions may include a request rate less than the execution rate, or a request rate less than the execution rate while the execution rate is greater than a set threshold.
[0090] In the aforementioned database keep-alive method, when the target database accessed by the current access request is in a resource bottleneck state, the target access user and target data pattern associated with the current access request are determined. The target data pattern is used to manage data in the target database. Based on the user information of the target access user and the category information of the target data pattern, the execution rate of the current access request is determined. Based on the historical request volume for the target data pattern, the request rate of the current access request is determined. Based on the execution rate, request rate, and keep-alive level corresponding to the resource bottleneck state, the keep-alive execution strategy for the current access request is determined. By monitoring the resource occupancy status of the target database, the keep-alive process is initiated when the resource bottleneck state is reached. The execution rate can represent the ratio of execution of the current access request, and the request rate can represent the request frequency of the current access request for the target data pattern to be accessed. Different keep-alive levels can represent the bias of the keep-alive execution strategy under different resource bottleneck states, thereby obtaining a targeted keep-alive execution strategy to adapt to different business usage scenarios and improve business smoothness under resource bottleneck states.
[0091] In one exemplary embodiment, such as Figure 3 As shown, the keep-alive execution strategy for the current access request is determined based on the execution rate, request rate, and keep-alive level corresponding to the resource bottleneck status, including steps 302 to 306.
[0092] Step 302: When the keep-alive level is Level 1 and the request rate is less than the execution rate, determine the keep-alive execution strategy for the current access request as executing the current access request.
[0093] In this embodiment, the resource bottleneck states corresponding to the first, second, and third levels increase sequentially, with the resource utilization of the target database becoming increasingly higher. The keep-alive level is the first level, where there are relatively more available resources compared to other levels. If the request rate is less than the execution rate, the current access request is executed; if the request rate is greater than or equal to the execution rate, the current access request is rejected. Under the first level, by setting the constraint that the request rate must be less than the execution rate, requests that are executed less frequently within the sliding window can be executed.
[0094] In one embodiment, before determining the target user and target data pattern associated with the current access request when the target database accessed by the current access request is in a resource bottleneck state, the method further includes: when the target database receives the current access request, obtaining the current resource occupancy information of the target database; and when the resource occupancy value represented by the current resource occupancy information is greater than the resource occupancy threshold corresponding to the first level, determining that the target database is in a resource bottleneck state.
[0095] The kernel process of the target database can collect the overall memory resource usage of processes in real time, obtaining current resource usage information. The resource usage value can be the percentage of total memory currently used or a specific memory value. The resource usage threshold corresponds to the keep-alive level and can be flexibly configured according to actual conditions. The first level is the lowest resource bottleneck state level, and therefore can be used as a restriction condition for entering the keep-alive process. For example, the resource usage threshold corresponding to the first level could be a usage percentage of 96%. If the target database's current resource usage value is determined to be greater than 96%, then the target database is determined to be in a resource bottleneck state.
[0096] This embodiment determines the resource bottleneck status by using the current resource usage information, and can accurately obtain the resource usage in real time. When the resource usage is high, it can promptly intercept business requests and promptly restore business requests when the resource usage drops, thus achieving dynamic adjustment.
[0097] Step 304: When the keep-alive level is the second level, the execution rate is greater than the preset first execution rate threshold, and the request rate is less than the execution rate, determine the keep-alive execution strategy for the current access request as executing the current access request.
[0098] The resource utilization threshold for the second level can be set to 98%. At the second keep-alive level, the available resources of the target database are further reduced, and the constraints for executing the current access request are more stringent. Not only must the request rate be less than the execution rate, but the execution rate must also be greater than a preset first execution rate threshold. The preset first execution rate threshold is an execution rate condition set for the resource utilization situation at the second level. If the execution rate is greater than the preset first execution rate threshold, it indicates that the current access request has a high priority, and it can be determined to execute the current access request. If, at the second level, the conditions of an execution rate greater than the preset first execution rate threshold and a request rate less than the execution rate are not met, then the current access request is determined to be rejected. The preset first execution rate threshold can be set to 50%. At the second level, by setting the constraint that the execution rate is greater than the preset first execution rate threshold and the request rate is less than the execution rate, requests with fewer execution attempts within the sliding window and higher priority can be executed.
[0099] Step 306: If the keep-alive level is level 3 and the execution rate is less than the preset second execution rate threshold, identify active access requests whose execution rate is less than the execution rate of the current access request, and the keep-alive execution strategy for the current access request is to terminate the active access request.
[0100] The resource consumption threshold for the third level can be set to 99%. At the third keep-alive level, the target database's available resources are about to be exhausted. In this case, the primary goal is to ensure normal access to the most critical business processes. The current access request is only executed if the execution rate is greater than or equal to the preset second execution rate threshold. The preset second execution rate threshold is an execution rate condition set for the resource consumption situation at the third level. It can be set at a high level to avoid resource consumption by low-priority requests. For example, if the preset second execution rate threshold is set to 100%, only current access requests with an execution rate of 100% can be executed. This ensures that operation and maintenance-related requests are prioritized under high load, facilitating DBA troubleshooting and resolving issues. Setting high priority for monitoring users also ensures that the observable functions of the service remain normal as much as possible.
[0101] Active access requests refer to access requests that consume target database memory resources. If the execution rate is less than a preset second execution rate threshold, it means that the priority of this active access request is lower than the current access request, and it can be terminated to release memory resources and prevent resource exhaustion.
[0102] In another implementation, if the keep-alive level is level three and the execution rate is less than a preset second execution rate threshold, the active access request with the lowest execution rate is identified and the active access request is terminated.
[0103] In another implementation, if the keep-alive level is level three and the execution rate is less than a preset second execution rate threshold, an active access request whose execution rate is less than the execution rate of the current access request and whose execution duration exceeds a preset duration is identified, and the active access request is terminated.
[0104] In this embodiment, by setting different levels of keep-alive, a certain lead time can be provided before resources are exhausted, low-priority requests can be intercepted in advance, and the speed of resource exhaustion can be slowed down by gradually increasing the protection level.
[0105] In one exemplary embodiment, such as Figure 4 As shown, after determining the keep-alive execution strategy for the current access request based on the execution rate, the request rate of the current access request, and the keep-alive level corresponding to the resource bottleneck state, steps 402 to 404 are also included.
[0106] Step 402: If the current access request is determined to be executed, record the resource consumption information of the current access request.
[0107] Resource consumption information represents the target database resources consumed by the execution of the current access request. The target database may include a resource statistics module, which records the start time of the request execution and the cumulative memory resource consumption after execution, forming resource consumption information. The resource statistics module can perform resource statistics on all executed requests, which is used to determine which requests need to be terminated under high keep-alive level resource bottleneck conditions.
[0108] Step 404: Update the resource bottleneck status of the target database based on resource consumption information.
[0109] The execution of the current access request requires memory resources from the target database. Memory resources are closely related to resource bottleneck status. Based on the memory resource usage value or percentage in the resource consumption information, the resource usage value associated with the resource bottleneck status can be updated to determine whether the keep-alive level corresponding to the resource bottleneck status has changed. If the keep-alive level is increased, upon receiving another access request, service keep-alive will be performed based on the updated keep-alive level corresponding to the resource bottleneck status.
[0110] In this embodiment, by statistically analyzing the resource consumption of executed requests, the resource bottleneck status of the target database is updated in a timely manner, and the keep-alive strategy is adjusted. This allows for the timely rejection of low-priority requests and ensures normal access for high-priority requests.
[0111] In one exemplary embodiment, such as Figure 5 As shown, the method includes steps S1 to S5.
[0112] S1. Determine resource bottleneck status. When the target database receives a current access request of type SQL (Structured Query Language), it can determine whether the current memory usage exceeds the minimum threshold of the keep-alive level (e.g., 96%), which is the resource usage threshold corresponding to the first level. If it does not exceed the threshold, the SQL request can be executed directly. Otherwise, the keep-alive strategy process begins.
[0113] S2. Obtain user priority and database priority. Upon entering the keep-alive strategy process, the user priority (user_prior) associated with the SQL request can be found, and the database priority (schema_prior) associated with the request can be found. The user priority and database priority are multiplied to calculate the final execution rate of the request.
[0114] S3. Trigger resource statistics. SQL requests and their execution rates can be registered in the resource statistics module of the target database. If an SQL request is executed, the resource statistics module records the corresponding execution time and memory resource allocation for subsequent processing.
[0115] S4. Calculate the sliding window request rate. The number of SQL requests can be summarized by user and schema granularity, and then the request rate of the current SQL request within the sliding window can be calculated.
[0116] S5. Implement keep-alive strategy. Based on resource utilization (e.g., 96% for Level 1, 98% for Level 2, 99% for Level 3), different keep-alive levels are set, with each level progressively increasing the requirements for executing a request. Specifically: Level 1 (Level 1): Execute the SQL request if the request rate is less than the execution rate; otherwise, reject the request. Level 2 (Level 2): Execute the SQL request if both the execution rate and request rate are greater than the execution rate; otherwise, reject the request. Level 3 (Level 3): Execute the SQL request if the execution rate is 1; otherwise, search for SQL requests that have not finished for a long time (e.g., more than 5 seconds). If their execution rate is less than the current SQL request's execution rate, terminate the execution of that SQL request early.
[0117] 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.
[0118] Based on the same inventive concept, this application also provides a database keep-alive device for implementing the database keep-alive method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more database keep-alive device embodiments provided below can be found in the limitations of the database keep-alive method described above, and will not be repeated here.
[0119] In one exemplary embodiment, such as Figure 6 As shown, a database keep-alive device 600 is provided, including: a user mode determination module 601, an execution rate determination module 602, a request rate determination module 603, and an execution strategy determination module 604.
[0120] The user pattern determination module 601 is used to determine the target user and target data pattern associated with the current access request when the target database accessed by the current access request is in a resource bottleneck state. The target data pattern is a node in the target database.
[0121] The execution rate determination module 602 is used to determine the execution rate of the current access request based on the user information of the target accessing user and the category information of the target data pattern.
[0122] The request rate determination module 603 is used to determine the request rate of the current access request based on the historical request volume for the target data pattern.
[0123] The execution strategy determination module 604 is used to determine the keep-alive execution strategy for the current access request based on the execution rate, request rate, and keep-alive level corresponding to the resource bottleneck status.
[0124] In an exemplary embodiment, the execution rate determination module 602 is further configured to: determine the user priority matching the user information; determine the library priority matching the category information; and determine the execution rate of the current access request based on the first priority parameter corresponding to the user priority and the second priority parameter corresponding to the library priority.
[0125] In an exemplary embodiment, the request rate determination module 603 is further configured to: determine the request execution volume of the target data pattern within a historical time window; and, based on the historical request volume for the target data pattern, use the ratio of the request execution volume to the historical request volume as the request rate of the current access request.
[0126] In an exemplary embodiment, the execution strategy determination module 604 is further configured to: determine the current access request's keep-alive execution strategy as executing the current access request when the keep-alive level is at the first level and the request rate is less than the execution rate; determine the current access request's keep-alive execution strategy as executing the current access request when the keep-alive level is at the second level, the execution rate is greater than a preset first execution rate threshold, and the request rate is less than the execution rate; and determine an active access request with an execution rate less than the execution rate of the current access request as the keep-alive execution strategy for the current access request as terminating the active access request when the keep-alive level is at the third level and the execution rate is less than a preset second execution rate threshold; wherein the resource bottleneck states corresponding to the first, second, and third levels increase sequentially.
[0127] In an exemplary embodiment, the database keep-alive device 600 further includes a bottleneck state determination module, configured to: obtain current resource occupancy information of the target database when the target database receives a current access request; and determine that the target database is in a resource bottleneck state when the resource occupancy value represented by the current resource occupancy information is greater than the resource occupancy threshold corresponding to the first level.
[0128] In an exemplary embodiment, the database keep-alive device 600 further includes a resource statistics module, used to: record the resource consumption information of the current access request when the current access request is determined to be executed; and update the resource bottleneck status of the target database based on the resource consumption information.
[0129] Each module in the aforementioned database keep-alive device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.
[0130] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, 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 operation of the operating system and computer programs stored in the non-volatile storage media. The database stores user information and category information. The I / O interfaces are used for exchanging information 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 database keep-alive method.
[0131] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 8 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a database persistence method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.
[0132] Those skilled in the art will understand that Figure 7 and Figure 8The 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.
[0133] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.
[0134] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.
[0135] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.
[0136] 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.
[0137] 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.
[0138] 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 database keep-alive method, characterized in that, The method includes: If the target database accessed by the current access request is in a resource bottleneck state, determine the target access user and target data pattern associated with the current access request. The target data pattern is used to manage the data in the target database. The execution rate of the current access request is determined based on the user information of the target accessing user and the category information of the target data pattern. The request rate of the current access request is determined based on the historical request volume for the target data pattern. Based on the execution rate, the request rate, and the keep-alive level corresponding to the resource bottleneck state, determine the keep-alive execution strategy for the current access request.
2. The method according to claim 1, characterized in that, Determining the execution rate of the current access request based on the user information of the target accessing user and the category information of the target data pattern includes: Determine the priority of users who match the user information; Determine the library priority that matches the category information; The execution rate of the current access request is determined based on the first priority parameter corresponding to the user priority and the second priority parameter corresponding to the library priority.
3. The method according to claim 1, characterized in that, Determining the request rate of the current access request based on the historical request volume for the target data pattern includes: Determine the number of requests executed for the target data pattern within a historical time window; Based on the historical request volume for the target data pattern, the ratio of the request execution volume to the historical request volume is used as the request rate of the current access request.
4. The method according to claim 1, characterized in that, The step of determining the keep-alive execution strategy for the current access request based on the execution rate, the request rate, and the keep-alive level corresponding to the resource bottleneck state includes: If the keep-alive level is the first level and the request rate is less than the execution rate, the keep-alive execution strategy for the current access request is determined to be to execute the current access request. If the keep-alive level is the second level, the execution rate is greater than the preset first execution rate threshold, and the request rate is less than the execution rate, then the keep-alive execution strategy for the current access request is determined to be to execute the current access request. If the keep-alive level is level three and the execution rate is less than a preset second execution rate threshold, an active access request with an execution rate less than the execution rate of the current access request is identified, and the keep-alive execution strategy for the current access request is determined to be to terminate the active access request. The resource bottleneck status corresponding to the first level, the second level, and the third level increases sequentially.
5. The method according to claim 4, characterized in that, Before determining the target user and target data pattern associated with the current access request when the target database accessed by the current access request is in a resource bottleneck state, the method further includes: When the target database receives the current access request, obtain the current resource usage information of the target database; If the resource occupancy value represented by the current resource occupancy information is greater than the resource occupancy threshold corresponding to the first level, the target database is determined to be in a resource bottleneck state.
6. The method according to any one of claims 1 to 5, characterized in that, After determining the keep-alive execution strategy for the current access request based on the execution rate, the request rate of the current access request, and the keep-alive level corresponding to the resource bottleneck state, the method further includes: If the current access request is determined to be executed, record the resource consumption information of the current access request; Based on the resource consumption information, the resource bottleneck status of the target database is updated.
7. A database keep-alive device, characterized in that, The device includes: The user mode determination module is used to determine the target access user and target data mode associated with the current access request when the target database accessed by the current access request is in a resource bottleneck state. The target data mode is used to manage the data in the target database. The execution rate determination module is used to determine the execution rate of the current access request based on the user information of the target access user and the category information of the target data pattern; The request rate determination module is used to determine the request rate of the current access request based on the historical request volume for the target data pattern. The execution strategy determination module is used to determine the keep-alive execution strategy for the current access request based on the execution rate, the request rate, and the keep-alive level corresponding to the resource bottleneck state.
8. 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.
9. 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.
10. 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.