Method and system for cache management of collection items for database behavior load collection

CN116225659BActive Publication Date: 2026-10-27上海沄熹科技有限公司
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202310261206.9
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2023-03-17
Publication Date
2026-10-27
Estimated Expiration
2043-03-17

AI Technical Summary

Technical Problem

用户缺乏数据库系统全面的行为数据,无法从不同的角度准确地对系统运行情况进行评估和对SQL行为进行优化决策

Benefits of technology

[0029]1、本发明提出的方法可以完整达到应用负载采集的功能。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116225659B_ABST
    Figure CN116225659B_ABST
Patent Text Reader

Abstract

The application discloses a collection item cache management method and system for database behavior load collection, belongs to the technical field of databases, and separately creates a collection item cache queue for each link connected to a database system, all collection cache queues are uniformly managed by a load collection central dispatcher, and a thread is separately arranged to execute serialization and disk storage tasks; the load collection central dispatcher comprises a link registration queue, a link processing queue, a serialization and disk storage thread, collection items are saved into collection cache queues, and the collection cache queues are saved in each link management object; when the collection items of the collection cache queue are all filled, the link management object is flipped into the link processing queue, and the serialization and disk storage thread regularly removes the link management object from the link processing queue for processing. The application can reduce the burden of a load collection system and reduce the influence of load collection on normal execution processes as much as possible.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of database technology, specifically to a method and system for managing the cache of data collection items for database behavioral load collection. Background Technology

[0002] The existing data metrics collected in the database mainly focus on cluster and node detection and log monitoring, while the collection of behavioral data related to application load, compilation and execution is not comprehensive enough. For example, the application load layer lacks session-level behavioral data; the statistical information, optimization rules, and data referenced during plan pruning used in the SQL compilation phase are not collected in detail; and multi-dimensional, fine-grained behavioral metrics are not collected during the execution phase. Users lack comprehensive behavioral data about the database system, making it impossible to accurately evaluate system performance and make optimization decisions regarding SQL behavior from different perspectives. For instance, the inability to comprehensively assess application load and the lack of behavioral data during the compilation and execution phases lead to inaccurate optimizer estimations, making it difficult to select the optimal execution plan. Consequently, the autonomous management system cannot systematically and comprehensively understand, manage, and adjust database application and SQL behavior to achieve performance improvements.

[0003] In the use of database systems, in most cases, multiple users connect to the same database system to perform operations. At this time, the load balancing system will face the test of high concurrency. If the structure of the data to be collected is not locked, multiple connections may obtain the same data item, causing behavioral data collection to fail. Locking the structure of the data to be collected can ensure that the data items obtained by multiple connections are independent and will not cause confusion, but it will cause multiple connections to compete for the lock. Connections that cannot acquire the lock can only wait for a period of time, and this waiting time will affect the normal operation of the database system. The impact will be more serious when the number of connections reaches a certain level. Summary of the Invention

[0004] The technical objective of this invention is to address the above-mentioned shortcomings by providing a method and system for managing the cache of data collection items for database behavior load collection, thereby reducing the burden on the load collection system, minimizing the impact of load collection on the normal execution process, and ensuring that information is collected without significantly affecting the speed of normal database execution.

[0005] The technical solution adopted by this invention to solve its technical problem is:

[0006] A method for managing the cache of collection items for database behavior load scrambling involves creating a separate collection item cache queue for each connection to the database system, and all collection cache queues are managed uniformly by the load scrambling central scheduler, with a separate thread performing serialization and disk write tasks.

[0007] The load acquisition central scheduler includes a link registration queue, a link processing queue, a serialization and disk write thread, and acquisition items are saved to an acquisition cache queue, which is stored in each link management object.

[0008] Once the collection cache queue is filled with all the collection items, the link management object will be flipped into the link processing queue. The serialization and disk write threads will periodically remove it from the link processing queue for processing.

[0009] The link retrieves collection items from the collection cache queue, and returns them to the collection queue after collection is complete;

[0010] When a connection first enters the database system, it is registered with the load acquisition central management system. When a connection exits, it is deregistered with the load acquisition central management system.

[0011] The workflow of the load data acquisition central management system is as follows: When a user inputs an SQL command into the database system, the database system requests an empty data collection item from the load data acquisition central management system. During execution, behavioral data is collected into the data collection item. After the statement execution is complete, the data collection item is returned to the load data acquisition central management system. The load data acquisition central management system centrally stores the data collection items and periodically serializes and persists the populated data collection items to disk, thereby achieving the function of saving behavioral data. The application load data acquisition central management system aims to collect behavioral data from the database about application load, compilation phase, and execution phase in a comprehensive and multi-layered manner. This behavioral data will be saved to provide data support for building a data warehouse and optimizing SQL engine performance on the autonomous data management platform.

[0012] This method creates a separate collection item cache queue for each connection to the database system, and all collection cache queues are managed centrally by a load balancing scheduler. This allows multiple connections to safely and concurrently retrieve and return collection items without any locking or waiting processes, minimizing the impact of load balancing on tasks executed within the connections and better supporting high-concurrency scenarios. Furthermore, a separate thread handles serialization and disk persistence, reducing the workload of the central scheduler and accelerating its response time, thereby minimizing the impact of load balancing on the database system's execution flow.

[0013] Preferably, a load balancing central management system (Scheduler) is configured, which includes a connection registration queue (wliConnRegistList), a connection processing queue (wliConnPorcessList), and a serialization + disk write thread. The connection registration queue stores connection management objects (wliConnHandler), each corresponding to a connection. The connection management object (wliConnHandler) stores the acquisition cache queue and a status flag. The status flag is an atomic variable. When its value is 0, it indicates an idle state, at which time the connection can retrieve memory items from the acquisition cache queue. When its value is 1, it indicates that the connection is currently acquiring data, and the load balancing central management system cannot operate on it. When its value is 2, it indicates that all memory items in the acquisition cache queue are filled, and serialization and disk write operations are in progress or about to begin, at which time the connection cannot retrieve memory items.

[0014] The serialization and disk write thread periodically monitors the link processing queue for any pending link management objects. If any are found, they are retrieved, and each memory item within them is serialized and written to disk. Then, the registration process is attempted again. If the link management object is found in the link registration queue, only the flag is changed to 0, indicating that the link is idle. If the link management object is not found in the link registration queue, it is considered that the link has been deregistered, and the link management object is discarded.

[0015] Furthermore, when a connection first connects to the database system and executes its first SQL command, it registers with the load balancing central management system. The load balancing central management system initializes a connection management object and returns a pointer to the connection management object to the connection for requesting and returning memory items. After obtaining the pointer, the connection first checks the status of the connection management object. If it is 0 (idle), it attempts to change it to 1 (in progress), then retrieves a memory item from the head of the cache queue and performs the collection process. After collection is complete, the collected item is returned and placed at the tail of the cache queue, with its status set to 0. When all memory items in the cache queue are filled, the connection management object changes its status to 2 (busy) and then inserts itself into the connection processing queue, which is then handed over to the serialization and disk write thread for processing.

[0016] Furthermore, when a link needs to exit the database, it first sends a deregistration request to the load acquisition central management system during the exit process. Then, the load acquisition central management system iterates through each link management object in the link registration queue. If the link management object is idle, it is first removed from the link registration queue. Then, it checks if there are any used memory items in the cache queue. If so, it puts them into the link processing queue. If the link management object is unavailable, it indicates that a serialization operation is in progress. In this case, the link management object can simply be removed from the link registration queue.

[0017] Furthermore, if the serialization and disk write thread finds the link processing queue empty for an extended period, it triggers a forced disk write mechanism: This thread iterates through the link registration queue three times at 20ms intervals, attempting to change the state of all entries to 2. Only entries with a state of 0 can be changed to state 2; entries with a state of 1 are skipped and tried again on the next iteration. Then, all link management objects with a state of 2 are added to the link processing queue. This operation forces the disk write operation for any incomplete cache queues, and the number of used memory items is stored in the link management object.

[0018] Preferably, when it is necessary to shut down data collection but not the database, the load balancing central management system first changes the status of the link processing list to unavailable to prevent new link management objects from being added. Then, it waits for the serialization and disk write threads to process the data until the link processing queue is empty. After that, it polls the status of the link management objects in the link registration queue. If the status of the link management object is idle, its status is changed to 2, i.e., unusable, to prevent the link from continuously accessing memory items. Then, the contents of the link management object are cleared, i.e., the saved data collection is discarded. Then, the link management object is removed from the link registration list. If the status of the link management object is 1, i.e., in use, this round is skipped and no processing is performed. If the status of the link management object is 2, i.e., unusable, it indicates that serialization and disk write operations have been performed. At this time, the contents of the link management object are cleared and the link management object is removed from the registration list.

[0019] Furthermore, no more memory items will be requested after the collection switch is turned off; the link will first check the switch status during collection, and return the memory items already held when the switch is turned off;

[0020] If the link holds a memory item and the process is stuck, it is necessary to check whether the collection switch is turned off and whether the pointer to the link management object is null. If so, the collection should be discarded.

[0021] If the link gets stuck when it doesn't hold a memory item, it will release the pointer to the link management object and stop collecting data after it is restored.

[0022] This invention also claims a collection item caching management system for database behavior load scavenging, including a connection registration queue, a connection processing queue, a serialization + disk persistence thread, and a load scavenging central scheduler.

[0023] This system can implement the above-mentioned method for managing the cache of data collection items for database behavior load collection.

[0024] The present invention also claims a collection item cache management device for database behavior load collection, comprising: at least one memory and at least one processor;

[0025] The at least one memory is used to store a machine-readable program;

[0026] The at least one processor is configured to call the machine-readable program to execute the above-described method for managing the cache of collected items for database behavior load collection.

[0027] The present invention also claims a computer-readable medium storing computer instructions that, when executed by a processor, cause the processor to perform the above-described method for managing the cache of data collection items for database behavioral load collection.

[0028] Compared with the prior art, the collection item cache management method and system of the present invention for database behavioral load collection have the following advantages:

[0029] 1. The method proposed in this invention can fully achieve the function of application load acquisition.

[0030] 2. This invention proposes a method of creating a separate collection item cache queue for each link and managing it uniformly by a central scheduler. This reduces the impact of load collection on the database system execution process and better supports high-concurrency scenarios.

[0031] 3. The newly proposed serialization of acquisition items and disk storage thread in this invention reduce the workload of the central scheduler and speed up the response.

[0032] 4. The forced disk write process proposed in this invention can effectively reduce thread idle time and make more efficient use of resources. Attached Figure Description

[0033] Figure 1 This is an implementation architecture diagram of a method for managing the cache of collection items for database behavior load collection, provided by an embodiment of the present invention;

[0034] Figure 2 This is a schematic diagram of the link management object flag bits provided in one embodiment of the present invention;

[0035] Figure 3 This is a flowchart of link registration and normal execution provided in one embodiment of the present invention;

[0036] Figure 4 This is a flowchart of the link cancellation process provided in one embodiment of the present invention;

[0037] Figure 5 This is a flowchart of a forced disk placement process provided in one embodiment of the present invention;

[0038] Figure 6 This is a flowchart of shutting down the load acquisition central management system provided in one embodiment of the present invention. Detailed Implementation

[0039] The present invention will be further described below with reference to specific embodiments.

[0040] This invention provides a method for managing the cache of collection items for database behavior load scrambling. A separate collection item cache queue is created for each connection to the database system, and all collection cache queues are managed uniformly by the load scrambling central scheduler. A separate thread is set up to perform serialization and disk writing tasks.

[0041] The load acquisition central scheduler includes a link registration queue, a link processing queue, a serialization and disk write thread, and acquisition items are saved to an acquisition cache queue, which is stored in each link management object.

[0042] Once the collection cache queue is filled with all the collection items, the link management object will be flipped into the link processing queue. The serialization and disk write threads will periodically remove it from the link processing queue for processing.

[0043] The link retrieves collection items from the collection cache queue, and returns them to the collection queue after collection is complete;

[0044] When a connection first enters the database system, it is registered with the load acquisition central management system. When a connection exits, it is deregistered with the load acquisition central management system.

[0045] The workflow of the load data acquisition central management system is as follows: When a user inputs an SQL command into the database system, the database system requests an empty data collection item from the load data acquisition central management system. During execution, behavioral data is collected into the data collection item. After the statement execution is complete, the data collection item is returned to the load data acquisition central management system. The load data acquisition central management system centrally stores the data collection items and periodically serializes and persists the populated data collection items to disk, thereby achieving the function of saving behavioral data. The application load data acquisition central management system aims to collect behavioral data from the database about application load, compilation phase, and execution phase in a comprehensive and multi-layered manner. This behavioral data will be saved to provide data support for building a data warehouse and optimizing SQL engine performance on the autonomous data management platform.

[0046] The specific implementation process of this method is as follows:

[0047] like Figure 1 As shown, the Scheduler is a central management system for load balancing, which includes a connection registration queue (wliConnRegistList), a connection processing queue (wliConnProcessList), and a serialization and disk write thread. The connection registration queue stores connection management objects (wliConnHandler), each corresponding to a connection. The connection management object (wliConnHandler) stores the acquisition cache queue and status flags. The status flags are atomic variables, and their meanings are as follows: Figure 2 As shown, a value of 0 indicates an idle state, at which point the link can retrieve memory items from the acquisition cache queue; a value of 1 indicates that the link is currently acquiring data, and the load acquisition central management system cannot operate on it; a value of 2 indicates that all memory items in the acquisition cache queue are filled, and serialization and disk writing operations are in progress or about to begin, at which point the link cannot retrieve memory items.

[0048] The serialization and disk write thread periodically monitors the link processing queue for any pending link management objects. If any are found, they are retrieved, and each memory item within the queue is serialized and written to disk. Then, the registration process is attempted again. If the link management object is found in the link registration queue, only the flag is changed to 0 (idle); if the link management object is not found in the queue, the link is considered to have been deregistered, and the link management object is discarded.

[0049] like Figure 3As shown, when a connection first connects to the database system and executes its first SQL command, it registers with the load balancing central management system, the scheduler. The scheduler initializes a connection management object and returns a pointer to this object to the connection. This pointer is used by the connection to request and return memory items. After receiving the pointer, the connection first checks the status of the connection management object. If it is 0 (idle), it attempts to change it to 1 (collecting). Then, it retrieves a memory item from the head of the cache queue and performs the collection process. After collection, the memory item is returned and placed at the tail of the cache queue, and its status is set to 0 (idle). Once all memory items in the cache queue are filled, the connection management object changes its status to 2 (busy) and then adds itself to the connection processing queue, which is then handed over to the serialization and disk write thread for processing.

[0050] When the link needs to be removed from the database, such as Figure 4 As shown, during the exit process, the link will first send a deregistration request to the load acquisition central management system scheduler. Then, the scheduler will traverse each link management object in the link registration queue. If the link management object is in an idle state, it will first remove the link management object from the link registration queue. Then, it will check if there are any used memory items in the cache queue. If so, it will put them into the link processing queue. If the link management object is in an unavailable state, it indicates that a serialization operation is in progress. In this case, the link management object can simply be removed from the link registration queue.

[0051] If the serialization and disk write thread finds the link processing queue to be empty for an extended period, it triggers a forced disk write mechanism, such as... Figure 5 As shown: This thread iterates through the link registration queue three times at 20ms intervals, attempting to change the state of all links to 2. Only links with a state of 0 can be changed to state 2; links with a state of 1 are skipped and tried again on the next iteration. Then, all link management objects with a state of 2 are added to the link processing queue. This operation forces unfilled cache queues to trigger disk write operations, and the number of used memory items is stored by the link management object.

[0052] When it is necessary to shut down data collection but not the database, the process is as follows: Figure 6As shown, the scheduler first changes the status of the link processing list to unavailable to prevent new link management objects from being added. Then it waits for the serialization and disk write threads to process the data until the link processing queue is empty. After that, it polls the status of the link management objects in the link registration queue. If the status of the link management object is idle, its status is changed to 2 (unavailable) to prevent the link from continuously accessing memory items. Then, the contents of the handler are cleared, i.e., the saved collected data is discarded. Then, the link management object is removed from the link registration list. If the status of the link management object is 1 (in use), this round is skipped and no processing is performed. If the status of the link management object is 2 (unavailable), it indicates that serialization and disk write operations have been performed. At this time, the contents of the handler are cleared and the link management object is removed from the registration list.

[0053] Under normal circumstances, no memory items will be requested after the collection switch is turned off; the link will first check the switch status during collection, and return the memory items already held when the switch is turned off;

[0054] If the link holds a memory item and the process is stuck, it is necessary to check whether the collection switch is turned off and whether the pointer to the link management object is null. If so, the collection should be discarded.

[0055] If the link gets stuck when it doesn't hold a memory item, it will release the pointer to the link management object and stop collecting data after it is restored.

[0056] This method reduces the load on the data collection system by creating a separate collection item cache queue for the connection to the database system and adding serialization and disk writing threads. This minimizes the impact of data collection on the normal execution process, ensuring that information is collected without significantly affecting the speed of normal database execution.

[0057] This invention also provides a collection item cache management system for database behavior load scavenging, including a link registration queue, a link processing queue, a serialization + disk persistence thread, and a load scavenging central scheduler. This system can implement the collection item cache management method for database behavior load scavenging described in the above embodiments.

[0058] The data collection item caching management system creates a separate data collection item caching queue for each connection to the database system, and all data collection caching queues are managed uniformly by the load data collection central scheduler, with a separate thread to perform serialization and disk writing tasks;

[0059] The collected items are saved to the collection cache queue, which is stored in each link management object;

[0060] Once the collection cache queue is filled with all the collection items, the link management object will be flipped into the link processing queue. The serialization and disk write threads will periodically remove it from the link processing queue for processing.

[0061] The link retrieves collection items from the collection cache queue, and returns them to the collection queue after collection is complete;

[0062] When a link initially connects to the database system, it registers with the data collection item cache management system; when a link exits, it deregisters with the data collection item cache management system.

[0063] The connection registration queue stores connection management objects wliConnHandler. Each connection management object corresponds to a connection. The connection management object wliConnHandler stores the acquisition cache queue and status flags. The status flag is an atomic variable. When its value is 0, it indicates an idle state, at which time the connection can retrieve memory items from the acquisition cache queue. When its value is 1, it indicates that the connection is currently acquiring data, and the load acquisition central management system cannot operate on it. When its value is 2, it indicates that all memory items in the acquisition cache queue are filled, and serialization and disk writing operations are in progress or about to begin. At this time, the connection cannot retrieve memory items.

[0064] The serialization and disk write thread periodically monitors the link processing queue for any pending link management objects. If any are found, they are retrieved, and each memory item within the queue is serialized and written to disk. Then, the registration process is attempted again. If the link management object is found in the link registration queue, only the flag is changed to 0 (idle); if the link management object is not found in the queue, the link is considered to have been deregistered, and the link management object is discarded.

[0065] When a connection first connects to the database system and executes its first SQL command, it registers with the data collection item cache management system. The system initializes a connection management object and returns a pointer to this object to the connection. This pointer is used by the connection to request and return memory items. After receiving the pointer, the connection first checks the status of the connection management object. If it is 0 (idle), it attempts to change it to 1 (collecting data). Then, it retrieves a memory item from the head of the cache queue, performs the data collection process, and returns the collected item to the tail of the cache queue, setting its status to 0 (idle). Once all memory items in the cache queue are filled, the connection management object changes its status to 2 (busy) and adds itself to the connection processing queue, which is then handed over to the serialization and disk write thread for processing.

[0066] When a link needs to exit the database, it first sends a deregistration request to the collection item cache management system during the exit process. Then, the collection item cache management system iterates through each link management object in the link registration queue. If the link management object is idle, it is first removed from the link registration queue. Then, it checks if there are any used memory items in the cache queue. If so, it puts them into the link processing queue. If the link management object is unavailable, it indicates that a serialization operation is in progress. In this case, the link management object can simply be removed from the link registration queue.

[0067] If the serialization and disk write thread finds the link processing queue empty for an extended period, it triggers a forced disk write mechanism. This thread iterates through the link registration queue three times at 20ms intervals, attempting to change the state of all entries to 2. Only entries with a state of 0 are changed to state 2; entries with a state of 1 are skipped and tried again on the next iteration. Then, all link management objects with a state of 2 are added to the link processing queue. This operation forces a disk write operation for any incomplete cache queues, and the number of used memory items is stored in the link management object.

[0068] When data collection needs to be stopped but the database remains open, the data collection item caching management system first changes the status of the connection processing list to unavailable to prevent new connection management objects from being added. Then, it waits for the serialization and disk write threads to process the data until the connection processing queue is empty. After that, it polls the status of the connection management objects in the connection registration queue. If the status of the connection management object is idle, its status is changed to 2 (unusable) to prevent the connection from continuously accessing memory items. Then, the contents of the handler are cleared, i.e., the saved data collection is discarded. Then, the connection management object is removed from the connection registration list. If the status of the connection management object is 1 (in use), this round is skipped and no processing is performed. If the status of the connection management object is 2 (unusable), it indicates that serialization and disk write operations have been performed. At this time, the contents of the handler are cleared and the connection management object is removed from the registration list.

[0069] Under normal circumstances, no memory items will be requested after the collection switch is turned off; the link will first check the switch status during collection, and return the memory items already held when the switch is turned off;

[0070] If the link holds a memory item and the process is stuck, it is necessary to check whether the collection switch is turned off and whether the pointer to the link management object is null. If so, the collection should be discarded.

[0071] If the link gets stuck when it doesn't hold a memory item, it will release the pointer to the link management object and stop collecting data after it is restored.

[0072] This invention also provides a collection item cache management device for database behavior load collection, comprising: at least one memory and at least one processor;

[0073] The at least one memory is used to store a machine-readable program;

[0074] The at least one processor is configured to call the machine-readable program to execute the collection item cache management method for database behavior load collection described in the above embodiments.

[0075] This invention also provides a computer-readable medium storing computer instructions. When executed by a processor, the computer instructions cause the processor to perform the data collection item cache management method for database behavior load collection described in the above embodiments. Specifically, a system or apparatus equipped with a storage medium storing software program code that implements the functions of any of the above embodiments can be provided, and the computer (or CPU or MPU) of the system or apparatus can read and execute the program code stored in the storage medium.

[0076] In this case, the program code read from the storage medium can itself implement the function of any of the above embodiments, and therefore the program code and the storage medium storing the program code constitute part of the present invention.

[0077] Examples of storage media used to provide program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer via a communication network.

[0078] Furthermore, it should be clear that not only can the program code read by the computer be executed, but also the operating system or other components operating on the computer can be instructed based on the program code to perform some or all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0079] Furthermore, it is understood that the program code read from the storage medium is written to the memory set in the expansion board inserted into the computer or to the memory set in the expansion unit connected to the computer. Then, based on the instructions of the program code, the CPU or other components installed on the expansion board or expansion unit execute some and all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0080] The present invention has been shown and described in detail above with reference to the accompanying drawings and preferred embodiments. However, the present invention is not limited to these disclosed embodiments. Based on the above embodiments, those skilled in the art will know that more embodiments of the present invention can be obtained by combining the code review methods in the different embodiments. These embodiments are also within the protection scope of the present invention.

Claims

1. A method for managing the cache of data collection items for database behavioral load balancing, characterized in that, A separate collection item cache queue is created for each connection to the database system, and all collection cache queues are managed uniformly by the load collection central management system, with a separate thread to perform serialization and disk writing tasks; The load acquisition central management system includes a link registration queue, a link processing queue, a serialization + disk write thread, and acquisition items are saved to an acquisition cache queue, which is stored in each link management object. Once all the collection items in the collection cache queue are filled, the link management object will be flipped into the link processing queue, and the serialization + disk write thread will periodically remove it from the link processing queue for processing. The link retrieves collection items from the collection cache queue, and returns them to the collection queue after collection is complete; When a connection first enters the database system, it registers with the load acquisition central management system; when a connection exits, it deregisters with the load acquisition central management system. When a connection first connects to the database system and executes its first SQL command, it registers with the load balancing central management system. The load balancing central management system initializes a connection management object and returns a pointer to this object to the connection. This pointer is used by the connection to request and return memory items. After receiving the pointer, the connection first checks the status of the connection management object. If it is 0 (idle), it attempts to change it to 1 (in progress). Then, it retrieves a memory item from the head of the cache queue and performs the collection process. After collection, the connection returns the collected item to the tail of the cache queue and sets its status to 0. Once all memory items in the cache queue are filled, the connection management object changes its status to 2 (busy) and then adds itself to the connection processing queue, where it is then handled by the serialization and disk write thread. When a link needs to exit the database, it first sends a deregistration request to the load balancing central management system during the exit process. Then, the load balancing central management system iterates through each link management object in the link registration queue. If the link management object is idle, it is first removed from the link registration queue. Then, it checks if there are any used memory items in the cache queue. If so, it puts them into the link processing queue. If the link management object is unavailable, it indicates that a serialization operation is in progress. In this case, the link management object can simply be removed from the link registration queue. The serialization and disk write thread periodically monitors the link processing queue for any pending link management objects. If any are found, they are retrieved, and each memory item within them is serialized and written to disk. Then, the registration process is attempted again. If the link management object is found in the link registration queue, only the flag is changed to 0, indicating that the link is idle. If the link management object is not found in the link registration queue, it is considered that the link has been deregistered, and the link management object is discarded.

2. The method for managing the cache of data collection items for database behavior load collection according to claim 1, characterized in that, The load balancing central management system, Scheduler, is configured, which includes a connection registration queue (wliConnRegistList), a connection processing queue (wliConnProcessList), and a serialization and disk write thread. The connection registration queue stores connection management objects (wliConnHandler), each corresponding to a connection. The connection management object (wliConnHandler) stores the acquisition cache queue and a status flag. The status flag is an atomic variable; when its value is 0, it indicates an idle state, at which time the connection can retrieve memory items from the acquisition cache queue; when its value is 1, it indicates that the connection is currently acquiring data, and the load balancing central management system cannot operate on it. When its value is 2, it means that all memory items in the acquisition cache queue are filled and serialization to disk operation is in progress or about to be performed. At this time, the link cannot retrieve memory items.

3. The method for managing the cache of data collection items for database behavior load collection according to claim 2, characterized in that, If the serialization and disk write thread finds that the link processing queue is empty for a long time, it will trigger the forced disk write mechanism: the thread will traverse the link registration queue three times at 20ms intervals, try to change all the states to 2, and only change the state to 2 when the state is 0. If it encounters a state of 1, it will skip it and try again on the next traversal; then, it will fill the link management objects with the state of 2 into the link processing queue.

4. The method for managing the cache of collection items for database behavior load collection according to claim 2, characterized in that, When data collection needs to be stopped but the database remains open, the load balancing central management system first changes the status of the connection processing list to unavailable to prevent new connection management objects from being added. Then, it waits for the serialization and disk write threads to process the data until the connection processing queue is empty. After that, it polls the status of the connection management objects in the connection registration queue. If the connection management object's status is idle, its status is changed to 2 (unusable) to prevent the connection from continuously accessing memory items. Then, the content of the connection management object is cleared, meaning the saved data collection is discarded, and the connection management object is removed from the connection registration list. If the connection management object's status is 1 (in use), this round is skipped. If the connection management object's status is 2 (unusable), it indicates that serialization and disk write operations have already been performed. In this case, the content of the connection management object is cleared, and the connection management object is removed from the registration list.

5. The method for managing the cache of data collection items for database behavior load collection according to claim 4, characterized in that, After the collection switch is turned off, no more memory items will be requested; the link will first check the switch status during collection, and return the memory items already held when the switch is turned off; If the link holds a memory item and the process is stuck, it is necessary to check whether the collection switch is turned off and whether the pointer to the link management object is null. If so, the collection should be discarded. If the link gets stuck when it doesn't hold a memory item, it will release the pointer to the link management object and stop collecting data after it is restored.

6. A collection item cache management system for database behavior load retrieval, characterized in that, This includes a connection registration queue, a connection processing queue, a serialization and disk write thread, and a central management system for load balancing. The system implements the collection item cache management method for database behavior load collection as described in any one of claims 1 to 5.

7. A collection item cache management device for database behavior load collection, characterized in that, include: At least one memory and at least one processor; The at least one memory is used to store a machine-readable program; The at least one processor is configured to invoke the machine-readable program to execute the method according to any one of claims 1 to 5.

8. A computer-readable medium, characterized in that, The computer-readable medium stores computer instructions that, when executed by a processor, cause the processor to perform the method described in any one of claims 1 to 5.

Citation Information

Patent Citations

  • Internet-of-things-based data acquisition system and data compression method based on the same

    CN107390650A

  • Index backfilter operator parallel method and module based on kv

    CN115756337A