Software implemented using circuitry and method for key-value storage

Abstract

The present invention discloses a software that can be implemented using a circuit. The software may include an application programming interface (API) to receive requests related to key-value pairs of a key-value solid-state drive (KV-SSD) from an application. The key-value pairs may include a key and a value; the application may be executed by a processor. The software may further include: a combiner software that combines the key with an index to generate an index key; and an execution software that performs an operation on the key-value solid-state drive using the index key and the value. A method for key-value storage is also provided.

Description

[0001] [Related Application Data]

[0002] This application claims the benefit of U.S. Provisional Patent Application Ser. No. 62 / 836,065, filed Apr. 18, 2019, which is incorporated herein by reference for all purposes. Field of the Invention

[0003] The present inventive concept generally relates to computer systems, and more particularly, to enhancing the functionality of key-value solid state drives (KV-SSDs). Background Art

[0004] Key-value storage is the simplest form of a database management system. It can store multiple pairs of keys and values and can also retrieve a value when the key is known. These simple systems are generally not suitable for complex applications without additional features. For example, these systems do not support appending a value to a key.

[0005] There is still a need to support append operations on key-value storage. Summary of the Invention

[0006] According to one aspect of the present inventive concept, there is provided software implemented using circuitry, including an application programming interface, combiner software, and execution software. The application programming interface receives requests related to key-value pairs of a key-value solid state drive from an application, the key-value pairs including a key and a value, and the application is executed by a processor. The combiner software combines the key with an index to generate an index key; the execution software performs an operation on the key-value solid state drive using the index key and the value.

[0007] According to one aspect of the present inventive concept, there is provided a method for key-value storage, including: receiving a write request from an application to store a value associated with a key on a key-value solid state drive as a key-value pair, the application being executed by a processor; determining a base index of the key; combining the base index with the key to generate an index key; and performing a storage operation on the key-value solid state drive to associate the index key with the value.

[0008] According to one aspect of the present inventive concept, there is provided a method for key-value storage, including: receiving an append request from an application to append a second value to a value associated with a key on a key-value solid state drive as a key-value pair, the application being executed by a processor; determining a highest append index of the key; incrementing the highest append index to generate a new highest append index; combining the new highest append index with the key to generate an append index key; and performing a second storage operation on the key-value solid state drive to associate the append index key with the second value. Brief Description of the Drawings

[0009] Figure 1 A machine is shown according to an embodiment of the present invention concept, which is designed to support append operations on values stored in a Key-Value Solid State Drive (KV-SSD) using a Key Value Virtualization (KVV) layer.

[0010] Figure 2 Shown Figure 1 additional details of the machine.

[0011] Figure 3 Shown Figure 1 details of the KV-SSD.

[0012] Figure 4 Shown Figure 1 the application, Figure 1 the KVV, and Figure 1 the KV-SSD, which performs a write operation on the Figure 1 KV-SSD.

[0013] Figure 5 Shown Figure 1 the application, Figure 1 the KVV, and Figure 1 the KV-SSD, which performs an append operation on the Figure 1 KV-SSD.

[0014] Figure 6 Shown Figure 1 the application, Figure 1 the KVV, and Figure 1 the KV-SSD, which performs a read operation on the Figure 1 KV-SSD.

[0015] Figure 7 Shown Figure 1 the application, Figure 1 the KVV, and Figure 1 the KV-SSD, which performs a delete operation on the Figure 1 KV-SSD.

[0016] Figure 8 Shown Figure 1 details of the KVV.

[0017] Fig. 9 Shown Figure 8 The combiner software combines a key with an index to generate an index key.

[0018] Fig.10 Shown is the Figure 1 structure of the metadata according to an embodiment of the present invention concept.

[0019] Fig.11 The second combiner software shown Figure 8 combines a value with metadata to produce a modified value.

[0020] Fig.12 shows various embodiments in accordance with the concepts of the present invention, Figure 8 The index determination software shown Figure 1 can be used to determine different techniques for the highest append index of keys on the KV-SSD shown.

[0021] FIG. 13A to FIG. 13C shows an embodiment in accordance with the concepts of the present invention, Figure 1 The KVV support shown Figure 1 on the KV-SSD shown Figure 4 for a write request is shown in the flowchart of an exemplary procedure.

[0022] FIG. 14A to FIG. 14B shows the flowchart of an exemplary procedure for storing metadata of a key in a hash table shown in an embodiment in accordance with the concepts of the present invention. Figure 1 The flowchart of an exemplary procedure for storing metadata of a key in a hash table shown in an embodiment in accordance with the concepts of the present invention.

[0023] FIG. 15A to FIG. 15B shows an embodiment in accordance with the concepts of the present invention, Figure 1 The KVV support shown Figure 1 on the KV-SSD shown Figure 5 for an append request is shown in the flowchart of an exemplary procedure.

[0024] FIG. 16A to FIG. 16C shows an embodiment in accordance with the concepts of the present invention, Figure 1 The KVV support shown Figure 1 on the KV-SSD shown Figure 6 for a read request is shown in the flowchart of an exemplary procedure.

[0025] FIG. 17A to FIG. 17C shows an embodiment in accordance with the concepts of the present invention, Figure 1 The KVV support shown Figure 1 on the KV-SSD shown Figure 7 for a delete request is shown in the flowchart of an exemplary procedure.

[0026] FIG. 18A to FIG. 18B shows an embodiment in accordance with the concepts of the present invention, Figure 1 The KVV shown Figure 1 on the KV-SSD shown determines the highest append index of a key in the flowchart of an exemplary procedure.

[0027] FIG. 19A to FIG. 19B shows another embodiment in accordance with the concepts of the present invention, Figure 1 The KVV shown Figure 1 on the KV-SSD shown determines the highest append index of a key in the flowchart of an exemplary procedure.

[0028] Fig. 20 Shows yet another embodiment according to the inventive concept, Figure 1 wherein the KVV determines the highest append index of a key on Figure 1 the KV-SSD in an exemplary procedure of a flowchart.

[0029] [Description of symbols]

[0030] 105: Machine;

[0031] 110, 330: Processor;

[0032] 115: Operating system;

[0033] 120: Application;

[0034] 125: Key-Value Solid State Drive / Storage device;

[0035] 130: Memory;

[0036] 135: Memory controller;

[0037] 140: Device driver;

[0038] 145-1, 145-2, 145-3: Key-Value pairs;

[0039] 150-1, 150-2, 150-3: Keys;

[0040] 155-1, 155-2, 155-3: Values;

[0041] 160: Key-Value virtualization;

[0042] 165: Hash table;

[0043] 170-1, 170-2: Metadata;

[0044] 175-1, 175-2: Age;

[0045] 205: Clock;

[0046] 210: Network connection;

[0047] 215: Bus;

[0048] 220: User interface;

[0049] 225: Input / Output engine;

[0050] 305: Host interface logic;

[0051] 310: KV-SSD controller;

[0052] 315-1, 315-2, 315-3, 315-4, 315-5, 315-6, 315-7, 315-8: Flash memory chips;

[0053] 320-1, 320-2, 320-3, 320-4: Channels;

[0054] 325: Conversion layer;

[0055] 405: Write request;

[0056] 410, 415, 430, 510, 515, 525, 530, 610, 620-1, 625, 630, 710, 715-1, 715-2, 720-1, 720-2, 725: Operations;

[0057] 420-1, 420-2, 520: Write operations;

[0058] 425-1, 620-2: Operation / Result;

[0059] 425-2: Result;

[0060] 505: Append request;

[0061] 605: Read request;

[0062] 615-1: Read operation / First read request;

[0063] 615-2: Read operation;

[0064] 705: Delete request;

[0065] 805: API;

[0066] 810: Combiner software;

[0067] 815: Execution software;

[0068] 820: Result software;

[0069] 825: Metadata software;

[0070] 830: Second combiner software;

[0071] 835: Hash table software;

[0072] 840: Eviction software;

[0073] 845: Partitioning software;

[0074] 850: Index determination software;

[0075] 905: Index;

[0076] 910: Index key;

[0077] 1005: Append offset;

[0078] 1010: Append length;

[0079] 1015: Append search structure;

[0080] 1105: Modify value;

[0081] 1305, 1310, 1315, 1320, 1325, 1330, 1340, 1345, 1350, 1355, 1360, 1365, 1370, 1375, 1380, 1385, 1405, 1410, 1415, 1425, 1430, 1435, 1440, 1445, 1450, 1455, 1505, 1510, 1515, 1520, 1525, 1530, 1535, 1540, 1545, 1605, 1610, 1615, 1625, 1630, 1635, 1645, 1650, 1655, 1660, 1665, 1670, 1675, 1680, 1685, 1705, 1710, 1715, 1720, 1725, 1730, 1735, 1740, 1745, 1750, 1755, 1760, 1770, 1805, 1810, 1815, 1820, 1825, 1830, 1835, 1905, 1910, 1915, 1920, 1925, 1930, 1940, 1945, 1950, 2005, 2010: Boxes;

[0082] 1420, 1620, 1640, 1765: Dashed lines. Detailed implementation

[0083] Now, embodiments of the present invention concept will be described in detail, examples of which are shown in the accompanying drawings. In the following detailed description, many specific details are set forth in order to provide a thorough understanding of the present invention concept. However, it should be understood that those of ordinary skill in the art may practice the present invention concept without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure various aspects of the embodiments.

[0084] It will be understood that although the terms "first", "second", etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish between the elements. For example, without departing from the scope of the present invention concept, the first module may be referred to as the second module, and similarly, the second module may be referred to as the first module.

[0085] In this document, the terms used in the description of the inventive concept are for the purpose of describing particular embodiments only and are not intended to limit the inventive concept. Unless clearly stated otherwise in the context, the singular forms "a," "an," and "the" used in the description of the inventive concept and the appended claims are also intended to include the plural forms. It will also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the term "comprises and / or comprising," when used in this specification, specifies the presence of the stated features, integers, steps, operations, elements, and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. The components and features of the drawings do not have to be drawn to scale.

[0086] At a high level, additional functionality can write each addition as a separate key-value pair to maintain an in-memory least recently used (LRU) hash table. For persistence, the key metadata can prefix each value written to the KV-SSD. The architecture can be implemented as a layer between an application and a key-value solid-state drive (KV-SSD) (e.g., within an operating system) or as a layer between the operating system and the KV-SSD (or within firmware on the KV-SSD itself).

[0087] To perform an append operation, a separate key-value pair can be written to the KV-SSD. The original key can be prefixed with two bytes of the sequence number of the append index ('append index'), although other lengths of append index can also be supported. When data is written to the KV-SSD for the first time for a key, the append index used can be 0, or the key can remain unchanged.

[0088] For each key, in-memory data structures can be maintained in the LRU hash table to keep track of appends. If the in-memory LRU hash table lacks space to store a new key, an existing key can be selected for eviction. The techniques described in the following paper can be implemented to provide concurrent control in a multi-core system: for example, "CPHash: A Cache-Partitioned Hash Table with LRU Eviction", a master's thesis submitted by Zviad Metreveli in the Department of Electrical Engineering and Computer Science at the Massachusetts Institute of Technology, which is incorporated herein by reference. The size of the hash table can be a function of the number of keys that can be stored in the KV-SSD and the amount of memory available in the system. The least recently used key can be evicted to make room for a new key.

[0089] The metadata stored in the hash table can store the current append information and a self-balancing binary search tree (or other data structure) with information about all appends. An exemplary data structure for the metadata can be:

[0090]

[0091] Each node in the tree (or other data structure) can contain the sequence number (append index), offset, and length of each append request. This representation of the metadata can improve the performance of GETs using the offset.

[0092] Insertions into the self-balancing binary search tree (or other data structure) can increase monotonically with respect to the append index. When using a self-balancing binary search tree, two common choices are the AVL tree and the Red Black tree.

[0093] AVL tree

[0094] In an AVL tree, the heights of the two subtrees of any node differ by at most 1; if they differ by more than 1 at any time, rebalancing is performed to restore this property. In the average and worst cases, lookup, insertion, and deletion all take O(log n) time, where 'n' is the number of nodes in the tree before the operation. Insertion and deletion may require one or more tree rotations to rebalance the tree.

[0095] Red Black tree

[0096] The balance of a red-black tree is not perfect, but it is sufficient to guarantee search in O(log n) time, where 'n' is the total number of elements in the tree. Insertion and deletion operations, as well as tree rearrangement and recoloring, are also performed in O(log n) time. For monotonically increasing data, red-black trees provide a good balance between insertion and search performance. Since append indexes are monotonically increasing, red-black trees are a good way to track metadata.

[0097] To balance the amount of memory required and cache misses, the maximum number of append operations can be fixed: for example, 1K (1024) appends. This maximum number of appends can be configurable and can be a function of the number of keys, available memory, and the append requirements of the application.

[0098] Each append value can be prefixed with metadata to achieve persistence. Serialized'metadata' can be encoded, prefixed to the value, and written to the KV-SSD.

[0099] Important considerations can include system performance (minimizing the number of device read and write operations performed) and persistence (ensuring that append operations are persistent and recoverable).

[0100] In the optimal case, each append request can generate only one write input / output (I / O) request to the KV-SSD. If the metadata is not available in memory, the worst case should cause "log n" additional reads to retrieve the metadata from the append with the highest sequence number, where 'n' is the maximum number of allowed (configurable) appends.

[0101] Process PUT(Key1,Value,Overwrite) requests from the application

[0102] 1) Look up the metadata for key 1 (Key1) in the hash table. If the Key1 metadata is not found in the hash table, retrieve the Key1 metadata from the KV-SSD by performing a binary search to find the highest append index used previously.

[0103] 2) If the Key1 metadata is not found, this must be a new key, and a new entry in the hash table and a new instance of the Key1 metadata can be generated.

[0104] 3) If the Key1 metadata is found:

[0105] a) If the 'overwrite' flag is set, delete all appends for the existing key.

[0106] b) If the 'overwrite' flag is not set, return a 'key exists error' to the application.

[0107] 4) If this is the first write to this key, set the append index to "0" and insert a new node (append index, offset of this append, length of the value) into the Key1 metadata.

[0108] 5) Prefix the append index to the key, prefix the serialized Key1 metadata to the value, and write it to the KV-SSD.

[0109] Process the Append(Key1, Value) request from the application

[0110] 1) Look up the metadata of key 1 (Key1) in the hash table. If the Key1 metadata cannot be found in memory, retrieve the Key1 metadata from the KV-SSD by performing a binary search on the highest append index used previously.

[0111] 2) If the Key1 metadata cannot be found, return a 'key not found error' to the application.

[0112] 3) If the Key1 metadata is found, increment the append index and insert a new node (append index, offset of this append, length of the value) into the Key1 metadata.

[0113] 5) Prefix the append index to the key, prefix the serialized Key1 metadata to the value, and write it to the KV-SSD.

[0114] Process the Get(Key1) request from the application

[0115] 1) Look up the metadata of Key1 in the hash table. If the Key1 metadata cannot be found in the hash table, perform a binary search to find the highest append index and retrieve the Key1 metadata from the KV-SSD.

[0116] 2) If the Key1 metadata cannot be found in the KV-SSD, return an error to the application.

[0117] 3) Using the information in the Key1 metadata, the entire value of the key can be composed by retrieving all the appended values. The application can also choose to receive an iterator that can retrieve one append at a time.

[0118] Note: The 'GET with an OFFSET' capability of the KV-SSD can improve performance by avoiding memory copies.

[0119] Process the Delete(Key1, Value, Overwrite) request from the application

[0120] 1) Search for the metadata of Key1 in the hash table. If the Key1 metadata cannot be found in memory, retrieve the Key1 metadata from the KV-SSD by performing a binary search on the highest append index used previously.

[0121] 2) If the Key1 metadata cannot be found, return a 'Key not found error' to the application.

[0122] 3) If the Key1 metadata is found, delete all appends of the key (including the original write request with an append index of 0000).

[0123] 4) Alternatively, since the goal is to delete all append requests, a delete request can be sent to the KV-SSD starting from append index 0000 until the KV-SSD returns a 'Key not found' error, without first searching for the highest append index.

[0124] Embodiments of the present inventive concept support the following technical advantages. First, embodiments of the present inventive concept introduce append semantics that are not currently provided by KV-SSDs. Second, the append semantics prevent data loss or data corruption (e.g., in the case of a power failure). Third, the append semantics avoid the performance loss associated with traditional read-modify-write sequences to append new data to a value. Fourth, the append semantics enable storing data values that exceed the maximum object size of the KV-SSD, without the application having to manage the storage of data across multiple objects.

[0125] Other optimizations are possible:

[0126] 1) The hash table can be periodically cleared, which can reduce the binary search required to recover metadata in the case of a power failure and other errors.

[0127] 2) The hash table can be stored in persistent memory (either in main memory or in the persistent memory of the KV-SSD controller), which can avoid the need for an LRU hash table and the need to reconstruct metadata in the case of a power failure.

[0128] 3) Advanced techniques can be used to store the hash table and associated metadata somewhere on the KV-SSD, thus eliminating the need for third-party non-volatile memory technologies.

[0129] 4) Instead of using a standard LRU replacement algorithm, another algorithm, such as a weighted LRU replacement algorithm, can be used to select the data to be evicted from the hash table.

[0130] 5) To avoid the (configurable but otherwise fixed) maximum number of appends, cascaded appends can be used to store more data.

[0131] 6) Without any additional keys, a Bloom filter can be used to improve performance.

[0132] 7) When the metadata of a key rotates out of the hash table, a special key-value pair (e.g., using an appended index -1 and the original key) can be used to store the current highest appended index of the key instead of searching the KV-SSD for the highest appended index. Then, when the metadata is loaded back into the hash table, this special key can be accessed to immediately determine the highest appended index. To avoid stale data, this special key can be deleted when the metadata of the key is loaded into the hash table. Thus, if a power failure occurs (and thus data is lost) when the metadata is stored in the hash table, the metadata can be fully reconstructed from the metadata stored on the KV-SSD.

[0133] 8) According to the instructions of the application or when other conditions are met (e.g., low solid-state drive activity, or as part of garbage collection or otherwise related to garbage collection), keys with a large number of appends can be read. These can fit fewer objects (depending on the size of the append and the maximum object size of the SSD). The appended data is merged into a single object or a smaller set of objects and then written back to the SSD (where the original object and the append are invalid for subsequent garbage collection and reuse).

[0134] 9) As part of a GET request for a key, the application can provide an optional value for the appended index. Then, depending on the implementation and / or other parameters from the application, the system can return the original data plus any appends up to the provided appended index (and exclude any data from subsequent append operations), the data appended associated with the appended index, or the data appended associated with the appended index and all subsequent append operations. The application can also provide two appended indexes to specify the range of append operations to return (and exclude any data appended outside of those appended indexes). The appended index can be replaced with an alternative indicator of how many append operations to include: e.g., a date / time stamp (if such information is included in the metadata / nodes of a binary search tree or other data structure).

[0135] Figure 1 A machine is shown that is designed to use a key-value virtualization (KVV) layer to support append operations on values stored in a key-value solid-state drive (KV-SSD). In Figure 1In it, machine 105 is shown. Machine 105 may include a processor 110. The processor 110 can be any kind of processor: for example, an Intel Xeon, Celeron, Itanium, or Atom processor, an Advanced Micro Devices (AMD) Opteron processor, an Advanced RISC Machine (ARM) processor, etc. Although Figure 1 a single processor 110 in machine 105 is shown, machine 105 may include any number of processors, each of which can be a single-core or multi-core processor and can be mixed in any desired combination.

[0136] The processor 110 can execute an operating system 115 and an application 120. The operating system 115 can be any desired operating system, and examples thereof may include, among other possibilities, any version of the Microsoft Windows operating system or an operating system similar to Unix. (Microsoft and Windows are trademarks or registered trademarks of Microsoft Corporation in the United States and other countries.) The application 120 can be any application that can issue input / output (I / O) requests to a storage device such as, for example, a key-value solid-state drive (125) (discussed below).

[0137] Machine 105 may also include a memory 130. The memory 130 can be any kind of memory, such as flash memory, Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), permanent random access memory, Ferroelectric Random Access Memory (FRAM), or Non-Volatile Random Access Memory (NVRAM), such as Magnetoresistive Random Access Memory (MRAM), etc. The memory 130 can also be any desired combination of different memory types. The memory 130 can be managed by a memory controller 135.

[0138] The machine 105 may also include a key-value solid state drive (KV-SSD) 125, which may be controlled by a device driver 140. For example, the KV-SSD 125 is shown storing various key-value pairs 145-1, 145-2, and 145-3, each key-value pair 145-1, 145-2, and 145-3 including a key (150-1, 150-2, and 150-3 respectively) and a value (155-1, 155-2, and 155-3 respectively). A single key-value pair 145-1, 145-2, or 145-3 may be stored in an object on the KV-SSD 125: the value 155-1, 155-2, or 155-3 may be written to a specific physical address in the KV-SSD 125, and the key 150-1, 150-2, or 150-3 may be stored in association with the physical address, thereby allowing the value 150-1, 150-2, or 150-3 to be easily retrieved later. Although Figure 1 the KV-SSD 125 is shown storing three key-value pairs 145-1, 145-2, and 145-3, embodiments of the inventive concept may include a KV-SSD 125 storing any number of key-value pairs.

[0139] Although Figure 1 only one KV-SSD 125 is shown, embodiments of the inventive concept may support any number of KV-SSD 125s. As described below, multiple KV-SSD 125s may be virtualized to appear as a single KV-SSD. The KV-SSD 125s may have different manufacturers, models, and / or capacities. Additionally, the KV-SSD 125 may include other storage devices using a similar key-value storage system (e.g., a key-value database stored on one or more other types of storage devices such as block access SSDs or hard disk drives).

[0140] The processor 110 may also execute key-value virtualization (KVV) 160, which may provide a virtualized view of the KV-SSD. KVV 160 may be implemented at any desired location. For example, KVV 160 may be implemented within the operating system 115, or as a separate layer between the operating system 115 running on the processor 110 and the KV-SSD 125. KVV 160 may also be implemented using separate logic coupled to the processor 110. KVV 160 may also be implemented as part of firmware (or other software) running on the KV-SSD 125. Finally, KVV 160 may be implemented using circuitry that is part of a hardware component located between the processor 110 and the KV-SSD 125: for example, inserted between a connector on the KV-SSD 125 and a connector on a certain circuit board in the machine 105. Among other possibilities, examples of circuitry that may be used to implement KVV 160 include a Field Programmable Gate Array (FPGA), a Graphics Processing Unit (GPU), and an Application-Specific Integrated Circuit (ASIC).

[0141] KVV 160 can also support the virtualization of multiple KV-SSDs 125. For example, if machine 105 includes two or more KV-SSDs 125, KVV 160 can be embedded between application 120 and KV-SSD 125 such that it appears as if only one KV-SSD 125 exists (but provides the combined capacity of multiple KV-SSDs 125). KVV 160 can then be responsible for determining where any particular key-value pair is stored. Such management can be implemented in any desired manner. The key assigned by the application can be used to determine which KV-SSD 125 stores the key-value pair: for example, the key can be hashed, or the least significant bits of the key can be used to map the key-value pair to a particular KV-SSD. The identification (ID) associated with the application can be used to determine which KV-SSD 125 stores the key-value pair (which will keep all data associated with a particular application on a single KV-SSD 125). KVV 160 can also arbitrarily assign data to different KV-SSDs 125 (but in this case, when data needs to be read from the KV-SSD 125, KVV 160 may need to search all KV-SSDs 125). KVV 160 can also use other techniques to determine which KV-SSD 125 should store a particular key-value pair. In the remainder of this document, it is assumed that machine 105 includes only a single KV-SSD 125, but embodiments of the inventive concept can still include any number of KV-SSDs 125 by adding appropriate logic to determine which KV-SSD 125 stores which key-value pair.

[0142] Memory 130 can be used to store hash table 165. Hash table 165 can store metadata about the various keys paired with the values stored on KV-SSD 125. For example, Figure 1 Hash table 165 is shown as storing metadata 170-1 and 170-2 for keys 150-1 and 150-2, respectively. Note that hash table 165 does not store metadata for key 150-3: this fact indicates that at any given point in time, hash table 165 may or may not store metadata for any particular key associated with the data stored on KV-SSD 125.

[0143] The hash table 165 may also store the ages 175-1 and 175-2 of the keys 150-1 and 150-2. The ages 175-1 and 175-2 may store aging information associated with the keys 150-1 and 150-2, and then when the metadata of a new key is to be stored in the hash table 165, the aging information may be used to determine which metadata to evict from the hash table 165. The ages 175-1 and 175-2 may be managed in any desired manner. For example, the ages 175-1 and 175-2 may store the clock times at which the metadata of the keys 150-1 and 150-2 were last respectively accessed from the hash table 165. Alternatively, the ages 175-1 and 175-2 may store values representing the number of accesses to the hash table 165 since the metadata of the keys 150-1 and 150-2 were last respectively accessed: whenever the metadata of a key is accessed, the age of that key may be set to zero, and the ages of all other keys in the hash table 165 may be incremented by 1. Other techniques may also be used to determine the ages 175-1 and 175-2, and in some implementations the ages 175-1 and 175-2 may be omitted without loss of functionality.

[0144] Thus, when the application 120 issues an input / output request destined for the KV-SSD 125, the KVV 160 may instead receive the input / output request and process it according to the new semantics that support data append requests. The KVV 160 may then issue an appropriate input / output request to the KV-SSD 125 and ultimately return any result information to the application 120.

[0145] Although Figure 1 The machine 105 is depicted as a server (which may be a stand-alone or rack-mounted server), embodiments of the inventive concept may include any desired type of machine 105 without limitation. For example, the machine 105 may be replaced with a desktop computer or a laptop computer or any other machine that may benefit from embodiments of the inventive concept. The machine 105 may also include dedicated portable computing devices, tablet computers, smart phones, and other computing devices.

[0146] Figure 2 Shown Figure 1 additional details of the machine. In Figure 2In this case, typically, the machine 105 includes one or more processors 110, and the one or more processors 110 may include a memory controller 135 and a clock 205, which can be used to coordinate the operation of the components of the machine 105. For example, the processor 110 may also be coupled to a memory 130, and the memory 130 may include a random access memory (RAM), a read-only memory (ROM), or other state-saving media. The processor 110 may also be coupled to a storage device 125 and a network connector 210, and the network connector 210 may be, for example, an Ethernet connector or a wireless connector. The processor 110 may also be connected to a bus 215, and the bus 215 may be attached to a user interface 220 and input / output interface ports, and the input / output interface ports may use an input / output engine 225 and other components for management.

[0147] Figure 3 Shows Figure 1 Details of the KV-SSD. In Figure 3 this case, the KV-SSD 125 may include a host interface logic 305, a KV-SSD controller 310, and various flash memory chips 315-1 to 315-8, and the flash memory chips 315-1 to 315-8 may be organized into various channels 320-1 to 320-4. The host interface logic 305 may manage Figure 1 the communication between the KV-SSD 125 and the machine 105. The KV-SSD controller 310 may manage read operations, write operations, garbage collection, and other operations on the flash memory chips 315-1 to 315-8.

[0148] The KV-SSD controller 310 may include a translation layer 325. The translation layer 325 may perform the traditional function of converting the key provided by the Figure 1 application 120 in the input / output request into the physical address of the object stored on the KV-SSD 125. The KV-SSD 310 may also include a processor 330, and the processor 330 may execute instructions governing how to use the KV-SSD 125. Therefore, the KV-SSD 125 may also include a KVV 160, rather than the KVV 160 executed by the Figure 1 processor 110. To fully support the KVV 160, the KV-SSD controller 310 may also include a hash table 165 (which may be stored in the memory (volatile or non-volatile) in the KV-SSD 125 (this memory is Figure 3 not shown in

[0149] Although Figure 3The KV-SSD 125 is shown as including eight flash memory chips 315-1 to 315-8 organized into four channels 320-1 to 320-4, but embodiments of the inventive concept may support any number of flash memory chips organized into any number of channels.

[0150] Figure 4 shown Figure 1 application 120, Figure 1 KVV 160, and Figure 1 KV-SSD 125, which performs a write operation on the Figure 1 KV-SSD 125. In Figure 4 , the application 120 may send a write request 405, and the write request 405 may be a request to write data to the KV-SSD 125. Typically, the KV-SSD 125 receives a command structured as PUT(key,value[,parameter]), where "PUT" is the command, key is the key of the key-value pair (e.g., Figure 1 keys 150-1, 150-2, and 150-3), value is the value of the key-value pair (e.g., Figure 1 values 155-1, 155-2, and 155-3), and parameter is an optional parameter, but in various embodiments of the inventive concept, other syntax, different parameter names, and different parameter lists may be used. An exemplary parameter that may be used is "overwrite". If "overwrite" is not included as a parameter and the KV-SSD 125 stores a key-value pair with key, the KV-SSD 125 may return an error instead of performing the write operation (omitting the parameter "overwrite" may prevent conflicts between multiple applications that may associate different data with the same key on the KV-SSD 125). By including the parameter "overwrite", the application 120 may indicate that any existing key-value pair including key may be deleted and a new key-value pair using key may be substituted. Another exemplary parameter that may be used is a parameter indicating that the key-value pair is not subject to an append command. When such a parameter is used, the KVV 160 may simply pass the write request 405 directly to the KV-SSD 125 without modification. In this case, the application 120 will be responsible for handling the append itself (instead of relying on the KVV 160): but if the application 120 knows or anticipates that the data will not be modified, this cost may be acceptable.

[0151] In some embodiments of the present inventive concept, the syntax of the write request 405 provided by the application programming interface (API) of the KVV 160 may be different from the syntax provided by the KV-SSD 125. In other embodiments of the present inventive concept, the syntax of the write request 405 may be the same as the syntax provided by the KV-SSD 125. By using the same API whenever possible, applications that do not require software updates can benefit from the use of the KVV 160.

[0152] In operation 410, the KVV 160 may determine a base index for the key-value pair to be written in the write request 405. This base index may be zero, or any other desired value may be used. In operation 415, the KVV 160 may create metadata, such as Figure 1 metadata 170-1 and 170-2.

[0153] In write operation 420-1, the KVV 160 may send a write request (again, possibly using a PUT command or a similar command provided by the API of the KV-SSD 125) to store the key-value pair on the KV-SSD 125. However, instead of storing the original value sent by the application 120 in the write request 405, or associating the value sent by the application 120 in the write request 405 with the original key, the KVV 160 may send a request to store a modified value with an indexed key. The indexed key may be a combination of the base index (determined in operation 410) and the original key sent by the application 120 in the write request 405. Similarly, the modified value may be a combination of the serialized form of the metadata and the original value sent by the application 120 in the write request 405. Finally, in operation 425-1, the KV-SSD 125 may return a write result to the KVV 160, and in operation 430, the KVV 160 may return the write result to the application 120.

[0154] The term "combination" is intended to mean any desired mechanism for combining two data segments. For example, the index key could be the concatenation of a base index and an original key, and the modified data could be the concatenation of serialized metadata and an original value. Alternatively, the order of concatenation could be reversed. Delimiters could be added or omitted, or the various data being combined could be set to a fixed length so that it can be generated consistently. Thus, for example, the index could be the first two bytes of the index key, with the remaining index key length being made up of the original key. Any other desired mechanism for "combining" two values could be used: the only "caveat" is that the data being "combined" should be separately recoverable. (This caveat may not even necessarily extend to the index key, since there may be no mechanism for querying which keys are stored on the KV-SSD 125. Since the only important aspect is knowing whether a particular key identifies data stored on the KV-SSD 125, it may only be important to be able to deterministically generate the key rather than to reverse the process. Thus, for example, assuming the hash function generates a unique hash on the KV-SSD 125, the hash function could be applied in some way to some combination of the base index and the original key.)

[0155] Note that Figure 4 shows multiple PUT commands sent from the KVV 160 to the KV-SSD 125. This is intended to represent that the original value can be larger than the value that can be stored in a single object on the KV-SSD 125. For example, consider a case where the KV-SSD 125 has a maximum object size of 1 GB, and the application 120 sends a 2 GB value in the write request 405. Traditionally, the KV-SSD 125 would return an error to the application 120 indicating that the value is too large to store. But the KVV 160 can determine that the value is too large to store in a single object, and can split the value into multiple parts to be written separately. For simulation purposes, consider that the KVV 160 processes a single write request 405 into a write request for the first GB of data, followed by an append request for the second GB of data. (In reality, the KVV 160 may need to split the value into three parts because the serialized metadata will take up some of the space used by the object, but for basic understanding, this consideration can be ignored.) Thus, the KVV 160 can send two write operations 420-1 and 420-2 to the KV-SSD 125, and receive two results 425-1 and 425-2. Although Figure 4 shows two write operations 420-1 and 420-2, embodiments of the inventive concept can include any number of write operations sent from the KVV 160 to the KV-SSD 125.

[0156] Note that, in write operation 420-1, the index used is the base index (BI), while in write operation 420-2, the index used is the append index (AI). The append index can be determined in any desired manner, just as the base index is determined in any desired manner. In some embodiments of the inventive concept, the append index can be 1 greater than the base index (i.e., an increment of the base index). If KVV 160 needs to send more than two write operations 420-1 and 420-2, the append index can be incremented for each write operation after the first write operation. This approach creates a unique key for the objects stored on KV-SSD 125, and although all the objects are related (as an append to earlier data for a particular key), it allows for easy reconstruction of the append in sequence (for later reading values from KV-SSD 125, as discussed below in Figure 6 ).

[0157] In write operations 420-1 and 420-2, the same metadata is shown for the modified values stored on KV-SSD 125. This fact can be true in some embodiments of the inventive concept (since the various write operations are the result of a single write request 405 from application 120). In other embodiments of the inventive concept, the metadata for each part of the value stored on KV-SSD 125 that is modified can vary (e.g., to mimic separate write requests and append requests).

[0158] Figure 5 Shown Figure 1 is application 120, Figure 1 KVV 160, and Figure 1 KV-SSD 125, which performs an append operation on Figure 1 KV-SSD 125. In Figure 5 , application 120 can send an append request 505, and append request 505 can be a request to append data to the value stored on KV-SSD 125. The append syntax provided by KVV 160 (which may not have an analogue in the API of KV-SSD 125) can be in the form of APPEND(key,value), where "APPEND" is the command, key is the key of the key-value pair (e.g., Figure 1 keys 150-1, 150-2, and 150-3), and value is the value to be appended to the existing value of the key-value pair (e.g., Figure 1 values 155-1, 155-2, and 155-3). In embodiments of the inventive concept, this append syntax can also include optional parameters not discussed herein and can be different from this form.

[0159] In operation 510, the KVV 160 may determine a new highest append index for the key-value pair to be written in the append request 505. This new highest append index may be determined by identifying the highest append index used so far and then generating the next append index (e.g., by incrementing the existing highest append index). In operation 515, the KVV 160 may create metadata, such as Figure 1 metadata 170-1 and 170-2 of

[0160] In the write operation 520, the KVV 160 may send a write request (again, perhaps using a PUT command or a similar command provided by the API of the KV-SSD 125) to store the key-value pair on the KV-SSD 125. As in Figure 4 write operations 420-1 and 420-2 of

[0161] Figure 5 only a single write operation 520 sent from the KVV 160 to the KV-SSD 125 is shown, which means that the value appended to the key will fit into a single object on the KV-SSD 125. But as with Figure 4 the processing of the write request 405 of Figure 4 if needed, the KVV 160 may divide the appended value into multiple parts, assign each part to a unique append index (and thus to a unique index key), and store the parts (modified by the metadata) associated with those unique index keys on the KV-SSD 125. As in

[0162] Figure 6 shows Figure 1 the application 120 of Figure 1 the KVV 160 of Figure 1 and the KV-SSD 125 of Figure 1 performing a read operation on the KV-SSD 125 of Figure 6In this case, application 120 may send a read request 605, and the read request 605 may be a request to read data from KV-SSD 125. Typically, KV-SSD 125 receives a command structured as GET(key[,parameter]), where "GET" is the command, key is the key of the key-value pair (e.g., Figure 1 keys 150-1, 150-2, and 150-3), and parameter is an optional parameter, but in various embodiments of the inventive concept, other syntax, different parameter names, and different parameter lists may be used. An exemplary parameter that may be used is a parameter indicating that the key-value pair is not subject to the append command. When using such a parameter, KVV 160 may simply pass the read request 605 directly to KV-SSD 125 without modification. Another exemplary parameter that may be used is one or more append indices to specify a particular portion of the value to be retrieved. For example, the application may request all appends that occur within a particular range of append indices, or all data written from the original write request by a particular append index, or all data written from a particular append index until the end of the append. In the absence of these parameters, the default operation may be to retrieve the entire value associated with the key, including all appends.

[0163] Assume that the read request 605 requests data via the last append request. In operation 610, KVV 160 may determine the highest append index used so far. In read operation 615-1, KVV 160 may send a read request (again, possibly using the GET command or a similar command provided by the API of KV-SSD 125) to read the value associated with the index key on KV-SSD 125. This first read request 615-1 may combine the key with the base index of the key (as shown in the figure if application 120 does not specify the lower end of the append range to be read), or it may combine the key with the lower end of the range provided by application 120 in read request 605. Similarly, in operation 620-1, KV-SSD 125 may return the modified value stored on KV-SSD 125. KVV 160 may send as many read requests as there are append indices to be retrieved. As shown in read operation 615-2, KV-SSD 125 may return results 620-2 to it: Although Figure 6 two read operations 615-1 and 615-2 are shown, there may be any number of read operations sent from KVV 160 to KV-SSD 125. After receiving the modified values in operations 620-1 and 620-2, KVV 160 may separate the original value from the metadata in the modified value stored on KV-SSD 125 (in some embodiments of the inventive concept, the metadata may be discarded because it is not returned to application 120).

[0164] In operation 625, KVV 160 may combine these values to produce a complete value (which may include as many values as those of write request 405 from Figure 4 and all subsequent append requests 505 from Figure 5 ). Finally, in operation 630, KVV 160 may send the complete value back to application 120.

[0165] In some embodiments of the inventive concept, KVV 160 may also return the highest append index of the key to application 120. This information may be useful to application 120. For example, if application 120 needs to allocate memory to store the returned value, the combination of the highest append index of the key and the maximum size of the object stored on KV-SSD 125 may provide a rough guide as to how much memory will be needed to store the value. For example, if the maximum size of an object stored on KV-SSD 125 is 1 GB and there are Figure 4 two append requests 505 after write request 405 from Figure 5 then the highest append index will be 2. Incrementing this index by 1 (to account for write request 405 from Figure 4 ) and multiplying by 1 GB indicates that the total storage required for the complete value will not exceed 3 GB. If KVV 160 returns the highest append index to application 120, KVV 160 will typically return this value before sending the value associated with the key (as constructed).

[0166] Figure 7 Illustrates Figure 1 application 120 from Figure 1 KVV 160 from Figure 1 and KV-SSD 125 from Figure 1 performing a deletion operation on KV-SSD 125 from Figure 7 . In Figure 1 , application 120 may send a delete request 705, which may be a request to delete data associated with a key on KV-SSD 125. Typically, KV-SSD 125 receives a command structured as ERASE(key[,parameter]), where "ERASE" is the command, key is the key of the key-value pair (e.g., keys 150-1, 150-2, and 150-3 from

[0167] In operation 710, the KVV 160 may determine the highest append index for the key-value pair to be deleted in the delete request 705. Then, for each append index (starting from the base index), in operations 715-1 and 715-2, the KVV 160 may send a delete request to the KV-SSD 125 to delete the value associated with the index key, and the KV-SSD 125 may respond thereto in operations 720-1 and 720-2. Although Figure 7 two delete operations are shown being sent from the KVV 160 to the KV-SSD 125, embodiments of the inventive concept may include any number of delete operations (since any number of index keys may be stored on the KV-SSD 125). Finally, in operation 725, the KVV 160 may report the result of the delete request 705 to the application 120.

[0168] Although Figure 7 it is shown that the KVV 160 first determines the highest append index used so far in operation 710, this operation may be omitted. For example, the KVV 160 may simply send a delete request to the KV-SSD 125 for each index key until the KV-SSD 125 responds that no such key was found, at which point the KVV 160 knows that all appends for the key have been deleted.

[0169] Figure 8 is shown Figure 1 details of the KVV 160. In Figure 8 it, the KVV 160 is shown as including an API 805, a combiner software 810, an execution software 815, a result software 820, a metadata software 825, a second combiner software 830, a hash table software 835, an eviction software 840, a partitioning software 845, and an index determination software 850. Although Figure 8 various elements are shown, not all elements are required for each implementation, and different embodiments of the inventive concept may include or omit various elements as needed. Additionally, some (or all) of the elements may be combined into a single "package" to achieve the two (all) software objectives, and / or the functions performed by one element may be implemented using different elements. Finally, although Figure 4The various components shown are labeled as "software", but embodiments of the inventive concept may implement these components as appropriately programmed circuitry rather than software executed by a processor: the term "software" is intended to mean the general concept of instructions that can be implemented using some circuit design, rather than being limited to instructions stored in some memory (or other storage) and executed by a general-purpose processor. Thus, "software" may include instructions stored in an operating system file and executed by a main processor (such as a Central Processing Unit (CPU)), instructions stored in firmware and executed by the processor or GPU in the Figure 1 KV-SSD 125, an appropriately designed and / or programmed FPGA or ASIC, or any other mechanism by which a computer or its equivalent may be understood to execute a particular set of instructions.

[0170] The API 805 is an API that exposes functions accessible by the Figure 1 application 120. The API 805 may be designed such that it includes all the functions typically provided by the API of the Figure 1 KV-SSD 125, plus some additional functions that benefit from the capabilities introduced by the KVV 160. For example, the API 805 may include PUT functions, GET functions, and ERASE functions similar to those provided by the API of the KV-SSD 125 (and referred to above with reference to Figure 4 and Figure 6 to Figure 7 ), but may include other functions such as APPEND (as referred to above with reference to Figure 5 ). Other functions that may be exposed by the API 805 may include a CONSOLIDATE function (like PUT, GET, ERASE, and APPEND, this function may be provided under a different name). Consolidation can be used as a built-in read-modify-erase function, enabling the application 120 to request that the KVV 160 consolidate all the appended data associated with a single key into a single object. That is, Figure 1 the application 120 may request that the KVV 160 consolidate a particular key. The KVV 160 may then perform a read request on the key (similar to that described above with reference to Figure 6 ), but instead of returning the value to the application, the KVV 160 may then perform a delete request on the key (similar to that described above with reference to Figure 7 ), followed by a write request on the key with the consolidated value (similar to that described above with reference to Figure 4 ). By consolidating the values into a single object, Figure 1 some space on the KV-SSD 125 may be freed up for other uses (of course, subject to traditional garbage collection performed on flash devices).

[0171] The combiner software 810 can obtain an index and a key, and combine the two into an index key. As described above, the index key provides a mechanism by which multiple different objects associated with the same key (such as those provided by an application 120) can be stored on the KV-SSD 125 (since the KV-SSD 125 does not allow storing more than one object with a given key), and the data can be retrieved easily. Figure 1 of Figure 1 and the KV-SSD 125 of Figure 1 does not allow storing more than one object with a given key), and the data can be retrieved easily. Fig. 9 FIG. shows the operation of the combiner software 810: Given a key 150-1 and an index 905, the combiner software 810 can generate an index key 910. As described above, the index key 910 can be any desired combination of the index 905 and the key 150-1, including (for example) the concatenation of the index 905 and the key 150-1.

[0172] Returning to Figure 8 , the execution software 815 can send commands to the KV-SSD 125 of Figure 1 and receive results from the KV-SSD 125 of Figure 1 . In other words, the execution software 815 can use the functions provided by the KV-SSD 125 to implement the enhanced functions provided by the KVV 160. The result software 820 can return results suitable for the requests issued by the application 120 of Figure 1 to the application 120.

[0173] The metadata software 825 can create metadata, and the KVV 160 can use the metadata to process the requests shown in Figures 4 to 7 . Fig.10 This metadata is described in detail, and it is shown that, among other elements, the metadata 170-1 and 170-2 can include an append index 905 (an index assigned to a specific append request issued by the application 120 of Figure 1 ), an append offset 1005 (how much data was previously written in the original write request 405 for this key in Figure 4 or in the append request 505 for this key in Figure 5 ), an append length 1010 (how much data was written in this append request 505 for this key in Figure 5 ), and an append search structure 1015 (the data structure stores information about all append requests 505 for this key so far, including the original write request 405 for this key in Figure 5 ). Figure 4 ).

[0174] Returning to Figure 8 , the second combiner software 830 can combine the serialized metadata with the data to be written to Figure 1Value combinations of the KV-SSD 125 to produce a modified value. This modified value allows both the metadata and the value to be stored together on Figure 1 the KV-SSD 125 to allow retrieval of both based on the same index key. Fig.11 Illustrates the operation of the second combiner software 830: Given value 155-1 and metadata 170-1, the second combiner software 830 can produce a modified value 1105. As described above, the modified value 1105 can be any desired combination of the metadata 170-1 and the value 155-1, including (for example) the concatenation of the metadata 170-1 and the value 155-1. Since the combiner software 810 and the second combiner software 830 operate the same (only for different data), the combiner software 810 and the second combiner software 830 can be the same software, rather than different software.

[0175] Returning to Figure 8 , the hash table software 835 can manage Figure 1 the hash table 165. This management can include adding new entries to Figure 1 the hash table 165 and looking up metadata from Figure 1 the hash table 165 for a given key. For example, the hash table software 845 can receive a key, locate the associated metadata (or report that Figure 1 the hash table 165 does not store the associated metadata), and report the highest append index for the key: This information can then be used to perform Figure 5 further append requests 505. The hash table software 845 can also include eviction software 840, and the eviction software 840 can be responsible for selecting Figure 1 entries in the hash table 165 for eviction (in this case, the eviction software 840 is part of the hash table software 840).

[0176] The partitioning software 845 can partition a given value into multiple parts. As discussed above with reference to Figure 4 , it is possible that Figure 1 the application 120 can request to write a value larger than the value that can be stored in a single object on Figure 1 the KV-SSD 125. The partitioning software 845 can partition the value into multiple parts, each of which can fit into a single object on Figure 1 the KV-SSD 125. For example, if Figure 1 the maximum size of an object on the KV-SSD125 is 1GB and a 3GB value is to be stored, the partitioning software 845 can partition the value into three parts. The partitioning software can also consider the size of any serialized metadata that can be combined with the parts of the value before writing, as this information can affect how many parts the value should be partitioned into.

[0177] Finally, the index determination software 850 can determine the append index for a given key. The index determination software 850 can use the metadata of the key stored in the Figure 1 hash table 165 (this may involve accessing the metadata using the hash table software 835), or the index determination software 850 can directly determine this information from the objects stored on the KV-SSD 125.

[0178] Fig.12 illustrates various embodiments in accordance with the inventive concept, Figure 8 the index determination software 850 can be used to determine Figure 1 the highest append index of the keys on the KV-SSD 125 of Fig.12 illustrates various embodiments of the inventive concept: These embodiments can be combined in any desired manner. That is, these embodiments should not be considered mutually exclusive.

[0179] As Fig.12 shown, in one embodiment of the inventive concept, the index determination software 850 can simply access the highest append index from the metadata stored in the hash table 165. In a second embodiment of the inventive concept, the index determination software 850 can perform a sequential search on the indexes that may be stored on the KV-SSD 125. For example, the index determination software 850 can combine a base index with the key (using the Figure 8 combiner software 810), and query the KV-SSD 125 to obtain any value associated with the index key. If the KV-SSD 125 indicates that a value is stored for the index key, the index determination software 850 can then increment the base index, combine the new index with the key, and query the KV-SSD 125 again. This process can be repeated until the KV-SSD 125 indicates that a particular index key was not found on the KV-SSD 125, at which point the index determination software has determined the highest append index for the key (the last index that produced a successful query). In a third embodiment of the inventive concept, the index determination software 850 can perform the same sequential search, but start from the possible highest append index instead of the base index, decrement the index instead of incrementing it, and know that the highest append index has been located when the KV-SSD 125 first indicates a successful query.

[0180] In a fourth embodiment of the inventive concept, the index determination software 850 can perform a binary search of the highest append index. In a binary search, a range of possible values is identified: for example, a range starting from the base index and ending at the possible highest append index (e.g., if Figure 1The KVV 160 supports a total of 1024 writes plus appends (i.e., 0 to 1023). This range can be split in half, and the middle value is selected (continuing the above example, 511). Then, the middle index can be combined with the key to produce an index key, and the KV-SSD 125 can be queried to obtain any value associated with the index key. If the query is successful (i.e., the KV-SSD 125 stores an object for the index key), then the lower end of the range can be replaced with the middle index; otherwise, the upper end of the range can be replaced with the middle index (continuing the above example, if the index key is not found, the upper end of the range can be reduced from 1023 to 511). The process of selecting the middle index, combining the middle index with the key, and querying the KV-SSD 125 to obtain the index key can be repeated until the range has been reduced to a single index, and then the single index can be determined as the highest append index for the key.

[0181] In a fifth embodiment of the inventive concept, the index determination software 850 can identify a special key that stores the highest append index for the key. For example, when evicting metadata for a particular key from the hash table 165, the special key can be used to store this highest append index value. Continuing the above example, if the append index for the key can vary from 0 to 1023, the special key can be generated from the combination of -1 and the key (the combiner software 810 can be used). Alternatively (since data should not be written to the KV-SSD 125 using the original key without combining it with an index), the special key can be the unmodified original key. The special key can be formed in any other desired manner. By storing the highest append index for the key in an index object on the KV-SSD 125, the determination of the highest append index for the key can be achieved using a single read request from the KV-SSD 125. Figure 8 The various embodiments of the inventive concept can provide different levels of performance. Generally, the first embodiment of the inventive concept can be expected to run the fastest (since queries to memory tend to be faster than queries to the KV-SSD 125), but only when the metadata is stored in the hash table 165. If the metadata is not stored in the hash table 165, then another embodiment of the inventive concept may be required.

[0182] The various embodiments of the inventive concept can provide different levels of performance. Generally, the first embodiment of the inventive concept can be expected to run the fastest (since queries to memory tend to be faster than queries to the KV-SSD125), but only when the metadata is stored in the hash table 165. If the metadata is not stored in the hash table 165, then another embodiment of the inventive concept may be required.

[0183] The second, third, and fourth embodiments of the present invention concept described above can be expected to take different amounts of time. If n represents the highest possible append index (i.e., the maximum number of writes plus appends for a single key), then on average, the second and third embodiments of the present invention concept can be expected to require n / 2 queries to the KV-SSD 125 to find the highest append index (mathematically, this can be expressed as Θ(n), which identifies the polynomial amount of time required on average). However, in the worst case, it may be necessary to perform n queries to the KV-SSD 125 (mathematically, this can be expressed as O(n), which identifies the polynomial amount of time required in the worst case). In contrast, the fourth embodiment of the present invention concept can be expected to require log2 n queries to the KV-SSD 125 in both the average and worst cases (Θ(log2 n) and O(log2 n)). On the other hand, in the best case, the second and third embodiments of the present invention concept may require no more than two queries to the KV-SSD 125 to find the highest append index, while even in the best case, the fourth embodiment of the present invention concept still requires log2 n queries to the KV-SSD 125. Therefore, which approach is best may depend on Figure 1 circumstances where the KVV 160 of

[0184] Finally, the fifth embodiment of the present invention concept may only require one query to the KV-SSD 125 to determine the highest append index: but like the first embodiment of the present invention concept described above, the fifth embodiment of the present invention concept depends on the index object stored on the KV-SSD 125. In the fifth embodiment of the present invention concept, when the metadata is loaded into the hash table 165, the index object can be deleted. (After the metadata is loaded into the hash table 165 and updated therein, this option prevents the index object from providing stale information in the event of a power failure: in this case, the KV-SSD 125 can be searched to reconstruct the metadata.) If the index object is not stored on the KV-SSD 125, then the index determination software 850 may need to use a different approach to identify the highest append index of the key.

[0185] FIG. 13A to FIG. 13C illustrates an exemplary program flow diagram of a write request 405 to a KV-SSD125 supported by a KVV 160 according to an embodiment of the present invention concept. In Figure 1 a KVV 160 of Figure 1 the KV-SSD125 of Figure 4 In Fig.13A a block 1305, an application 120 of Figure 1 the KVV 160 of Figure 1 the KVV 160 may send a write request 405 of Figure 4 the KVV 160 to Figure 1The value 155-1, when stored on the KV-SSD125 stored in Figure 1 , is paired with the key 150-1 in Figure 1 . In block 1310, the KVV 160 in Figure 1 can determine the basic index of the key 150-1 in Figure 1 . In block 1315, the combiner software 810 in Figure 8 can combine the basic index with the key 150-1 in Figure 1 to form the index key 910 in Fig. 9 . In block 1320, the metadata software 825 in Figure 8 can generate the Figure 1 metadata 170-1 of the key 150-1 in Figure 1 . In block 1325, the KVV 160 in Figure 1 can determine whether the value 155-1 is greater than or will fit a single object on the KV-SSD125. Figure 1

[0186] If Figure 1 the value 155-1 will fit Figure 1 a single object on the KV-SSD 125, then in block 1330 ( Fig. 13B ), the second combiner software 830 in Figure 8 can combine the Figure 1 metadata 170-1 with the Figure 1 value 150-1 to form the Fig.11 modified value 1105. In block 1335, the execution software 815 in Figure 8 can perform a storage operation on the KV-SSD 125 to store the Fig. 9 modified value 1105 associated with the index key 910 in Figure 1 . In block 1340, the KVV 160 in Figure 1 can store the Figure 1 metadata 170-1 in the Figure 1 hash table 165. Finally, in block 1345, the result software 820 can return the result from the Figure 1 KVV160 to the Figure 1 application 120.

[0187] Or, if Figure 1 the value 155-1 will not fit Figure 1 a single object on the KV-SSD 125, then in block 1350, the partitioning software 845 in Figure 8 can partition the Figure 1 value 155-1 into multiple parts. In block 1355, the second combiner software 830 in Figure 3 can combine the​ Figure 1 The metadata 170-1 of Figure 1 is combined with the first part of the value 155-1 to form Fig.11 the modified value 1105. In block 1360, the execution software 815 can Fig. 9 store the modified value 1105 associated with the Fig.11 index key 910 of Figure 1 on the KV-SSD 125 of

[0188] In block 1365 ( Fig. 13C ), Figure 1 the KVV 160 of Figure 1 can determine whether all parts of the value 155-1 have been stored on Figure 1 the KV-SSD 125 of Fig. 13B . If so, the process continues in block 1340 of Fig. 13C . Otherwise, in block 1370 ( Figure 1 ), Figure 8 the KVV160 of Figure 1 can increment or otherwise adjust the index to a new index value. In block 1375, Fig. 9 the combiner software 810 of Figure 3 can combine the new index with the Figure 1 key 150-1 of Figure 1 to form Fig.11 the new index key 910 of Fig. 9 . In block 1380, Fig.11 the second combiner software 830 of Figure 1 can combine the metadata 170-1 of

[0189] FIG. 14A to FIG. 14B with the next part of the value 155-1 of Figure 1 to form Fig.14A In Figure 8 the hash table software 835 of Figure 1 can check to see if the hash table 165 of Figure 8 is full. If so, the hash table software 835 of Figure 1 needs to evict entries from the hash table 165 of Figure 1 before new metadata can be stored in the hash table 165 of Figure 8 In block 1405,The eviction software 840 can select the entries to be evicted. Figure 8 The eviction software 840 can use, for example, Figure 1 the ages 175-1 and 175-2 to help determine which entries to evict. Figure 8 The eviction software 840 can select to evict the least recently used or least frequently used entries, or can use any other desired mechanism to select entries. Once selected, in block 1410, Figure 8 the eviction software 840 can evict the selected entries. In block 1415, Figure 8 the execution software 815 can store the highest appended index of the key whose metadata is being evicted from Figure 1 the hash table 165: This highest appended index can be stored in Figure 1 the index object on the KV-SSD 125. As shown by the dashed line 1420, block 1415 can be omitted.

[0190] At this time, in Figure 1 the hash table 165 there is at least one open entry (either because Figure 1 the hash table 165 is not full in block 1425, or because in block 1410 Figure 8 the eviction software 840 evicted an entry from Figure 1 the hash table 165). In block 1430 ( Fig. 14B ), Figure 8 the hash table software 835 can select an available entry in Figure 1 the hash table 165 to store the new metadata. Since the new metadata is not yet in Figure 1 the hash table 165, Figure 8 the hash table software 835 needs to load the metadata from Figure 1 the KV-SSD 125. In block 1435, Figure 8 the index determination software 850 can determine the highest appended index of the key whose metadata will be stored in Figure 1 the hash table 165. Refer to the following FIG. 18A to FIG. 20 for further discussion of Figure 8 the operation of the index determination software 850. Alternatively, in block 1440, Figure 8 the hash table software 835 can access the highest appended index from the index object stored on Figure 1 the KV-SSD 125. Either way, in block 1445, the highest appended index can be combined with Figure 1 the key 150-1 using the combiner software 810 to form Fig. 9 the index key 910. In block 1450, Figure 8 the hash table software 835 can use Figure 8The execution software 815 targets Fig. 9 The index key 910 of Figure 1 Accesses the KV-SSD 125 of Fig.11 The modified value 1105 of Figure 8 The hash table software 835 of Figure 1 The metadata 170-1 of Fig.11 Isolates the modified value 1105 of Figure 8 The hash table software 835 of Figure 1 Stores the metadata 170-1 of Figure 1 In the hash table 165 of

[0191] FIG. 15A to FIG. 15B Shows an embodiment according to the concepts of the present invention Figure 1 The KVV 160 of Figure 1 On the KV-SSD125 of Figure 5 The flowchart of an exemplary program for the append request 505 of Fig.15A In Figure 1 The application 120 of Figure 1 Sends the append request 505 to the KVV 160 of Figure 5 In block 1510, Figure 8 The index determination software 850 of Figure 1 Determines the highest append index of the key 150-1 of FIG. 18A to FIG. 20 Is further discussed Figure 8 The operation of the index determination software 850 of Figure 1 The KVV 160 of Figure 8 Increments the highest append index to form a new highest append index. In block 1520, Figure 1 The key 150-1 of Fig. 9 Combines with the new highest append index to form Figure 8 The index key 910 of Figure 1 The metadata software 825 of Figure 1 Generates the metadata 170-1 of the key 150-1 of

[0192] In block 1530( Fig. 15B ) Figure 8 The second combiner software 830 of Figure 1 Combines the metadata 170-1 of Figure 1 With the value 155-1 to form Fig.11 The modified value 1105 of Figure 8 The execution software 815 of Sends a storage operation on the KV-SSD125 to store the Fig. 9 associated with the index key 910 Figure 1 the modified value 1105. In block 1540, the Figure 8 hash table software 835 of Figure 1 stores and / or updates in the hash table 165 of Figure 1 the metadata 170-1. Note that, except if the Figure 1 metadata 170-1 has already been in the Figure 1 hash table 165, then Figure 1 in the hash table 165 of Figure 1 the metadata 170-1 only needs to be updated with the new metadata information (e.g., Fig. 9 the new highest append index 905 and Fig.10 the updated append search structure 1015) instead of directly storing new ones. Block 1540 is almost the same as Fig. 13B block 1340 of Figure 8 Finally, in block 1545, the Figure 1 result software 820 of Figure 5 returns the result of the append request 505 from the Figure 1 KVV 160 of

[0193] FIG. 16A to FIG. 16C shows a flowchart of an exemplary program for a read request 605 on a Figure 1 KVV 160 of Figure 1 KV-SSD 125 according to an embodiment of the inventive concept. In Figure 6 , in block 1605, the Fig.16A application 120 of Figure 1 can send a Figure 1 read request 605 to the Figure 6 KVV 160 of Figure 8 In block 1610, the Figure 1 index determination software 850 of FIG. 18A to FIG. 20 can determine the highest append index of the Figure 8 key 150-1. Refer to the following Figure 8 for further discussion of the operation of the Figure 1 index determination software 850. In block 1615, the Figure 1 result software 820 of Figure 6 reports to the Figure 1 application 120 of Figure 1 the highest append index of the

[0194] In block 1625, Figure 8 the combiner software 810 of Figure 1 can combine the highest appended index of the key 150-1 of Figure 1 with the key 150-1 of Fig. 9 to form the index key 910 of Figure 8 . In block 1630, Fig. 9 the execution software 815 of Figure 1 can access the metadata 170-1 of Figure 1 from the KV-SSD 125 of Figure 8 using the index key 910 of Figure 1 . After that (in block 1635), Figure 1 the hash table software 835 of

[0195] Once Figure 1 the KVV 160 of Figure 1 knows the highest appended index of the key 150-1 of Fig. 16B , in block 1645 ( Figure 1 ) Figure 1 the KVV 160 of Figure 8 can determine the base index of the key 150-1 of Figure 1 . In block 1650, Fig. 9 the combiner software 810 of Figure 8 can combine the base index with the key 150-1 of Figure 1 to generate the index key 910 of Fig.11 . In block 1655, Figure 4 the execution software 815 of Figure 1 can access the modified value 1105 of

[0196] In block 1660 ( Fig. 16C ), Figure 1 the KVV 160 of Figure 1 can determine whether all the requested data has been accessed from the KV-SSD 125 of Figure 1 . In other words, Figure 1 the KVV 160 of Figure 1 can compare the current index for accessing the value 155-1 from the KV-SSD 125 of Figure 1 with the highest appended index of the key 150-1 of Figure 1 . If there is still a key 150-1 of Figure 1 to be accessed from the KV-SSD 125 of Figure 5 For the additional request 505, in block 1665, Figure 1 the KVV 160 can increment the index or adjust it to the next value. In block 1670, Figure 1 the combiner software 810 can combine the new index with Figure 1 the key 150-1 to form Fig. 9 the new index value 910. In block 1675, Figure 8 the execution software 815 can access Figure 1 the modified value 1105 from the KV-SSD 125 and extract the Fig.11 value 155-1 included in the index append request 505, and then control returns to block 1660. Figure 5 Figure 1

[0197] Once Figure 1 the KVV 160 has retrieved all the data associated with Figure 1 the key 150-1, in block 1680, Figure 1 the KVV 160 can concatenate the various retrieved values to form Figure 1 the value expected by the application 120. Finally, in block 1685, Figure 8 the result software 820 can return the combined value to Figure 1 the application 120.

[0198] Note that FIG. 16A to FIG. 16C the exemplary program shown can operate without first determining Figure 1 the highest append index of the key 150-1. Specifically, since Figure 1 the KVV 160 will need to read the original written value and all subsequent append values from Figure 1 the KV-SSD 125, the KVV 160 can operate by simply reading each index of Figure 1 the key 150-1 starting from the base index and ending when Figure 1 the KV-SSD 125 reports that Figure 1 the KV-SSD 125 does not store the value for a particular index key. And even though Figure 1 the KV-SSD 125 Figure 8 the result software 820 needs to report the highest append index to Figure 1 the application 120 before the combined value is returned, Figure 1 the KVV 160 can still temporarily store the combined value after reporting the highest append index to give Figure 1 the application 120 time to use the highest append index.

[0199] In FIG. 16A to FIG. 16C assuming Figure 6 The read request 605 is for the entire value of the key 150-1, starting from Figure 4 the original write request 405 and including Figure 5 each append request 505. If only a subset of these write / append requests is desired in Figure 6 the read request 605, then the base index mentioned in Figures 16A to 16C is replaced with a lower append index provided by the application 120 of Figure 1 and a higher append index provided by the application 120 of Figure 1 is used.

[0200] In some embodiments of the inventive concept, Figure 6 the read request 605 may support an offset parameter. The offset parameter may indicate that only a portion of the data will be returned, starting at a specific offset relative to the value. These embodiments of the inventive concept may use Figure 1 the metadata 170-1 to find the append index for the append request 505 that stores the data starting from the offset. That is, embodiments of the inventive concept may search Figure 5 the metadata 170-1 to locate Figure 1 the append index 905 such that Figure 9 the append offset 1005 is less than or equal to the desired offset, and Figure 10 the append offset 1005 plus Figure 10 the append length 1010 is greater than or equal to the desired offset. This search may be performed in any desired manner using conventional techniques to access Figure 10 the information in the append search structure 1015. In these embodiments of the inventive concept, the base index mentioned above in the discussion regarding Figure 10 is then replaced with an append index that includes the desired offset. Figures 16A to 16C

[0201] Figures 17A to 17C FIG. shows an exemplary procedure of the KVV 160 supporting Figure 1 the deletion request 705 on the Figure 1 KV-SSD 125 according to an embodiment of the inventive concept. In Figure 7 , in block 1705, Figure 17A the application 120 may send Figure 1 the deletion request 705 to Figure 1 the KVV 160. In block 1710, Figure 7 the index determination software 850 may determine Figure 8 the highest append index of the key 150-1. Refer to the following Figure 1 for further discussion Figures 18A to 20 Figure 8The operation of the index determination software 850. In block 1715, Figure 1 the KVV 160 of Figure 1 can determine the basic index of the key 150-1 of Figure 8 In block 1720, the combiner software 810 of Figure 1 can combine the basic index with the key 150-1 of Figure 9 to form the index key 910 of Figure 8 In block 1725, the execution software 815 of Figure 1 can instruct the KV-SSD 125 of

[0202] to delete the index key. Figure 17B In block 1730 ( Figure 1 ) the KVV 160 of Figure 1 can determine whether all appended indexes of the key 150-1 of Figure 1 have been deleted. The KVV 160 of Figure 1 can make this determination by comparing the current index with the highest appended index of the key 150-1 of Figure 1 : If the current index is less than the highest appended index of the key 150-1 of Figure 1 then not all appended indexes of the key 150-1 of Figure 1 have been deleted. If not all appended indexes of the key 150-1 of Figure 1 have been deleted, then in block 1735, the KVV 160 of Figure 17A can increment the index or otherwise modify it to the next value, and control can return to Figure 8 block 1720. Otherwise, in block 1740, the hash table software 835 of Figure 1 can determine whether the metadata 170-1 of the key 150-1 of Figure 1 is in the hash table 165 of Figure 1 .

[0203] If Figure 1 the metadata 170-1 of Figure 1 is in the hash table 165 of Figure 17C , then in block 1745 ( Figure 8 ) the hash table software 835 of Figure 1 can locate the metadata 170-1 of Figure 8 and in block 1750, the hash table software 835 of Figure 1 can remove (i.e., delete) the metadata 170-1 of Figure 1 from the hash table 165 of

[0204] Regardless of whether the hash table 165 of Figure 1 contains the metadata 170-1 of Figure 1The metadata 170-1, in block 1755, Figure 1 The KVV 160 of Figure 1 can all form a key of an index object representing the highest append index of the key 150-1 that can exist and be stored. Then, in block 1760, Figure 8 The execution software 815 of Figure 1 can instruct the KV-SSD 125 of Figure 8 to delete the index object. As shown by the dashed line 1765, blocks 1755 and 1760 can be omitted. Finally, in block 1770, Figure 1 The resulting software 820 of Figure 7 can return the result of the deletion request 705 from the KVV160 of Figure 1 to the application 120 of

[0205] In Figures 14A to 17C there are some blocks that include determining the highest append index of the key. Figures 18A to 20 Shows various embodiments for determining the highest append index of the key. As referenced above Figure 12 stated, these embodiments can be combined and are not mutually exclusive.

[0206] Figures 18A to 18B Shows an embodiment according to the inventive concept, Figure 1 The KVV 160 of Figure 1 on the KV-SSD 125 of Figure 18A In Figure 8 the index determination software 850 of Figure 1 can determine the possible highest append index. As stated above,

[0207] In block 1805, Figure 8 the KVV 160 of Figure 1 can set a limit on the number of append operations that can be performed: this limit relates to the possible highest append index. For example, if a total of 1024 write / append requests are allowed for a given key and the base index is 0, the possible highest append index will be 1023. Figure 9 In block 1810, Figure 8 the combined software 810 of Figure 1 can combine the possible highest append index with the key 150-1 of Figure 9 to form the index key 910 of

[0208] In block 1820( Figure 18B ) Figure 8 the index determination software 850 ofFigure 1 whether the KV-SSD 125 stores an object having Figure 9 the index key 910. If so, in block 1825, the index is Figure 1 the highest appended index of key 150-1, and the process may end. Otherwise, Figure 1 the KV-SSD 125 does not store an object having Figure 9 the index key 910. In block 1830, Figure 8 the index determination software 850 may decrement the index, and in block 1835, Figure 8 the combined software 810 may combine the new index with Figure 1 key 150-1 to form Figure 1 the new index key 910. The process may then return to block 1815 to check Figure 1 whether the KV-SSD 125 stores an object having Figure 9 the new index key 910. In this way, Figure 8 the index determination software 850 may iteratively search for Figure 1 the highest appended index of key 150-1.

[0209] Note that in Figures 18A to 18B , Figure 8 the index determination software 850 may start searching sequentially downward from the possible highest appended index to locate Figure 1 the highest appended index of key 150-1. However, Figure 8 the index determination software 850 may also start searching sequentially upward from the base index, incrementing the index until Figure 1 the KV-SSD 125 indicates that no object was found for a particular index key, at which point Figure 8 the index determination software 850 will know that the previous index is the highest appended index of the key.

[0210] Figures 19A to 19B shows another embodiment according to the inventive concept, Figure 1 the KVV 160 determines an exemplary program flowchart of the highest appended index of a key on Figure 1 the KV-SSD 125. In Figure 19A , in block 1905, Figure 8 the index determination software 850 may determine Figure 1 the base index of key 150-1. In block 1910, Figure 8 the index determination software 850 may determine Figure 1 the possible highest appended index of key 150-1. Similar to Figure 18A block 1805, the highest appended index may be relative to Figure 1Determined by the maximum number of append requests to the key permitted by the KVV 160. The boxes 1905 and 1910 therebetween define the range of possible append indices to search for the highest append index of the key 150-1 Figure 1 of.

[0211] In box 1915, Figure 8 the index determines that the software 850 can check to see if the range has been narrowed down to a single index: that is, the lower end of the range is equal to the upper end of the range. If so, in box 1920, the highest append index of the key 150-1 has been found, and the process can end. Figure 1 of.

[0212] Otherwise, in box 1925( Figure 19B ), Figure 8 the index determines that the software 850 can select the index in the middle of the range. For example, if low represents the index of the lower end of the range and high represents the index of the upper end of the range, this middle index can be calculated as (high - low) ÷ 2 (if the value is not an integer, a number just above or below this value can be selected). In box 1930, Figure 8 the combiner software 810 can combine this middle index value with Figure 1 the key 150-1 to form Figure 9 the index key 910. In box 1935, Figure 8 the execution software 815 can attempt to access the value of the index key 910 from Figure 1 the KV-SSD 125. In box 1940, Figure 9 the index determines that the software 850 can determine if the access is successful: that is, Figure 8 the KV-SSD 125 stores an object with the index key. Note that Figure 1 the index determines that the software 850 is not concerned here with any value in the object stored on Figure 8 the KV-SSD 125: Figure 1 all the index determines that the software 850 is interested in whether the object exists on Figure 8 the KV-SSD 125. If the access is successful, in box 1945, Figure 1 the index determines that the software 850 can replace the lower end of the range with the middle index; otherwise, in box 1950, Figure 8 the index determines that the software 850 can replace the upper end of the range with the middle index. Either way, control returns to box 1915( Figure 8 ) to see if the highest append index has been located. Figure 19A ).

[0213] Figure 20 Shows yet another embodiment according to the inventive concept, Figure 1 of the KVV 160 in Figure 1 of the KV-SSD 125 to determine the flowchart of an exemplary program of the highest append index of the key. In Figure 20 , in block 2005, Figure 8 of the index determination software 850 can determine the key associated with the index object stored on Figure 1 of the KV-SSD125, and the index object stores Figure 1 of the highest append index of the key 150-1. Finally, in block 2010, Figure 8 of the execution software 815 can access the highest append index from the index object on Figure 1 of the KV-SSD125.

[0214] In Figures 13A to 20 , some embodiments of the inventive concept are shown. However, those skilled in the art will recognize that other embodiments of the inventive concept are also possible by changing the order of the blocks, by omitting blocks, or by including links not shown in the figures. All such variations of the flowchart, whether explicitly set forth or not, are considered embodiments of the inventive concept.

[0215] Embodiments of the inventive concept provide technical advantages over the prior art. Embodiments of the inventive concept provide a mechanism by which data can be appended to an existing value stored on Figure 1 of the KV-SSD125. In a traditional system, when Figure 1 of the application 120 wants to append new data to a value stored on the KV-SSD 125, the application 120 must read the existing value, modify the value to append the new data, and store the modified value back to Figure 1 of the KV-SSD 125 (to reuse the original key, this requires invalidating the original object stored on Figure 1 of the KV-SSD 125). This approach requires read requests, write requests, and delete requests sent by Figure 1 of the application 120 to Figure 1 of the KV-SSD 125, plus any processor cycles required to modify the value to append the new data. In addition, the delete operation means that there is more storage on Figure 1 of the KV-SSD 125 that stores invalid data that needs to be garbage collected, which can be an expensive (time-consuming) process.

[0216] In contrast, assuming Figure 1 of the metadata 170-1 is stored in Figure 1 of the hash table 165 (which should be a correct assumption in most cases), in embodiments of the inventive concept, noFigure 1 a read request or a delete request of the KV-SSD 125. All that is required is Figure 1 a write request of the KV-SSD 125 to store additional information. Additionally, modifying the value does not require processor cycles. Finally, by avoiding the need to delete an object from Figure 1 the KV-SSD 125, the need for garbage collection on Figure 1 the KV-SSD125 can be reduced.

[0217] Append semantics also provide other benefits. In traditional systems, Figure 1 the application 120 must handle the possibility that a particular value may exceed Figure 1 the maximum object size allowed on the KV-SSD 125. Utilizing the append semantics provided by embodiments of the inventive concept, Figure 1 the KVV 160 can handle the possibility that a particular value may be too large to fit into Figure 1 a single object on the KV-SSD 125, thereby eliminating the need for Figure 1 the application 120 to handle such a situation.

[0218] The following discussion is intended to provide a brief general description of one or more suitable machines in which certain aspects of the inventive concept may be implemented. The one or more machines may be controlled, at least in part, by: input from conventional input devices such as, for example, a keyboard, a mouse, etc.; and instructions received from another machine, interaction with a virtual reality (VR) environment, biometric feedback, or other input signals. As used herein, the term "machine" is intended to broadly encompass a single machine, a virtual machine, or a system formed by machines, virtual machines, or devices operating together in communication. Exemplary machines include computing devices (such as a personal computer, a workstation, a server, a portable computer, a handheld device, a telephone, a tablet computer, etc.) and transportation devices (such as private or public transportation (such as an automobile, a train, a taxi, etc.)).

[0219] The one or more machines may include an embedded controller, such as a programmable or non-programmable logic device or array, an application specific integrated circuit (ASIC), an embedded computer, a smart card, etc. The one or more machines may utilize one or more connections to one or more remote machines (e.g., via a network interface, a modem, or other communicative coupling). The machines may be interconnected via physical networks and / or logical networks such as, for example, an intranet, the Internet, a local area network, a wide area network, etc. Those skilled in the art will appreciate that network communications may utilize a variety of wired and / or wireless short-range or long-range carriers and protocols, including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 802.11, Bluetooth , optical, infrared, cable, laser, etc.

[0220] Embodiments of the inventive concept may be described by reference to or in conjunction with associated data, including functions, programs, data structures, applications, etc. that, when accessed by a machine, cause the machine to perform tasks or define abstract data types or low-level hardware contexts. The associated data may be stored, for example, in volatile and / or non-volatile memory (e.g., RAM, ROM, etc.) or other storage devices and their associated storage media (including hard disk drives, floppy disks, optical storage, magnetic tape, flash memory, memory sticks, digital video disks, biological storage, etc.). The associated data may be delivered in the form of data packets, serial data, parallel data, propagated signals, etc. via a transmission environment (including physical networks and / or logical networks), and may be used in compressed or encrypted formats. The associated data may be used in a distributed environment and may be stored locally and / or remotely for access by a machine.

[0221] Embodiments of the inventive concept may include a tangible, non-transitory machine-readable medium including instructions executable by one or more processors, the instructions including instructions for performing the elements of the inventive concept described herein.

[0222] The various operations of the above method may be performed by any suitable means capable of performing these operations, such as various hardware and / or software components, circuits, and / or modules. The software may include an ordered list of executable instructions for implementing logical functions, and may be embodied in any “processor-readable medium” for use by or in connection with an instruction execution system, apparatus, or device (e.g., a single-core or multi-core processor or a system including a processor).

[0223] The methods, algorithms, and functional blocks or steps described in connection with the embodiments disclosed herein can be implemented directly in hardware, implemented by software modules executed by a processor, or implemented in a combination of both. If implemented in software, the functions can be stored on or transmitted through a tangible, non-transitory computer-readable medium as one or more instructions or codes. The software modules can reside in a random access memory (RAM), flash memory, read-only memory (ROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), registers, a hard disk, a removable disk, a compact disk ROM (CD ROM), or any other form of storage medium known in the art.

[0224] The principles of the inventive concept have been described and illustrated with reference to the embodiments shown. It will be recognized that the embodiments shown can be arranged and modified in detail and combined in any desired manner without departing from these principles. And although the foregoing discussion has focused on specific embodiments, other configurations are also contemplated. Specifically, even though expressions such as "embodiments according to the inventive concept" are used herein, these phrases are meant to generally refer to the possibility of embodiments and are not intended to limit the inventive concept to a particular embodiment configuration. These terms used herein can refer to the same or different embodiments that can be combined into other embodiments.

[0225] The above-described illustrative embodiments should not be considered as limiting the inventive concept of the illustrative embodiments. Although several embodiments have been described, those skilled in the art will readily understand that many modifications can be made to these embodiments without materially departing from the novel teachings and advantages of the present disclosure. Accordingly, all such modifications are intended to be included within the scope of the inventive concept as defined by the claims.

[0226] Embodiments of the inventive concept can extend to the following statements, but are not limited thereto:

[0227] Statement 1. Embodiments of the inventive concept include software implemented using circuitry, the software including:

[0228] An application programming interface (API) that receives requests related to key-value pairs of a key-value solid-state drive (KV-SSD) from an application, the key-value pairs including keys and values, the application being executed by a processor;

[0229] A combiner software that combines the key with an index to generate an index key; and

[0230] An execution software that performs an operation on the KV-SSD using the index key and the value.

[0231] Statement 2. An embodiment of the inventive concept includes the software implemented using a circuit according to Statement 1, and the software further includes a result software that returns the result of a request to an application.

[0232] Statement 3. An embodiment of the inventive concept includes the software implemented using a circuit according to Statement 1, wherein the circuit includes a second processor.

[0233] Statement 4. An embodiment of the inventive concept includes the software implemented using a circuit according to Statement 3, wherein the second processor is a processor that executes an application.

[0234] Statement 5. An embodiment of the inventive concept includes the software implemented using a circuit according to Statement 4, wherein the software is a part of an operating system executed by a processor.

[0235] Statement 6. An embodiment of the inventive concept includes the software implemented using a circuit according to Statement 3, wherein the second processor is a component of the KV-SSD.

[0236] Statement 7. An embodiment of the inventive concept includes the software implemented using a circuit according to Statement 1, wherein the circuit includes at least one of a field programmable gate array (FPGA), a graphics processing unit (GPU), and an application specific integrated circuit (ASIC).

[0237] Statement 8. An embodiment of the inventive concept includes the software implemented using a circuit according to Statement 1, and the software further includes a metadata software that generates metadata of a key.

[0238] Statement 9. An embodiment of the inventive concept includes the software implemented using a circuit according to Statement 8, wherein the metadata includes at least one of an append index, an append offset, an append length, and a data structure of an append request for a key-value pair.

[0239] Statement 10. An embodiment of the inventive concept includes the software implemented using a circuit according to Statement 8, and the software further includes:

[0240] A second combiner software that combines the metadata with the value to generate a modified value; and

[0241] The execution software is operable to perform an operation on the KV-SSD using the index key and the modified value.

[0242] Statement 11. An embodiment of the inventive concept includes software implemented using a circuit according to Statement 8, the software further including hash table software that uses a hash table in memory to store the metadata associated with the key.

[0243] Statement 12. An embodiment of the inventive concept includes software implemented using a circuit according to Statement 11, wherein the hash table software includes eviction software that evicts old metadata from the hash table.

[0244] Statement 13. An embodiment of the inventive concept includes software implemented using a circuit according to Statement 1, wherein:

[0245] the request includes one of a write request and an append request; and

[0246] the execution software is operable to store the value associated with the index key on the KV-SSD.

[0247] Statement 14. An embodiment of the inventive concept includes software implemented using a circuit according to Statement 13, wherein:

[0248] the value is greater than the maximum size of an object on the KV-SSD;

[0249] the combiner software is operable to combine the key with multiple indexes, thereby generating multiple index keys;

[0250] the software implemented using a circuit further includes partitioning software that partitions the value into multiple parts; and

[0251] the execution software is operable to store the multiple parts associated with the multiple index keys on the KV-SSD.

[0252] Statement 15. An embodiment of the inventive concept includes software implemented using a circuit according to Statement 14, wherein

[0253] the hash table software is operable to add an entry for the key in the hash table.

[0254] Statement 16. An embodiment of the inventive concept includes software implemented using a circuit according to Statement 14, wherein

[0255] the hash table software is operable to update an entry for the key in the hash table.

[0256] Statement 17. An embodiment of the inventive concept includes software implemented using a circuit according to Statement 1, wherein:

[0257] the request includes a read request; and

[0258] The execution software is operable to read a plurality of values associated with a plurality of index keys on the KV-SSD and combine the plurality of values to generate the value.

[0259] Statement 18. Embodiments of the inventive concept include software implemented using a circuit according to Statement 1, wherein:

[0260] The request includes a deletion request; and

[0261] The execution software is operable to delete a plurality of index keys on the KV-SSD.

[0262] Statement 19. Embodiments of the inventive concept include software implemented using a circuit according to Statement 18, wherein

[0263] The hash table software is operable to delete an entry for a key in the hash table.

[0264] Statement 20. Embodiments of the inventive concept include software implemented using a circuit according to Statement 1, the software further including index determination software for determining the highest appended index of a key.

[0265] Statement 21. Embodiments of the inventive concept include software implemented using a circuit according to Statement 20, wherein the index determination software is operable to access the highest appended index of a key from the metadata of the key in the hash table stored in memory.

[0266] Statement 22. Embodiments of the inventive concept include software implemented using a circuit according to Statement 20, wherein the index determination software is operable to search the KV-SSD to obtain the highest appended index of the key.

[0267] Statement 23. Embodiments of the inventive concept include software implemented using a circuit according to Statement 22, wherein the index determination software is operable to sequentially attempt to access the index keys on the KV-SSD to determine the highest appended index of the key.

[0268] Statement 24. Embodiments of the inventive concept include software implemented using a circuit according to Statement 22, wherein the index determination software is operable to perform a binary search of the index key range on the KV-SSD to determine the highest appended index.

[0269] Statement 25. Embodiments of the inventive concept include software implemented using a circuit according to Statement 20, wherein the index determination software is operable to access the highest appended index from the index object on the KV-SSD.

[0270] Statement 26. Embodiments of the inventive concept include a method, the method including:

[0271] Receive a write request from an application to store a value associated with a key as a key-value pair on a key-value solid-state drive (KV-SSD), the application being executed by a processor;

[0272] Determine a base index of the key;

[0273] Combine the base index with the key to generate an index key; and

[0274] Perform a storage operation on the KV-SSD to associate the index key with the value.

[0275] Statement 27. An embodiment of the inventive concept includes the method according to statement 26, the method further including returning a write result of the storage operation to the application.

[0276] Statement 28. An embodiment of the inventive concept includes the method according to statement 26, wherein:

[0277] The method further includes:

[0278] Establish first metadata of the key; and

[0279] Combine the value with the first metadata to generate a first modified value; and

[0280] Performing the storage operation on the KV-SSD to associate the index key with the value includes performing the storage operation on the KV-SSD to associate the index key with the first modified value.

[0281] Statement 29. An embodiment of the inventive concept includes the method according to statement 28, wherein the first metadata includes a base index of the key.

[0282] Statement 30. An embodiment of the inventive concept includes the method according to statement 29, wherein the first metadata further includes a first append offset and a first append length.

[0283] Statement 31. An embodiment of the inventive concept includes the method according to statement 29, wherein the first metadata further includes a first data structure of an append write request for the key-value pair.

[0284] Statement 32. An embodiment of the inventive concept includes the method according to statement 29, the method further including storing the first metadata in a hash table in memory, the first metadata being associated with the key.

[0285] Statement 33. An embodiment of the inventive concept includes the method according to statement 32, wherein storing the first metadata in a hash table in memory includes evicting existing metadata associated with a second key from the hash table.

[0286] Statement 34. An embodiment of the inventive concept includes the method according to Statement 33, wherein evicting the existing metadata associated with the second key from the hash table includes selecting the second key as the least recently used key in the hash table.

[0287] Statement 35. An embodiment of the inventive concept includes the method according to Statement 26, wherein:

[0288] the method further includes determining, at least in part based on the value exceeding the maximum size of an object on the KV-SSD, the number of objects required to store the value;

[0289] combining the base index with the key to produce an index key includes combining a plurality of indexes with the key to produce a plurality of index keys, wherein the plurality of index keys are at least as large as the number of objects required to store the value; and

[0290] performing a storage operation on the KV-SSD to associate the index key with the value includes performing a plurality of storage operations on the KV-SSD to associate each of the plurality of index keys with a portion of the value.

[0291] Statement 36. An embodiment of the inventive concept includes the method according to Statement 26, the method further includes bypassing the operations of determining the base index of the key, combining the base index with the key to produce an index key, and performing a storage operation on the KV-SSD to associate the index key with the value, and instead performing a traditional storage operation on the KV-SSD to associate the key with the value.

[0292] Statement 37. An embodiment of the inventive concept includes the method according to Statement 36, wherein bypassing the operations of determining the base index of the key, combining the base index with the key to produce an index key, and performing a storage operation on the KV-SSD to associate the index key with the value, and instead performing a traditional storage operation on the KV-SSD to associate the key with the value is at least in part based on the write request specifying a traditional storage operation.

[0293] Statement 38. An embodiment of the inventive concept includes the method according to Statement 26, the method further includes:

[0294] receiving an append request from the application to append a second value to the value associated with the key on the KV-SSD;

[0295] determining the highest append index of the key;

[0296] incrementing the highest append index to produce a new highest append index;

[0297] Combine the new highest append index with the key to generate an append index key; and

[0298] Perform a second storage operation on the KV-SSD to associate the append index key with the second value.

[0299] Statement 39. An embodiment of the inventive concept includes the method according to Statement 38, the method further including returning an append result of the second storage operation to the application.

[0300] Statement 40. An embodiment of the inventive concept includes the method according to Statement 38, wherein:

[0301] The method further includes:

[0302] Establish second metadata of the key; and

[0303] Combine the second value with the second metadata to generate a second modified value; and

[0304] Performing a second storage operation on the KV-SSD to associate the append index key with the second value includes performing the second storage operation on the KV-SSD to associate the append index key with the second modified value.

[0305] Statement 41. An embodiment of the inventive concept includes the method according to Statement 40, wherein the second metadata includes an append index of the key.

[0306] Statement 42. An embodiment of the inventive concept includes the method according to Statement 41, wherein the second metadata further includes a second append offset and a second append length.

[0307] Statement 43. An embodiment of the inventive concept includes the method according to Statement 41, wherein the second metadata further includes a second data structure of an append request for a key-value pair.

[0308] Statement 44. An embodiment of the inventive concept includes the method according to Statement 41, the method further including storing the second metadata in a hash table in memory, the second metadata being associated with the key.

[0309] Statement 45. An embodiment of the inventive concept includes the method according to Statement 44, wherein storing the second metadata in a hash table in memory includes evicting existing metadata associated with a second key from the hash table.

[0310] Statement 46. An embodiment of the inventive concept includes the method according to Statement 45, wherein evicting existing metadata associated with a second key from the hash table includes selecting the second key as the least recently used key in the hash table.

[0311] Statement 47. An embodiment of the inventive concept includes the method according to Statement 44, wherein the second metadata is stored in a hash table in memory, the second metadata being associated with the key and including:

[0312] Determining that the hash table does not store the first metadata associated with the key;

[0313] Determining the highest append index of the key; and

[0314] In response to the highest append index of the key, accessing the first metadata from the KV-SSD.

[0315] Statement 48. An embodiment of the inventive concept includes the method according to Statement 47, wherein determining the highest append index of the key includes systematically requesting data associated with the key from the KV-SSD until the highest append index of the key is determined.

[0316] Statement 49. An embodiment of the inventive concept includes the method according to Statement 48, wherein systematically requesting data associated with the key from the KV-SSD until the highest append index of the key is determined includes:

[0317] Determining a possible highest append index of the key;

[0318] Combining the possible highest append index of the key with the key to generate a test key; and

[0319] Attempting to access the data associated with the test key.

[0320] Statement 50. An embodiment of the inventive concept includes the method according to Statement 49, wherein systematically requesting data associated with the key from the KV-SSD until the highest append index of the key is determined further includes:

[0321] Decrementing the possible highest append index of the key to generate a possible new append index;

[0322] Combining the possible new append index of the key with the key to generate a new test key;

[0323] Attempting to access the data associated with the new test key; and

[0324] Repeating the operations of decrementing the possible highest append index of the key, combining the possible new append index of the key with the key, and attempting to access the data until the KV-SSD reports data associated with the new test key, at least partially based on the response of the KV-SSD to attempting to access the data associated with the new test key.

[0325] Statement 51. An embodiment of the inventive concept includes the method according to statement 48, wherein data associated with a key from the KV-SSD is systematically requested until it is determined that the highest append index of the key includes:

[0326] Determining a range of possible highest append indexes of the key;

[0327] Selecting a middle append index in the middle of the range of possible highest append indexes of the key;

[0328] Combining the middle append index with the key to generate a test key;

[0329] Attempting to access the data associated with the test key;

[0330] Narrowing the range of possible highest append indexes of the key to one of a first half range and a second half range, at least in part based on a response of the KV-SSD to the attempt to access the data associated with the test key; and

[0331] Repeating the operations of selecting a middle append index, combining the middle append index with the key, narrowing the range of possible highest append indexes of the key, and attempting to access the data associated with the test key until the range includes a single possible highest append index.

[0332] Statement 52. An embodiment of the inventive concept includes the method according to statement 47, wherein determining the highest append index of a key includes accessing the highest append index of the key from an index object of the key on the KV-SSD.

[0333] Statement 53. An embodiment of the inventive concept includes the method according to statement 44, the method further including storing a new highest append index in an index object of the key on the KV-SSD, at least in part based on the key being selected for eviction from a hash table.

[0334] Statement 54. An embodiment of the inventive concept includes the method according to statement 38, the method further including:

[0335] Receiving a read request from the application to read a value associated with the key from the KV-SSD;

[0336] Determining a basic index of the key;

[0337] Determining a new highest append index of the key;

[0338] Combine each index from the base index of the key to the new highest append index of the key with the key to generate at least two index keys;

[0339] Perform a read operation on each of the at least two index keys on the KV-SSD to generate at least two read values;

[0340] Combine the at least two read values to generate the value; and

[0341] In response to a read request, return the value to the application.

[0342] Statement 55. An embodiment of the inventive concept includes the method according to statement 54, wherein:

[0343] The KV-SSD stores first metadata associated with the key and second metadata associated with the key. The first metadata includes at least one of a first append index, a first offset, a first length, and a first data structure of an append request for a key-value pair. The second metadata includes at least one of a new highest append index, a second offset, a second length, and a second data structure of an append request for a key-value pair. The second metadata is also stored in a hash table in memory; and

[0344] Determining the new highest append index of the key includes determining the new highest append index of the key from the second metadata in the hash table.

[0345] Statement 56. An embodiment of the inventive concept includes the method according to statement 54, the method further including storing second metadata associated with the key in a hash table in memory. The second metadata includes at least one of a new highest append index, a second offset, a second length, and a second data structure of an append request for a key-value pair.

[0346] Statement 57. An embodiment of the inventive concept includes the method according to statement 56, wherein storing the second metadata in a hash table in memory includes evicting existing metadata associated with a second key from the hash table.

[0347] Statement 58. An embodiment of the inventive concept includes the method according to statement 57, wherein evicting existing metadata associated with a second key from the hash table includes selecting the second key as the least recently used key in the hash table.

[0348] Statement 59. An embodiment of the inventive concept includes the method according to statement 56, wherein storing the second metadata in a hash table in memory, the second metadata being associated with the key, includes:

[0349] Determine that the hash table does not store the second metadata associated with the key; and

[0350] Access the second metadata from the KV-SSD in response to the new highest append index of the key.

[0351] Statement 60. An embodiment of the inventive concept includes the method according to Statement 59, wherein determining the highest append index of the key includes systematically requesting data associated with the key from the KV-SSD until the new highest append index of the key is determined.

[0352] Statement 61. An embodiment of the inventive concept includes the method according to Statement 60, wherein systematically requesting data associated with the key from the KV-SSD until the new highest append index of the key is determined includes:

[0353] Determine the possible highest append index of the key;

[0354] Combine the possible highest append index of the key with the key to generate a test key; and

[0355] Attempt to access the data associated with the test key.

[0356] Statement 62. An embodiment of the inventive concept includes the method according to Statement 61, wherein systematically requesting data associated with the key from the KV-SSD until the highest append index of the key is determined further includes:

[0357] Decrement the possible highest append index of the key to generate a possible new append index;

[0358] Combine the possible new append index of the key with the key to generate a new test key;

[0359] Attempt to access the data associated with the new test key; and

[0360] Repeat the operations of decrementing the possible highest append index of the key, combining the possible new append index of the key with the key, and attempting to access the data until the KV-SSD reports data associated with the new test key, at least in part based on the response of the KV-SSD to the attempt to access the data associated with the new test key.

[0361] Statement 63. An embodiment of the inventive concept includes the method according to Statement 60, wherein systematically requesting data associated with the key from the KV-SSD until the new highest append index of the key is determined includes:

[0362] Determine the range of the possible highest append index of the key;

[0363] Select a middle append index in the middle of the range of the possible highest append index of the key;

[0364] Combine the middle append index with the key to generate a test key;

[0365] Attempt to access the data associated with the test key;

[0366] Narrow the range of the possible highest append index of the key to one of the first half range and the second half range at least partially based on the response of the KV-SSD to the attempt to access the data associated with the test key; and

[0367] Repeat the operations of selecting a middle append index, combining the middle append index with the key, narrowing the range of the possible highest append index of the key, and attempting to access the data associated with the test key until the range includes a single possible highest append index.

[0368] Statement 64. An embodiment of the inventive concept includes the method according to statement 59, wherein determining the new highest append index of the key includes accessing the new highest append index of the key from the index object of the key on the KV-SSD.

[0369] Statement 65. An embodiment of the inventive concept includes the method according to statement 56, the method further including storing the new highest append index in the index object of the key on the KV-SSD at least partially based on the key being selected to be evicted from the hash table.

[0370] Statement 66. An embodiment of the inventive concept includes the method according to statement 54, the method further including returning the new highest append index to the application.

[0371] Statement 67. An embodiment of the inventive concept includes the method according to statement 66, wherein returning the new highest append index to the application includes returning the new highest append index to the application before returning the value to the application in response to a read request.

[0372] Statement 68. An embodiment of the inventive concept includes the method according to statement 38, the method further including:

[0373] Receiving a delete request from the application to delete the value associated with the key as a key-value pair on the key-value solid state drive (KV-SSD);

[0374] Determining the basic index of the key;

[0375] Combining the basic index with the key to generate a first index key;

[0376] Perform a first deletion operation on the first index key on the KV-SSD;

[0377] Determine at least one append index of the key;

[0378] Combine the at least one append index with the key to generate at least one second index key; and

[0379] Perform at least one second deletion operation on the at least one second index key on the KV-SSD.

[0380] Statement 69. An embodiment of the inventive concept includes the method according to Statement 68, the method further including returning deletion results of the first deletion operation and the at least one second deletion operation to the application.

[0381] Statement 70. An embodiment of the inventive concept includes the method according to Statement 68, the method further including:

[0382] Locate metadata in a hash table in memory, the metadata being associated with the key; and

[0383] Remove the metadata from the hash table in memory.

[0384] Statement 71. An embodiment of the inventive concept includes the method according to Statement 68, the method further including:

[0385] Identify an index object of a key stored on the KV-SSD; and

[0386] Delete the index object of the key from the KV-SSD.

[0387] Statement 72. An embodiment of the inventive concept includes a method, the method including:

[0388] Receive an append request from an application to append a second value as a key-value pair to a value associated with a key on a key-value solid state drive (KV-SSD), the application being executed by a processor;

[0389] Determine the highest append index of the key;

[0390] Increment the highest append index to generate a new highest append index;

[0391] Combine the new highest append index with the key to generate an append index key; and

[0392] Perform a second storage operation on the KV-SSD to associate the append index key with the second value.

[0393] Statement 73. An embodiment of the inventive concept includes the method according to Statement 72, the method further including returning an append result of a second storage operation to the application.

[0394] Statement 74. An embodiment of the inventive concept includes the method according to Statement 72, wherein:

[0395] the KV-SSD stores first metadata associated with the key, the first metadata including at least one of a highest append index of an append request for the key-value pair, a first offset, a first length, and a first data structure;

[0396] the method further includes:

[0397] establishing second metadata for the key; and

[0398] combining the second value with the second metadata to produce a second modified value; and

[0399] performing a second storage operation on the KV-SSD to associate the append index key with the second value includes performing the second storage operation on the KV-SSD to associate the append index key with the second modified value.

[0400] Statement 75. An embodiment of the inventive concept includes the method according to Statement 74, wherein the second metadata includes a new highest append index of the key.

[0401] Statement 76. An embodiment of the inventive concept includes the method according to Statement 75, wherein the second metadata further includes a second append offset and a second append length.

[0402] Statement 77. An embodiment of the inventive concept includes the method according to Statement 75, wherein the second metadata further includes a second data structure of an append request for the key-value pair.

[0403] Statement 78. An embodiment of the inventive concept includes the method according to Statement 75, the method further including storing the second metadata in a hash table in memory, the second metadata being associated with the key.

[0404] Statement 79. An embodiment of the inventive concept includes the method according to Statement 78, wherein storing the second metadata in a hash table in memory includes evicting existing metadata associated with a second key from the hash table.

[0405] Statement 80. An embodiment of the inventive concept includes the method according to Statement 79, wherein evicting existing metadata associated with a second key from the hash table includes selecting the second key as the least recently used key in the hash table.

[0406] Statement 81. An embodiment of the inventive concept includes the method according to Statement 78, wherein the second metadata is stored in a hash table in memory, and the second metadata is associated with the key and includes:

[0407] Determining that the hash table does not store the first metadata associated with the key;

[0408] Determining the highest append index of the key; and

[0409] In response to the highest append index of the key, accessing the first metadata from the KV-SSD.

[0410] Statement 82. An embodiment of the inventive concept includes the method according to Statement 81, wherein determining the highest append index of the key includes systematically requesting data associated with the key from the KV-SSD until the highest append index of the key is determined.

[0411] Statement 83. An embodiment of the inventive concept includes the method according to Statement 82, wherein systematically requesting data associated with the key from the KV-SSD until the highest append index of the key is determined includes:

[0412] Determining the possible highest append index of the key;

[0413] Combining the possible highest append index of the key with the key to generate a test key; and

[0414] Attempting to access the data associated with the test key.

[0415] Statement 84. An embodiment of the inventive concept includes the method according to Statement 83, wherein systematically requesting data associated with the key from the KV-SSD until the highest append index of the key is determined further includes:

[0416] Decrementing the possible highest append index of the key to generate a possible new append index;

[0417] Combining the possible new append index of the key with the key to generate a new test key;

[0418] Attempting to access the data associated with the new test key; and

[0419] Repeating the operations of decrementing the possible highest append index of the key, combining the possible new append index of the key with the key, and attempting to access the data until the KV-SSD reports data associated with the new test key, at least partially based on the response of the KV-SSD to attempting to access the data associated with the new test key.

[0420] Statement 85. An embodiment of the inventive concept includes the method according to Statement 82, wherein data associated with a key from the KV-SSD is systematically requested until it is determined that the highest append index of the key includes:

[0421] Determine a range of possible highest append indexes of the key;

[0422] Select an intermediate append index in the middle of the range of possible highest append indexes of the key;

[0423] Combine the intermediate append index with the key to generate a test key;

[0424] Attempt to access the data associated with the test key;

[0425] At least partially based on the response of the KV-SSD to the attempt to access the data associated with the test key, narrow the range of possible highest append indexes of the key to one of the first half range and the second half range; and

[0426] Repeat the operations of selecting an intermediate append index, combining the intermediate append index with the key, narrowing the range of possible highest append indexes of the key, and attempting to access the data associated with the test key until the range includes a single possible highest append index.

[0427] Statement 86. An embodiment of the inventive concept includes the method according to Statement 81, wherein determining the highest append index of a key includes accessing the highest append index of the key from an index object of the key on the KV-SSD.

[0428] Statement 87. An embodiment of the inventive concept includes the method according to Statement 78, the method further including storing a new highest append index in an index object of the key on the KV-SSD at least partially based on the key being selected for eviction from a hash table.

[0429] Statement 88. An embodiment of the inventive concept includes a method, the method including:

[0430] Receiving a read request from an application to read a value associated with a key as a key-value pair from a key-value solid-state drive (KV-SSD), the application being executed by a processor;

[0431] Determine a basic index of the key;

[0432] Determine the highest append index of the key;

[0433] Combine each index from the basic index of the key to the highest append index of the key with the key to generate at least two index keys;

[0434] Perform a read operation on each of the at least two index keys on the KV-SSD to generate at least two read values;

[0435] Combine the at least two read values to generate the value; and

[0436] In response to a read request, return the value to the application.

[0437] Statement 89. Embodiments of the inventive concept include the method according to statement 88, wherein:

[0438] The KV-SSD stores first metadata associated with a key and second metadata associated with the key, the first metadata including at least one of a first append index, a first offset, a first length, and a first data structure of an append request for a key-value pair, the second metadata including at least one of a highest append index, a second offset, a second length, and a second data structure of an append request for a key-value pair, and the second metadata is also stored in a hash table in memory; and

[0439] Determining the highest append index of the key includes determining the highest append index of the key from the second metadata in the hash table.

[0440] Statement 90. Embodiments of the inventive concept include the method according to statement 88, the method further including storing the second metadata in a hash table in memory, the second metadata including at least one of a highest append index, a second offset, a second length, and a second data structure of an append request for a key-value pair.

[0441] Statement 91. Embodiments of the inventive concept include the method according to statement 90, wherein storing the second metadata in a hash table in memory includes evicting existing metadata associated with a second key from the hash table.

[0442] Statement 92. Embodiments of the inventive concept include the method according to statement 91, wherein evicting existing metadata associated with a second key from the hash table includes selecting the second key as the least recently used key in the hash table.

[0443] Statement 93. Embodiments of the inventive concept include the method according to statement 90, wherein storing the second metadata in a hash table in memory, the second metadata being associated with the key, includes:

[0444] Determining that the hash table does not store the second metadata associated with the key; and

[0445] In response to the highest append index of the key, accessing the second metadata from the KV-SSD.

[0446] Statement 94. An embodiment of the inventive concept includes the method according to Statement 93, wherein determining the highest append index of the key includes systematically requesting data associated with the key from the KV-SSD until the highest append index of the key is determined.

[0447] Statement 95. An embodiment of the inventive concept includes the method according to Statement 94, wherein systematically requesting data associated with the key from the KV-SSD until the highest append index of the key is determined includes:

[0448] determining a possible highest append index of the key;

[0449] combining the possible highest append index of the key with the key to generate a test key; and

[0450] attempting to access the data associated with the test key.

[0451] Statement 96. An embodiment of the inventive concept includes the method according to Statement 95, wherein systematically requesting data associated with the key from the KV-SSD until the highest append index of the key is determined further includes:

[0452] decrementing the possible highest append index of the key to generate a possible new append index;

[0453] combining the possible new append index of the key with the key to generate a new test key;

[0454] attempting to access the data associated with the new test key; and

[0455] repeating the operations of decrementing the possible highest append index of the key, combining the possible new append index of the key with the key, and attempting to access the data until the KV-SSD reports data associated with the new test key, at least in part based on the response of the KV-SSD to attempting to access the data associated with the new test key.

[0456] Statement 97. An embodiment of the inventive concept includes the method according to Statement 94, wherein systematically requesting data associated with the key from the KV-SSD until the highest append index of the key is determined includes:

[0457] determining a range of possible highest append indices of the key;

[0458] selecting an intermediate append index in the middle of the range of possible highest append indices of the key;

[0459] combining the intermediate append index with the key to generate a test key;

[0460] attempt to access the data associated with the test key;

[0461] narrow the range of the possible highest append index of the key to one of a first half range and a second half range, at least in part based on a response of the KV-SSD to the attempt to access the data associated with the test key; and

[0462] repeat the operations of selecting an intermediate append index, combining the intermediate append index with the key, narrowing the range of the possible highest append index of the key, and attempting to access the data associated with the test key until the range includes a single possible highest append index.

[0463] Statement 98. An embodiment of the inventive concept includes the method according to Statement 93, wherein determining the highest append index of a key includes accessing the highest append index of the key from an index object of the key on the KV-SSD.

[0464] Statement 99. An embodiment of the inventive concept includes the method according to Statement 90, the method further including storing the highest append index in an index object of the key on the KV-SSD, at least in part based on the key being selected to be evicted from a hash table.

[0465] Statement 100. An embodiment of the inventive concept includes the method according to Statement 88, the method further including returning the highest append index to an application.

[0466] Statement 101. An embodiment of the inventive concept includes the method according to Statement 100, wherein returning the highest append index to an application includes returning the highest append index to the application before returning a value to the application in response to a read request.

[0467] Statement 102. An embodiment of the inventive concept includes a method, the method including:

[0468] receiving, from an application executed by a processor, a delete request to delete a value associated with a key as a key-value pair on a key-value solid state drive (KV-SSD);

[0469] determining a basic index of the key;

[0470] combining the basic index with the key to generate a first index key;

[0471] performing a delete operation on the first index key on the KV-SSD;

[0472] determining at least one append index of the key;

[0473] Combine the at least one additional index with the key to generate at least one second index key; and

[0474] Perform at least one deletion operation on the at least one second index key on the KV-SSD.

[0475] Statement 103. An embodiment of the inventive concept includes the method according to Statement 102, the method further including returning the deletion results of the first deletion operation and the at least one second deletion operation to the application.

[0476] Statement 104. An embodiment of the inventive concept includes the method according to Statement 102, the method further including:

[0477] Locate metadata in a hash table in memory, the metadata being associated with the key; and

[0478] Remove the metadata from the hash table in memory.

[0479] Statement 105. An embodiment of the inventive concept includes the method according to Statement 102, the method further including:

[0480] Identify an index object of a key stored on the KV-SSD; and

[0481] Delete the index object of the key from the KV-SSD.

[0482] Statement 106. An embodiment of the inventive concept includes an article of manufacture, the article of manufacture including a non-transitory storage medium having instructions stored thereon that, when executed by a machine, cause:[[]]

[0483] Receive a write request from an application to store a value associated with a key as a key-value pair on a key-value solid state drive (KV-SSD), the application being executed by a processor;

[0484] Determine a basic index of the key;

[0485] Combine the basic index with the key to generate an index key; and

[0486] Perform a storage operation on the KV-SSD to associate the index key with the value.

[0487] Statement 107. An embodiment of the inventive concept includes the article of manufacture according to Statement 106, the non-transitory storage medium having further instructions stored thereon that, when executed by a machine, cause the write result of the storage operation to be returned to the application.

[0488] Statement 108. An embodiment of the inventive concept includes the article of manufacture according to Statement 106, wherein:

[0489] The method further includes:

[0490] establishing first metadata of the key; and

[0491] combining the value with the first metadata to produce a first modified value; and

[0492] Performing a storage operation on the KV-SSD to associate the index key with the value includes performing the storage operation on the KV-SSD to associate the index key with the first modified value.

[0493] Statement 109. Embodiments of the inventive concept include the article according to statement 108, wherein the first metadata includes a basic index of the key.

[0494] Statement 110. Embodiments of the inventive concept include the article according to statement 109, wherein the first metadata further includes a first append offset and a first append length.

[0495] Statement 111. Embodiments of the inventive concept include the article according to statement 109, wherein the first metadata further includes a first data structure for an append write request of the key-value pair.

[0496] Statement 112. Embodiments of the inventive concept include the article according to statement 109, wherein further instructions are stored on the non-transitory storage medium, which when executed by a machine, cause the first metadata to be stored in a hash table in memory, the first metadata being associated with the key.

[0497] Statement 113. Embodiments of the inventive concept include the article according to statement 112, wherein storing the first metadata in a hash table in memory includes evicting existing metadata associated with a second key from the hash table.

[0498] Statement 114. Embodiments of the inventive concept include the article according to statement 113, wherein evicting existing metadata associated with a second key from the hash table includes selecting the second key as the least recently used key in the hash table.

[0499] Statement 115. Embodiments of the inventive concept include the article according to statement 106, wherein:

[0500] The method further includes determining, at least in part based on the value exceeding a maximum size of an object on the KV-SSD, the number of objects required to store the value;

[0501] Combining the basic index with the key to generate an index key includes combining a plurality of indexes with the key to generate a plurality of index keys, where the plurality of index keys are at least as large as the number of objects required to store the value; and

[0502] Performing a storage operation on the KV-SSD to associate the index key with the value includes performing a plurality of storage operations on the KV-SSD to associate each of the plurality of index keys with a portion of the value.

[0503] Statement 116. An embodiment of the inventive concept includes the article according to Statement 106, further instructions being stored on the non-transitory storage medium, which when executed by a machine, cause the operations of determining the basic index of the key, combining the basic index with the key to generate an index key, and performing a storage operation on the KV-SSD to associate the index key with the value to be bypassed, and instead performing a traditional storage operation on the KV-SSD to associate the key with the value.

[0504] Statement 117. An embodiment of the inventive concept includes the article according to Statement 116, wherein bypassing the operations of determining the basic index of the key, combining the basic index with the key to generate an index key, and performing a storage operation on the KV-SSD to associate the index key with the value, and instead performing a traditional storage operation on the KV-SSD to associate the key with the value is at least partially based on a write request specifying a traditional storage operation.

[0505] Statement 118. An embodiment of the inventive concept includes the article according to Statement 106, further instructions being stored on the non-transitory storage medium, which when executed by a machine, cause:

[0506] Receiving an append request from the application to append a second value to the value associated with the key on the KV-SSD;

[0507] Determining the highest append index of the key;

[0508] Incrementing the highest append index to generate a new highest append index;

[0509] Combining the new highest append index with the key to generate an append index key; and

[0510] Performing a second storage operation on the KV-SSD to associate the append index key with the second value.

[0511] Statement 119. An embodiment of the inventive concept includes the article according to Statement 118, wherein further instructions are stored on the non-transitory storage medium, and the instructions, when executed by a machine, cause an append result of a second storage operation to be returned to the application.

[0512] Statement 120. An embodiment of the inventive concept includes the article according to Statement 118, wherein:

[0513] The method further includes:

[0514] establishing second metadata of the key; and

[0515] combining the second value with the second metadata to produce a second modified value; and

[0516] performing a second storage operation on the KV-SSD to associate the append index key with the second value includes performing the second storage operation on the KV-SSD to associate the append index key with the second modified value.

[0517] Statement 121. An embodiment of the inventive concept includes the article according to Statement 120, wherein the second metadata includes an append index of the key.

[0518] Statement 122. An embodiment of the inventive concept includes the article according to Statement 121, wherein the second metadata further includes a second append offset and a second append length.

[0519] Statement 123. An embodiment of the inventive concept includes the article according to Statement 121, wherein the second metadata further includes a second data structure of an append request for a key-value pair.

[0520] Statement 124. An embodiment of the inventive concept includes the article according to Statement 121, wherein further instructions are stored on the non-transitory storage medium, and the instructions, when executed by a machine, cause the second metadata to be stored in a hash table in memory, and the second metadata is associated with the key.

[0521] Statement 125. An embodiment of the inventive concept includes the article according to Statement 124, wherein storing the second metadata in a hash table in memory includes evicting existing metadata associated with a second key from the hash table.

[0522] Statement 126. An embodiment of the inventive concept includes the article according to Statement 125, wherein evicting existing metadata associated with a second key from the hash table includes selecting the second key as the least recently used key in the hash table.

[0523] Statement 127. An embodiment of the inventive concept includes the article according to Statement 124, wherein second metadata is stored in a hash table in memory, the second metadata being associated with the key and including:

[0524] determining that the hash table does not store the first metadata associated with the key;

[0525] determining the highest append index of the key; and

[0526] accessing the first metadata from the KV-SSD in response to the highest append index of the key.

[0527] Statement 128. An embodiment of the inventive concept includes the article according to Statement 127, wherein determining the highest append index of the key includes systematically requesting data associated with the key from the KV-SSD until the highest append index of the key is determined.

[0528] Statement 129. An embodiment of the inventive concept includes the article according to Statement 128, wherein systematically requesting data associated with the key from the KV-SSD until the highest append index of the key is determined includes:

[0529] determining a possible highest append index of the key;

[0530] combining the possible highest append index of the key with the key to produce a test key; and

[0531] attempting to access the data associated with the test key.

[0532] Statement 130. An embodiment of the inventive concept includes the article according to Statement 129, wherein systematically requesting data associated with the key from the KV-SSD until the highest append index of the key is determined further includes:

[0533] decrementing the possible highest append index of the key to produce a possible new append index;

[0534] combining the possible new append index of the key with the key to produce a new test key;

[0535] attempting to access the data associated with the new test key; and

[0536] repeating the operations of decrementing the possible highest append index of the key, combining the possible new append index of the key with the key, and attempting to access the data until the KV-SSD reports data associated with the new test key, at least in part based on the response of the KV-SSD to attempting to access the data associated with the new test key.

[0537] Statement 131. An embodiment of the inventive concept includes the article according to statement 128, wherein data associated with a key from the KV-SSD is systematically requested until it is determined that the highest append index of the key includes:

[0538] Determining a range of possible highest append indexes of the key;

[0539] Selecting a middle append index in the middle of the range of possible highest append indexes of the key;

[0540] Combining the middle append index with the key to generate a test key;

[0541] Attempting to access the data associated with the test key;

[0542] Narrowing the range of possible highest append indexes of the key to one of a first half range and a second half range at least in part based on the response of the KV-SSD to attempting to access the data associated with the test key; and

[0543] Repeating the operations of selecting a middle append index, combining the middle append index with the key, narrowing the range of possible highest append indexes of the key, and attempting to access the data associated with the test key until the range includes a single possible highest append index.

[0544] Statement 132. An embodiment of the inventive concept includes the article according to statement 127, wherein determining the highest append index of a key includes accessing the highest append index of the key from an index object of the key on the KV-SSD.

[0545] Statement 133. An embodiment of the inventive concept includes the article according to statement 124, wherein further instructions are stored on the non-transitory storage medium, which when executed by a machine, cause a new highest append index to be stored in an index object of the key on the KV-SSD at least in part based on the key being selected for eviction from a hash table.

[0546] Statement 134. An embodiment of the inventive concept includes the article according to statement 118, wherein further instructions are stored on the non-transitory storage medium, which when executed by a machine, cause:

[0547] Receiving a read request from the application to read a value associated with the key from the KV-SSD;

[0548] Determining a basic index of the key;

[0549] Determining a new highest append index of the key;

[0550] Combine each index from the base index of the key to the new highest append index of the key with the key to generate at least two index keys;

[0551] Perform a read operation on each of the at least two index keys on the KV-SSD to generate at least two read values;

[0552] Combine the at least two read values to generate the value; and

[0553] In response to a read request, return the value to the application.

[0554] Statement 135. An embodiment of the inventive concept includes the article according to statement 134, wherein:

[0555] The KV-SSD stores first metadata associated with a key and second metadata associated with the key. The first metadata includes at least one of a first append index, a first offset, a first length, and a first data structure of an append request for a key-value pair. The second metadata includes at least one of a new highest append index, a second offset, a second length, and a second data structure of an append request for a key-value pair. The second metadata is also stored in a hash table in memory; and

[0556] Determining the new highest append index of the key includes determining the new highest append index of the key from the second metadata in the hash table.

[0557] Statement 136. An embodiment of the inventive concept includes the article according to statement 134, wherein further instructions are stored on the non-transitory storage medium that, when executed by a machine, cause the second metadata associated with the key to be stored in a hash table in memory. The second metadata includes at least one of a new highest append index, a second offset, a second length, and a second data structure of an append request for a key-value pair.

[0558] Statement 137. An embodiment of the inventive concept includes the article according to statement 136, wherein storing the second metadata in a hash table in memory includes evicting the existing metadata associated with a second key from the hash table.

[0559] Statement 138. An embodiment of the inventive concept includes the article according to statement 137, wherein evicting the existing metadata associated with a second key from the hash table includes selecting the second key as the least recently used key in the hash table.

[0560] Statement 139. An embodiment of the inventive concept includes the article according to statement 136, wherein storing the second metadata in a hash table in memory, the second metadata being associated with the key, includes:

[0561] Determine that the hash table does not store the second metadata associated with the key; and

[0562] In response to the highest append index of the key, access the second metadata from the KV-SSD.

[0563] Statement 140. An embodiment of the inventive concept includes the article according to Statement 139, wherein determining the highest append index of the key includes systematically requesting data associated with the key from the KV-SSD until the new highest append index of the key is determined.

[0564] Statement 141. An embodiment of the inventive concept includes the article according to Statement 140, wherein systematically requesting data associated with the key from the KV-SSD until the new highest append index of the key is determined includes:

[0565] Determine the possible highest append index of the key;

[0566] Combine the possible highest append index of the key with the key to generate a test key; and

[0567] Attempt to access the data associated with the test key.

[0568] Statement 142. An embodiment of the inventive concept includes the article according to Statement 141, wherein systematically requesting data associated with the key from the KV-SSD until the highest append index of the key is determined further includes:

[0569] Decrement the possible highest append index of the key to generate a possible new append index;

[0570] Combine the possible new append index of the key with the key to generate a new test key;

[0571] Attempt to access the data associated with the new test key; and

[0572] Repeat the operations of decrementing the possible highest append index of the key, combining the possible new append index of the key with the key, and attempting to access the data until the KV-SSD reports data associated with the new test key, at least partially based on the response of the KV-SSD to the attempt to access the data associated with the new test key.

[0573] Statement 143. An embodiment of the inventive concept includes the article according to Statement 140, wherein systematically requesting data associated with the key from the KV-SSD until the new highest append index of the key is determined includes:

[0574] Determine the range of the possible highest append index of the key;

[0575] Select a middle append index in the middle of the range of the possible highest append index of the key;

[0576] Combine the middle append index with the key to generate a test key;

[0577] Attempt to access the data associated with the test key;

[0578] At least partially based on the response of the KV-SSD to the attempt to access the data associated with the test key, narrow the range of the possible highest append index of the key to one of the first half range and the second half range; and

[0579] Repeat the operations of selecting a middle append index, combining the middle append index with the key, narrowing the range of the possible highest append index of the key, and attempting to access the data associated with the test key until the range includes a single possible highest append index.

[0580] Statement 144. An embodiment of the inventive concept includes the article according to statement 139, wherein determining the new highest append index of the key includes accessing the new highest append index of the key from the index object of the key on the KV-SSD.

[0581] Statement 145. An embodiment of the inventive concept includes the article according to statement 136, wherein further instructions are stored on the non-transitory storage medium, and when executed by a machine, the instructions cause the new highest append index to be stored in the index object of the key on the KV-SSD at least partially based on the key being selected for eviction from the hash table.

[0582] Statement 146. An embodiment of the inventive concept includes the article according to statement 134, wherein further instructions are stored on the non-transitory storage medium, and when executed by a machine, the instructions cause the new highest append index to be returned to the application.

[0583] Statement 147. An embodiment of the inventive concept includes the article according to statement 146, wherein returning the new highest append index to the application includes returning the new highest append index to the application before returning a value to the application in response to a read request.

[0584] Statement 148. An embodiment of the inventive concept includes the article according to statement 118, wherein further instructions are stored on the non-transitory storage medium, and when executed by a machine, the instructions cause:

[0585] Receive a deletion request from the application to delete the value associated with the key as a key-value pair on a key-value solid-state drive (KV-SSD).

[0586] Determine a base index of the key;

[0587] Combine the base index with the key to generate a first index key;

[0588] Perform a first deletion operation on the first index key on the KV-SSD;

[0589] Determine at least one appended index of the key;

[0590] Combine the at least one appended index with the key to generate at least one second index key; and

[0591] Perform at least one second deletion operation on the at least one second index key on the KV-SSD.

[0592] Statement 149. Embodiments of the inventive concept include the article of manufacture according to Statement 148, wherein further instructions are stored on the non-transitory storage medium, and when executed by a machine, cause the deletion results of the first deletion operation and the at least one second deletion operation to be returned to the application.

[0593] Statement 150. Embodiments of the inventive concept include the article of manufacture according to Statement 148, wherein further instructions are stored on the non-transitory storage medium, and when executed by a machine, cause:

[0594] Locate metadata in a hash table in memory, the metadata being associated with the key; and

[0595] Remove the metadata from the hash table in memory.

[0596] Statement 151. Embodiments of the inventive concept include the article of manufacture according to Statement 148, wherein further instructions are stored on the non-transitory storage medium, and when executed by a machine, cause:

[0597] Identify an index object of the key stored on the KV-SSD; and

[0598] Delete the index object of the key from the KV-SSD.

[0599] Statement 152. Embodiments of the inventive concept include an article of manufacture, the article of manufacture including a non-transitory storage medium having instructions stored thereon, and when executed by a machine, cause:

[0600] Receive an append request from an application to append a second value to a value associated with a key on a key-value solid state drive (KV-SSD) as a key-value pair, the application being executed by a processor;

[0601] Determine a highest append index for the key;

[0602] Increment the highest append index to produce a new highest append index;

[0603] Combine the new highest append index with the key to produce an append index key; and

[0604] Perform a second storage operation on the KV-SSD to associate the append index key with the second value.

[0605] Statement 153. Embodiments of the inventive concept include the article according to Statement 152, further instructions being stored on the non-transitory storage medium, the instructions when executed by a machine causing the append result of the second storage operation to be returned to the application.

[0606] Statement 154. Embodiments of the inventive concept include the article according to Statement 152, wherein:

[0607] The KV-SSD stores first metadata associated with the key, the first metadata including at least one of a highest append index, a first offset, a first length, and a first data structure of an append request for the key-value pair;

[0608] The method further includes:

[0609] Establish second metadata for the key; and

[0610] Combine the second value with the second metadata to produce a second modified value; and

[0611] Performing the second storage operation on the KV-SSD to associate the append index key with the second value includes performing the second storage operation on the KV-SSD to associate the append index key with the second modified value.

[0612] Statement 155. Embodiments of the inventive concept include the article according to Statement 154, wherein the second metadata includes a new highest append index of the key.

[0613] Statement 156. Embodiments of the inventive concept include the article according to Statement 155, wherein the second metadata further includes a second append offset and a second append length.

[0614] Statement 157. An embodiment of the inventive concept includes the article according to Statement 155, wherein the second metadata further includes a second data structure for an append request of key-value pairs.

[0615] Statement 158. An embodiment of the inventive concept includes the article according to Statement 155, wherein further instructions are stored on the non-transitory storage medium, and when executed by a machine, cause the second metadata to be stored in a hash table in memory, the second metadata being associated with a key.

[0616] Statement 159. An embodiment of the inventive concept includes the article according to Statement 158, wherein storing the second metadata in a hash table in memory includes evicting existing metadata associated with a second key from the hash table.

[0617] Statement 160. An embodiment of the inventive concept includes the article according to Statement 159, wherein evicting existing metadata associated with a second key from the hash table includes selecting the second key as the least recently used key in the hash table.

[0618] Statement 161. An embodiment of the inventive concept includes the article according to Statement 158, wherein storing the second metadata in a hash table in memory, the second metadata being associated with the key, includes:

[0619] determining that the hash table does not store the first metadata associated with the key;

[0620] determining the highest append index of the key; and

[0621] accessing the first metadata from the KV-SSD in response to the highest append index of the key.

[0622] Statement 162. An embodiment of the inventive concept includes the article according to Statement 161, wherein determining the highest append index of the key includes systematically requesting data associated with the key from the KV-SSD until the highest append index of the key is determined.

[0623] Statement 163. An embodiment of the inventive concept includes the article according to Statement 162, wherein systematically requesting data associated with the key from the KV-SSD until the highest append index of the key is determined includes:

[0624] determining a possible highest append index of the key;

[0625] combining the possible highest append index of the key with the key to generate a test key; and

[0626] Attempt to access the data associated with the test key.

[0627] Statement 164. An embodiment of the inventive concept includes the article according to statement 163, wherein systematically requesting data associated with a key from the KV-SSD until the highest append index of the key is determined further includes:

[0628] Decrementing the possible highest append index of the key to produce a possible new append index;

[0629] Combining the possible new append index of the key with the key to produce a new test key;

[0630] Attempting to access the data associated with the new test key; and

[0631] Repeating the operations of decrementing the possible highest append index of the key, combining the possible new append index of the key with the key, and attempting to access the data until the KV-SSD reports data associated with the new test key, at least in part based on the response of the KV-SSD to the attempt to access the data associated with the new test key.

[0632] Statement 165. An embodiment of the inventive concept includes the article according to statement 162, wherein systematically requesting data associated with a key from the KV-SSD until the highest append index of the key is determined includes:

[0633] Determining the range of the possible highest append index of the key;

[0634] Selecting a middle append index in the middle of the range of the possible highest append index of the key;

[0635] Combining the middle append index with the key to produce a test key;

[0636] Attempting to access the data associated with the test key;

[0637] Narrowing the range of the possible highest append index of the key to one of the first half range and the second half range, at least in part based on the response of the KV-SSD to the attempt to access the data associated with the test key; and

[0638] Repeating the operations of selecting a middle append index, combining the middle append index with the key, narrowing the range of the possible highest append index of the key, and attempting to access the data associated with the test key until the range includes a single possible highest append index.

[0639] Statement 166. An embodiment of the inventive concept includes the article according to Statement 161, wherein determining the highest append index of a key includes accessing the highest append index of the key from an index object of the key on the KV-SSD.

[0640] Statement 167. An embodiment of the inventive concept includes the article according to Statement 158, wherein further instructions are stored on the non-transitory storage medium, and when executed by a machine, the instructions cause a new highest append index to be stored in an index object of a key on the KV-SSD, at least partially based on the key being selected for eviction from a hash table.

[0641] Statement 168. An embodiment of the inventive concept includes an article that includes a non-transitory storage medium having instructions stored thereon that, when executed by a machine, cause:

[0642] receiving a read request from an application to read a value associated with a key as a key-value pair from a key-value solid state drive (KV-SSD), the application being executed by a processor;

[0643] determining a base index of the key;

[0644] determining a highest append index of the key;

[0645] combining each index from the base index of the key to the highest append index of the key with the key to generate at least two index keys;

[0646] performing a read operation on each of the at least two index keys on the KV-SSD to generate at least two read values;

[0647] combining the at least two read values to generate the value; and

[0648] returning the value to the application in response to the read request.

[0649] Statement 169. An embodiment of the inventive concept includes the article according to Statement 168, wherein:

[0650] the KV-SSD stores first metadata associated with a key and second metadata associated with the key, the first metadata including at least one of a first append index, a first offset, a first length, and a first data structure of an append request for a key-value pair, the second metadata including at least one of a highest append index, a second offset, a second length, and a second data structure of an append request for a key-value pair, and the second metadata is also stored in a hash table in memory; and

[0651] Determining the highest append index for a key includes determining the highest append index for the key from second metadata in a hash table.

[0652] Statement 170. An embodiment of the inventive concept includes the article according to statement 168, further instructions being stored on the non-transitory storage medium, which when executed by a machine, cause second metadata to be stored in a hash table in memory, the second metadata including at least one of a highest append index for an append request for a key-value pair, a second offset, a second length, and a second data structure.

[0653] Statement 171. An embodiment of the inventive concept includes the article according to statement 170, wherein storing the second metadata in a hash table in memory includes evicting existing metadata associated with a second key from the hash table.

[0654] Statement 172. An embodiment of the inventive concept includes the article according to statement 171, wherein evicting existing metadata associated with a second key from the hash table includes selecting the second key as the least recently used key in the hash table.

[0655] Statement 173. An embodiment of the inventive concept includes the article according to statement 170, wherein storing the second metadata in a hash table in memory, the second metadata being associated with the key, includes:

[0656] determining that the hash table does not store the second metadata associated with the key; and

[0657] in response to the highest append index for the key, accessing the second metadata from the KV-SSD.

[0658] Statement 174. An embodiment of the inventive concept includes the article according to statement 173, wherein determining the highest append index for the key includes systematically requesting data associated with the key from the KV-SSD until the highest append index for the key is determined.

[0659] Statement 175. An embodiment of the inventive concept includes the article according to statement 174, wherein systematically requesting data associated with the key from the KV-SSD until the highest append index for the key is determined includes:

[0660] determining a possible highest append index for the key;

[0661] combining the possible highest append index for the key with the key to produce a test key; and

[0662] attempting to access the data associated with the test key.

[0663] Statement 176. An embodiment of the inventive concept includes the article according to Statement 175, wherein systematically requesting data associated with a key from the KV-SSD until the highest append index of the key is determined further includes:

[0664] Decrementing a possible highest append index of the key to produce a possible new append index;

[0665] Combining the possible new append index of the key with the key to produce a new test key;

[0666] Attempting to access data associated with the new test key; and

[0667] Repeating the operations of decrementing the possible highest append index of the key, combining the possible new append index of the key with the key, and attempting to access the data until the KV-SSD reports data associated with the new test key, at least in part based on the response of the KV-SSD to attempting to access data associated with the new test key.

[0668] Statement 177. An embodiment of the inventive concept includes the article according to Statement 174, wherein systematically requesting data associated with a key from the KV-SSD until the highest append index of the key is determined includes:

[0669] Determining a range of possible highest append indexes of the key;

[0670] Selecting a middle append index in the middle of the range of possible highest append indexes of the key;

[0671] Combining the middle append index with the key to produce a test key;

[0672] Attempting to access the data associated with the test key;

[0673] Narrowing the range of possible highest append indexes of the key to one of a first half range and a second half range, at least in part based on the response of the KV-SSD to attempting to access the data associated with the test key; and

[0674] Repeating the operations of selecting a middle append index, combining the middle append index with the key, narrowing the range of possible highest append indexes of the key, and attempting to access the data associated with the test key until the range includes a single possible highest append index.

[0675] Statement 178. An embodiment of the inventive concept includes the article according to Statement 173, wherein determining the highest append index of a key includes accessing the highest append index of the key from an index object of the key on the KV-SSD.

[0676] Statement 179. An embodiment of the inventive concept includes the article according to Statement 170, wherein further instructions are stored on the non-transitory storage medium, and when executed by a machine, the instructions cause the highest append index to be stored in the index object of the key on the KV-SSD, at least partially based on the key being selected for eviction from the hash table.

[0677] Statement 180. An embodiment of the inventive concept includes the article according to Statement 168, wherein further instructions are stored on the non-transitory storage medium, and when executed by a machine, the instructions cause the highest append index to be returned to the application.

[0678] Statement 181. An embodiment of the inventive concept includes the article according to Statement 180, wherein returning the highest append index to the application includes returning the highest append index to the application before returning a value to the application in response to a read request.

[0679] Statement 182. An embodiment of the inventive concept includes an article that includes a non-transitory storage medium having instructions stored thereon that, when executed by a machine, cause:

[0680] Receiving a delete request from an application to delete a value associated with a key as a key-value pair on a key-value solid state drive (KV-SSD), the application being executed by a processor;

[0681] Determining a base index of the key;

[0682] Combining the base index with the key to produce a first index key;

[0683] Performing a delete operation on the first index key on the KV-SSD;

[0684] Determining at least one append index of the key;

[0685] Combining the at least one append index with the key to produce at least one second index key; and

[0686] Performing at least one delete operation on the at least one second index key on the KV-SSD.

[0687] Statement 183. An embodiment of the inventive concept includes the article according to Statement 182, wherein further instructions are stored on the non-transitory storage medium, and when executed by a machine, the instructions cause the delete results of the first delete operation and the at least one second delete operation to be returned to the application.

[0688] Statement 184. An embodiment of the inventive concept includes the article according to Statement 182, wherein further instructions are stored on the non-transitory storage medium, and the instructions, when executed by a machine, cause:

[0689] Locate metadata in a hash table in memory, the metadata being associated with a key; and

[0690] Remove the metadata from the hash table in memory.

[0691] Statement 185. An embodiment of the inventive concept includes the article according to Statement 182, wherein further instructions are stored on the non-transitory storage medium, and the instructions, when executed by a machine, cause:

[0692] Identify an index object of a key stored on the KV-SSD; and

[0693] Delete the index object of the key from the KV-SSD.

[0694] Accordingly, considering the various permutations of the embodiments described herein, this detailed description and the accompanying materials are intended to be illustrative only and should not be regarded as limiting the scope of the inventive concept. Thus, the inventive concept claims that all such modifications may fall within the scope and spirit of the appended claims and their equivalents.

Claims

1. A method for software execution implemented by using a circuit, comprising: Receiving, from an application, a request related to a key-value pair of a key-value solid-state drive, the key-value pair including a key and a value, the application being executed by a processor; Combining the key with an index to generate an index key including bytes of the index and bytes of the key; And Performing an operation on the key-value solid-state drive by using the index key and the value.

2. The method according to claim 1 further comprises: Generating metadata of the key.

3. The method according to claim 2 further comprises: Using a hash table in memory to store the metadata associated with the key.

4. The method according to claim 1, wherein: The request includes a read request; and Performing an operation on the key-value solid-state drive by using the index key and the value includes: reading multiple values associated with multiple index keys on the key-value solid-state drive and combining the multiple values to generate the value.

5. The method according to claim 1, wherein: The request includes a delete request; and Performing an operation on the key-value solid-state drive by using the index key and the value includes: deleting multiple index keys on the key-value solid-state drive.

6. A method for key-value storage, comprising: Receiving, from an application, a write request to store a value associated with a key on a key-value solid-state drive as a key-value pair, the application being executed by a processor; Determining a basic index of the key; Combining the basic index with the key to generate an index key including bytes of the index and bytes of the key; And Performing a storage operation on the key-value solid-state drive to associate the index key with the value.

7. The method according to claim 6, further comprising returning a write result of the storage operation to the application.

8. The method according to claim 6, wherein: The method further comprises: Establishing first metadata of the key; and Combining the value with the first metadata to generate a first modified value; and Performing a storage operation on the key-value solid-state drive to associate the index key with the value includes performing the storage operation on the key-value solid-state drive to associate the index key with the first modified value.

9. The method according to claim 8, wherein the first metadata includes the basic index of the key.

10. The method according to claim 9, further comprising storing the first metadata in a hash table in memory, the first metadata being associated with the key.

11. The method according to claim 6, wherein: The method further comprises, at least partially based on the value exceeding a maximum size of an object on the key-value solid-state drive, determining a number of objects required to store the value; Combining the basic index with the key to generate an index key includes combining multiple indexes with the key to generate multiple index keys, wherein the multiple index keys are at least as large as the number of the objects required to store the value; Performing a storage operation on the key-value solid-state drive to associate the index key with the value includes performing a plurality of storage operations on the key-value solid-state drive to associate each of the plurality of index keys with a portion of the value.

12. The method according to claim 6, further comprising: Receiving an append request from the application to append a second value to the value associated with the key on the key-value solid-state drive; Determining a highest append index of the key; Incrementing the highest append index to generate a new highest append index; Combining the new highest append index with the key to generate an append index key; And Performing a second storage operation on the key-value solid-state drive to associate the append index key with the second value.

13. A method for key-value storage, comprising: Receiving an append request from an application to append a second value as a key-value pair to a value associated with a key on a key-value solid-state drive, the application being executed by a processor; Determining a highest append index of the key; Incrementing the highest append index to generate a new highest append index; Combining the new highest append index with the key to generate an append index key; And Performing a second storage operation on the key-value solid-state drive to associate the append index key with the second value.

14. The method according to claim 13, further comprising returning an append result of the second storage operation to the application.

15. The method according to claim 13, wherein: The key-value solid-state drive stores first metadata associated with the key, the first metadata including at least one of the highest append index, a first offset, a first length, and a first data structure of an append request for the key-value pair; The method further comprises: Establishing second metadata of the key; and Combining the second value with the second metadata to generate a second modified value; and Performing a second storage operation on the key-value solid-state drive to associate the append index key with the second value includes performing the second storage operation on the key-value solid-state drive to associate the append index key with the second modified value.

16. The method according to claim 15, wherein the second metadata includes the new highest append index of the key.

17. The method according to claim 16, further comprising storing the second metadata in a hash table in memory, the second metadata being associated with the key.

18. The method according to claim 17, wherein storing the second metadata in a hash table in memory, the second metadata being associated with the key, includes: Determining that the hash table does not store the first metadata associated with the key; Determining the highest append index of the key; And Accessing the first metadata from the key-value solid-state drive in response to the highest append index of the key.

19. The method according to claim 18, wherein determining the highest append index of the key includes systematically requesting data associated with the key from the key-value solid state drive until the highest append index of the key is determined.

20. The method according to claim 19, wherein systematically requesting data associated with the key from the key-value solid state drive until the highest append index of the key is determined includes: Determining a range of possible highest append indices of the key; Selecting a middle append index in the middle of the range of possible highest append indices of the key; Combining the middle append index with the key to produce a test key; Attempting to access the data associated with the test key; Narrowing the range of possible highest append indices of the key to one of a first half range and a second half range at least partially based on the response of the key-value solid state drive to the attempt to access the data associated with the test key; and Repeating the operations of selecting a middle append index, combining the middle append index with the key, narrowing the range of possible highest append indices of the key, and attempting to access the data associated with the test key until the range includes a single possible highest append index.

Images