WO2025042576A2 - Procédés et systèmes configurés pour éliminer l'utilisation de journaux d'écriture anticipée dans des magasins de valeurs clés de mappage direct par radiomessagerie - Google Patents

Procédés et systèmes configurés pour éliminer l'utilisation de journaux d'écriture anticipée dans des magasins de valeurs clés de mappage direct par radiomessagerie Download PDF

Info

Publication number
WO2025042576A2
WO2025042576A2 PCT/US2024/041093 US2024041093W WO2025042576A2 WO 2025042576 A2 WO2025042576 A2 WO 2025042576A2 US 2024041093 W US2024041093 W US 2024041093W WO 2025042576 A2 WO2025042576 A2 WO 2025042576A2
Authority
WO
WIPO (PCT)
Prior art keywords
metadata
value
keys
atomickeytag
transaction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/US2024/041093
Other languages
English (en)
Other versions
WO2025042576A3 (fr
Inventor
Andrew John TOMLIN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qistor Inc
Original Assignee
Qistor Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qistor Inc filed Critical Qistor Inc
Publication of WO2025042576A2 publication Critical patent/WO2025042576A2/fr
Publication of WO2025042576A3 publication Critical patent/WO2025042576A3/fr
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing

Definitions

  • Disk and flash storage devices such as Hard Disk Drives and Solid-State Drives provide block-based storage via their interfaces.
  • block-based storage devices have standardized logical interfaces to map fixed-size blocks 102, typically 512 bytes or 4096 bytes of data, to a logical block address (LBA) 104. Examples of these interfaces include NVMe, SATA and SCSI.
  • a common storage mapping interface abstraction that is used to map variable-sized pieces of user data is known as Key-Value, as shown in Fig. IB.
  • This abstraction provides an application-friendly interface to the storage system by associating each piece of data (the Value) 108 with a unique identifier (the Key) 106, a user-defined reference.
  • the Key 106 is user- defined, it is an abstraction that does not rely on the physical location of the data, which is a problem delegated to lower levels.
  • the user supplies both the Key 106 and the Value datal08 for storage operations, while for retrieval operations, the user provides the Key 106, and the system returns the corresponding Value data 108.
  • Key-Value mapping allows for rapid and efficient data access, as the Key 106 directly links to the Value data 108.
  • the simplicity and versatility of Key-Value stores enable them to handle a wide variety of data types, making Key- Value stores particularly suitable for scalable and adaptable data management solutions. These characteristics render Key- Value stores a fundamental component in contemporary data storage and retrieval systems, providing significant performance benefits and operational efficiency.
  • the LBA 104 is a device-supplied reference to a fixed- size block 102 in a linear address space 105, while Key- Value is a user- supplied reference to a variable-sized block of data.
  • the Key 106 is a number of user-defined bytes of user-defined length (up to a maximum number), and importantly, unlike an LBA-style mapping system, the Key 106 does not necessarily reference a contiguous set of addresses.
  • Key- Value mapping systems While convenient for applications, Key- Value mapping systems present several implementation challenges that simple LBA mapping schemes do not. These include: the Key is not fixed in size; the Key is user-defined; the mapping space is not contiguous; the Value is variable sized, and a variable number of Key-Value data may exist in a predetermined storage capacity.
  • FIG. 1A is a diagram of a conventional logical block address based data storage system.
  • Fig. IB is a representation of a Key-Value store system.
  • Fig. 2 shows a basic diagram of a paged direct mapping Key- Value store that may be configured according to embodiments.
  • Fig. 3 is a block diagram illustrating a Key- Value store implementing a conventional Log Structure Merge (LSM) system.
  • LSM Log Structure Merge
  • Fig. 4 shows a multi-command transaction.
  • Fig. 5 is a block diagram illustrating a transaction define sequence.
  • Fig. 6 is a block diagram showing a duplicate Key detector, according to embodiments.
  • Fig. 7 is a representation of a TransactionLogPage, according to embodiments.
  • Fig. 8 Fig. 8 shows the state of the media after the initial TransactionLogPage write, according to embodiments.
  • FIG. 9 shows the logical relationship between the AtomicTransactionTag, the AtomicKeyTag and the UserKeys, according to embodiments.
  • Fig. 10 is a diagram illustrating the one-to-one mapping of a UserKey to Value data.
  • Fig. 11 shows a manner in which a UserKey may be mapped to both an original Value (before execution of the multi-command transaction) and a pending Value (after execution of the multi-command transaction), according to embodiments.
  • Fig. 12 shows the manner in which the UserKey corresponds to an AtomicKeyTag, which may be encoded as a Location pointing to both the original Value and the pending Value, according to embodiments.
  • FIG. 13 shows the structure of one possible implementation of an AtomicTransactionTag table and an AtomicKeyTag table, according to an embodiments.
  • Fig. 14 shows an incomplete TransactionLogPage stored in media, according to embodiments.
  • Fig. 15 shows a complete TransactionLogPage stored in media, according to embodiments.
  • Fig. 16 is a flowchart of a computer-implemented method of processing a multicommand transaction in a Key- Value store, including the processing that occurs when an Abort is detected, according to embodiments.
  • Fig. 17 is a flowchart of a computer-implemented method of power fail recovery in a Key- Value store according to embodiments.
  • an LSM system may include an Application 302 that issues write and read commands, Memory (e.g., Random Access Memory or RAM) 304 and persistent storage (e.g., a disk including rotating media and/or a solid state device such as Flash memory) 306.
  • Memory e.g., Random Access Memory or RAM
  • persistent storage e.g., a disk including rotating media and/or a solid state device such as Flash memory
  • the memory 304 stores a Memtable 308, which is an in-memory table that enables fast write operations.
  • WAL Write Ahead Log
  • the LSM tree goes to disk 306 and uses a so-called Bloom Filter to repeatedly search the indices to determine a probability that the data of interest is located in one of the n SSTables 312, starting at L0 and moving down as needed. After determining that the Value data is likely to be present in a particular one of the SSTables, the LSM tree searches that table and if the data of interest is present therein, returns the value.
  • Key-Value storage is for database applications. Key- Value is commonly used as the storage engine layer in these databases and other similar applications. In these applications, it is desirable to be able to atomically write multiple separate Key-Value pairs at the same time, as a single transaction.
  • Fig. 5 is a block diagram illustrating a transaction define sequence.
  • a transaction define sequence is a sequence comprising a Transaction Define command 502 and a List of Keys 0-n 504 to be handled atomically provided at the beginning of the sequence.
  • the Transaction Define 502 and the List of Keys 504 is then followed by a plurality of Key- Value pairs 5O6o to 506 n .
  • the Transaction Define command is considered completed when the storage of all Keys 0-n are acknowledged, or via completion of the Transaction Define command 502 depending on interface semantics.
  • the Duplicate Key Detector functionality of Fig. 6 is primarily a mechanism to detect host error, potentially from independent hosts, such as multiple writes of the same Key that would otherwise result in incorrect count of updates and identification of transaction completion.
  • the Hash table 602 may be consulted for a match for every command entering the device to detect Key overlaps. Note that other implementations are possible, such as red/black tree, AVL tree, or a brute force search. An alternate implementation can forgo this duplicate check and still guarantee the transaction, as the embodiments disclosed herein can still guarantee the atomicity.
  • the structure and functionality of Fig. 6 is an implementation that is configured to quickly detect and return errors to the host.
  • the AtomicTransactionTag 701 assigned to the List of Keys 504 and each UserKey and Atomic Metadata of the multi-command transaction is also written to the media in a TransactionLogPage 702 at this time to allow the detection of various cases and recovery in event of power cycle.
  • the TransactionLogPage 702 may be configured to provide a running record of the multi-command transaction as it executes or, in the case of a power fail recovery, as the multi-command transaction was executed, either partially or to completion.
  • the TransactionLogPage 702, as shown in Fig. 7, may include an AtomicTransactionTag 701.
  • a Count field in the TransactionLogPage 702 indicates the number of UserKeys present in the TransactionLogPage 702.
  • each TransactionLogPage includes a list of the 0-n UserKeys in the Transaction Define sequence, each being associated with Atomic Metadata.
  • Fig. 8 shows the state of the media immediately after the initial TransactionLogPage Write and before any Value data corresponding to the UserKeys has been written. Note that the Atomic Metadata information associated with each UserKey in the TransactionLogPage 702 is marked as “Invalid” in this initial write.
  • Fig. 9 shows the logical relationship between the AtomicTransactionTag, the AtomicKeyTag and the UserKeys.
  • the AtomicKeyTags 902 may be allocated at the beginning of the transaction, or the AtomicKeyTag may be allocated upon arrival of the actual UscrKcy.
  • the AtomicKeyTag 902 may be encoded in the system as a special location within a predetermined portion of the media address range. That is, for a small number of locations at, for example, the end of the media address range, instead of the location corresponding to a physical location, the location is instead interpreted as an AtomicKeyTag corresponding to a UserKey.
  • the AtomicKeyTag 902 is handled in a similar fashion as location, it can be handled as a regular location update for most of the system.
  • An alternate embodiment may be configuring other parts of the Atomic Metadata, including a flag or other unique and otherwise illegal metadata configurations to indicate that the metadata refers to an AtomicKeyTag 902.
  • a significant element is that the system, when accessing the metadata, can determine that it is an in-process transaction and redirect to the appropriate control information.
  • the Key- Value metadata mapping system is designed to manage the one-to-one mapping of Keys to locations. Indeed, such a metadata mapping system relies on the concept that for every Key there is a unique item of metadata that indicates the size and location of the data. In a paged system, the metadata page where the metadata corresponding to a Key of interest is specified is often not present in Random Access Memory (RAM) but is stored on media and must be identified and paged into memory.
  • RAM Random Access Memory
  • the primary challenge of managing the transaction is that during the transaction process, there are two versions of the Value data corresponding to a UserKey: the original Value 1102 and the new pending Value 1104, as shown in Fig. 11.
  • the new pending Value 1104 is the Value data after the transaction, assuming the transaction or this portion of the transaction completes. According to embodiments, there can be no assumptions on which Value (original or pending) will ultimately be valid until the transaction define completes or fails in its entirety. This must hold true even in the event of a power cycle.
  • the AtomicKeyTag may be encoded into a media location (thereby generating the Encoded AtomicKeyTag 1204), which replaces the actual metadata tracked by the Key-Value metadata mapping system to enable an additional level of indirection.
  • this indirection allows the management of two metadata items, one metadata item storing the original Value metadata (the OriginalValue 1206) prior to the transaction or after the failure of the transaction and the other item storing the pending Value metadata (the Pending Value 1208) as it would be after the transaction, assuming the transaction completes.
  • the details of the additional indirection can be hidden from most of the metadata mapping system, as being referenced simply as the Encoded AtomicKeyTag, which is treated by the metadata mapping system as a location, thereby simplifying the overall complexity.
  • the metadata management system manages the one-to-one mapping of Keys to location and size metadata.
  • the location may be specified using n-bits, and the size may be specified using m-bits.
  • the n location bits and m size bits can be used, according to embodiments, for purposes other than indicating location and size metadata.
  • a size value that exceeds a predetermined maximum allowable size may be re-interpreted as a flag that indicates that the n location bits should be interpreted not as a location but as the AtomicKeyTag 902.
  • entries at locations within a predetermined portion of the media or predetermined portion of the addressing range (such as at the end of the addressing range) of the media may be interpreted as AtomicKeyTags instead of locations.
  • any normal operations such as garbage collection, reads, and other management operation can proceed unaffected by the additional abstraction. If the operation requires use of the location, the Encoded AtomicKeyTag can be detected and the location information of either the original value or the pending value may be retrieved via the AtomicKeyTag as needed.
  • the pending Value data may not yet be written by the host (depending on AtomicKeyTag allocation method).
  • the host includes a reference to the transaction so the updates can be identified as part of the transaction. Should some other host attempt to update a Key that is part of a transaction, this can be detected using the AtomicKeyTag encoded in the location, or via the Duplicate Key Detector as discussed relative to Fig. 6. On detection, various behaviors arc possible depending on API and system requirements, most likely aborting the transaction.
  • the Atomic Metadata generated from the writes of the pending values may be temporarily stored in the AtomicKeyTag table 1302, which is indexed by Atomic KeyTag 902.
  • Each entry in the AtomicKeyTag table 1302 indexed by the AtomicKeyTag 902 may include the AtomicTransactionTag to identify the multi-command transaction, the AtomicMetadata, which is the metadata of the Pending Value 1208 and the OriginalMetadata, which is the metadata of the OriginalValue 1206, to enable the system to back out of a transaction and restore original Value data and the corresponding metadata thereof should the command fail.
  • Several entries in the AtomicKeyTag table 1302 may list the same AtomicTransactionTag 504.
  • the AtomicTransactionTag 504 is used to index into the AtomicTransactionTag Table 1304, which may include head and tail location pointers for the list of AtomicKeyTags 902 specified by the AtomicTransactionTag 504.
  • the metadata of list of Keys that is written as the initial part of the transaction, ListMetadata may also be tracked in the AtomicTransactionTag table 1304, along with a count of the AtomicKeyTags 902 corresponding to the UserKeys specified by the multi-command transaction identified by the AtomicTransactionTag 504.
  • Atomic Metadata updates may also be stored in the AtomicMetadata field in the AtomicKeyTag table 1302.
  • the new key-Value data is written with an AtomicHeader in the media, which AtomicHeader includes a field for the AtomicTransactionTag.
  • Figure 14 shows the Media during execution of the multi-command transaction, after writing some (in this case, two) but not all of the Keys of the transaction.
  • the TransactionLogPage 702 will be discovered and, as only two of the Keys are written, the Atomic Metadata corresponding to the writes of the two Keys will be discarded, such that the metadata mapping system no longer tracks the written Keys, as if they never existed. It may be necessary for management purposes to rewrite the TransactionLogPage. If this is necessary, the location information for any previously written Keys would also be saved.
  • the difference between the partial transaction and completed transaction cases can be determined from the TransactionLogPage.
  • the TransactionLogPage includes a Count of the AtomicTransactionTags. Therefore, the Count of the AtomicHeaders / Key Values present in the TransactionLogPage may be used to determine whether the transaction has failed/was only partially completed (Fig. 14) or has completed (Fig. 15). Any unwritten Atomic Metadata lost during a power cycle can be reconstructed for completed transactions or discarded for partial transactions.
  • Fig. 16 is a flow chart of a computer- implemented method according to an embodiment, detailing steps taken for a completed multi-command transaction and an aborted transaction.
  • a transaction may begin at 1602, whereupon a multi-command transaction may be received and a corresponding TransactionLogPage may be written, as shown at 1604.
  • the TransactionLogPage 702 includes the AtomicTransactionTag assigned to the list of Keys and each constituent UserKey and location of the List of Keys 504.
  • the AbortTransactionLogPage referred to at 1608 may have the same structure as the TransactionLogPage 702 of Figs. 7 and 8, but for the presence of a different header that indicates that this TransactionLogPage is, in fact, an AbortTransactionLogPage.
  • the AbortTransactionLogPage provides a persistent record of the failure of the underlying multi-command transaction.
  • the original metadata may be restored the metadata mapping system, as shown at 1610. Indeed, if a transaction is aborted, the Original Metadata (OriginalMetadata in Fig. 13) saved in the AtomicKeyTag table 1302 may be used to replace the AtomicKeyTag currently in the metadata management system.
  • the restoration of the original metadata may not require an actual update, as the original metadata was not changed.
  • implementation simplicity may recommend performing the update to media, even if the original metadata is replaced with the identical metadata (the Original Metadata) from the AtomicKeyTag table 1302.
  • a transaction log with failure indication (the AbortTransactionLogPage referred to at 1608) may be written to the media.
  • the AbortTransactionLogPage allows for simplified detection of aborted transaction during power-fail recovery, as detailed relative to Fig. 17. In Fig. 16, after the original metadata has been restored following an abort, the end of the aborted transaction is reached at 1612.
  • FIG. 1 Another embodiment is a Key- Value data store configured to implement a multicommand transaction, comprising: a storage device, the storage device being configured to store and enable access to user data via a key-value system; a memory; at least one processor, and a plurality of processes spawned by the processor.
  • another embodiment is a computer-implemented method of recovering from a power failure in a Key- Value store implementing a multi-command transaction.
  • Such a method may comprise, as shown at B 191, finding, and reading a TransactionLogPage in media, the TransactionLogPage being configured to provide a running record of the multicommand transaction as the multi-command transaction was executed.
  • the TransactionLogPage may comprise at least an AtomicTransactionTag assigned to the multi-command transaction, a count of the n keys of the multi-command transaction, and the n keys.
  • it may be determined whether or not the TransactionLogPage is an AbortTransactionLogPage that is indicative of a failure of an execution of the milt-command transaction.
  • the TransactionLogPage in the media may be scanned for value data for which no updated Atomic metadata has been recorded. If such value data for which no Atomic Metadata was recorded is found, the Atomic Metadata thereof may be recorded, as shown at Bl 93.
  • either block B 194 or B 195 may be carried out.
  • it may then be determined that the multi-command transaction has been completed by determining that, for each of the n keys, Value data has been written to the TransactionLogPage and corresponding updated Atomic Metadata has been recorded. All saved and updated Atomic metadata may then be saved to the metadata mapping system.
  • all updated Atomic Metadata may be discarded.
  • an AtomicKeyTag may be assigned for each of the n keys, each AtomicKeyTag being associated with an original value and a pending value and each AtomicKeyTag is encoded as a predetermined location in the media.
  • an AtomicKeyTag may be assigned to each of the n keys and each AtomicKeyTag being associated with an original value and a pending value and the computer-implemented method may further comprise configuring the metadata mapping system to manage both the original value and the pending value using a flag, a unique metadata configuration or an illegal metadata configuration to refer to at least one of the AtomicKeyTags.
  • Recording the updated Atomic Metadata may include writing the updated Atomic Metadata in an AtomicKcyTag tabic that is indexed by the AtomicKeyTag of each of the n keys.
  • the AtomicKeyTag table may include Original Metadata of an original value data prior to the multi-command transaction and Atomic Metadata of the written Value data.
  • Fig. 20 a computer system configured to execute the computer-implemented methods shown and described herein.
  • the computer system may comprise at least storage media 2004, 2005, 2006, at least one processor 2008, memory 2010 and a network interface 2013.
  • a plurality of processes may be spawned by the processor 2008, which plurality of processes may comprise processing logic to carry out the computer-implemented methods and functionality shown and described at least relative to Figs. IB, 2 and 4-19.
  • FIG. 20 also shows exemplary tangible, non-transitory computer-readable media 2018 having data stored thereon representing sequences of instructions which, when executed by the computer system, cause the computer system to carry out a computer-implemented method of implementing a multicommand transaction in a Key- Value store and a computer-implemented method of recovering from a power failure in a Key- Value store implementing a multi-command transaction according to one or more of the embodiments described herein.
  • the computer system may comprise direct access data storage devices such as magnetic disks 2004, non-volatile semiconductor memories (EEPROM, Flash, etc.) 2006, a hybrid data storage device 2005 comprising both magnetic disks 2004 and non-volatile semiconductor memories, one or more microprocessors 2008 and volatile memory 2010.
  • the computer system may also comprise a network interface 2013, configured to communicate over network 2014 with remote servers, storage services and the like.
  • References 2004, 2005, 2006 and 2018 are examples of tangible, non-transitory computer-readable media having data stored thereon representing sequences of instructions or processing logic which, when executed by the computer system, cause the computer system to carry out the computer implemented methods described herein and shown at least relative to Figs. IB, 2 and 4-19.
  • Some of these instructions may be stored locally in the computer system 2002, while others of these instructions may be stored (and/or executed) remotely and communicated to the computer system 2002 over the network 2014. In other embodiments, all these instructions may be stored locally in the computer system 2002, while in still other embodiments, all of these instructions are stored and executed remotely, and the results communicated to the computer system 2002. In another embodiment, the instructions may be stored on another form of a tangible, non-transitory computer readable medium, such as shown at 2018.
  • reference 2018 may be implemented as an optical or magnetic disk, which may constitute a suitable data carrier to load the instructions stored thereon onto the computer system 2002, thereby re-configuring the computer system to one or more of the embodiments described and shown herein.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé mis en œuvre par ordinateur de mise en œuvre d'une transaction à commandes multiples dans un magasin de valeurs clés consistant à recevoir la transaction qui comprend une liste de clés, des commandes séparées et des données de valeur pour chacune des clés. Une page de journal de transaction peut être écrite dans des supports, avec une balise de transaction atomique attribuée à la transaction, un comptage des clés, des clés et des métadonnées atomiques correspondant à chacune des clés. Une balise de clé atomique peut être attribuée à chacune des clés, chacune associée à une valeur d'origine et à une valeur en attente et chaque balise de clé atomique peut être codée en tant qu'emplacement dans le support. Une commande correspondant à chacune des clés peut être reçue pour écrire les données de valeur en tant que valeur en attente correspondant à chacune des balises de clé atomiques dans le support conjointement avec un en-tête identifiant la balise de transaction atomique. Des métadonnées atomiques peuvent être mises à jour et stockées temporairement pour chacune des valeurs en attente écrites. Lorsqu'un abandon est détecté indiquant que la transaction a échoué ou a été interrompue, la page de journal de transaction peut être réécrite sous la forme d'une page de journal de transaction abandonnée qui identifie la balise de transaction atomique défaillante et les métadonnées d'origine peuvent être restaurées au système de mappage de métadonnées. En variante, lorsque toutes les données de valeur ont été écrites pour chaque balise de clé atomique et les métadonnées atomiques pour chacune des valeurs en attente écrites ont été mises à jour et stockées temporairement, le système de mappage de métadonnées peut être mis à jour à l'aide des métadonnées atomiques.
PCT/US2024/041093 2023-08-24 2024-08-06 Procédés et systèmes configurés pour éliminer l'utilisation de journaux d'écriture anticipée dans des magasins de valeurs clés de mappage direct par radiomessagerie Pending WO2025042576A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202363578513P 2023-08-24 2023-08-24
US63/578,513 2023-08-24

Publications (2)

Publication Number Publication Date
WO2025042576A2 true WO2025042576A2 (fr) 2025-02-27
WO2025042576A3 WO2025042576A3 (fr) 2025-04-17

Family

ID=94732704

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2024/041093 Pending WO2025042576A2 (fr) 2023-08-24 2024-08-06 Procédés et systèmes configurés pour éliminer l'utilisation de journaux d'écriture anticipée dans des magasins de valeurs clés de mappage direct par radiomessagerie

Country Status (1)

Country Link
WO (1) WO2025042576A2 (fr)

Also Published As

Publication number Publication date
WO2025042576A3 (fr) 2025-04-17

Similar Documents

Publication Publication Date Title
US11449430B2 (en) Key-value store architecture for key-value devices
EP3485377B1 (fr) Reparation connectee de blocs de donnees corrompues
US10176190B2 (en) Data integrity and loss resistance in high performance and high capacity storage deduplication
US10564850B1 (en) Managing known data patterns for deduplication
US9170938B1 (en) Method and system for atomically writing scattered information in a solid state storage device
US8620884B2 (en) Scalable blob storage integrated with scalable structured storage
EP2454691B1 (fr) Architecture de stockage de base de données
US8280858B2 (en) Storage pool scrubbing with concurrent snapshots
EP1739535B1 (fr) Système de fichiers pour enregistrer des données de transaction dans des supports de stockage de type flash
US8112607B2 (en) Method and system for managing large write-once tables in shadow page databases
US11841801B2 (en) Metadata management in non-volatile memory devices using in-memory journal
US20130311521A1 (en) Blob manipulation in an integrated structured storage system
JP7580371B2 (ja) トライデータ構造ベースのデータベースのための効率的なインメモリマルチバージョン同時実行制御
CN112597254B (zh) 面向混合dram-nvm主存的联机事务型数据库系统
US8108356B2 (en) Method for recovering data in a storage system
CN113515501B (zh) 非易失性内存数据库管理系统恢复方法、装置和电子设备
Xu et al. Building a fast and efficient lsm-tree store by integrating local storage with cloud storage
US20120317384A1 (en) Data storage method
WO2025042576A2 (fr) Procédés et systèmes configurés pour éliminer l'utilisation de journaux d'écriture anticipée dans des magasins de valeurs clés de mappage direct par radiomessagerie
US7281188B1 (en) Method and system for detecting and correcting data errors using data permutations
CN118502682B (zh) 数据存储方法、设备、介质和计算机程序产品
CN121681229A (zh) 一种数据备份的方法及装置
CN119739688A (zh) 用于分布式存储的通用可配置数据去重架构及方法
CN121979915A (en) Data processing method, apparatus, computer device, storage medium and program product based on shared cache
CN117850682A (zh) 一种基于位图的追加写场景下磁盘管理方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24856998

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE