Method and device for optimizing read-write performance of database, computer equipment and storage medium
By replacing ordinary variables in the database and replacing the LwLock mechanism with atomic read and write operations, the non-atomic problem of WAL log writing location recording in a multi-threaded environment is solved, and efficient database read and write performance is achieved, avoiding lock competition and CPU cache failure.
Patent Information
- Application Number
- CN202510631657.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-16
- Publication Date
- 2025-06-13
- Estimated Expiration
- 2045-05-16
AI Technical Summary
In an environment of multi-threaded or multi-process concurrent execution, the read and write operation of WAL log write position record variables faces non-atomic problems, resulting in data inconsistency and seriously threatening the stable operation of the system. The traditional LwLock mechanism triggers lock competition, CPU cache failure and process scheduling overhead in high concurrency scenarios, resulting in performance bottlenecks.
Atomic variables are used instead of ordinary variables, atomic read operations are used instead of LwLock read protection operations, and atomic write operations are used instead of LwLock write protection operations, so as to achieve lock-free WAL log write position record synchronization.
Through lock-free operation of atomic variables, lock competition and CPU cache failure are avoided, time and resources consumed by threads or processes during waiting for lock release are reduced, the overall read and write performance of the database is significantly improved, and the performance overhead caused by lock competition is reduced.
Smart Images

Figure CN120144601A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of databases, and more specifically, to a method, device, computer device, and storage medium for optimizing the read and write performance of a database. Background Art
[0002] In key business scenarios such as record storage in the financial transaction and medical and health fields, the data persistence and stability of the database system are crucial. As a core technology to ensure data consistency and system crash recovery ability, the correctness and efficiency of the WAL log mechanism's log disk flushing operation directly affect the overall performance and reliability of the database system. During the process of writing WAL logs, accurately recording the current log writing position is the basis for ensuring data integrity and system recovery consistency.
[0003] However, in an environment where multiple threads or processes execute concurrently, the read and write operations on the variable recording the WAL log writing position face the problem of non-atomicity. Due to the lack of an effective synchronization mechanism, a thread may read the intermediate state value when another thread is modifying the variable, thus triggering data inconsistency errors such as log record misalignment and data recovery failure, seriously threatening the stable operation of the system.
[0004] To solve the above problems, the prior art generally uses LwLock (lightweight lock) as a synchronization primitive to protect the access to the WAL log writing position. LwLock ensures data consistency by restricting only one thread or process to modify the position record at the same time. However, in a high-concurrency writing scenario, the LwLock mechanism exposes significant performance bottlenecks, which are specifically manifested as follows: Performance bottleneck caused by lock contention: As the number of concurrent threads or processes increases, the situation where multiple execution units compete for the WAL insertion lock simultaneously becomes more frequent, resulting in a significant extension of the lock waiting time. This not only reduces the system throughput but also extends the average response time of transactions, affecting the user experience.
[0005] CPU cache invalidation problem: The frequent acquisition and release operations of LwLock will break the principle of locality of the CPU cache, resulting in a decrease in the cache hit rate. Since different threads or processes may access different memory regions after acquiring the lock, the CPU cache needs to frequently load data from the main memory, further exacerbating the performance loss.
[0006] Process scheduling overhead: The use of LwLock introduces additional thread or process scheduling overhead. In a high-load scenario, the operating system needs to spend more time on lock acquisition, release, and thread switching, which significantly increases the system management burden and reduces the overall execution efficiency.
[0007] Especially when dealing with a large number of concurrent transactions, WAL insertion locks become a key factor restricting system scalability and response speed. With the continuous expansion of business scale and the sharp increase in user access, the traditional LwLock mechanism can no longer meet the requirements of modern database systems for high performance and high reliability.
[0008] Therefore, how to design an efficient and low-latency WAL log write position record synchronization mechanism to reduce lock contention, reduce CPU cache failure, and optimize process scheduling overhead has become a technical problem that needs to be solved urgently in the current database system field. Summary of the invention
[0009] The purpose of the present invention is to overcome the defects of the prior art and provide a method, device, computer equipment and storage medium for optimizing database read and write performance.
[0010] To achieve the above object, the present invention adopts the following technical solutions: Methods for optimizing database read and write performance include: Set to use atomic variables instead of ordinary variables, set to use atomic read operations instead of LwLock read protection operations, and set to use atomic write operations instead of LwLock write protection operations to obtain the setting content; The database is initialized according to the setting content to obtain an atomic variable database.
[0011] A further technical solution is: the setting uses atomic variables to replace ordinary variables, including: Declare atomic variables used to record the progress of WAL log insertion operations; Use the atomic variable initialization operation to assign the value of the variable InsertingAt.
[0012] The further technical solution is: the setting uses atomic read operation to replace LwLock read protection operation, including: Use the read operation of the atomic variable to read the value of the current progress variable recorded in the WAL log in the shared memory.
[0013] The further technical solution is: the setting uses atomic write operation to replace LwLock write protection operation, including: Use the write operation of the atomic variable to write the value of the current insertion progress variable of the locally recorded WAL log to the shared memory.
[0014] Its further technical solution is: after the database is initialized according to the setting content to obtain the atomic variable database, it also includes: The atomic variable database is backed up to construct backup data.
[0015] A further technical solution thereof is: after backing up the atomic variable database to construct backup data, it further includes: Restoring the database according to the backup data to obtain a test set.
[0016] A further technical solution thereof is: after restoring the database according to the backup data to obtain a test set, it further includes: Performing read and write tests on the test set.
[0017] The present invention also provides a device for optimizing the read and write performance of a database, including: A setting unit for setting to use atomic variables to replace ordinary variables, setting to use atomic read operations to replace LwLock read protection operations, and setting to use atomic write operations to replace LwLock write protection operations to obtain set content; An initialization unit for initializing the database according to the set content to obtain an atomic variable database.
[0018] The present invention also provides a computer device, the computer device includes a memory and a processor, a computer program is stored on the memory, and when the processor executes the computer program, the above method is implemented.
[0019] The present invention also provides a storage medium, the storage medium stores a computer program, and when the computer program is executed by a processor, the above method is implemented.
[0020] The beneficial effects of the present invention compared with the prior art are: by using atomic variables to initialize the database to obtain an atomic variable database, since the operations of atomic variables are lock-free, the lock competition problem brought by the traditional lock mechanism is fundamentally avoided. In a multi-core processor environment, the lock-free feature enables different cores to independently and efficiently process data without waiting for the release of the lock, thereby making full use of the parallel computing power of the multi-core processor and realizing the efficient execution of database read and write operations on the multi-core processor, significantly improving the overall read and write performance of the database; in addition, in a high-concurrency scenario of the traditional lock mechanism, multiple threads or processes competing for the lock at the same time will lead to an increase in lock waiting time and a decrease in system throughput, thereby generating a large amount of performance overhead. The present invention avoids lock competition through the lock-free operation of atomic variables, reduces the time and resources consumed by threads or processes during the waiting for the lock to be released, and significantly reduces the performance overhead caused by lock competition.
[0021] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. Description of the Drawings
[0022] To more clearly illustrate the technical solutions of the embodiments of the present invention, the following will briefly introduce the accompanying drawings required for the description of the embodiments. Obviously, the accompanying drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can also be obtained based on these drawings.
[0023] Figure 1 Schematic diagram of the application scenario of the method for optimizing database read and write performance provided by the embodiment of the present invention; Figure 2 Flow chart of the method for optimizing database read and write performance provided by the embodiment of the present invention; Figure 3 Schematic block diagram of the device for optimizing database read and write performance provided by the embodiment of the present invention; Figure 4 Schematic block diagram of the computer device provided by the embodiment of the present invention. Detailed implementation manners
[0024] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts fall within the scope of protection of the present invention.
[0025] It should be understood that when used in this specification and the appended claims, the terms "comprises" and "comprising" indicate the presence of the described features, wholes, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or their combinations.
[0026] It should also be understood that the terms used in this specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention. As used in this specification of the present invention and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an", and "the" are intended to include the plural forms.
[0027] It should be further understood that the term "and / or" used in this specification of the present invention and the appended claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes these combinations.
[0028] Please refer to Figure 1 and Figure 2 , Figure 1 Schematic diagram of the application scenario of the method for optimizing database read and write performance provided by the embodiment of the present invention. Figure 2Schematic flowchart of the method for optimizing database read and write performance provided by an embodiment of the present invention. The method for optimizing database read and write performance is applied to a server that interacts with a terminal. By making full use of the parallel computing power of a multi-core processor, efficient execution of database read and write operations on the multi-core processor is achieved, significantly improving the overall read and write performance of the database. In this method, first, an atomic variable database is obtained by initializing the database with atomic variables. Since the operations of atomic variables are lock-free, the lock contention problem caused by the traditional lock mechanism is fundamentally avoided. In a multi-core processor environment, the lock-free feature allows different cores to independently and efficiently process data without waiting for the release of the lock, thus making full use of the parallel computing power of the multi-core processor and achieving efficient execution of database read and write operations on the multi-core processor, significantly improving the overall read and write performance of the database. Additionally, in a high-concurrency scenario, when multiple threads or processes compete for the lock simultaneously in the traditional lock mechanism, the lock waiting time increases and the system throughput decreases, resulting in a large amount of performance overhead. The present invention avoids lock contention through the lock-free operation of atomic variables, reduces the time and resources consumed by threads or processes during the waiting for the lock release, and significantly reduces the performance overhead caused by lock contention.
[0029] Figure 2 is a schematic flowchart of the method for optimizing database read and write performance provided by an embodiment of the present invention. As Figure 2 shown, the method includes the following steps S110 to S120.
[0030] S110. Set to use atomic variables to replace ordinary variables, set to use atomic read operations to replace LwLock read protection operations, and set to use atomic write operations to replace LwLock write protection operations to obtain the set content; As computers evolve from single-core processors to multi-core processors, traditional synchronization mechanisms (such as LwLock locks) are gradually showing performance bottlenecks, especially in high-concurrency scenarios. To improve system performance and scalability, developers have started exploring lock-free programming and non-blocking synchronization techniques. As a result, modern processors (such as x86, ARM, etc.) and operating systems provide a variety of atomic operation instructions. Hardware instructions provide underlying support for atomic operations, making the execution speed of atomic operations very fast, much higher than software-implemented synchronization mechanisms (such as LwLock locks). Atomic variables are different from ordinary variables. They ensure the atomicity of operations, that is, operations cannot be interrupted by other threads during execution. Whether it is a read or modify operation, it is completed as an indivisible whole, thus ensuring data consistency and correctness, and can be efficiently executed on multi-core processors, avoiding lock contention and CPU cache invalidation problems, thereby significantly reducing lock contention and performance overhead.
[0031] S120. Initialize the database according to the set content to obtain an atomic variable database.
[0032] In this embodiment, select an appropriate atomic variable type according to the data type required to be recorded for database initialization. For example, if it is necessary to record the initial state identifier of the database (such as different states represented by integer types), std::atomic can be selected. <int>; If you need to record the initialization timestamp of the database (which can be represented by a 64-bit integer), then choose std::atomic<int64_t>. In the database initialization code, define and initialize the atomic variable. For example, use std::atomic <int>Define an atomic variable `db_init_status{0}` to represent the database initialization status. The initial value is 0, indicating that the database is not initialized.
[0033] At the beginning of the database initialization function, read its current value through the `load()` method of the atomic variable to determine whether the database has been initialized. For example, `if (db_init_status.load() != 0) { / * The database has been initialized, execute the corresponding processing logic * / }`. If the database is not initialized, perform the database initialization operations, including creating data tables, loading initial data, etc. After the initialization operations are completed, use the `store()` method of the atomic variable to update its value to the status indicating that it has been initialized. For example, `db_init_status.store(1)`; where 1 indicates that the database has been successfully initialized.
[0034] During the initialization process, if an error occurs (such as a database connection failure, a data loading error, etc.), depending on the error type and severity, you can choose to roll back the executed initialization operations and restore the value of the atomic variable to the initial state (such as 0), or set the atomic variable to the status indicating initialization failure (such as -1). During the initialization process, record detailed log information, including the initialization start time, end time, executed operation steps, encountered errors and handling results, etc., for subsequent problem troubleshooting and performance analysis.
[0035] That is to say, through the check mechanism of the atomic variable, ensure that the database is initialized only once. In a high-concurrency environment, multiple threads or processes may attempt to initialize the database simultaneously. The atomic operations of the atomic variable can ensure that only one thread or process can successfully update the value of the atomic variable from the initial state to the initialized state. Other threads or processes will find that the database has been initialized when checking the atomic variable, thus avoiding repeated initialization operations and ensuring the consistency of the database state. If an error occurs during the initialization process, by restoring the atomic variable to the initial state or setting it to the initialization failure state, it can prevent the database from being in a partially initialized state. Other threads or processes can take corresponding measures when detecting that the database has not been successfully initialized, such as retrying the initialization or reporting an error. In addition, the operations of the atomic variable are lock-free. Compared with traditional lock mechanisms, it avoids lock contention and the waiting time of threads or processes. In a multi-core processor environment, multiple threads or processes can execute the relevant operations for database initialization simultaneously without waiting for the lock to be released, thus making full use of the parallel computing power of multi-core processors and improving the performance of database initialization. Since lock-free operations reduce the waiting time of threads or processes and lower the scheduling frequency of threads or processes, the overhead of context switching is reduced, further improving the overall performance of the system.
[0036] More specifically, determine the atomic variable type and replacement strategy: Analyze the characteristics of ordinary variables: Sort out the key ordinary variables involved in the database initialization process, such as the flag bit (e.g., is_initialized) used to identify the database initialization status, the variable for recording the initialization timestamp, the variable for counting the initialization steps, etc.; Select the appropriate atomic variable: According to the data type of the ordinary variable, select the corresponding atomic variable type. If the ordinary variable is of integer type, std::atomic can be selected <int>(C++); if it is a boolean type, then select std::atomic <bool>For example, replace the original bool is_initialized with std::atomic <bool>is_initialized。
[0037] Modify the database initialization code: Replace the declaration of ordinary variables: In the code, replace the declaration of ordinary variables with the declaration of atomic variables. For example, change bool is_initialized = false; to std::atomic <bool>is_initialized{false}; Adjust the usage of variables: Read operation: Replace the direct read operation of ordinary variables with a call to the load() method of atomic variables. For example, change if (is_initialized); to if (is_initialized.load()); Write operation: Replace the direct assignment operation of ordinary variables with a call to the store() method of atomic variables. For example, change is_initialized = true; to is_initialized.store(true). For some simple atomic operations, such as atomic increment and decrement, etc., the operation methods provided by atomic variables can be directly used, such as fetch_add(), fetch_sub(), etc.
[0038] Design the initialization process based on atomic variables: Initialization status check: At the beginning of the database initialization function, use the load() method of atomic variables to check whether the database has been initialized. If it has been initialized (for example, is_initialized.load() == true), then decide whether to skip initialization, re-initialize, or throw an exception according to specific requirements; Execute the initialization operation: If the database is not initialized, execute the initialization operation of the database according to the predetermined initialization steps, such as creating data tables, loading initial data, setting system parameters, etc. In each initialization step, atomic variables can be used to record the execution status or progress of the steps; Update the initialization status: After the initialization operation is completed, use the store() method of atomic variables to update the initialization status of the database to initialized. For example, is_initialized.store(true).
[0039] That is to say, in a multi-threaded or multi-process environment, multiple threads or processes may simultaneously attempt to initialize the database. The atomic operations of atomic variables can ensure that only one thread or process can successfully update the initialization status of the database, avoiding data conflicts and inconsistencies caused by multiple threads or processes simultaneously performing initialization operations. In addition, the operations of atomic variables are atomic, and even in the case of system failures or abnormal interruptions, it can ensure that the atomic operations that have been executed will not be lost. For example, if the system crashes during initialization, after restarting, it can be judged whether the database has been partially initialized through the status of atomic variables, and corresponding recovery measures can be taken to ensure data integrity.
[0040] For example: in the financial field, atomic variables can be used to set the account status identifier and the transaction serial number. Among them, in a financial trading system, an atomic variable is set for each account to identify the account status, such as std::atomic <int>account_status. The initial value is set to 0 for inactive status, 1 for normal activation status, 2 for frozen status, etc. Use atomic variables to generate unique transaction serial numbers, such as std::atomic<long long> transaction_id. Each time a new transaction occurs, the new transaction serial number is obtained through an atomic increment operation (such as transaction_id.fetch_add(1)).
[0041] During database initialization, an account table is created based on the atomic variable settings. The table contains fields such as account ID, account status (corresponding to the storage method of the atomic variable account_status), and balance. Then a transaction record table is created, using the atomic variable transaction_id as the data source for the transaction serial number field, and initializing other related fields such as transaction time, transaction amount, and transaction type.
[0042] In account opening, account closing, freezing, and unfreezing operations, the load() and store() methods of atomic variables are used to read and update the account status. For example, when freezing an account, the value of account_status is updated to 2. When making a transaction, first obtain the current transaction_id as the transaction serial number, then execute the transaction logic, and finally insert the transaction record into the transaction record table.
[0043] That is to say, in a financial trading system, multiple threads may operate on account status or transaction serial numbers at the same time in a high-concurrency environment. The atomic operation of atomic variables can ensure the mutual exclusion of these operations and avoid data inconsistency, such as multiple threads obtaining the same transaction serial number at the same time or modifying the account status at the same time, resulting in state confusion. The operation of atomic variables is atomic, and even in the event of a system failure or abnormal interruption, it can ensure that the atomic operations that have been executed will not be lost, ensuring the integrity of the account status and transaction serial number. In addition, the traditional lock mechanism will cause serious lock competition problems in high-concurrency scenarios, reducing system performance. The lock-free operation of atomic variables can avoid lock competition, improve the system's concurrent processing capabilities, and enable the financial trading system to quickly respond to a large number of transaction requests. The operation speed of atomic variables is faster than the traditional lock mechanism, reducing the time the thread waits for the lock, thereby reducing the delay in transaction processing and improving the real-time performance of the system.
[0044] In addition to the above financial business scenarios, this technology is also applicable to systems in medical and health care business scenarios. For example, in the field of medical health, atomic variables can be used to set the patient's medical record status and the patient's unique identifier. The patient's medical record status sets an atomic variable for each patient's medical record to identify the medical record status, such as std::atomic <int>medical_record_status. The initial value is set to 0 indicating incomplete, 1 indicating completed, 2 indicating reviewed, etc. The patient unique identifier uses an atomic variable to generate the patient's unique identifier, such as std::atomic<long long> patient_id. Each time a new patient registers, a new patient unique identifier is obtained through an atomic increment operation.
[0045] During the database initialization process, a patient information table is created according to the settings of the atomic variable. The table contains fields such as patient ID (corresponding to the storage method of the atomic variable patient_id), name, gender, age, etc. Then a medical record table is created, using the atomic variable medical_record_status to identify the medical record status, and other related fields are initialized, such as medical record content, creation time, modification time, etc. When a new patient registers, the current patient_id is obtained as the patient unique identifier, and the patient information is inserted into the patient information table, and at the same time, medical_record_status is initialized to 0. When a doctor creates, modifies, or reviews a medical record, the load() and store() methods of the atomic variable are used to read and update the medical record status. For example, after the doctor completes filling out the medical record, the value of medical_record_status is updated to 1.
[0046] That is to say, in the healthcare system, multiple doctors may operate on the medical records of the same patient simultaneously. The atomic operations of the atomic variable can ensure the mutual exclusion of these operations and avoid data conflicts, such as multiple doctors modifying the medical record content simultaneously, resulting in data chaos. The operations of the atomic variable are atomic, which can ensure the integrity of the medical record status and the patient unique identifier, and avoid data loss or damage caused by system failures or abnormal interruptions. In addition, the lock-free operation of the atomic variable can reduce lock contention and improve the concurrent processing ability of the system, enabling the healthcare system to handle the medical record operations of multiple patients simultaneously and improving the efficiency of medical services. The operation speed of the atomic variable is fast, reducing the waiting time of doctors for system responses, enabling doctors to complete medical record operations faster, and improving the quality of medical services. In addition, using atomic variables to manage the medical record status and patient unique identifier makes the system management process more concise and efficient. Hospital administrators can more conveniently query and count the medical record information and registration status of patients. The use of atomic variables reduces the complexity and maintenance difficulty of the code, reduces the possibility of system failures, and thus reduces the system maintenance cost.
[0047] First, sort out the ordinary variables used in the database system, such as the variable connection_count for recording the number of database connections, the variable transaction_status representing the database transaction status, etc. Clearly define the data types of these variables (such as integers, booleans, etc.), their roles in the system, and the update frequencies. Then, select the corresponding atomic variable types according to the data types of the ordinary variables. For example, for the integer-type connection_count, std::atomic can be selected <int>(C++); for the boolean type transaction_status, select std::atomic <bool>. In the code, replace the declaration of ordinary variables with the declaration of atomic variables. For example, change int connection_count = 0; to std::atomic <int>connection_count{0}.
[0048] Read operation: Replace the direct read operation of ordinary variables with a call to the load() method of atomic variables. For example, change int count = connection_count; to int count = connection_count.load().
[0049] Write operation: Replace the direct assignment operation of ordinary variables with a call to the store() method of atomic variables. For example, change connection_count++; to connection_count.fetch_add(1); (fetch_add() is an atomic increment operation, equivalent to reading first, adding one, and then writing back, and ensuring atomicity).
[0050] Set to use atomic read operations instead of LwLock read protection operations: In a database system, LwLock (Lightweight Lock) is often used to protect concurrent access to shared data during reading. Locate the code segment that uses LwLock for read protection. For example, when reading database configuration parameters, use LwLock to ensure that only one thread can read the parameter, avoiding data inconsistency caused by other threads reading simultaneously. According to the data type of the protected data, select the appropriate atomic read operation. For example, for shared data of integer type, the load() method of atomic variables can be used; for shared data of custom structure type, if each member in the structure can be represented by atomic variables (or the whole can be guaranteed atomic reading through other means), a similar method can also be adopted. Replace the read protection code: Replace the read protection code using LwLock with atomic read operations.
[0051] Set to use atomic write operations instead of LwLock write protection operations: Find the code segments protected by LwLock for writing. For example, when updating database statistics, use LwLock to ensure that only one thread can write to the statistics, avoiding data errors caused by multiple threads writing simultaneously. Select appropriate atomic write operations according to the data type of the protected data. For example, for shared data of integer type, you can use the store() method of atomic variables or operations such as fetch_add(), fetch_sub(); for complex data structures, if you need to update the entire structure atomically, you can consider using the compare_exchange_weak() or compare_exchange_strong() methods of std::atomic for lock-free updates. Replace the write-protected code: Replace the write-protected code using LwLock with atomic write operations.
[0052] That is to say, the atomic operations of atomic variables can ensure that in a multi-threaded or multi-process environment, read and write operations on shared data will not conflict. For example, when multiple threads read or write the same atomic variable simultaneously, there will be no data inconsistency, avoiding problems such as deadlocks and livelocks that may occur when using LwLock. In addition, LwLock causes serious lock contention problems in high-concurrency scenarios, reducing system performance. The lock-free operations of atomic variables can avoid lock contention and improve the system's concurrent processing ability. Multiple threads or processes can simultaneously execute read and write operations on shared data without waiting for the lock to be released, thus making full use of system resources and improving the overall performance of the database system. The operation speed of atomic variables is faster than traditional lock mechanisms, reducing the waiting time of threads or processes for locks, and thus reducing the latency of database operations. For example, when reading database configuration parameters, using atomic read operations can immediately obtain the parameter value without waiting for the acquisition and release of LwLock, improving the system's response speed.
[0053] For example: In the financial field, it is set to use atomic variables to replace ordinary variables, including account balance variables and transaction count variables.
[0054] Account balance variable: In a financial trading system, the account balance is a key variable. Traditional implementations may use ordinary integer variables to store the account balance, such as int accountBalance = 1000. Now replace it with the atomic variable std::atomic <int>accountBalance{1000}。
[0055] Transaction count variable: The transaction count variable is used to record the number of transactions for each account. For example, int transactionCount = 0; is changed to std::atomic <int>transactionCount{0}.
[0056] Setting the use of atomic read operations instead of LwLock read protection operations can refer to reading account information: when displaying user account information, it is necessary to read the account balance and transaction count.
[0057] Setting the use of atomic write operations instead of LwLock write protection operations can refer to processing deposit transactions: when a user performs a deposit operation, the account balance and transaction count need to be updated.
[0058] That is to say, in a high-concurrency financial transaction scenario, multiple threads may read and write account balances and transaction counts at the same time. The atomic operation of atomic variables can ensure that these operations do not interfere with each other, avoiding data inconsistency problems. For example, it will not happen that two threads read the same account balance at the same time and then both perform deposit operations, resulting in an incorrect final balance. Atomic operations ensure data integrity, and even in the event of a system failure or abnormal interruption, the atomic operations that have been executed will not be lost. This is crucial for financial transaction systems because every transaction involves the security and accuracy of funds. In addition, LwLock will cause serious lock contention in a high-concurrency environment, reducing system performance. The lock-free operation of atomic variables can avoid this contention and improve the concurrent processing capability of the system. For example, when processing a large number of concurrent deposit transactions, the use of atomic variables can significantly reduce the time threads wait for locks and increase the speed of transaction processing. The speed of atomic read and write operations is faster than traditional lock mechanisms, reducing the time users wait for transaction processing and improving user experience.
[0059] In addition to the above financial business scenarios, this technology is also applicable to systems in medical and health care business scenarios. For example, in the field of medical health, atomic variables are set to replace ordinary variables, including patient vital signs data and medical equipment status variables.
[0060] Patient vital signs data: In medical monitoring systems, patients' vital signs data such as heart rate and blood pressure need to be updated and read in real time. Traditional implementations may use ordinary floating-point variables to store this data, such as floatheartRate = 70.0; now replace it with an atomic variable std::atomic <float>heartRate{70.0}。
[0061] Medical device status variable: used to record the operating status of a medical device, such as int deviceStatus = 0; (0 indicates normal, 1 indicates a fault), changed to std::atomic <int>deviceStatus{0}。
[0062] Setting to use atomic read operations instead of LwLock read protection operations can refer to real-time monitoring of patient data: medical staff need to view the vital sign data of patients in real time.
[0063] Setting to use atomic write operations instead of LwLock write protection operations can refer to updating patient data and device status: when the medical device collects new patient vital sign data or the device status changes, the corresponding variables need to be updated.
[0064] That is to say, in the field of medical and health technology, the real-time nature of data is crucial. The atomic operations of atomic variables can ensure the timely update and reading of data. Medical staff can obtain the latest vital sign data of patients in real time to make timely diagnosis and treatment decisions. Atomic operations avoid data errors caused by concurrent access and ensure the accuracy of patient data. For example, there will be no situation where data is overwritten or confused when multiple devices write patient data simultaneously. In addition, the lock contention of LwLock will cause the system response speed to slow down, especially in high-concurrency medical monitoring scenarios. The lock-free operation of atomic variables can reduce the time for threads to wait for locks, improve the system response speed, and enable medical staff to obtain patient data faster. Fast atomic read operations can support real-time monitoring of patient data, promptly detect abnormal conditions of patients, and gain precious time for medical treatment.
[0065] In one embodiment, the setting to use atomic variables instead of ordinary variables includes: Declaring an atomic variable for recording the progress of WAL log insertion operations; Assigning the value of the variable InsertingAt using the initialization operation of the atomic variable.
[0066] Specifically, declaring an atomic variable for recording the progress of WAL log insertion operations: In a database management system, WAL (Write-Ahead Logging) logs are used to record all modification operations on the database to ensure data consistency and durability. To record the position where the WAL log is written, an atomic variable can be declared to replace the traditional ordinary variable. Assuming the C++ language is used, std::atomic<uint64_t> defines an atomic variable InsertingAt of 64-bit unsigned integer type to record the position of WAL log insertion operations. The atomic type std::atomic provides atomic operations, ensuring that read and write operations on this variable are thread-safe in a multi-threaded environment.
[0067] Assign the value of variable InsertingAt using the initialization operation of the atomic variable: When the system is initialized or the WAL log write position needs to be reset, the initialization operation or assignment operation of the atomic variable can be used to set the value of InsertingAt. When declaring the atomic variable, it can be directly initialized. As shown above, InsertingAt is initialized to 0. During the operation of the system, if the WAL log write position needs to be reset, the store method of the atomic variable can be used for assignment. When performing the WAL log insertion operation, the value of InsertingAt needs to be read and updated. Since InsertingAt is an atomic variable, the atomic read and write operations provided by it can be used to ensure thread safety.
[0068] That is to say, in a multi-threaded environment, multiple threads may simultaneously read and write the WAL log write position. Using atomic variables can ensure that these operations are thread-safe and avoid errors caused by data races. For example, if atomic variables are not used, multiple threads may simultaneously read and write the value of InsertingAt, which may lead to data inconsistency and situations such as log record loss or overwriting. Traditional synchronization mechanisms, such as mutexes, require explicit locking and unlocking, increasing the complexity and overhead of the code. Atomic variables provide lock-free atomic operations, simplifying the synchronization mechanism, improving the readability and maintainability of the code. In addition, since atomic variables do not require the use of mutexes, the lock contention between threads can be reduced, improving the concurrent processing ability of the system. In a highly concurrent database system, a large number of WAL log insertion operations can be performed simultaneously without performance degradation due to lock contention. Atomic operations are faster than traditional lock mechanisms, reducing the time for threads to wait for locks and decreasing the latency of WAL log insertion operations. This is very important for database systems with high real-time requirements, as it can improve the response speed and throughput of the system.
[0069] For example: In the financial field, WAL logs are used to record every transaction operation to ensure the integrity and recoverability of transaction data. For example, in a financial transaction backend system developed in C++, a std::atomic<uint64_t> can be used to declare an atomic variable InsertingAt to record the progress of WAL log insertion operations. When the system starts or the log record position needs to be reset, InsertingAt is initialized. It can be directly assigned a value in the system initialization function or assigned a value after calculation based on specific conditions. When a new transaction operation needs to be recorded in the WAL log, first read the current value of InsertingAt as the starting position of the transaction log, then perform the log write operation, and finally update the value of InsertingAt.
[0070] That is to say, in a financial transaction system, multiple transactions may occur at the same time and need to be recorded in the WAL log at the same time. The use of atomic variables can ensure that the read and write operations of InsertingAt by multiple threads are thread-safe, avoiding log record errors caused by data competition, thereby ensuring the consistency and integrity of transaction data. Atomic operations ensure that the update of log record positions is atomic, and there will be no situation where some threads read the wrong position value, resulting in log record loss or overwriting. In addition, the use of atomic variables can avoid deadlock and livelock problems caused by improper lock management, ensuring that the system can run stably in a multi-threaded environment. In a financial transaction system, the stability of the system is crucial, and any failure may lead to serious economic losses. Since the WAL log records complete transaction operations, the use of atomic variables ensures the accuracy of log records, allowing for faster and more accurate fault recovery after system failures, reducing data loss and business interruption time.
[0071] In addition to the above financial business scenarios, this technology is also applicable to systems in medical and health care business scenarios. For example, in the field of medical health, WAL logs are used to record patients' medical data modification operations, such as medical record updates, examination result entry, etc. For example, in a medical health information system developed in Java, you can use the AtomicLong class to declare an atomic variable InsertingAt. When the system is initialized, InsertingAt is initialized. The log record position when the system was last shut down can be read from the database, or initialized according to the system configuration. When there is a medical data modification operation, use InsertingAt to record the log insertion position.
[0072] In other words, atomic variables ensure the correct update of the WAL log record position and ensure that the log record order of medical data modification operations is consistent with the actual order of occurrence. This is very important for medical and health information systems, because accurate log records can help doctors trace the patient's medical history and make correct diagnosis and treatment decisions. Since the WAL log records the detailed information of all medical data modification operations and the use of atomic variables ensures the integrity of the log records, any illegal tampering of medical data can be discovered and tracked in a timely manner. In addition, the medical and health information system needs to process a large number of patient data modification requests at the same time. The use of atomic variables can improve the system's concurrent processing capabilities, reduce thread waiting time, and enable the system to respond to patient needs more quickly. The efficient operation of atomic variables can reduce the overhead of log management and improve the overall performance of the system. For example, during log backup and recovery, log records can be located and processed more quickly.
[0073] In one embodiment, the setting uses an atomic read operation to replace the LwLock read protection operation, including: Use the read operation of the atomic variable to read the value of the variable that records the current progress of the WAL log in the shared memory.
[0074] Specifically, assume that this technical feature is implemented in a database management system that uses shared memory to store the variable of the current progress of the WAL log, and the original system uses LwLock for read protection operations. In a C language environment, atomic types provided by the stdatomic.h header file can be used. For example, declare an atomic variable atomic_uint_least64_t current_progress to record the current progress of the WAL log. In the initialization stage, initialize this atomic variable to a reasonable value, such as loading the previous WAL log progress from persistent storage.
[0075] That is to say, after using the atomic read operation, there is no need to write complex lock acquisition and release code, which simplifies the code logic, reduces the complexity and maintenance cost of the code, and reduces potential errors caused by improper lock management. In addition, after using the atomic read operation, the system has stronger scalability. For example, when more shared variables need to be added, it is more convenient to use atomic variables to manage these variables without introducing a new lock mechanism.
[0076] For example: In the financial field, such as in a securities trading system, a large amount of transaction data needs to be recorded and processed in real time. The WAL log is used to ensure data consistency and recoverability. The variable of the current progress of the WAL log recorded in the shared memory reflects the latest position of the log record, and other modules (such as the data persistence module, the transaction analysis module) need to frequently read this variable to determine the log processing status.
[0077] In the shared memory area of the financial trading system, define an atomic variable atomic_uint_least64_t wal_progress to record the current progress of the WAL log. When the system starts, load the previous WAL log progress value from persistent storage (such as a disk file) and initialize it into the atomic variable using the atomic_store function. During the transaction processing, whenever a new transaction record is written to the WAL log, use the atomic_fetch_add atomic operation to update the current progress of the WAL log.
[0078] That is to say, the financial trading system usually needs to process a large number of concurrent trading requests. The LwLock read protection operation causes threads to frequently acquire and release locks, increasing the system overhead. After using the atomic read operation, the lock mechanism is not required, reducing the thread waiting time and improving the system throughput. The atomic read operation is faster than the LwLock read protection operation, can obtain the current progress of the WAL log faster, reduces the latency of transaction processing, and improves the real-time performance of the system.
[0079] In addition to the above financial business scenarios, this technology is also applicable to the systems in the medical and health care business scenarios. For example, in the field of medical and health, such as in a medical information management system, information such as patients' medical record data and examination reports needs to be recorded and backed up in real time. The WAL log is used to ensure the security and recoverability of medical data. The current progress variable of the WAL log in the shared memory is used to track the latest position of the log record so that other modules (such as the data backup module and the medical data analysis module) can obtain the latest log information in a timely manner.
[0080] In the shared memory area of the medical information management system, an atomic variable atomic_uint_least64_t medical_wal_progress is defined to record the current progress of the WAL log. When the system starts up, the last WAL log progress value is loaded from the database and initialized into the atomic variable using the atomic_store function. During the medical data processing, whenever a new medical data record is written to the WAL log, the atomic_fetch_add atomic operation is used to update the current progress of the WAL log.
[0081] That is to say, the medical information management system needs to process a large amount of medical data in real time. The atomic read operation reduces the lock overhead, enabling other modules to obtain the current progress of the WAL log faster, improving the system response speed, and ensuring that medical staff can obtain the latest information of patients in a timely manner. With the continuous development of medical informatization, the medical information management system needs to support more and more concurrent accesses. The high efficiency of the atomic read operation enables the system to better handle high-concurrency scenarios and improves the scalability of the system.
[0082] In one embodiment, the setting uses an atomic write operation to replace the LwLock write protection operation, including: Use the write operation of the atomic variable to write the value of the current insertion progress variable of the locally recorded WAL log into the shared memory.
[0083] Specifically, in a financial transaction system or a medical and health information management system, the WAL mechanism is used to ensure data consistency and recoverability. Each system node maintains a local variable recording the current insertion progress of the WAL log. When new log records are written, the progress value needs to be updated to the shared memory so that other nodes or modules can obtain the latest log progress in a timely manner. Define an atomic variable atomic_uint_least64_t wal_insert_progress in the shared memory area to store the current insertion progress of the WAL log. When the system starts, load the last WAL log insertion progress value from persistent storage (such as a disk file or a database) and initialize it into the atomic variable using the atomic_store function. In each system node, maintain a local variable local_insert_progress to record the WAL log insertion progress of the current node. When new log records are written, update this local variable. When it is necessary to write the locally recorded progress value to the shared memory, use the atomic write operation atomic_store to replace the LwLock write protection operation. A timer can be set to periodically call the update_shared_wal_progress function to write the local progress value to the shared memory. When the local progress value changes significantly, the update_shared_wal_progress function can also be called immediately for update. For example, after writing a large number of log records at one time, it can be judged whether the progress change exceeds a certain threshold. If so, the shared memory is updated immediately.
[0084] That is to say, in the fields of finance and medical and health technologies, using the atomic write operation to replace the LwLock write protection operation to write the value of the current insertion progress variable of the locally recorded WAL log to the shared memory can significantly improve the performance, reliability, and scalability of the system.
[0085] In one embodiment, after initializing the database according to the set content to obtain the atomic variable database, the following steps are further included: Back up the atomic variable database to build backup data.
[0086] Specifically, after the database initialization is completed, close the atomic variable database and back up the atomic variable database to build backup data.
[0087] In one embodiment, after backing up the atomic variable database to build backup data, the following steps are further included: Restore the database according to the backup data to obtain a test set.
[0088] Specifically, before each test, the database is restored using backup data to ensure that the same test set is used for each test.
[0089] That is to say, using the same test set for each test eliminates the problem of inconsistent test results caused by data differences. For example, in software functional testing, if the database data used for each test is different, it may cause some functions to work properly in some tests but fail in others, thus affecting the reliability of the test results. In addition, the same test set enables testers to more accurately evaluate the functions and performance of the software. Testers can focus on the defects and problems of the software itself without having to worry about the interference caused by data differences. Moreover, since the pre-restored test set is used before each test, testers do not need to spend a lot of time preparing test data. Testers can directly start the test, improving the test efficiency. When problems are found during the test, the problems can be easily reproduced and debugged. Because the test set is fixed, testers can run the same test cases multiple times to determine the root cause of the problem.
[0090] In one embodiment, after restoring the database according to the backup data to obtain the test set, it further includes: Pre-reading the test data into the cache.
[0091] Specifically, pre-reading the test data into the cache before read-write testing is beneficial for obtaining relatively stable test data.
[0092] That is to say, after pre-reading the test data into the cache, the test application directly obtains the data from the cache during the read-write test, avoiding data fluctuations caused by frequent access to the database. For example, in the case of high database load or concurrent access, the data in the database may change, resulting in unstable test results. The data in the cache is relatively stable after pre-reading, ensuring the consistency of the test data. In addition, the cache system usually has high availability and performance, which can reduce the impact of external factors such as network latency and database failures on the test data. Even when the database experiences a short-term failure, the test application can still obtain data from the cache, ensuring the continuity of the test. Moreover, the access speed of the cache is much faster than that of the database. Pre-reading the test data into the cache can significantly improve the data access speed of the test application. For example, for some frequently accessed data, the time to obtain data from the cache may be shortened by several orders of magnitude compared to obtaining data from the database, thus accelerating the test execution speed. By caching the data, the access frequency of the test application to the database is reduced, lowering the load on the database, which enables the database to process other business requests more efficiently and also improves the overall performance of the test environment.
[0093] In one embodiment, after restoring the database according to the backup data to obtain a test set, the method further includes: Performing read and write tests on the test set.
[0094] Specifically, through read and write tests, the performance of the database under different loads can be comprehensively evaluated, including response time, throughput, concurrent processing ability, etc. For example, the average response time and maximum response time of the database under 100 concurrent users can be determined to evaluate whether the database can meet the business requirements. During the test process, performance bottlenecks of the database can be detected in a timely manner, such as slow queries, missing indexes, lock contention, etc. By optimizing these bottlenecks, the performance of the database can be improved. In addition, under long-term and high-concurrency read and write tests, the stability of the database can be verified. Observe whether the database will crash, data loss, etc., to ensure that the database can run stably. Some potential problems may be found during the test process, such as memory leaks, resource exhaustion, etc. Solving these problems in a timely manner can improve the reliability and availability of the database.
[0095] In the above method for optimizing the read and write performance of the database, an atomic variable database is obtained by initializing the database with atomic variables. Since the operations of atomic variables are lock-free, the lock contention problem brought by the traditional lock mechanism is fundamentally avoided. In a multi-core processor environment, the lock-free feature enables different cores to independently and efficiently process data without waiting for the release of the lock, thus making full use of the parallel computing power of the multi-core processor and achieving efficient execution of database read and write operations on the multi-core processor, significantly improving the overall read and write performance of the database. In addition, in a high-concurrency scenario, when multiple threads or processes compete for the lock simultaneously in the traditional lock mechanism, the lock waiting time increases and the system throughput decreases, resulting in a large amount of performance overhead. The present invention avoids lock contention through the lock-free operation of atomic variables, reducing the time and resources consumed by threads or processes during the waiting for the lock release, and significantly reducing the performance overhead caused by lock contention. In addition, the use of the traditional lock mechanism will introduce additional thread or process scheduling overhead. Especially in a high-load scenario, threads or processes frequently acquire and release the lock, resulting in the operating system spending more time on thread switching and scheduling. The lock-free design of the present invention avoids this problem, reduces thread or process scheduling overhead, enables the system to more efficiently utilize CPU resources, and improves the overall performance of the system. In addition, when the traditional lock mechanism processes database read and write operations, since the acquisition and release of the lock take time and will cause threads or processes to wait for a long time in the case of intense lock contention, the response speed of the system is reduced. The present invention adopts a lock-free design, enabling database read and write operations to be executed quickly without waiting for the release of the lock, greatly shortening the average response time of transactions, improving the response speed of the system, and better meeting the user's requirement for fast response of the database.
[0096] Figure 3 It is a schematic block diagram of a device 300 for optimizing the read and write performance of a database provided by an embodiment of the present invention. As Figure 3 shown, corresponding to the above method for optimizing the read and write performance of a database, the present invention also provides a device 300 for optimizing the read and write performance of a database. The device 300 for optimizing the read and write performance of a database includes a unit for executing the above method for optimizing the read and write performance of a database, and this device can be configured in a server. Specifically, please refer to Figure 3 , the device 300 for optimizing the read and write performance of a database includes a setting unit 301 and an initialization unit 302.
[0097] The setting unit 301 is used to set to use atomic variables to replace ordinary variables, set to use atomic read operations to replace LwLock read protection operations, and set to use atomic write operations to replace LwLock write protection operations, so as to obtain the set content; The initialization unit 302 is used to initialize the database according to the set content to obtain an atomic variable database.
[0098] In one embodiment, the setting unit 301 includes: A declaration subunit, which is used to declare an atomic variable for recording the progress of WAL log insertion operations; An initialization subunit, which is used to assign the value of the variable InsertingAt using the initialization operation of the atomic variable.
[0099] In one embodiment, the setting unit 301 includes: A first setting subunit, which is used to read the value of the variable recording the current progress of the WAL log in the shared memory using the read operation of the atomic variable.
[0100] In one embodiment, the setting unit 301 includes: A second setting subunit, which is used to write the value of the variable of the current insertion progress of the local-recorded WAL log into the shared memory using the write operation of the atomic variable.
[0101] In one embodiment, the device further includes: a backup unit, which is used to back up the atomic variable database to build backup data.
[0102] In one embodiment, the device further includes: a recovery unit, which is used to recover the database according to the backup data to obtain a test set.
[0103] In one embodiment, the device further includes: an execution unit, which is used to perform read and write tests on the test set.
[0104] It should be noted that those skilled in the art can clearly understand the specific implementation processes of the above-mentioned device 300 for optimizing database read and write performance and each unit. They can refer to the corresponding descriptions in the foregoing method embodiments. For the sake of convenience and conciseness of description, they will not be elaborated herein.
[0105] The above-mentioned device 300 for optimizing database read and write performance can be implemented in the form of a computer program, and this computer program can run on a computer device as shown in Figure 4 the following.
[0106] Please refer to Figure 4 , Figure 4 which is a schematic block diagram of a computer device provided by an embodiment of the present application. The computer device 500 may be a server. Among them, the server may be an independent server or a server cluster composed of multiple servers.
[0107] Referring to Figure 4 , the computer device 500 includes a processor 502, a memory, and a network interface 505 connected through a system bus 501. Among them, the memory may include a non-volatile storage medium 503 and an internal memory 504.
[0108] The non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions. When the program instructions are executed, the processor 502 can be made to execute a method for optimizing database read and write performance.
[0109] The processor 502 is used to provide computing and control capabilities to support the operation of the entire computer device 500.
[0110] The internal memory 504 provides an environment for the operation of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can be made to execute a method for optimizing database read and write performance.
[0111] The network interface 505 is used for network communication with other devices. Those skilled in the art can understand that Figure 4 the structure shown in is only a block diagram of some structures related to the solution of the present application, and does not constitute a limitation on the computer device 500 to which the solution of the present application is applied. The specific computer device 500 may include more or fewer components than those shown in the figure, or combine some components, or have different component arrangements.
[0112] Among them, the processor 502 is used to run the computer program 5032 stored in the memory to implement the following steps: Set to use atomic variables to replace ordinary variables, set to use atomic read operations to replace LwLock read protection operations, and set to use atomic write operations to replace LwLock write protection operations to obtain the set content; initialize the database according to the set content to obtain an atomic variable database.
[0113] It should be understood that in the embodiment of the present application, the processor 502 may be a central processing unit (CPU), and the processor 502 may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.
[0114] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program includes program instructions, and the computer program can be stored in a storage medium, and the storage medium is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the flow steps of the embodiments of the above methods.
[0115] Therefore, the present invention also provides a storage medium. The storage medium may be a computer-readable storage medium. The storage medium stores a computer program, and when the computer program is executed by a processor, the processor performs the following steps: Set to use atomic variables to replace ordinary variables, set to use atomic read operations to replace LwLock read protection operations, and set to use atomic write operations to replace LwLock write protection operations to obtain the set content; initialize the database according to the set content to obtain an atomic variable database.
[0116] The storage medium may be a USB flash drive, a mobile hard disk, a read-only memory (ROM), a magnetic disk, an optical disk, or other computer-readable storage media that can store program codes.
[0117] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.
[0118] In several embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of each unit is only a logical function division, and there can be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed.
[0119] The steps in the method of the embodiments of the present invention can be adjusted, combined, and deleted according to actual needs. The units in the device of the embodiments of the present invention can be combined, divided, and deleted according to actual needs. In addition, the functional units in each embodiment of the present invention can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit.
[0120] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in each embodiment of the present invention.
[0121] As described above, the above are only specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention can easily think of various equivalent modifications or substitutions, and these modifications or substitutions should be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention should be subject to the protection scope of the claims.< / int> < / float> < / int> < / int> < / int> < / bool> < / int> < / int> < / int> < / bool> < / bool> < / bool> < / int> < / int> < / int>
Claims
1. A method for optimizing database read and write performance, characterized in that: include: Set to use atomic variables instead of ordinary variables, set to use atomic read operations instead of LwLock read protection operations, and set to use atomic write operations instead of LwLock write protection operations to obtain the setting content; The database is initialized according to the setting content to obtain an atomic variable database.
2. The method for optimizing database read and write performance according to claim 1, characterized in that: The setting uses atomic variables instead of ordinary variables, including: Declare atomic variables used to record the progress of WAL log insertion operations; Use the atomic variable initialization operation to assign the value of the variable InsertingAt.
3. The method for optimizing database read and write performance according to claim 1, characterized in that: The setting uses atomic read operations instead of LwLock read protection operations, including: Use the read operation of the atomic variable to read the value of the current progress variable recorded in the WAL log in the shared memory.
4. The method for optimizing database read and write performance according to claim 1, characterized in that: The setting uses atomic write operations instead of LwLock write protection operations, including: Use the write operation of the atomic variable to write the value of the current insertion progress variable of the locally recorded WAL log to the shared memory.
5. The method for optimizing database read and write performance according to claim 1, characterized in that: After the database is initialized according to the setting content to obtain the atomic variable database, the method further includes: The atomic variable database is backed up to construct backup data.
6. The method for optimizing database read and write performance according to claim 5, characterized in that: After backing up the atomic variable database to construct backup data, the method further includes: The database is restored according to the backup data to obtain a test set.
7. The method for optimizing database read and write performance according to claim 6, characterized in that: After restoring the database according to the backup data to obtain the test set, the method further includes: Perform read and write tests on the test set.
8. A device for optimizing database read and write performance, characterized in that: include: A setting unit, used for setting to use atomic variables instead of ordinary variables, setting to use atomic read operations instead of LwLock read protection operations, and setting to use atomic write operations instead of LwLock write protection operations, so as to obtain setting contents; The initialization unit is used to initialize the database according to the setting content to obtain the atomic variable database.
9. A computer device, characterized in that: The computer device comprises a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.
10. A storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.
Citation Information
Patent Citations
Shared memory communication method and system based on atomic operation
CN115934377A
Methods and apparatus to perform atomic transactions in nonvolatile memory under hardware transactional memory
US20190004851A1
KR20200077297A
Cited By
Data reading method and device
CN120780239A