Transaction acceleration method and system based on key-value solid state drive

Abstract

The application discloses a transaction acceleration method and system based on a key-value solid state disk, and belongs to the technical field of computer storage of space-based systems. The method comprises the following steps: pre-allocating a transaction context in the nonvolatile memory of the KVSSD; intercepting a transaction key-value operation and storing the operation in a memory log; writing the log into the KVSSD through an atomic append write command; and atomically submitting updated data after the log is persisted. The system is composed of the KVSSD and a Key-Value API repository; the KVSSD comprises a front-end controller FE, a key-value processor KV-Core, an FTL and a back-end component BE; and the API repository comprises a transaction management module, a log management module, a version control module and a conflict detection module. Through the cooperation of software and hardware, the high performance of the KVSSD, the atomic key-value operation and the programmable firmware capability are utilized, the CPU overhead of a host computer is reduced, the problem of data loss in a complex space environment is reduced, and the transaction efficiency and data consistency are improved.

Description

Technical Field

[0001] This invention relates to the field of computer storage technology, and specifically to a transaction acceleration method and system based on key-value solid-state drives (KVSSDs). Background Technology

[0002] With the explosive growth of data volume and the ever-increasing demands for real-time performance, databases, distributed storage, and other systems are placing increasingly higher demands on transaction processing performance. Traditional block storage SSDs, when processing transactions, require host-side software (such as database engines) to maintain transaction logs, version control, and conflict detection. These operations not only rely on frequent, fine-grained, random I / O accesses but also incur significant context switching, memory copying, and CPU overhead on the host side. Especially in high-concurrency scenarios, log flushing (fsync) becomes a performance bottleneck, severely impacting transaction commit rates. In space-based systems, this problem is even more pronounced: unstable inter-satellite network connections, high communication latency, limited power supply, and the satellite operating environment's susceptibility to sudden power outages (such as solar panel obstruction, battery failure, or space radiation interference) significantly increase the risk of transaction processing interruptions and data inconsistencies.

[0003] KVSSD provides a native key-value pair interface on non-volatile storage devices, supporting atomic key-value pair operations (such as Store, Delete, and Retrieve). This allows the host to directly access data on the SSD at the key level without address translation through the file system or block device layer, improving data access efficiency. However, according to the NVMe 2.0 protocol released by the NVMe international standards organization, the protocol only defines atomic single-key-value operations and does not provide native multi-key transaction commands. Therefore, current mainstream KVSSD devices based on the Key-Value command set are mainly optimized for single-key operations, lacking awareness of transaction semantics. Their internal resource scheduling, garbage collection strategies, and cache management do not consider the lifecycle characteristics of transactions (such as batch commits, locality of read / write sets, rollback requirements, etc.), leading to performance degradation or resource contention under transaction-intensive loads. In space-based systems, due to frequent network interruptions and high power loss risks, the lack of an effective transaction processing mechanism can lead to data loss or consistency corruption, seriously threatening the reliable execution of satellite missions.

[0004] Therefore, how to retain KVSSD's efficient key-value access capabilities while introducing a lightweight transaction support mechanism into the KVSSD firmware library may become a key challenge in improving the performance of transactional applications. An ideal solution should leverage KVSSD's hardware characteristics, such as ensuring atomic persistence of critical logs through the FUA (Force Unit Access) command, optimizing append-only write performance of transaction logs using the ordered write characteristics of ZonedNamespace (ZNS), and pushing some transaction processing steps (such as log persistence, write set marking, and version data writing) to disk on KVSSD. This would reduce host-side intervention, lower end-to-end latency, and improve overall system scalability. However, currently, there are no mature technologies or systems that can implement an efficient, secure, and protocol-compatible storage layer transaction acceleration mechanism on KVSSD. Summary of the Invention

[0005] The purpose of this invention is to address the problems of lack of native transaction support, high host-side transaction management overhead, and long log paths in existing key-value solid-state drives (KVSSDs), and to provide a transaction acceleration method and system based on key-value solid-state drives (KVSSDs). By introducing a lightweight transaction management mechanism into the KVSSD firmware library, combined with Write-Ahead Log (WAL), Multi-Version Concurrency Control (MVCC), and atomic operation semantics, the key performance bottlenecks of transactions (including log persistence and version data writing) are offloaded to KVSSD for hardware acceleration. Simultaneously, the Key-Value API library collaboratively manages the transaction lifecycle, thereby significantly reducing host-side CPU load and I / O latency while ensuring ACID properties, and improving system throughput and response performance in high-concurrency transaction scenarios.

[0006] To achieve the above objectives, this invention provides a transaction acceleration method based on key-value solid-state drives (KVSSDs), adapted for space-based systems. The KVSSD supports the Key-Value command set and optional Zoned Namespaces (ZNS) features in the NVMe 2.0 protocol, and includes the following steps:

[0007] Transaction Initialization: The host application calls the API library to create a new operation transaction, specifying the transaction isolation level and priority label. The API library's transaction management module generates a globally unique transaction ID (TxID) and records the transaction start timestamp. Afterward, the API library calls the extended NVMe-KV command (KV_TransactionBegin) to notify KVSSD to prepare the context for the transaction and reserve log space, but does not allocate specific resources at this time. The context will be stored in the non-volatile controller memory inside the SSD during the actual execution of the transaction, ensuring recovery after power failure.

[0008] Operation Capture and Version Generation: Within a transaction context, the host initiates key-value operations (such as KV_Put, KV_Get, and KV_Delete). The API library's transaction management module intercepts these operations and records the generated operation log entries to the in-memory transaction log buffer. Each record contains a key, operation type, old value, new value, and a version number (VersionID) generated from the transaction ID and system-wide globally incrementing version information. The API library's version control module maintains a version chain for each key, and newly written data is organized in the form of Key@VersionID, supporting the coexistence of multiple versions.

[0009] Conflict Detection and Isolation Control: The API library's conflict detection module performs a version comparison before each write operation (checking whether the latest committed system-wide incremental version of the target key is later than the current transaction). If a later version exists, it indicates that the key has been modified by another transaction, resulting in a write-write conflict. If a write-write conflict occurs, the handling strategy is determined based on the transaction isolation level: Read Committed (RC) terminates the current transaction and returns a conflict error; Repeatable Read (RR) triggers the transaction retry mechanism, re-acquires a snapshot, and executes. This mechanism implements optimistic concurrency control based on global version number sorting in the API library, avoiding lock contention overhead.

[0010] Write-ahead log persistence: Before committing, it's crucial to ensure log data persistence. The API library's log management module encapsulates transaction operation log entries (including TxID, operation sequence, checksum, etc.) and writes them to KVSSD's dedicated non-volatile log zone using an extended atomic append command (KV_LogAppend). This log zone is based on ZNS partitioning and employs a sequential write mode to maximize write efficiency and reduce write amplification. KVSSD utilizes FUA to ensure log entries are immediately written to disk and returns a persistence confirmation. The initial state of log entries is "uncommitted".

[0011] Transaction commit:

[0012] 1. Decision and preparation: After receiving confirmation of log persistence, decide to execute the commit command (KV_CommitTransaction).

[0013] 2. Log persistence: Update the status of log entries to "committed" and ensure the persistence of commit records through KV_LogAppend and FUA.

[0014] 3. Data Writing: The API library uses the NVMe 2.0 standard KV_Put and KV_Delete commands to write new version data to the KVSSD data area in the form of Key@VersionID. After receiving these writes, the KVSSD firmware library's front-end controller (FE) associates them with the already persisted commit records.

[0015] 4. Transaction Completion: After successful commit, KVSSD can reclaim related resources. The log management module marks the log as reclaimable in subsequent garbage collection cycles; the oldest data version to be retained can be specified by configuring retention policy parameters on the host side, and the system will automatically and asynchronously clean up all historical data earlier than that version on the version chain accordingly.

[0016] Transaction rollback:

[0017] 1. Decision: The API library decides to roll back due to execution failure or timeout (KV_RollbackTransaction).

[0018] 2. Status marking: Mark the log status as "rollbacked" and ensure the persistence of commit records through KV_LogAppend and FUA.

[0019] 3. Data Cleanup: The Front Controller (FE) receives transaction failure notifications and performs reverse operations (such as deleting the new version or restoring the old version) based on the old values ​​in the logs to ensure the entire batch process is rolled back. The associated transaction status is either "rolled back" or never referenced by a "committed" record. All changes are completed internally by KVSSD, without requiring host-side data repair.

[0020] Furthermore, it also includes high-concurrency transaction optimization strategies:

[0021] Log partitioning: Logs from multiple transactions can be interleaved and written to the same ZNS log area (i.e., non-volatile log area), distinguished by TxID.

[0022] Multi-queue and time-slice scheduling: The API library's transaction management module allocates independent I / O queues for transactions of different priorities or key ranges, and executes them according to time-slice scheduling. It also manages resource quotas, limiting the log bandwidth and cache resources used by individual transactions to prevent long transactions from blocking short transactions.

[0023] Accordingly, the present invention also provides a transaction acceleration system based on key-value solid-state drives, comprising:

[0024] KEY-VALUE API library:

[0025] 1. Transaction Management Module: As the core scheduling unit, it is responsible for the creation, scheduling, status maintenance and lifecycle management of transactions, and responds to transaction requests from the host.

[0026] 2. Log Management Module: Manages the in-memory transaction log buffer and calls the KV_LogAppend command of the front controller (FE) to achieve efficient log persistence.

[0027] 3. Version Control Module: Manages and maintains a multi-version data chain for each key in memory and persists it to KVSSD. The key is Key@VersionChain, and the value is the multi-version data chain. Versions are distinguished by the Key@VersionID naming key, and snapshot isolation and hot key caching are supported.

[0028] 4. Conflict Detection Module: Based on the system's globally incremental version information optimistic concurrency control engine, it monitors read and write set conflicts in real time and executes termination or retry strategies according to the isolation level.

[0029] KVSSD includes the following modules in its firmware library:

[0030] 1. Front-end Controller (FE): Responsible for communicating with the host, parsing host commands, and processing NVMe protocols. Based on the NVMe 2.0 Key-Value command set, it defines and implements a set of transaction extension commands, including: starting a transaction (KV_StartTransaction); committing or rolling back a transaction (KV_CommitTransaction / KV_RollbackTransaction).

[0031] The log is atomically appended to KV_LogAppend.

[0032] 2. Key-Value Processor (KV-Core): As the computing core of KVSSD, it is responsible for executing the storage, retrieval and management logic of key-value data, directly processing KV commands (such as Put, Get, Delete) from the host, and coordinating with the front-end controller (FE) to process extended transaction commands.

[0033] 3. Flash Translation Layer (FTL): Responsible for managing the mapping from the logical address space of KVSSD to the physical address space of NAND flash memory, and performing functions such as garbage collection and wear leveling.

[0034] 4. Backend Interaction Component (BE): Responsible for direct interaction with NAND flash memory chips, performing the final write and read operations of data.

[0035] Compared with the prior art, the present invention has the following beneficial effects:

[0036] 1. Significantly Reduced Transaction Latency: The time-consuming log persistence process is moved to KVSSD via the KV_LogAppend command, and FUA and ZNS are used to achieve ultra-fast disk persistence, reducing host-side CPU involvement and cross-layer I / O interactions, thus significantly shortening the critical path. Experiments show that under typical OLTP loads, transaction commit latency can be reduced by more than 50%.

[0037] 2. Enhance data consistency and reliability: Through non-volatile logs, atomic writes, and multi-version control, ensure that ACID properties are guaranteed at the hardware level in the storage layer, and support rapid recovery of incomplete transactions after power failure.

[0038] 3. Excellent compatibility: The command extension is designed based on the NVMe 2.0 standard framework, requiring no modification to the upper-layer database architecture. It can be seamlessly integrated with existing KV storage systems (such as RocksDB and Redis), and has the potential for industrial application.

[0039] 4. Excellent high concurrency capability: Through log partitioning and multi-queue and time-slice scheduling, the system can maintain low latency and high throughput under thousands of TPS load, effectively dealing with the typical high concurrency challenge of "commit storm". Attached Figure Description

[0040] Figure 1 A detailed flowchart of the transaction acceleration method based on KVSSD provided in this embodiment of the invention.

[0041] Figure 2 A system fault recovery flowchart provided for an embodiment of the present invention.

[0042] Figure 3 This is a block diagram of a transaction acceleration system architecture based on KVSSD provided in an embodiment of the present invention.

[0043] Figure 4 The overall module block diagram of the control core of KVSSD provided in the embodiment of the present invention. Detailed Implementation

[0044] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0045] Example 1: Detailed process of a transaction acceleration method based on KVSSD

[0046] like Figure 1As shown, this invention provides a specific implementation of a transaction acceleration method based on key-value solid-state drives (KVSSDs), adapted to space-based systems. The KVSSD supports the Key-Value command set in the NVMe 2.0 protocol and has ZonedNamespaces (ZNS) and Force Unit Access (FUA) write capabilities. A transaction acceleration system based on key-value solid-state drives includes a software storage layer Key-Value API library provided for host-side calls and a hardware storage medium KVSSD, used to implement the aforementioned transaction acceleration method based on key-value solid-state drives. The following is combined with... Figure 1 The flowchart shown below provides a detailed explanation of the transaction lifecycle in this embodiment.

[0047] S101: Start transaction

[0048] When an application needs to perform a set of atomic operations, it calls the `kv_begin()` interface to initiate a transaction request. The Key-Value API library generates a 64-bit globally unique transaction ID (TxID), which is composed of a 48-bit timestamp and a 16-bit random number, ensuring global uniqueness and recording the start timestamp. This ID is used for context binding of all subsequent operations.

[0049] S102: Establish device-side context

[0050] The Key-Value API library sends the extended command KV_StartTransaction to KVSSD, notifying the device that a new transaction is about to begin. Upon receiving this command, the KVSSD firmware's front-end controller (FE) pre-allocates context space for the transaction in its non-volatile controller memory, including a log buffer and tracking transaction status information. After initialization, it returns a "SUCCESS" status code.

[0051] S103~S105: Intercept operations and generate versions

[0052] During transaction execution, all key-value pair operations such as KV_Put and KV_Delete are intercepted by the API library. The operation information is recorded in the log buffer of the non-volatile controller's memory. Each record contains the key, operation type, old value, new value, and a version number (VersionID) generated by the transaction ID and the system's globally incrementing version information. The data is organized in the form of Key@VersionID and temporarily stored in the non-volatile controller's memory, without directly updating the hardware data area.

[0053] Before each write operation, the system queries the latest system-global incremented version information of the target key and compares it with the version assigned to the current transaction to determine whether there is a write-write conflict. If a conflict exists and the isolation level is RC mode, the transaction is terminated immediately and the application is notified. If it is RR mode, a retry is marked to avoid dirty writes.

[0054] S106: Write-ahead and persistent logs

[0055] When a transaction is ready to commit, the API library packages the log entries in the local log buffer and calls the KV_LogAppend command to write the operation log entries to the dedicated ZNS log area within KVSSD. This area uses a sequential append mode to maximize write efficiency. After receiving the log entries, KVSSD uses the FUA mechanism to ensure that the operation log entries are forced to be written to the NAND flash memory to prevent loss in the event of a power outage. The initial state of the log entries is set to "uncommitted," but their content is already guaranteed to be persistent.

[0056] S107~S109: Atomic Submission

[0057] After receiving confirmation of log persistence, the API library sends the KV_CommitTransaction(TxID) command.

[0058] KVSSD performs the following actions: updates the status of the corresponding log entry to "committed"; uses FUA again to ensure the state change is persistent; the version control module marks the new version as committed, atomically completing the update of all keys; and releases the context resources occupied by the transaction. The entire process is completed internally by the device, without requiring host-side data writing or state synchronization, and returns a success response after the commit is complete.

[0059] S110~S112: Rollback Processing

[0060] When a transaction needs to be aborted due to a failed conflict detection, timeout, or a voluntary call to kv_rollback(), the API library sends the KV_RollbackTransaction(TxID) command.

[0061] KVSSD automatically performs the reverse operation based on the old value information saved in the log: it deletes the newly written Key@VersionID version; if an old value exists, it restores it to the latest visible version; and it marks the log status as "rollback". This mechanism allows the rollback operation to be completed entirely within the storage layer, significantly reducing the burden on the host side.

[0062] S113: Fault Recovery

[0063] See Figure 2After the system restarts, KVSSD automatically scans the ZNS log area to identify transactions in an intermediate state: for log entries with a status of "uncommitted", it performs a rollback operation; for transactions with a status of "committed" but whose data has not yet fully taken effect, it completes the version activation process.

[0064] This mechanism ensures that the system can recover to a consistent state after a power outage or crash, meeting the durability and consistency requirements of ACID.

[0065] This embodiment accelerates key performance bottlenecks in transactions (such as log persistence and version data writing) by offloading them to KVSSD. It utilizes ZNS log area, FUA persistence, and multi-version control mechanism to achieve low-latency, high-throughput transaction processing capabilities, making it suitable for high-performance scenarios such as databases and distributed storage.

[0066] Example 2: A transaction acceleration system based on key-value solid-state drives

[0067] like Figure 3 As shown, this invention also provides a KVSSD-based transaction acceleration system for implementing the transaction acceleration method described in Embodiment 1. The system adopts a layered architecture, mainly comprising two core components: a software storage layer Key-Value API library and a hardware storage medium KVSSD. It interacts efficiently through an extended NVMe-KV transaction command set.

[0068] 1. System Deployment Environment

[0069] This embodiment is deployed on an ARMv8.2 architecture server (CPU: Ampere Altra Max, 128 cores, 3.0GHz, memory: 128GB DDR4-3200), running a Linux kernel. The KVSSD uses an NVMe 2.0 protocol-compatible device, configured with 2TB 3D TLC NAND flash memory and 16GB DRAM, supporting ZNS (dividing into 2048 Log Zones, 1GB capacity per Zone, sequential write bandwidth ≥2GB / s) and FUA commands, communicating with the host via a PCIe 4.0 x4 interface. The Key-Value API library is provided as a dynamic link library (libkv_tx.so), optimized based on the ARM64 instruction set, compatible with C / C++ / Java calling interfaces, and can interface with existing KV storage systems such as RocksDB and Redis, fully leveraging the high energy efficiency and multi-core concurrency advantages of the ARM architecture.

[0070] 2. Detailed Implementation of Core Modules

[0071] 2.1 Key-Value API Library

[0072] Transaction management module: Generates a 64-bit globally unique TxID; maintains a transaction state machine (txInit→txSubmitted→txCommitted→txFinished / txRolledBack / txTimeout), supports 4-level priority scheduling (levels 0-3), and allows high-priority transactions to preempt the I / O queue resources of low-priority transactions, avoiding long transactions blocking short transactions.

[0073] Conflict detection module: In RC isolation level, a conflict will return error code 0x8001 and terminate the transaction; In RR isolation level, a maximum of 3 retries will be triggered (retry interval 15ms), and 0x8002 will be returned if the retry fails.

[0074] Log management module: The memory log buffer is 4MB by default. The log entry format is "TxID (8B)+KeyLen (2B)+Key (nB)+OpType (1B, Put=0x01 / Delete=0x02)+VersionID (8B)+Checksum (4B)". CRC32 verification is performed before calling KV_LogAppend to avoid log corruption.

[0075] Version control module: Manages and maintains a multi-version data chain for each key in memory and persists it to KVSSD, where the key is Key@VersionChain and the value is the multi-version data chain. It uses a 64-bit atomic global version counter (incrementing by 1 for each transaction commit) to distinguish versions by the Key@VersionID naming key.

[0076] 2.2 KVSSD (Device Side)

[0077] Figure 4 The overall block diagram of the control core of KVSSD provided in this embodiment of the invention specifically includes:

[0078] Front-end controller (FE): Extends four transaction-specific commands within the NVMe 2.0 standard command space: KV_StartTransaction, KV_CommitTransaction, KV_RollbackTransaction, and KV_LogAppend for atomic log appending. Extends the interface response latency to ≤10μs.

[0079] Key-Value Processor (KV-Core): As the computational core of KVSSD, it is responsible for executing the storage, retrieval, and management logic of key-value data. It directly processes KV commands (such as Put, Get, Delete) from the host and collaborates with the Front-End Controller (FE) to handle extended transaction commands. In memory management, a SkipList structure with pre-allocated fixed memory is used to maintain the hot data index, and the Value is stored in an independent memory pool. Combined with a Bloom filter integrated into the meta-key, millisecond-level key-value retrieval is achieved. The persistence layer is built on SSTable, employing a key-value separation design (keys are not compressed) to optimize read performance. An AB dual-index table mechanism and the associated maximum transaction number ensure power-loss safety during merging operations and system states.

[0080] Flash Translation Layer (FTL): Responsible for managing the mapping from the logical address space of KVSSD to the physical address space of NAND flash memory, and performing functions such as garbage collection and wear leveling.

[0081] Backend interaction component (BE): Responsible for direct interaction with NAND flash memory chips, performing the final write and read operations of data.

[0082] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described transaction acceleration method based on a key-value solid-state drive.

[0083] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described transaction acceleration method based on a key-value solid-state drive.

[0084] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0085] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0086] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0087] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0088] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A transaction acceleration method based on key-value solid-state drives, characterized in that, KVSSD extends the NVMe 2.0 standard key-value command set with the following commands: start transaction, commit transaction, rollback transaction, and atomic append write command to the log, including the following steps: Transaction initialization steps: The host calls the Key-Value API library to create a new transaction and pre-allocates the transaction context in the non-volatile controller memory of KVSSD; Operation capture and version generation steps: The Key-Value API library intercepts key-value operations within a transaction and records the generated operation log entries to the transaction log buffer in the memory of the non-volatile controller; the operation log entries include a version number; Conflict detection and isolation control steps: Optimistic concurrency control is performed based on the system's globally incremental version information, and conflict handling is carried out according to the transaction isolation level; Write-ahead log persistence steps: If there are no conflicts, the Key-Value API library sequentially writes operation log entries to the non-volatile log area of ​​KVSSD using atomic append write commands, and uses the FUA mechanism to ensure log persistence; Transaction commit steps: After the log is persisted, the Key-Value API library sends a commit command, and KVSSD atomically updates the data version and releases transaction resources through the commit command; Transaction rollback steps: If a transaction fails, times out, or is actively aborted, the Key-Value API library sends a rollback command, and KVSSD restores the data to its pre-transaction state based on the log records using the rollback command.

2. The method according to claim 1, characterized in that, In the transaction initialization step, the transaction context is stored in the non-volatile controller memory of the KVSSD for restoring the transaction state after a power outage.

3. The method according to claim 1, characterized in that, In the write-ahead log persistence step, the non-volatile log area is divided based on Zoned Namespace technology, supports sequential append writing, and is physically isolated from the data area.

4. The method according to claim 1, characterized in that, In the conflict detection and isolation control steps, the conflict handling strategy includes: immediately terminating conflicting transactions under the read committed isolation level, and triggering a transaction retry mechanism under the repeatable read isolation level.

5. The method according to claim 1, characterized in that, The method also includes a high-concurrency transaction optimization step, specifically including: interleaving the logs of multiple transactions into the same log area, allocating independent input / output queues for transactions of different priorities, and scheduling them by time slice.

6. The method according to claim 1, characterized in that, The method also includes a fault recovery step, specifically: after the system restarts, KVSSD automatically scans the non-volatile log area to identify transactions in an intermediate state: for log entries with a state of "uncommitted", a rollback operation is performed; for transactions with a state of "committed" but whose data has not yet fully taken effect, the version activation process is completed; wherein, the initial state of the log entry is set to "uncommitted", and when the transaction commit step is performed, its state is updated to "committed".

7. A transaction acceleration system based on key-value solid-state drives, characterized in that, For implementing the method of any one of claims 1-6, the system includes a software storage layer Key-Value API library and a hardware storage medium KVSSD provided for host software to call; The Key-Value API library includes: The transaction management module is configured to handle the creation, scheduling, and status maintenance of transactions. The log management module is configured to manage the in-memory transaction log buffer and call the device-side log write command; The version control module is configured to generate and manage multi-version data chains of keys; The conflict detection module is configured to perform optimistic concurrency control based on globally incrementing version information; The KVSSD includes the following modules in its firmware library: The Front-End Controller (FE) is responsible for communicating with the host, parsing host commands, and processing the NVMe protocol. The key-value processor (KV-Core) is responsible for key-value data storage and retrieval. The Flash Translation Layer (FTL) is responsible for mapping the logical address space to the NAND storage space. The backend interaction component BE is responsible for writing and reading NAND data. The Front-End Controller (FE) extends the NVMe 2.0 standard key-value command set with the following commands: start transaction, commit transaction, rollback transaction, and log atomic append write command; the Key-Value Processor (KV-Core) is responsible for coordinating with the Front-End Controller (FE) to process the extended transaction commands.

8. The system according to claim 7, characterized in that, The version control module distinguishes different versions of data by combining the key name and the version number to form a unique identifier, and persistently stores the multi-version data chain of the key in KVSSD.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 6.

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

Images