Method and device for optimizing database read-write performance, computer device and storage medium

Abstract

The application discloses a method and device for optimizing database read-write performance, computer equipment and a storage medium, and the method comprises the following steps: setting the use of an atomic variable to replace a normal variable, setting the use of an atomic read operation to replace an LwLock read protection operation, and setting the use of an atomic write operation to replace an LwLock write protection operation, so as to obtain setting content; initializing a database according to the setting content, so as to obtain an atomic variable database. Through the method of the application, in a multi-core processor environment, the lock-free characteristic enables different cores to independently and efficiently process data without waiting for the release of the lock, fully utilizes the parallel computing capability of the multi-core processor, realizes efficient execution of the database read-write operation on the multi-core processor, and significantly improves the overall read-write performance of the database. The scheme can be applied to the fields of financial technology business, medical care and other business fields.

Description

Technical Field

[0001] The present invention relates to the field of database technology, and more specifically to a method, device, computer equipment and storage medium for optimizing database read and write performance. Background Art

[0002] In critical business scenarios like financial transactions and healthcare record storage, database system data persistence and stability are crucial. As a core technology for ensuring data consistency and system crash recovery, the accuracy and efficiency of the WAL log flushing operation directly impacts the overall performance and reliability of the database system. During the WAL log writing process, accurately recording the current log write location is fundamental to ensuring data integrity and system recovery consistency.

[0003] However, in a multi-threaded or multi-process environment, read and write operations on variables recorded in the WAL log write location face non-atomicity. Due to the lack of an effective synchronization mechanism, one thread may read the intermediate state of the variable while another thread is modifying it, causing data inconsistency errors such as log record misalignment and data recovery failure, seriously threatening the stable operation of the system.

[0004] To address these issues, existing technologies commonly use LwLock (lightweight lock) as a synchronization primitive to protect access to the WAL log write location. LwLock ensures data consistency by limiting the ability of only one thread or process to modify the record at that location at a time. However, in high-concurrency write scenarios, the LwLock mechanism exposes significant performance bottlenecks, as shown below:

[0005] Performance bottlenecks caused by lock contention: As the number of concurrent threads or processes increases, multiple execution units increasingly compete for WAL insert locks, significantly increasing lock wait times. This not only reduces system throughput but also increases average transaction response times, impacting user experience.

[0006] CPU cache invalidation: Frequent acquisition and release of LwLocks disrupts the locality principle of the CPU cache, resulting in a decrease in cache hit rate. Because different threads or processes may access different memory areas after acquiring the lock, the CPU cache needs to frequently load data from main memory, further exacerbating performance losses.

[0007] Process scheduling overhead: LwLock introduces additional thread or process scheduling overhead. Under high load, the operating system needs to spend more time acquiring and releasing locks and switching threads, which significantly increases the system management burden and reduces overall execution efficiency.

[0008] Especially in processing a large number of concurrent transactions, the WAL insertion lock becomes a key factor restricting the system scalability and response speed. With the continuous expansion of business scale and the sharp increase of user access, the traditional LwLock mechanism has been difficult to meet the demand of modern database system for high performance and high reliability.

[0009] Therefore, how to design an efficient and low-delay WAL log write position record synchronization mechanism to reduce lock competition, reduce CPU cache invalidation and optimize process scheduling overhead has become a technical problem to be solved in the field of current database systems. SUMMARY

[0010] The present application aims to overcome the defects of the prior art and provide a method and device for optimizing database read-write performance, a computer device and a storage medium.

[0011] To achieve the above-mentioned purpose, the present application adopts the following technical solutions:

[0012] The method for optimizing database read-write performance comprises:

[0013] Setting an atomic variable instead of an ordinary variable, setting an atomic read operation instead of an LwLock read protection operation, and setting an atomic write operation instead of an LwLock write protection operation to obtain setting content;

[0014] Initializing the database according to the setting content to obtain an atomic variable database.

[0015] A further technical solution is that the setting an atomic variable instead of an ordinary variable comprises:

[0016] Declaring an atomic variable for recording the progress of the WAL log insertion operation;

[0017] Using the initialization operation of the atomic variable to assign a value to the variable InsertingAt.

[0018] A further technical solution is that the setting an atomic read operation instead of an LwLock read protection operation comprises:

[0019] Using the read operation of the atomic variable to read the value of the variable recording the current progress of the WAL log in the shared memory.

[0020] A further technical solution is that the setting an atomic write operation instead of an LwLock write protection operation comprises:

[0021] Using the write operation of the atomic variable to write the value of the locally recorded WAL log current insertion progress variable into the shared memory.

[0022] Further technical solutions are as follows: After the atomic variable database is initialized according to the setting content, the method further comprises:

[0023] The atomic variable database is backed up to build backup data.

[0024] After the atomic variable database is backed up to build backup data, the method further comprises:

[0025] The database is recovered according to the backup data to obtain a test set.

[0026] After the database is recovered according to the backup data to obtain a test set, the method further comprises:

[0027] Read-write testing is performed on the test set.

[0028] The application further provides an apparatus for optimizing database read-write performance, comprising:

[0029] A setting unit is configured to set that an atomic variable is used to replace a normal variable, an atomic read operation is used to replace an LwLock read protection operation, and an atomic write operation is used to replace an LwLock write protection operation, so as to obtain setting content.

[0030] An initialization unit is configured to initialize a database according to the setting content, so as to obtain an atomic variable database.

[0031] The application further provides a computer device, which comprises a memory and a processor, the memory stores a computer program, and the processor implements the above method when executing the computer program.

[0032] The application further provides a storage medium, which stores a computer program, and the computer program is executed by a processor to implement the above method.

[0033] Compared with the prior art, the present application has the beneficial effects that: by using the atomic variable to initialize the database to obtain the atomic variable database, since the operation of the atomic variable is lock-free, the lock competition problem caused by the traditional lock mechanism is fundamentally avoided, in the multi-core processor environment, the lock-free characteristic enables different cores to independently and efficiently process data without waiting for the release of the lock, thereby fully utilizing the parallel computing capability of the multi-core processor, realizing efficient execution of the database read-write operation on the multi-core processor, and significantly improving the overall read-write performance of the database; in addition, in the high concurrency scenario, the lock waiting time increases and the system throughput decreases due to the lock competition of multiple threads or processes at the same time, thereby generating a large amount of performance overhead, and the present application avoids the lock competition and reduces the time and resources consumed by the threads or processes in the process of waiting for the release of the lock, thereby significantly reducing the performance overhead caused by the lock competition.

[0034] The present application will be further described below in conjunction with the accompanying drawings and specific embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0035] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0036] Figure 1 The application scenario diagram of the method for optimizing the read-write performance of the database provided by the embodiment of the present application is shown.

[0037] Figure 2 The flowchart of the method for optimizing the read-write performance of the database provided by the embodiment of the present application is shown.

[0038] Figure 3 The schematic block diagram of the device for optimizing the read-write performance of the database provided by the embodiment of the present application is shown.

[0039] Figure 4 The schematic block diagram of the computer device provided by the embodiment of the present application is shown. DETAILED DESCRIPTION

[0040] The technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are some embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the protection scope of the present application.

[0041] It should be understood that the terms "comprises" and "comprising," when used in this specification and the following claims, indicate the presence of the described features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0042] It should also be understood that the terms used in the specification of the application herein are merely used for the purpose of describing particular embodiments and are not intended to limit the application. As used in the specification of the application and the following claims, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly indicates otherwise.

[0043] It should be further understood that the term "and / or" used in the specification of the application and the following claims means any combination of one or more of the associated listed items and all possible combinations thereof.

[0044] Please refer to Figure 1 and Figure 2 , Figure 1 The application scenario diagram of the method for optimizing the read-write performance of a database provided by the embodiments of the application. Figure 2 The schematic flowchart of the method for optimizing the read-write performance of a database provided by the embodiments of the application. The method for optimizing the read-write performance of a database is applied to a server, which performs data interaction with a terminal. By fully utilizing the parallel computing capability of a multi-core processor, the method realizes efficient execution of database read-write operations on the multi-core processor, and significantly improves the overall read-write performance of the database. In the method, first, an atomic variable database is obtained by initializing a database using an atomic variable. Since the operation of the atomic variable is lock-free, the lock contention problem caused by the traditional lock mechanism is fundamentally avoided. In the multi-core processor environment, the lock-free characteristic enables different cores to independently and efficiently process data without waiting for the release of the lock, thereby fully utilizing the parallel computing capability of the multi-core processor, realizing efficient execution of database read-write operations on the multi-core processor, and significantly improving the overall read-write performance of the database. In addition, in the high-concurrency scenario, the traditional lock mechanism causes multiple threads or processes to simultaneously compete for the lock, resulting in an increase in lock waiting time and a decrease in system throughput, thereby generating a large amount of performance overhead. The lock-free operation of the atomic variable avoids lock contention and reduces the time and resources consumed by threads or processes in the process of waiting for the release of the lock, thereby significantly reducing the performance overhead caused by lock contention.

[0045] Figure 2 The flowchart of the method for optimizing the read-write performance of a database provided by the embodiments of the application. As shown in Figure 2 , the method comprises the following steps S110 to S120.

[0046] S110, setting using an atomic variable to replace a normal variable, setting using an atomic read operation to replace an LwLock read protection operation, and setting using an atomic write operation to replace an LwLock write protection operation, to obtain a setting content;

[0047] With the development of computers from single processor to multi-processor and multi-core processor, the traditional synchronization mechanism (such as LwLock lock) gradually exposes performance bottleneck, especially in high concurrency scenarios. In order to improve the performance and scalability of the system, developers begin to explore lock-free programming (Lock-Free Programming) and non-blocking synchronization (Non-Blocking Synchronization) technology, therefore, modern processors (such as x86, ARM, etc.) and operating systems provide a variety of atomic operation instructions. Through hardware instructions, atomic operations are provided with underlying support, making the execution speed of atomic operations very fast, much higher than the software implemented synchronization mechanism (such as LwLock lock). Atomic variables are different from normal variables, which ensure the atomicity of operations, that is, the operation will not be interrupted by other threads in the execution process. Whether it is read or modify operation, it is completed as an indivisible whole, thereby ensuring the consistency and correctness of the data, and can be efficiently executed on multi-core processors, avoiding lock competition and CPU cache invalidation problems, thereby significantly reducing lock competition and performance overhead.

[0048] S120, initializing a database according to the setting content, to obtain an atomic variable database.

[0049] In this embodiment, according to the data type of the record required by the database initialization, a suitable atomic variable type is selected. For example, if the initial state identifier of the database needs to be recorded (such as an integer type representing different states), std::atomic <int>(in C++); if you need to record the initialization timestamp of the database (which can be represented using a 64-bit integer), choose std::atomic<int64_t>. In the database initialization code, define and initialize the atomic variable. For example, use std::atomic <int>db_init_status{0}; define an atomic variable representing the initialization status of the database, with an initial value of 0, indicating that it is not initialized.

[0050] At the beginning of the database initialization function, the current value of the atomic variable is read through the load() method 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 has not been initialized, perform the initialization operation, including creating data tables, loading initial data, etc. After the initialization operation is completed, the value of the atomic variable is updated to indicate that it has been initialized using the store() method. For example, db_init_status.store(1); where 1 indicates that the database has been successfully initialized.

[0051] During the initialization process, if an error occurs (such as a database connection failure, data loading error, etc.), depending on the error type and severity, the atomic variable value can be restored to the initial state (such as 0) or set to a state indicating initialization failure (such as -1) by rolling back the executed initialization operation. Detailed log information is recorded during the initialization process, including initialization start time, end time, executed operation steps, encountered errors, and processing results, etc., to facilitate subsequent problem troubleshooting and performance analysis.

[0052] That is, through the check mechanism of the atomic variable, it is ensured that the database is initialized only once. In a high-concurrency environment, multiple threads or processes may attempt to initialize the database simultaneously, and the atomic operation 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, thereby avoiding repeated initialization operations and ensuring the consistency of the database state. If an error occurs during initialization, the atomic variable can be restored to the initial state or set to the initialization failure state to prevent the database from being in a partially initialized state. Other threads or processes can take appropriate measures when detecting that the database has not been successfully initialized, such as reattempting initialization or reporting errors. In addition, the atomic variable operation is lock-free, which avoids lock contention and thread or process waiting time compared to traditional lock mechanisms. In a multi-core processor environment, multiple threads or processes can simultaneously perform related operations for database initialization without waiting for the release of the lock, thereby fully utilizing the parallel computing capabilities of multi-core processors and improving the performance of database initialization. Since lock-free operations reduce the waiting time of threads or processes and reduce the scheduling frequency of threads or processes, the overhead of context switching is reduced, further improving the overall performance of the system.

[0053] More specifically, determine the atomic variable type and the replacement strategy:

[0054] Analyze the common variable characteristics: tease out the key common variables involved in the database initialization process, such as flag bits used to identify the database initialization state (e.g., is_initialized), variables that record the initialization timestamp, variables that count the initialization steps, etc.

[0055] Select the appropriate atomic variable: based on the data type of the common variable, select the corresponding atomic variable type. For example, if the common variable is of integer type, std::atomic <int>(C++) ; if bool, select std::atomic <bool>For example, the original bool is_initialized is replaced with std::atomic <bool>is_initialized.

[0056] Modify database initialization code:

[0057] Replace ordinary variable declaration: In the code, replace the declaration of an ordinary variable with the declaration of an atomic variable. For example, change bool is_initialized = false; to std::atomic <bool>is_initialized{false};

[0058] Adjust the use of variables:

[0059] Read operation: Replace the direct read operation of ordinary variables with the load() method call of atomic variables. For example, change if (is_initialized); to if (is_initialized.load());

[0060] Write operations: Replace direct variable assignments with calls to the atomic variable's store() method. For example, replace "is_initialized = true;" with "is_initialized.store(true)." For simple atomic operations, such as atomic increments and decrements, you can directly use the atomic variable's methods, such as fetch_add() and fetch_sub().

[0061] Design initialization process based on atomic variables:

[0062] Initialization status check: At the beginning of the database initialization function, use the load() method of the atomic variable to check whether the database has been initialized. If it has been initialized (for example, is_initialized.load() == true), decide whether to skip initialization, reinitialize, or throw an exception based on specific needs;

[0063] Perform initialization operations: If the database is not initialized, perform database initialization operations 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 step;

[0064] Update the initialization state: After the initialization operation is completed, use the store() method of the atomic variable to update the initialization state of the database to initialized. For example, is_initialized.store(true).

[0065] That is, in a multi-threaded or multi-process environment, multiple threads or processes can attempt to initialize the database at the same time. The atomic operation of the atomic variable can ensure that only one thread or process can successfully update the initialization state of the database, avoiding data conflicts and inconsistency problems caused by multiple threads or processes simultaneously performing initialization operations. In addition, the operation of the atomic variable has atomicity, so even in the case of system failure or abnormal interruption, it can be ensured that the atomic operation that has been executed will not be lost. For example, if the system crashes during initialization, after restarting, it can be determined whether the database has been partially initialized through the state of the atomic variable, and appropriate recovery measures can be taken to ensure data integrity.

[0066] For example: in the financial field, atomic variables can be used to set account status identifiers and transaction serial numbers. Among them, in the financial transaction 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 to represent the inactive state, 1 to represent the normal active state, 2 to represent the frozen state, and so on. An atomic variable is used to generate a unique transaction serial number, such as std::atomic<long long> transaction_id. Each time a new transaction occurs, a new transaction serial number is obtained through an atomic increment operation (such as transaction_id.fetch_add(1)).

[0067] During the database initialization process, an account table is created according to the setting content of the atomic variable, which contains fields such as account ID, account status (corresponding to the storage mode of the atomic variable account_status), balance, and other fields. 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, transaction type, and so on.

[0068] In the account opening, closing, freezing, unfreezing, and other operations, the account status is read and updated through the load() and store() methods of the atomic variable. For example, when freezing an account, the value of account_status is updated to 2. When performing a transaction, the current transaction_id is obtained as the transaction serial number, then the transaction logic is executed, and finally the transaction record is inserted into the transaction record table.

[0069] That is, in a financial transaction system, multiple threads may simultaneously operate on account status or transaction serial numbers in a high-concurrency environment. The atomic operation of the atomic variable can ensure the mutual exclusion of these operations, avoiding inconsistent data, such as multiple threads obtaining the same transaction serial number or simultaneously modifying the account status, resulting in a chaotic state. The atomic variable operation has atomicity, even in the case of system failure or abnormal interruption, the atomic operation that has 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 contention problems in a high-concurrency scenario, reducing system performance. The lock-free operation of the atomic variable can avoid lock contention, improve the concurrent processing capability of the system, and enable the financial transaction system to quickly respond to a large number of transaction requests. The operation speed of the atomic variable is faster than the traditional lock mechanism, reducing the time for threads to wait for locks, thereby reducing the transaction processing delay and improving the real-time performance of the system.

[0070] In addition to the above financial business scenarios, this technology is also applicable in the system of medical and health care business scenarios, for example: in the medical health field, an atomic variable can be used to set the patient medical record status and the patient unique identifier. Among them, the patient medical record status is to set 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 identification is generated using an atomic variable, for example std::atomic<long long> patient_id. Each time a new patient registers, a new patient unique identification is obtained through an atomic increment operation.

[0071] During the database initialization process, a patient information table is created according to the content of the atomic variable, containing fields such as patient ID (corresponding to the storage method of atomic variable patient_id), name, gender, age, etc. Then create a medical record table, use atomic variable medical_record_status to identify the medical record status, and initialize other related fields such as medical record content, creation time, modification time, etc. When a new patient registers, the current patient_id is obtained as the patient's unique identification, and the patient's information is inserted into the patient information table, and the medical_record_status is initialized to 0. When the doctor creates, modifies or reviews the 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 the medical record filling, the value of medical_record_status is updated to 1.

[0072] That is, in the medical health system, multiple doctors may simultaneously operate the medical record of the same patient. The atomic operation of the atomic variable can ensure the mutual exclusion of these operations and avoid data conflicts, such as multiple doctors simultaneously modifying the medical record content causing data confusion. The atomic operation of the atomic variable ensures the integrity of the medical record status and the patient's unique identification, avoiding data loss or damage due to system failure or abnormal interruption. In addition, the lock-free operation of the atomic variable can reduce lock contention and improve the concurrent processing capability of the system, so that the medical health system can simultaneously process the medical record operations of multiple patients, improving the efficiency of medical services. The atomic variable operation is fast, reducing the time for doctors to wait for system response, so that doctors can complete medical record operations faster, improving the quality of medical services. In addition, using atomic variables to manage medical record status and patient unique identification makes the system management process more simple and efficient. Hospital management personnel can more conveniently query and statistics the medical record information and registration of patients. The use of atomic variables reduces the complexity and maintenance difficulty of the code, reduces the possibility of system failure, thereby reducing the maintenance cost of the system.

[0073] First, common variables used in the database system are combed, such as the variable connection_count used to record the number of database connections, the variable transaction_status representing the state of the database transaction, and the like. The data types of these variables (such as integer, Boolean, etc.) and the role and update frequency in the system are clarified. Then, according to the data type of the common variable, the corresponding atomic variable type is selected. For example, for the integer type connection_count, std::atomic <int>(C++); for the Boolean type transaction_status, std::atomic is chosen <bool>In code, replace the declaration of a normal variable with the declaration of an atomic variable. For example, change int connection_count = 0; to std::atomic <int>connection_count{0}.

[0074] Read operation: Replace the direct read operation of normal variable with the load() method call of atomic variable. For example, change int count = connection_count; to int count = connection_count.load().

[0075] Write operation: Replace the direct assignment operation of normal variable with the store() method call of atomic variable. 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 writing back, and ensuring atomicity).

[0076] Set up atomic read operation instead of LwLock read protection operation:

[0077] In database systems, LwLock (Lightweight Lock) is often used to protect concurrent access to shared data when reading. Find the code segment that uses LwLock for read protection, such as when reading database configuration parameters, use LwLock to ensure that only one thread can read the parameters, avoiding data inconsistency caused by other threads reading at the same time. According to the data type of the protected data, select the appropriate atomic read operation. For example, for integer type shared data, you can use the load() method of atomic variable; for custom structure type shared data, if each member of the structure can be represented by an atomic variable (or the whole can be guaranteed atomicity reading by other means), you can also use similar methods. Replace the read protection code: replace the read protection code using LwLock with atomic read operation.

[0078] Set up atomic write operation instead of LwLock write protection operation:

[0079] Find the code segment that uses LwLock for write protection, such as when updating database statistics, use LwLock to ensure that only one thread can write statistics, avoid data errors caused by multiple threads writing at the same time. According to the data type of the protected data, select the appropriate atomic write operation. For example, for integer type shared data, you can use the store() method of atomic variable or fetch_add(), fetch_sub() and other operations; for complex data structures, if you need to atomically update the entire structure, you can consider using std::atomic compare_exchange_weak() or compare_exchange_strong() method for lock-free update. Replace the write protection code: replace the write protection code using LwLock with atomic write operation.

[0080] That is, the atomic operation of the atomic variable can guarantee that the read and write operations on the shared data in the multi-threaded or multi-process environment will not conflict. For example, when multiple threads read or write the same atomic variable at the same time, there will be no data inconsistency, avoiding the problems such as deadlock and livelock that may occur when using LwLock. In addition, LwLock will cause serious lock competition problem in high concurrency scenario, reducing system performance. The lock-free operation of atomic variable can avoid lock competition and improve the concurrent processing capability of the system. Multiple threads or processes can simultaneously perform read and write operations on shared data without waiting for the release of the lock, thereby fully utilizing system resources and improving the overall performance of the database system. The operation speed of atomic variable is faster than traditional lock mechanism, reducing the time of thread or process waiting for lock, thereby reducing the delay of database operation. For example, when reading database configuration parameters, using atomic read operation can immediately get the parameter value without waiting for the acquisition and release of LwLock, improving the response speed of the system.

[0081] For example: in the financial field, set up atomic variables to replace ordinary variables including account balance variables and transaction count variables.

[0082] Account balance variable: In a financial transaction system, account balance is a key variable. Traditional implementation may use an ordinary integer variable to store account balance, such as int accountBalance = 1000. Now replace it with atomic variable std::atomic <int>accountBalance{1000}.

[0083] Transaction count variable: The transaction count variable is used to record the number of transactions for each account, such as inttransactionCount = 0; change to std::atomic <int>transactionCount{0}。

[0084] Setting up an atomic read operation instead of an LwLock read protection operation can refer to reading account information: when displaying user account information, the account balance and transaction count need to be read.

[0085] Setting up an atomic write operation instead of an LwLock write protection operation can refer to processing deposit transactions: when a user performs a deposit operation, the account balance and transaction count need to be updated.

[0086] That is, in a high-concurrency financial transaction scenario, multiple threads may simultaneously read and write account balance and transaction count. The atomicity 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 guarantee data integrity, and even in the event of system failure or abnormal interruption, the atomic operations that have been executed will not be lost. This is crucial for financial transaction systems, as each transaction involves the safety and accuracy of funds. In addition, LwLock can cause serious lock contention in a high-concurrency environment, reducing system performance. The lock-free operation of atomic variables can avoid such competition and improve the system's concurrent processing capability. For example, when processing a large number of concurrent deposit transactions, using atomic variables can significantly reduce the time threads wait for locks, improving transaction processing speed. Atomic read and write operations are faster than traditional locking mechanisms, reducing user waiting time for transaction processing and improving user experience.

[0087] In addition to the above financial business scenarios, this technology is also applicable in medical and health care business scenarios, such as: in the medical health field, setting up atomic variables instead of ordinary variables: including patient vital sign data and medical device state variables.

[0088] Patient vital sign data: In a medical monitoring system, patient vital sign data such as heart rate, blood pressure, etc. needs to be updated and read in real time. Traditional implementation may use ordinary floating-point number variables to store these data, such as float heartRate = 70.0; Now replace it with atomic variables std::atomic <float>heartRate{70.0}.

[0089] Medical device status variable: To record the running status of the medical device, such as int deviceStatus = 0; (0 means normal, 1 means fault), change to std::atomic <int>deviceStatus{0}.

[0090] Setting to use atomic read operation instead of LwLock read protection operation can refer to real-time monitoring of patient data: medical staff need to view patient vital sign data in real time.

[0091] Setting to use atomic write operation instead of LwLock write protection operation 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 variable needs to be updated.

[0092] That is to say, in the field of medical health technology, the real-time nature of data is crucial. The atomic operation of atomic variables can ensure timely updating and reading of data, and medical staff can obtain the latest vital sign data of patients in real time, so as to make diagnosis and treatment decisions in time. Atomic operations avoid data errors caused by concurrent access, ensuring the accuracy of patient data. For example, there will be no situation of data overwrite or confusion caused by multiple devices writing patient data at the same time. In addition, 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 of threads waiting for locks, improve the response speed of the system, and enable medical staff to obtain patient data faster. Fast atomic read operation can support real-time monitoring of patient data and timely detection of patient abnormalities, saving valuable time for medical treatment.

[0093] In an embodiment, the setting to use atomic variables instead of ordinary variables includes:

[0094] Declaring an atomic variable for recording the progress of WAL log insertion operations;

[0095] Using the initialization operation of the atomic variable to assign the value of the variable InsertingAt.

[0096] Specifically, an atomic variable for recording the progress of WAL log insertion operations is declared:

[0097] In a database management system, WAL (Write-Ahead Logging) log is used to record all modification operations on the database to ensure data consistency and persistence. In order to record the position of WAL log writing, an atomic variable can be declared to replace the traditional ordinary variable. Assuming that C++ language is used, std::atomic<uint64_t> defines a 64-bit unsigned integer atomic variable InsertingAt, which is used to record the position of WAL log insertion operation. The atomic type std::atomic provides atomic operations, which ensures that the read and write operations on this variable are thread-safe in a multi-threaded environment.

[0098] The initialization operation of the atomic variable assigns the value of the variable InsertingAt:

[0099] The initialization operation of the atomic variable or the assignment operation can be used to set the value of InsertingAt when the system is initialized or needs to reset the WAL log write position. When declaring the atomic variable, it can be initialized directly, as shown above, initializing InsertingAt to 0. During the system running process, 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, its atomic read and write operations can be used to ensure thread safety.

[0100] That is, 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, avoiding errors caused by data races. For example, if atomic variables are not used, multiple threads may read and write the value of InsertingAt simultaneously, which may cause data inconsistency and result in log record loss or overwrite. Traditional synchronization mechanisms, such as mutexes, require explicit locking and unlocking, increasing code complexity and overhead. Atomic variables provide lock-free atomic operations, simplifying synchronization mechanisms and improving code readability and maintainability. Additionally, since atomic variables do not require the use of mutexes, lock contention between threads can be reduced, improving the system's concurrent processing capability. In a high-concurrency database system, a large number of WAL log insertion operations can be performed simultaneously without causing performance degradation due to lock contention. Atomic operations are faster than traditional lock mechanisms, reducing the time threads spend waiting for locks and reducing the delay of WAL log insertion operations. This is very important for real-time database systems, as it can improve system response speed and throughput.

[0101] For example, in the financial field, WAL logs are used to record each transaction operation to ensure the integrity and recoverability of transaction data. For example, in a financial transaction background system developed in C++, an atomic variable InsertingAt can be declared using std::atomic<uint64_t> to record the progress of WAL log insertion operations. Initialize InsertingAt when the system starts or needs to reset the log recording position. It can be directly assigned in the system initialization function, or it can be calculated and assigned according to specific conditions. When a new transaction operation needs to be recorded to the WAL log, 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.

[0102] That is, in a financial transaction system, multiple transactions may occur simultaneously and need to be recorded in the WAL log at the same time. Using atomic variables can ensure that the read and write operations of multiple threads on InsertingAt are thread-safe, avoiding log recording errors caused by data competition, thereby ensuring the consistency and integrity of transaction data. Atomic operations ensure that the update of the log recording position is atomic, and there is no situation where some threads read the wrong position value, causing log recording loss or overwrite. In addition, using atomic variables can avoid deadlocks and livelocks caused by improper lock management, ensuring that the system can run stably in a multi-threaded environment. In a financial transaction system, system stability is crucial, and any failure can cause serious economic losses. Since the WAL log records complete transaction operations, using atomic variables ensures the accuracy of log recording, making it possible to recover more quickly and accurately after a system failure, reducing data loss and business interruption time.

[0103] In addition to the above financial business scenarios, this technology is also applicable in medical and health care business scenarios, such as: in the medical health field, WAL logs are used to record patient medical data modification operations such as medical record updates, test result entries, etc. For example, in a medical health information system developed in Java, an atomic variable InsertingAt can be declared using the AtomicLong class. Initialize InsertingAt when the system initializes. It can read the last log recording position when the system was last closed from the database, or initialize it according to the system configuration. When there is a medical data modification operation, use InsertingAt to record the log insertion position.

[0104] That is, the atomic variable guarantees the correct update of the WAL log record position, ensuring that the log record order of medical data modification operations is consistent with the actual occurrence order. This is very important for medical health information systems, because accurate logging can help doctors trace the medical history of patients and make correct diagnosis and treatment decisions. Since the WAL logs all the detailed information of the medical data modification operations and uses atomic variables to ensure the integrity of the logs, any illegal tampering with the medical data can be discovered and tracked in a timely manner. In addition, medical health information systems need to handle a large number of patient data modification requests at the same time, and the use of atomic variables can improve the concurrent processing capability of the system, reduce thread waiting time, and make the system respond to patient needs faster. Efficient operation of atomic variables can reduce the overhead of log management and improve the overall performance of the system. For example, during the log backup and recovery process, the log records can be located and processed more quickly.

[0105] In an embodiment, the setting uses an atomic read operation instead of an LwLock read protection operation, including:

[0106] The value of the record WAL log current progress variable in shared memory is read using the read operation of the atomic variable.

[0107] Specifically, assuming that this technical feature is implemented in a database management system, the system uses shared memory to store the WAL log current progress variable, and the original system uses LwLock for read protection operation. In the 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 WAL log current progress. In the initialization stage, the atomic variable is initialized to a reasonable value, such as loading the last WAL log progress from the persistent storage.

[0108] That is, 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 better scalability. For example, when more shared variables need to be added, atomic variables can be used to manage these variables more conveniently without introducing new lock mechanisms.

[0109] For example, in the financial field, such as the securities trading system, a large amount of transaction data needs to be recorded and processed in real time. WAL log is used to ensure the consistency and recoverability of data. The WAL log current progress variable recorded in shared memory reflects the latest position of log record, and other modules (such as data persistence module, transaction analysis module) need to frequently read this variable to determine the log processing state.

[0110] In the shared memory area of the financial transaction system, an atomic variable atomic_uint_least64_twal_progress is defined to record the current progress of the WAL log. When the system starts, the last WAL log progress value is loaded from the persistent storage (such as disk file), and the atomic_store function is used to initialize it to the atomic variable. During transaction processing, whenever a new transaction record is written to the WAL log, the atomic_fetch_add atomic operation is used to update the current progress of the WAL log.

[0111] That is, the financial transaction system usually needs to process a large number of concurrent transaction requests, and the LwLock read protection operation will cause threads to frequently acquire and release locks, increasing system overhead. After using atomic read operation, no lock mechanism is needed, reducing thread waiting time and improving system throughput. The atomic read operation is faster than the LwLock read protection operation, which can acquire the current progress of the WAL log faster, reduce the delay of transaction processing, and improve the real-time performance of the system.

[0112] In addition to the above financial business scenarios, this technology is also applicable in the system of medical and health care business scenarios, for example: in the medical health field, such as medical information management system, patient medical record data, examination report and other information need to be recorded and backed up in real time. WAL log is used to ensure the security and recoverability of medical data. The WAL log current progress variable in shared memory is used to track the latest position of log record, so that other modules (such as data backup module, medical data analysis module) can obtain the latest log information in time.

[0113] In the shared memory area of the medical information management system, an atomic variable atomic_uint_least64_tmedical_wal_progress is defined to record the current progress of the WAL log. When the system starts, the last WAL log progress value is loaded from the database, and the atomic_store function is used to initialize it to the atomic variable. During 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.

[0114] That is, the medical information management system needs to process a large amount of medical data in real time, and the atomic read operation reduces the lock overhead, so that other modules can obtain the current progress of the WAL log faster, improves the response speed of the system, and ensures that medical personnel can obtain the latest information of patients in time. With the continuous development of medical informatization, the medical information management system needs to support more and more concurrent access. The efficiency of the atomic read operation enables the system to better handle high-concurrency scenarios and improve the scalability of the system.

[0115] In an embodiment, the setting uses an atomic write operation to replace the LwLock write protection operation, including:

[0116] The write operation of the atomic variable writes the value of the locally recorded WAL log current insertion progress variable into the shared memory.

[0117] Specifically, in a financial transaction system or a medical health information management system, the WAL mechanism is used to ensure the consistency and recoverability of data. Each system node maintains a locally recorded WAL log current insertion progress variable, and 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 time. An atomic variable atomic_uint_least64_twal_insert_progress is defined in the shared memory area to store the current insertion progress of the WAL log. When the system starts, the last WAL log insertion progress value is loaded from the persistent storage (such as a disk file or a database), and the atomic_store function is used to initialize it to the atomic variable. In each system node, a local variable local_insert_progress is maintained to record the WAL log insertion progress of the current node. When new log records are written, the local variable is updated. When the locally recorded progress value needs to be written to the shared memory, the atomic write operation atomic_store is used 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 to update it. For example, after writing a large number of log records at a time, it can be judged whether the progress change exceeds a certain threshold, and if so, the shared memory is updated immediately.

[0118] That is, in the fields of finance and medical health technology, using an atomic write operation to replace the LwLock write protection operation to write the value of the locally recorded WAL log current insertion progress variable into the shared memory can significantly improve the performance, reliability, and scalability of the system.

[0119] In an embodiment, after the initializing the database according to the setting content to obtain the atomic variable database, the method further comprises:

[0120] backing up the atomic variable database to build backup data.

[0121] Specifically, after the database initialization is completed, the atomic variable database is closed and backed up to build backup data.

[0122] In an embodiment, after the backing up the atomic variable database to build backup data, the method further comprises:

[0123] restoring the database according to the backup data to obtain a test set.

[0124] Specifically, before each test, the database is restored using the backup data to ensure that the same test set is used for each test.

[0125] That is, the same test set is used for each test, eliminating the problem of inconsistent test results caused by data differences. For example, in software function testing, if the database data used for each test is different, it may cause some functions to be normal in some tests and fail in other tests, thereby affecting the reliability of the test results. In addition, the same test set enables the tester to more accurately evaluate the functions and performance of the software. The tester can focus on the defects and problems of the software itself without worrying about the interference caused by data differences. In addition, since the test set is restored in advance before each test, the tester does not need to spend a lot of time preparing test data. The tester can directly start testing, improving the testing efficiency. When problems are found during testing, the problems can be easily reproduced and debugged. Because the test set is fixed, the tester can run the same test case multiple times to determine the root cause of the problem.

[0126] In an embodiment, after the restoring the database according to the backup data to obtain a test set, the method further comprises:

[0127] pre-reading the test data into a cache.

[0128] Specifically, the test data is pre-read into the cache before read-write testing, which is beneficial to obtain relatively stable test data.

[0129] That is, after pre-reading the test data into the cache, the test application directly obtains data from the cache during read-write testing, avoiding data fluctuations caused by frequent database access. For example, in the case of high database load or concurrent access, the data in the database may change, causing unstable test results. The data in the cache is relatively stable after pre-reading, ensuring the consistency of test data. In addition, the cache system usually has high availability and performance, reducing the impact of external factors such as network delay and database failure on test data. Even in the case of temporary database failure, the test application can still obtain data from the cache, ensuring the continuity of testing. In addition, the access speed of the cache is much faster than that of the database, and pre-reading 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 several orders of magnitude shorter than the time to obtain data from the database, thereby speeding up the execution of the test. By caching data, the frequency of database access by the test application is reduced, reducing the load on the database, which allows the database to more efficiently handle other business requests, while also improving the overall performance of the test environment.

[0130] In an embodiment, after recovering the database according to the backup data to obtain the test set, the method further comprises:

[0131] Performing read-write testing on the test set.

[0132] Specifically, through read-write testing, the performance of the database under different loads can be comprehensively evaluated, including response time, throughput, concurrent processing capacity, 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 business requirements. Performance bottlenecks such as slow queries, missing indexes, lock contention, etc. can be discovered in a timely manner during testing. By optimizing these bottlenecks, the performance of the database can be improved. In addition, under long-term, high-concurrency read-write testing, the stability of the database can be verified. Whether the database will crash, data loss, etc. can be observed to ensure stable operation of the database. Some potential problems such as memory leaks, resource exhaustion, etc. may be discovered during testing, and these problems can be solved in a timely manner to improve the reliability and availability of the database.

[0133] The method for optimizing database read-write performance described above uses atomic variables to initialize a database to obtain an atomic variable database. Since the operation of atomic variables is lock-free, lock competition problems caused by traditional lock mechanisms are 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 a lock, thereby fully utilizing the parallel computing capabilities of a multi-core processor, enabling efficient execution of database read-write operations on a multi-core processor, and significantly improving the overall read-write performance of the database. In addition, in a high-concurrency scenario, multiple threads or processes simultaneously competing for a lock can increase lock waiting time and reduce system throughput, thereby generating a large amount of performance overhead. The lock-free operation of atomic variables avoids lock competition and reduces the time and resources consumed by threads or processes during the process of waiting for the release of a lock, thereby significantly reducing the performance overhead caused by lock competition. In addition, the use of traditional lock mechanisms introduces additional thread or process scheduling overhead, especially in a high-load scenario, where threads or processes frequently acquire and release locks, causing the operating system to spend more time on thread switching and scheduling. The lock-free design of the present application 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 processing database read-write operations, traditional lock mechanisms require time to acquire and release locks, and in the case of intense lock competition, threads or processes can be waiting for a long time, thereby reducing the response speed of the system. The lock-free design of the present application enables database read-write operations to be executed quickly without waiting for the release of a lock, greatly shortens the average response time of transactions, improves the response speed of the system, and better meets the needs of users for fast response of the database.

[0134] Figure 3 is a schematic block diagram of an apparatus 300 for optimizing database read-write performance provided by an embodiment of the present application. As shown in Figure 3 corresponding to the above method for optimizing database read-write performance, the present application also provides an apparatus 300 for optimizing database read-write performance. The apparatus 300 for optimizing database read-write performance includes units for executing the above method for optimizing database read-write performance, and the apparatus can be configured in a server. Specifically, referring to Figure 3 , the apparatus 300 for optimizing database read-write performance includes a setting unit 301 and an initialization unit 302.

[0135] The setting unit 301 is configured to set the use of atomic variables instead of ordinary variables, set the use of atomic read operations instead of LwLock read protection operations, and set the use of atomic write operations instead of LwLock write protection operations, to obtain setting content.

[0136] The initialization unit 302 is configured to initialize a database according to the setting content to obtain an atomic variable database.

[0137] In an embodiment, the setting unit 301 comprises:

[0138] A declaration sub-unit is configured to declare an atomic variable for recording the progress of the WAL log insertion operation.

[0139] An initialization sub-unit is configured to assign a value to the variable InsertingAt using an initialization operation of the atomic variable.

[0140] In an embodiment, the setting unit 301 comprises:

[0141] A first setting sub-unit is configured to read the value of the variable recording the current progress of the WAL log in the shared memory using a read operation of the atomic variable.

[0142] In an embodiment, the setting unit 301 comprises:

[0143] A second setting sub-unit is configured to write the value of the locally recorded WAL log current insertion progress variable into the shared memory using a write operation of the atomic variable.

[0144] In an embodiment, the apparatus further comprises a backup unit configured to backup the atomic variable database to build backup data.

[0145] In an embodiment, the apparatus further comprises a recovery unit configured to recover the database according to the backup data to obtain a test set.

[0146] In an embodiment, the apparatus further comprises an execution unit configured to perform read-write tests on the test set.

[0147] It should be noted that the specific implementation process of the above-mentioned apparatus 300 and each unit for optimizing the read-write performance of the database can be clearly understood by those skilled in the art, which can be referred to the corresponding description in the foregoing method embodiments. For the convenience and brevity of description, it will not be repeated here.

[0148] The above-mentioned apparatus 300 for optimizing the read-write performance of the database can be implemented in the form of a computer program, which can run on a computer device as shown in Figure 4 .

[0149] Please refer to Figure 4 , Figure 4 is a schematic block diagram of a computer device provided by an embodiment of the present application. The computer device 500 can be a server, wherein the server can be a standalone server or a server cluster composed of multiple servers.

[0150] Please refer to Figure 4 The computer device 500 includes a processor 502 , a memory, and a network interface 505 connected via a system bus 501 , wherein the memory may include a non-volatile storage medium 503 and an internal memory 504 .

[0151] The non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions, which, when executed, can cause the processor 502 to execute a method for optimizing database read and write performance.

[0152] The processor 502 is used to provide computing and control capabilities to support the operation of the entire computer device 500.

[0153] 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 execute a method for optimizing database read and write performance.

[0154] The network interface 505 is used to communicate with other devices through the network. Figure 4 The structure shown in the figure is merely a block diagram of a portion of the structure 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 shown in the figure, or combine certain components, or have a different component arrangement.

[0155] The processor 502 is configured to execute a computer program 5032 stored in the memory to implement the following steps:

[0156] 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 setting content; initialize the database according to the setting content to obtain an atomic variable database.

[0157] It should be understood that, in the embodiments of the present application, the processor 502 can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0158] It can be understood by those skilled in the art that all or part of the processes in the above-mentioned embodiments can be completed by a computer program instructing related hardware. The computer program includes program instructions, and the computer program can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the above-mentioned embodiments.

[0159] Therefore, the present application further provides a storage medium. The storage medium can be a computer-readable storage medium. The storage medium stores a computer program, wherein the computer program is executed by a processor to make the processor perform the following steps:

[0160] Setting the use of an atomic variable instead of a normal variable, setting the use of an atomic read operation instead of an LwLock read protection operation, and setting the use of an atomic write operation instead of an LwLock write protection operation to obtain setting content; initializing a database according to the setting content to obtain an atomic variable database.

[0161] The storage medium can be a U disk, a mobile hard disk, a read-only memory (ROM), a magnetic disk or an optical disk, and various computer-readable storage media that can store program codes.

[0162] Those skilled in the art can understand that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized in electronic hardware, computer software or a combination of both. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been described in general terms in the above description. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. A person skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0163] In several embodiments provided by the present application, it should be understood that the disclosed apparatus and method can be implemented in other ways. For example, the apparatus embodiments described above are merely schematic. For example, the division of each unit is only a logical function division, and actual implementation can have another division manner. For example, a plurality of units or components can be combined or integrated into another system, or some features can be omitted or not executed.

[0164] The steps in the method embodiments of the present application can be adjusted, combined and deleted in sequence according to actual needs. The units in the apparatus embodiments of the present application can be combined, divided and deleted according to actual needs. In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit.

[0165] The integrated unit, if realized in the form of a software functional unit and sold or used as an independent product, can be stored in a storage medium. Based on such understanding, the technical solutions of the present application essentially or the part that contributes to the prior art, or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes a plurality of 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 application.

[0166] The above description is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of various equivalent modifications or replacements within the technical range disclosed by the present application, and these modifications or replacements should be covered in the protection scope of the present application. Therefore, the protection scope of the present application 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 atomic variables to replace ordinary variables, set atomic read operations to replace LwLock read protection operations, and set atomic write operations to replace LwLock write protection operations to obtain the setting content; Initializing a database according to the setting content to obtain an atomic variable database; The settings use 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; Specifically, in a database management system, the WAL log is used to record all modification operations on the database. To record the location where the WAL log is written, an atomic variable is declared to replace the traditional ordinary variable. When the system is initialized or the WAL log write location needs to be reset, the atomic variable initialization operation or assignment operation is used to set the value of InsertingAt. When declaring an atomic variable, it is initialized directly. During system operation, if the WAL log write location needs to be reset, the atomic variable's store method is used to assign a value. When executing the WAL log insertion operation, the value of InsertingAt is read and updated. The settings use 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 into the shared memory; Specifically, each system node maintains a local variable for recording the current insertion progress of the WAL log. When a new log record is written, the value of the progress variable needs to be updated to the shared memory so that other nodes or modules can obtain the latest log progress in a timely manner. An atomic variable is defined in the shared memory area to store the current insertion progress of the WAL log. When the system starts, the value of the last WAL log insertion progress variable is loaded from the persistent storage and initialized to the atomic variable using the atomic_store function. In each system node, a local variable is maintained to record the WAL log insertion progress of the current node. When a new log record is written, the local variable is updated. When the value of the locally recorded progress variable needs to be written to the shared memory, the atomic write operation atomic_store is used instead of the LwLock write protection operation.

2. 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.

3. 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.

4. The method for optimizing database read and write performance according to claim 3, 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.

5. The method for optimizing database read and write performance according to claim 4, 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.

6. A device for optimizing database read and write performance, characterized in that: include: A setting unit, used to set atomic variables to replace ordinary variables, set atomic read operations to replace LwLock read protection operations, and set atomic write operations to replace LwLock write protection operations, so as to obtain setting content; an initialization unit, configured to initialize a database according to the setting content to obtain an atomic variable database; The setting unit includes: The declaration subunit is used to declare atomic variables used to record the progress of WAL log insertion operations; The initialization subunit is used to assign the value of the variable InsertingAt using the initialization operation of the atomic variable; Specifically, in a database management system, the WAL log is used to record all modification operations on the database. To record the location where the WAL log is written, an atomic variable is declared to replace the traditional ordinary variable. When the system is initialized or the WAL log write location needs to be reset, the atomic variable initialization operation or assignment operation is used to set the value of InsertingAt. When declaring an atomic variable, it is initialized directly. During system operation, if the WAL log write location needs to be reset, the atomic variable's store method is used to assign a value. When executing the WAL log insertion operation, the value of InsertingAt is read and updated. The setting unit includes: The second setting subunit is used to write the value of the current insertion progress variable of the locally recorded WAL log into the shared memory using the write operation of the atomic variable; Specifically, each system node maintains a local variable for recording the current insertion progress of the WAL log. When a new log record is written, the value of the progress variable needs to be updated to the shared memory so that other nodes or modules can obtain the latest log progress in a timely manner. An atomic variable is defined in the shared memory area to store the current insertion progress of the WAL log. When the system starts, the value of the last WAL log insertion progress variable is loaded from the persistent storage and initialized to the atomic variable using the atomic_store function. In each system node, a local variable is maintained to record the WAL log insertion progress of the current node. When a new log record is written, the local variable is updated. When the value of the locally recorded progress variable needs to be written to the shared memory, the atomic write operation atomic_store is used instead of the LwLock write protection operation.

7. A computer device, characterized in that: The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the method according to any one of claims 1 to 5 when executing the computer program.

8. 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 5 is implemented.

Images