KR20230025322A - Host, operating method of host and storage system - Google Patents

Abstract

According to one aspect of the technical idea of the present disclosure, a host comprises: an index tree which stores an index including information which identifies a versioning key contained in data stored on a storage device; and an index update buffer which stores an entry key included in entry requested data and the versioning key corresponding to the entry key. The host, when preset update conditions are met, updates the versioning key stored in the index update buffer to the index tree. In addition, the host, when recovery of the index update buffer is necessary, sets up a recovery section in the index tree which includes data corresponding to an unupdated versioning key, divides the recovery section and distributes the same to a plurality of threads, reads data included in the recovery section from the storage device through the plurality of threads, and recovers the index update buffer by inserting at least part of read data into the index update buffer. Accordingly, the index update buffer can be recovered more quickly.

Description

Host, operating method of host and storage system {HOST, OPERATING METHOD OF HOST AND STORAGE SYSTEM}

The technical concept of the present disclosure relates to a host, and more particularly, to a host communicating with a storage device that processes data using a key-value pair.

Storage devices may be classified into block storage, file storage, and object storage. Block storage can manage data based on physical location, and file storage can manage data based on logical sequence. Meanwhile, the object storage may manage data based on a unique identifier. While block storage and file storage are useful when there is a large amount of text data, object storage can be an efficient alternative when there is a large amount of unstructured data such as sound data and video data. As an example of object storage, there is a key-value storage that stores data based on key-value.

The key-value storage may perform a write or read operation based on a command received from the host. The host may transmit a read command including a key to the key-value storage, and the key-value storage may transmit a value to the host in response to the read command. The host can obtain a key for a value to be read through an index tree that stores the key through an index. In this case, the host may update the index tree at once after a large number of data is written, rather than updating the index tree every time new data is written to the key-value storage. In such a situation, when a situation such as a sudden power failure of the host occurs, data that is not updated in the index tree needs to be restored.

An object to be solved by the technical idea of the present disclosure is to provide a host capable of more quickly restoring data that has not been updated in an index tree.

In order to achieve the above object, a host communicating with a storage device that processes data using a key-value pair according to an aspect of the technical idea of the present disclosure is included in the data stored in the storage device. An index tree that stores an index including information identifying an updated versioning key, and an index update buffer that stores a write key included in write-requested data and the versioning key corresponding to the write key, , The host updates the versioning key stored in the index update buffer to the index tree when a preset update condition is satisfied, and the host updates the index tree when recovery of the index update buffer is required. A recovery period including data corresponding to the versioning key that has not been updated is set, the recovery period is divided and distributed to a plurality of threads, and the data included in the recovery period is transferred from the storage device through the plurality of threads. and restoring the index update buffer by inserting at least some of the read data into the index update buffer.

In order to achieve the above object, communication is performed with a storage device that processes data using a key-value pair according to an aspect of the technical idea of the present disclosure, and a versioning key included in data stored in the storage device is identified. An operating method of a host including an index tree storing an index including information to be written, and an index update buffer storing a write key included in write-requested data and the versioning key corresponding to the write key. Setting a recovery section including data corresponding to the versioning key that has not been updated in the index tree; dividing the recovery section into a plurality of threads by the host; dividing the recovery section into a plurality of threads by the host; and restoring the index update buffer by inserting at least a part of the read data into the index update buffer by the host.

In order to achieve the above object, a storage system according to an aspect of the technical idea of the present disclosure includes a storage device for processing data using a key-value pair, and a host including a memory and a processor, the memory comprising: Storing an index tree that stores an index including information identifying a versioning key included in data stored in the storage device, and a write key included in write-requested data and the versioning key corresponding to the write key An index update buffer is stored, and the processor updates the versioning key stored in the index update buffer to the index tree when a preset update condition is satisfied, and the processor updates the index update buffer when recovery is required. , setting a recovery period including data corresponding to the versioning key that has not been updated in the index tree, dividing the recovery period and distributing it to a plurality of threads, and performing the recovery period from the storage device through the plurality of threads. The index update buffer may be restored by reading data included in a recovery period and inserting at least a part of the read data into the index update buffer.

According to a host of technical ideas of the present disclosure, the index update buffer can be recovered more quickly by restoring the index update buffer using a plurality of threads.

1 is a block diagram illustrating a storage system according to an exemplary embodiment of the present disclosure.
2 is a block diagram illustrating a storage device according to an exemplary embodiment of the present disclosure.
3 is a flowchart illustrating an operation when a host receives a write request according to an embodiment of the present disclosure.
4 is a flowchart illustrating an operation when a host receives a read request according to an embodiment of the present disclosure.
5 is a diagram illustrating an index tree of a host according to an embodiment of the present disclosure.
6 is a diagram illustrating a method of updating an index tree of a host according to an embodiment of the present disclosure.
7 is a diagram illustrating an index update buffer of a host according to an embodiment of the present disclosure.
8 is a diagram illustrating an example of a memory block stored in a storage device according to an embodiment of the present disclosure.
9 is a diagram illustrating another example of a memory block stored in a storage device according to an embodiment of the present disclosure.
10 is a diagram illustrating another example of a memory block stored in a storage device according to another embodiment of the present disclosure.
11 is a flowchart illustrating a method of operating a host according to an embodiment of the present disclosure.
12 is a diagram illustrating a storage system according to another exemplary embodiment of the present disclosure.
13 is a block diagram illustrating an electronic device according to an embodiment of the present disclosure.

Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

1 is a block diagram illustrating a storage system according to an exemplary embodiment of the present disclosure.

Referring to FIG. 1 , a storage system 10 may include a storage device 100 and a host 200 .

In one embodiment of the present disclosure, the storage system 10 may be implemented as a personal computer (PC), a data server, a network-attached storage, an Internet of Things (IoT) device, or a portable electronic device. Portable electronic devices include laptop computers, mobile phones, smart phones, tablet PCs, personal digital assistants (PDAs), enterprise digital assistants (EDAs), digital still cameras, digital video cameras, audio devices, portable multimedia players (PMPs), and PNDs. It may be any one of a personal navigation device, an MP3 player, a handheld game console, an e-book, and a wearable device.

The storage device 100 may be an internal memory embedded in an electronic device. For example, the storage device 100 may be an SSD, an embedded universal flash storage (UFS) memory device, or an embedded multi-media card (eMMC). In some embodiments, the storage device 100 may be an external memory removable from an electronic device. For example, the storage device 100 may include a UFS memory card, Compact Flash (CF), Secure Digital (SD), Micro Secure Digital (Micro-SD), Mini Secure Digital (Mini-SD), extreme Digital (xD), or It may be a memory stick.

In one embodiment of the present disclosure, the storage device 100 may be a key-value storage device or a key-value store, for example, a key-value solid state drive (SSD). can A key-value storage device is a device that quickly and simply processes data using a key-value pair. Here, a "key-value pair" is a pair of a key having uniqueness and a value that is data corresponding to the key, and may be referred to as a "tuple" or a "key-value tuple". In addition, a key-value pair may mean a data storage paradigm designed for storage and search management of an associative array, which is a data structure called a dictionary or hash, and in a key-value pair, a key is a file Represented as an arbitrary string such as a file name, URI (Uniform Resource Identifier), field, or hash, and the value can be any kind of data such as an image, user favorite file, or document. . At this time, the size of the key and the value is variable, and for example, the size of the value can be changed according to the data included in the value.

Hereinafter, an embodiment in which the storage device 100 is a key-value storage device will be mainly described, and in this specification, the storage device 100 has substantially the same meaning as a key-value storage device or a key-value store. can be used as However, the storage device 100 is not limited to a key-value storage device, and may be applied to any object cache system or object storage system that manages data in object units. Accordingly, the storage device 100 may manage data in object units in an arbitrary method other than a key-value pair.

The storage device 100 may include a controller 110 , a data buffer 130 , and a non-volatile memory (NVM) 140 .

The controller 110 writes a value into the nonvolatile memory 140 in response to a write command from the host 200, or writes a value stored in the nonvolatile memory 140 in response to a read command from the host 200. The non-volatile memory 140 may be controlled to read.

The controller 110 may include a key-value manager 120 . The key-value manager 120 may receive a key-value pair included in the key-value command (CMD) and separate a key and value included in the key-value pair. The key-value manager 120 may extract a plurality of keys (KEYs) included in the key-value pair and store them in the data buffer 130 . The key-value manager 120 may extract a plurality of values included in the key-value pair and store them in the data buffer 130 .

When a plurality of keys (KEY) of a certain number or amount of data are stored in the data buffer 130, the key-value manager 120 stores the stored plurality of keys (KEY) in the non-volatile memory 140 as a key stream. can When a plurality of values (VALUEs) of a certain number or a certain amount of data are stored in the data buffer 130, the key-value manager 120 converts the stored values into the non-volatile memory 140 as a value stream. can be stored in In one embodiment, each of the value stream and key stream may be stored in different areas of non-volatile memory 140 .

The data buffer 130 may include at least one memory device for storing a key and a value, and in one example, the data buffer 130 includes a dynamic random access memory; DRAM) and static random access memory (SRAM).

The non-volatile memory 140 may include a memory cell array (MCA), and the memory cell array MCA may include memory blocks BLK1 to BLKz, and the memory block BLK1 may include a plurality of pages PG1 to PGk. Here, z and k may each be a positive integer and may be variously changed according to embodiments. For example, a memory block may be a unit of erase, and a page may be a unit of write and read. In some embodiments, the memory cell array MCA may include a plurality of planes, a plurality of dies, or a plurality of chips. In one embodiment, the non-volatile memory 140 may include a flash memory device, for example, a NAND flash memory device. However, the present invention is not limited thereto, and the non-volatile memory 140 may include a resistive memory device such as a resistive RAM (ReRAM), a phase change RAM (PRAM), or a magnetic RAM (MRAM).

In one embodiment, the key stream generated using the key (KEY) and the value stream generated using the value (VALUE) are stored in different memory blocks BLK1 to BLKz, respectively, or are stored in the same memory block (eg For example, it may be stored in different pages PG1 to PGk of BLK1).

The host 200 may communicate with the storage device 100 through various interfaces. In one embodiment, the host 200 may be implemented as an Application Processor (AP) or System-On-a-Chip (SoC).

The host 200 issues a key-value command (CMD), eg, a write command or a put command, to the storage device 100 for writing data including a key-value pair. transmission, and the storage device 100 may write a value into the non-volatile memory 140 in response to the key-value command CMD.

In addition, the host 200 may transmit a key-value command (CMD) including a key, for example, a read command or a get command to the storage device 100, and the storage device 100 may transmit the key-value command (CMD). A value corresponding to the key KEY may be read from the non-volatile memory 140 in response to the value command CMD.

In this case, the host 200 may transmit a key-value command (CMD) to the storage device 100 based on a write request or a read request received from the outside such as a user or another electronic device through an interface. An operation performed when the host 200 receives a write request or a read request will be described later with reference to FIGS. 3 and 4 .

The host 200 may include an index tree 210 and an index update buffer 220 .

The index tree 210 is a tree enabling a search for a key necessary to read data stored in the storage device 100 through an index. The index tree 210 may include information identifying a key required to read data stored in the storage device 100 . Accordingly, the host 200 may search for a key corresponding to the read request received from the outside through the index tree 210 and transmit a key-value command (CMD) generated based on the key to the storage device 100 .

The index tree 210 may be stored in the storage device 100, and the host 200 may load and use the index tree 210 in an internal volatile memory (eg, DRAM). A more detailed description of the index tree 210 will be described later with reference to FIGS. 5 and 6 .

The index update buffer 220 may temporarily store data included in a write request received from the outside. That is, when receiving a write request from the outside, the host 200 may store it in the index update buffer 220 and update the index tree 210 when a preset update condition is satisfied.

The index update buffer 220 is not stored in the storage device 100, and the host 200 may temporarily store and use the index update buffer 220 in an internal volatile memory (eg, DRAM). A more detailed description of the index update buffer 220 will be described later with reference to FIG. 7 .

When recovery of the index update buffer 220 is required, the host 200 sets a recovery period including data corresponding to a versioning key that has not been updated in the index tree 210, and divides the recovery period into a plurality of The index update buffer 220 is generated by distributing to threads, reading data included in the recovery section from the storage device 100 through a plurality of threads, and inserting at least some of the read data into the index update buffer 220. can be recovered A more detailed description of the recovery operation of the index update buffer 220 of the host 200 will be described later with reference to FIG. 11 .

2 is a block diagram illustrating a storage device according to an exemplary embodiment of the present disclosure.

Referring to FIG. 2 , the storage device 100 may include a key-value manager 120, a data buffer 130, and a non-volatile memory 140, and the key-value manager 120 is a key-value extractor. (121) may be included.

The key-value extractor 121 may extract a key (KEY) and a value (VALUE) included in the key-value command (CMD). The key-value extractor 121 may store the extracted key in the key buffer 131 of the data buffer 130 and store the extracted value in the value buffer 132 of the data buffer 130. . In one embodiment, the key buffer 131 and the value buffer 132 may be configured as separate memory devices. In another embodiment, the key buffer 131 and the value buffer 132 may be composed of different regions of the data buffer 130 .

In one embodiment, the key-value extractor 121 may manage the physical address of the key (KEY) stored in the key buffer 131 using a mapping table, and in one example, the mapping table is a key (KEY) It can be created as a hash table that stores a hash key corresponding to a key as a mapping index for KEY.

When a plurality of keys (KEY) stored in the key buffer 131 exceeds a certain amount of data, the key-value extractor 121 may generate a key stream (ST_KEY) based on the plurality of keys (KEY). In one embodiment, the key-value extractor 121 may generate a key stream (ST_KEY) by sequentially arranging a plurality of keys (KEY). In another embodiment, the key-value extractor 121 may generate a key stream (ST_KEY) by merging a plurality of keys (KEY) and an index of a value (VALUE) corresponding to each of the plurality of keys (KEY). there is. The key-value extractor 121 may store the generated key stream ST_KEY in the first area AR1 of the non-volatile memory 140 .

In one embodiment, the key-value extractor 121 may manage the physical address in the first area AR1 of the stored key KEY using a key table, and in one example, the key table is a key (KEY ), it can be created as a hash table that stores a hash key corresponding to a key (KEY) as a mapping index for .

When the plurality of values (VALUE) stored in the value buffer 132 exceeds a certain amount of data, the key-value extractor 121 may generate a value stream (ST_VAL) based on the plurality of values (VALUE). In one example, the key-value extractor 121 may generate a value stream ST_VAL by continuously arranging a plurality of values VALUE. The key-value extractor 121 may store the generated value stream ST_VAL in the second area AR2 of the non-volatile memory 140 . In one embodiment, the key-value extractor 121 may manage the physical address in the second area AR2 of the stored value using a value table.

3 is a flowchart illustrating an operation when a host receives a write request according to an embodiment of the present disclosure.

Referring to FIG. 3 , in step S310, the host 200 may receive a write request. The write request is a request to store data in the storage device 100 and may include a write key and value. In this case, the value may be data to be written, and the write key may be a key corresponding to the value.

In step S320, the host 200 may generate a versioning key corresponding to the write key. The versioning key corresponds to a value included in the write request and may indicate a location where the value is stored in the storage device 100 .

In one embodiment of the present disclosure, the host 200 may generate a versioning key based on the order of commits of the storage device 100 and the order of data in the commit. Commit may be a message confirming that data is stored from the storage device 100 to the host 200 . The storage device 100 may transmit a commit to the host 200 whenever a preset cycle arrives, and the host 200 may confirm that data is stored in the storage device 100 by receiving the commit. In this case, the commit sequence number may be the sequence number of commits transmitted from the storage device 100 to the host 200, and the sequence number of data in a commit is the sequence number stored in the storage device 100 among data confirmed to be stored by commits of the same sequence number. can be In one embodiment of the present disclosure, the host 200 confirms that data to be written according to a write request is stored in the storage device 100 by a third commit, and two of the data whose storage is confirmed by the third commit If it is the first written data, a versioning key may be generated as in CMT#3 DATA 2.

At this time, since the write key may be a value generated based on a specific attribute value unrelated to the storage location in the storage device 100, the host 200 generates a versioning key, thereby restoring the index update buffer 220 described later. can enable rapid execution of

In step S330, the host 200 may transmit a key-value command (CMD) including a versioning key and a value corresponding to the versioning key to the storage device 100. Accordingly, data may be written in the storage device 100 according to the write request.

In step S340, the host 200 may store a versioning key and a value corresponding to the versioning key in the index update buffer 220.

In step S350, the host 200 may determine whether an update condition is satisfied. The update condition may be a criterion for determining whether to update the index tree 210 based on data stored in the index update buffer 220 .

In an embodiment of the present disclosure, the update condition may include at least one of the number of commits of the storage device 100, whether a preset reference time has elapsed, and whether or not the power of the host 200 is turned off. In this case, the number of commits may be the number of times the host 200 receives a commit after the index update buffer 220 is updated. For example, the host 200 may determine that the update condition is satisfied when the number of commits received after the index tree 210 is updated reaches three. As another example, the host 200 may determine that the update condition is satisfied when a reference time (eg, 1 hour) elapses after the index tree 210 is updated. As another example, the host 200 may determine that an update condition is satisfied when receiving a power shutdown command.

When determining that the update conditions are not satisfied, the host 200 may perform step S350 again. In one embodiment of the present disclosure, when the update condition is the number of commits of the storage device 100 or whether a preset reference time has elapsed, the host 200 determines that the update condition is not satisfied, as shown in FIG. Similarly, step S350 may be performed again. However, in another embodiment of the present disclosure, when the update condition is whether or not the power of the host 200 is turned off, the host 200 does not perform an additional operation, as shown in FIG. , the step can be terminated.

Conversely, if it is determined that the update condition is satisfied, the host 200 may update the index tree 210 based on the index update buffer 220 in step S360. That is, the host 200 may update the versioning key stored in the index update buffer 220 to the index tree 210 .

At this time, the host 200 may collectively update all versioning keys stored in the index update buffer 220 to the index tree 210 . Accordingly, operations required for updating the index tree 210 may be reduced.

4 is a flowchart illustrating an operation when a host receives a read request according to an embodiment of the present disclosure.

Referring to FIG. 4 , the host 200 may receive a read request in step S410. The read request may be a request to read data from the storage device 100 .

In step S420, the host 200 may determine whether a versioning key corresponding to the read-requested data exists in the index update buffer 220.

When the host 200 determines that the versioning key corresponding to the read-requested data exists in the index update buffer 220, the host 200 may acquire the versioning key from the index update buffer 220 in step S430.

Conversely, if the host 200 determines that the versioning key corresponding to the read-requested data does not exist in the index update buffer 220, in step S440, the versioning key corresponding to the read-requested data is added to the index tree ( 210) can be determined.

When the host 200 determines that the versioning key corresponding to the read-requested data exists in the index tree 210, the host 200 may obtain the versioning key from the index tree 210 in step S450.

Conversely, if the host 200 determines that the versioning key corresponding to the read-requested data does not even exist in the index tree 210, the read-requested data does not exist in the storage device 100, so the step is performed as it is. can be terminated

After acquiring the versioning key in step S430 or step S450, the host 200 may transmit a key-value command (CMD) including the versioning key to the storage device 100 in step S460. Accordingly, the read-requested data may be read from the storage device 100 .

5 is a diagram illustrating an index tree of a host according to an embodiment of the present disclosure.

Referring to FIG. 5 , one embodiment of the index tree 210a can be seen. The index tree 210a may store an index including information identifying a versioning key included in data stored in the storage device 100 .

The index tree 210a may include a plurality of index nodes A, B, and C and a plurality of leaf nodes D1', D2, D3', and D4.

The index node may store an index including information identifying a versioning key corresponding to data to be read. Also, the index node may route a request for a versioning key corresponding to the read request to another index node or leaf node based on the index. For example, index node A may route a request for a versioning key corresponding to the read request to index node B or index node C based on data to be read. Further, the index node B may route a request for a versioning key corresponding to the read request to the leaf node D1' or the leaf node D2 based on the data to be read. Further, the index node C may route a request for a versioning key corresponding to the read request to the leaf node D3' or the leaf node D4 based on the data to be read.

The leaf node may store a versioning key corresponding to data to be read. Accordingly, the host 200 may obtain a versioning key corresponding to data to be read using the index tree 210a.

6 is a diagram illustrating a method of updating an index tree of a host according to an embodiment of the present disclosure.

Referring to FIG. 6 , an embodiment in which the index tree 210b is updated can be confirmed. The embodiment shown in FIG. 6 is an embodiment illustrating changes in the index tree 210b when the leaf node D2 is updated to the leaf node D2' and the leaf node D4 is updated to the leaf node D4'.

In an embodiment of the present disclosure, the index tree 210b may be updated using an append-only method. In the append-only method, when the tree is updated, a new node is created to replace the existing node instead of overwriting the existing leaf node and the upper index node of the leaf node.

At this time, when leaf node D2 is updated to leaf node D2', the host 200 must newly create nodes corresponding to index node B and index node A, which are upper index nodes of leaf node D2. Also, when leaf node D4 is updated to leaf node D4′, the host 200 must newly create nodes corresponding to index node C and index node A, which are upper index nodes of leaf node D4.

Accordingly, the host 200 may create new index nodes such as index node A', index node B', and index node C'. And index node A' is routable connected to index node B' or index node C', index node B' is routable connected to leaf node D1' or leaf node D2', and index node C' is a leaf node. It can be routable connected to D3' or leaf node D4'.

7 is a diagram illustrating an index update buffer of a host according to an embodiment of the present disclosure.

Referring to FIG. 7 , an embodiment of the index update buffer 220a can be seen. The index update buffer 220a may store a write key included in write-requested data and a versioning key corresponding to the write key.

First, row 1 of the index update buffer 220a may store D5 as data including a write key and CMT#4 DATA 1 as a versioning key. Also, row 2 of the index update buffer 220a may store D6 as data including a write key and CMT#4 DATA 2 as a versioning key. In this case, if the data stored in row 2 of the index update buffer 220a has the same commit order as the data stored in row 1 of the index update buffer 220a, only the order of the data in the commit may have a versioning key that is increased by 1.

Also, row 3 of the index update buffer 220a may store D2' as data including a write key and CMT#4 DATA 3 as a versioning key. At this time, if the commit order is the same between the data stored in row 3 of the index update buffer 220a and the data stored in rows 1 and 2 of the index update buffer 220a, a versioning key in which only the data order in the commit is increased by 1 or 2 can have

Also, row 4 of the index update buffer 220a may store D6' as data including a write key and CMT#5 DATA 1 as a versioning key. At this time, if the data stored in row 4 of the index update buffer 220a and the data stored in rows 1 to 3 of the index update buffer 220a and the commit order are different, the commit order is increased by 1, and the data order in the commit is initialized to 1. You can have an inversioning key.

8 is a diagram illustrating an example of a memory block stored in a storage device according to an embodiment of the present disclosure.

Referring to FIG. 8 , an example of a memory block stored in the storage device 100 may be seen.

The memory block may sequentially store data in the order in which it is written. In the embodiment of FIG. 8 , the order of writing data may be the same as the direction indicated by the arrow in FIG. 8 .

A memory block may include a super block (SB), one or more data blocks (D1, D2, ??), one or more index blocks (A, B, C), and one or more header blocks (H).

The super block SB may store the latest commit sequence number and the location of the header block H indicating the last commit sequence updated in the index tree 210 . In this case, the latest commit sequence number represents the commit sequence including the most recently committed data block, and the last commit sequence updated in the index tree 210 is the commit sequence including the most recently updated data block in the index tree 210. sequence can be indicated. Accordingly, the host 200 may set a recovery period of the index update buffer as will be described later by accessing the header block.

One or more data blocks (D1, D2, ??) may store a versioning key and value. One or more index blocks A, B, and C may store indexes of the index tree 210 . One or more header blocks (H) may store values indicating that a commit has been performed.

In the case of the embodiment of FIG. 8 , after data is stored in the data block D1 and the data block D2, it can be confirmed that a commit is performed and the header block H is created. Then data is stored in data block D3, data block D4, data block D1' and data block D3', then indexes of the index tree 210 are stored in index block A, index block B and index block C, It can be seen that the commit was performed and the header block H was created. Then, after the data is stored in the data block D5 and the data block D6, it can be confirmed that the header block H is created by performing a commit. Finally, after data is stored in data block D2' and data block D6', it can be seen that a commit is performed and header block H is created.

9 is a diagram illustrating another example of a memory block stored in a storage device according to an embodiment of the present disclosure.

Referring to FIG. 9 , an embodiment showing only data blocks excluding super blocks, index blocks, and header blocks from memory blocks stored in the storage device 100 can be seen. At this time, the stored versioning key is displayed on each data block.

In the case of the embodiment of FIG. 9 , after data having CMT#1 DATA 1, CMT#1 DATA 2, and CMT#1 DATA 3 are stored as versioning keys, it can be seen that the first commit (COMMIT 1) is performed. At this time, it can be confirmed that the first commit (COMMIT 1) is performed and the update of the index tree 210 is also performed.

Then, after data having CMT#2 DATA 1 and CMT#2 DATA 2 are stored as the versioning key, it can be confirmed that the second commit (COMMIT 2) has been performed. In addition, after data having CMT#3 DATA 1 and CMT#3 DATA 2 are stored as the versioning key, it can be confirmed that the third commit (COMMIT 3) has been performed. In addition, after data having CMT#4 DATA 1 and CMT#4 DATA 2 are stored as the versioning key, it can be confirmed that the fourth commit (COMMIT 4) has been performed. In addition, after data having CMT#5 DATA 1, CMT#5 DATA 2, and CMT#5 DATA 3 as the versioning key is stored, it can be confirmed that the fifth commit (COMMIT 5) has been performed. At this time, when the second commit (COMMIT 2) to the fifth commit (COMMIT 5) are performed, it can be confirmed that the index tree 210 is not updated.

10 is a diagram illustrating another example of a memory block stored in a storage device according to another embodiment of the present disclosure.

Referring to FIG. 10 , an embodiment showing only data blocks excluding super blocks, index blocks, and header blocks from memory blocks stored in the storage device 100 can be seen. At this time, the stored versioning key is displayed on each data block.

The embodiment of FIG. 10 is the same as the embodiment of FIG. 9 until the third commit (COMMIT 3) is performed. However, in the embodiment of FIG. 10, after the third commit (COMMIT 3) is performed, data having CMT#4 DATA 1, CMT#4 DATA 2, and CMT#4 DATA 3 as versioning keys is stored, and the fourth commit (COMMIT 4) can confirm that it has not been performed yet. At this time, when the second commit (COMMIT 2) and the third commit (COMMIT 3) are performed, it can be confirmed that the index tree 210 is not updated.

11 is a flowchart illustrating a method of operating a host according to an embodiment of the present disclosure. A method of operating a host according to an embodiment of the present disclosure will be described with reference to the embodiment of FIG. 9 .

Referring to FIG. 11 , a flowchart illustrating a method for the host 200 to perform a recovery operation of the index update buffer 220 can be seen.

At this time, when recovery of the index update buffer 220 is required, the host 200 may start the step of FIG. 11 . For example, when the power of the host 200 is suddenly terminated or an error occurs in the internal memory of the host 200, and atomicity or persistence of the index update buffer 220 is not guaranteed, the host 200 It may be determined that recovery of the index update buffer 220 is necessary.

In step S1110, the host 200 may set a recovery period.

In more detail, the host 200 may obtain the latest commit sequence number from the header block H of the storage device 100 and the last commit sequence number updated in the index tree 210 . In the embodiment of FIG. 9 , the host 200 may obtain the fifth commit (COMMIT 5) as the latest commit sequence and obtain the first commit (COMMIT 1) as the last commit sequence updated in the index tree 210. there is.

Also, the host 200 may set an interval between the last commit sequence updated in the index tree 210 and the latest commit sequence as a recovery interval. In the embodiment of FIG. 9 , the host 200 may set a recovery period from a data block after the first commit (COMMIT 1) to a data block before the fifth commit (COMMIT 5).

In step S1120, the host 200 may divide the recovery period and distribute it to a plurality of threads.

In more detail, the host 200 may divide the recovery period into a plurality of commit periods based on the order of commits. For example, the host 200 may divide the recovery period into a plurality of commit periods so that data blocks having the same commit sequence are included in the same commit period. In the embodiment of FIG. 9 , the host 200 uses a data block having CMT#2 DATA 1 and CMT#2 DATA 2 as a versioning key as a first commit period and CMT#3 DATA 1 and CMT#3 DATA as a versioning key. 2 as the second commit interval, and the data blocks having CMT#4 DATA 1 and CMT#4 DATA 2 as the versioning key as the third commit interval, CMT#5 DATA 1 and CMT#5 DATA as the versioning key 2 and CMT#5 DATA 3 may be divided into a fourth commit section.

Also, the host 200 may distribute each of the plurality of commit sections to a plurality of threads. In the embodiment of FIG. 9 , when the plurality of threads include the first through fourth threads, the host 200 uses the first commit section as the first thread, the second commit section as the second thread, and the third commit section as the second thread. The commit section may be distributed to the third thread and the fourth commit section may be distributed to the fourth thread.

In step S1130, the host 200 may read data included in the recovery period.

In one embodiment of the present disclosure, the host 200 may read data from the storage device 100 based on a commit sequence corresponding to a commit section distributed through each of a plurality of threads. That is, each of the plurality of threads may read data from the storage device 100 based on the commit order of data blocks included in the distributed commit period. In the embodiment of FIG. 9 , since the commit order of data blocks included in the first commit section, which is a distributed commit section, is 2, the first thread can read all data having a commit order of 2 from the storage device 100. . Also, since the commit order of data blocks included in the fourth commit section, which is a distributed commit section, is 5, the fourth thread may read all data having a commit order of 5 from the storage device 100 .

At this time, each of the plurality of threads may determine the number of data blocks included in the commit section, and read all data having the same commit sequence based on this. In the embodiment of FIG. 9 , since there are a total of three data blocks included in the fourth commit interval, all three data blocks having a commit sequence number of 4 can be read.

In another embodiment of the present disclosure, the host 200 may read data having a commit sequence having the same prefix from the storage device 100 through each of a plurality of threads. In this case, the host 200 may read data from the storage device 100 using an iterator that reads all data having the same prefix and commit sequence.

When reading data included in the recovery period through a plurality of threads, the host 200 may read data included in the recovery period from the storage device 100 in parallel through each of the plurality of threads. That is, a plurality of threads can read data included in a distributed commit section at the same point in time. In the embodiment of FIG. 9 , when the first thread reads data included in the first commit section, the second thread reads data included in the second commit section, and the third thread reads data included in the third commit section. read data, and the fourth thread may read data included in the fourth commit interval.

By reading data in parallel through a plurality of threads, the recovery speed of the index update buffer can be increased.

In step S1140, the host 200 may restore the index update buffer based on the read data.

In more detail, the host 200 may restore the index update buffer 220 by inserting at least some of data read through a plurality of threads into the index update buffer 220 .

At this time, the host 200 may select valid data from among the read data and insert the valid data into the index update buffer 220 . In an embodiment of the present disclosure, valid data may be data having a valid versioning key.

After restoring the index update buffer 220 through step S1140, although not shown in FIG. 11, the host 200 may delete data stored after a recent commit among data stored in the storage device 100. This can be explained with reference to the embodiment of FIG. 10 .

In the embodiment of FIG. 10, the latest commit sequence is the third commit (COMMIT 3), and the last commit sequence updated in the index tree 210 is the first commit (COMMIT 1), so the recovery interval is the first commit (COMMIT 1). ) may be performed to a data block before the third commit (COMMIT 3) is performed.

In this case, data blocks after the third commit (COMMIT 3) is performed are not restored to the index update buffer 220. That is, data blocks having versioning keys of CMT#4 DATA 1, CMT#4 DATA 2, and CMT#4 DATA 3 are not restored to the index update buffer 220.

At this time, the host 200 may delete data stored after a recent commit among data stored in the storage device 100 and having versioning keys of CMT#4 DATA 1, CMT#4 DATA 2, and CMT#4 DATA 3. .

Here, the data blocks whose versioning keys are CMT#4 DATA 1, CMT#4 DATA 2, and CMT#4 DATA 3 include data for which the host 200 has not confirmed that they have been stored by the commit of the storage device 100. are blocks Therefore, the host 200 can prevent problems such as duplicate use of a versioning key that may occur in the future by deleting data stored after a recent commit among data stored in the storage device 100 .

Using the host 200 and the operating method of the host 200 according to the present disclosure as described above, the index update buffer 220 can be restored more quickly by using a plurality of threads. .

12 is a diagram illustrating a storage system according to another exemplary embodiment of the present disclosure.

Referring to FIG. 12 , the storage system 30 may include a storage device 300 and a host 400 . Also, the storage device 300 may include a controller 310 , a data buffer 330 , and a non-volatile memory (NVM) 340 . Since the embodiment shown in FIG. 12 generally performs similar operations to the embodiment shown in FIG. 1 , differences will be mainly described.

In the embodiment of FIG. 12 , the host 400 may include a memory 430 and a processor 440 .

The memory 430 may store the index tree 410 and the index update buffer 420 . In this case, the memory 430 may be implemented as a volatile memory such as dynamic random access memory (DRAM) or static random access memory (SRAM). Accordingly, the index tree 410 and the index update buffer 420 may be volatilized in the memory 430 when the power of the host 400 is terminated. In this case, the index tree 410 may be stored in the storage device 300 and the index update buffer 420 may be updated in the index tree 410 .

The processor 440 may include a central processing unit (CPU) or a microprocessor, and may control overall operations of the host 400 . The memory 430 may operate under the control of the processor 440 . That is, the processor 440 may perform all of the operations described with reference to FIGS. 3, 4, and 11 and operations necessary therefor.

13 is a block diagram illustrating an electronic device according to an embodiment of the present disclosure.

Referring to FIG. 13 , an electronic device 1000 may include a processor 1100, a memory device 1200, a storage device 1300, a modem 1400, an input/output device 1500, and a power supply 1600. . In this case, the processor 1100 and the memory device 1200 may be implemented as the processor 440 and the memory 430 included in the host 400 of FIG. 12 . Also, the memory device 1200 may store an index tree and an index update buffer therein. Also, the storage device 1300 may be implemented like the storage devices 100 and 300 shown in FIG. 1 or 12 .

In one embodiment of the present disclosure, when recovery of the index update buffer in the memory device 1200 is required, the processor 1100 sets a recovery period including data corresponding to a versioning key that has not been updated in the index tree; By dividing the recovery period and distributing it to a plurality of threads, reading data included in the recovery period from the storage device 1300 through the plurality of threads, and inserting at least some of the read data into the index update buffer 220. The index update buffer 220 may be restored. By restoring the index update buffer 220 using a plurality of threads in this way, the index update buffer can be recovered more quickly.

As above, exemplary embodiments have been disclosed in the drawings and specifications. Embodiments have been described using specific terms in this specification, but they are only used for the purpose of explaining the technical spirit of the present disclosure, and are not used to limit the scope of the present disclosure described in the meaning or claims. Therefore, those of ordinary skill in the art will understand that various modifications and equivalent other embodiments are possible therefrom. Therefore, the true technical scope of protection of the present disclosure should be determined by the technical spirit of the appended claims.

Claims (10)

A host communicating with a storage device that processes data using a key-value pair,
an index tree storing an index including information identifying a key required to read data stored in the storage device; and
An index update buffer configured to store a write key included in write-requested data and the versioning key corresponding to the write key;
The host updates the versioning key stored in the index update buffer to the index tree when a preset update condition is satisfied;
When recovery of the index update buffer is required, the host sets a recovery period including data corresponding to the versioning key that has not been updated in the index tree, divides the recovery period, and distributes the recovery period to a plurality of threads. and restoring the index update buffer by reading data included in the recovery section from the storage device through the plurality of threads and inserting at least some of the read data into the index update buffer.
host. According to claim 1,
When receiving a write request, the host generates the versioning key corresponding to the write key based on the order of commits of the storage device and the order of data in the commit, and converts the versioning key to the storage device and the host. characterized by storing in the index update buffer
host. According to claim 1,
The host obtains the latest commit sequence and the last commit sequence updated in the index tree from the header block of the storage device, and sets an interval between the last commit sequence updated in the index tree and the latest commit sequence as the recovery period. characterized by
host. According to claim 1,
Characterized in that the host divides the recovery period into a plurality of commit periods based on the commit order, and distributes each of the plurality of commit periods to a plurality of threads.
host. According to claim 4,
Characterized in that the host reads data from the storage device based on a commit sequence corresponding to a commit section distributed through each of the plurality of threads.
host. According to claim 1,
Characterized in that the host reads data having a commit sequence having the same prefix from the storage device through each of the plurality of threads.
host. According to claim 1,
Characterized in that the host reads data included in the recovery section from the storage device in parallel through each of the plurality of threads.
host. According to claim 1,
Characterized in that the host restores the index update buffer by selecting valid data from the read data and inserting the valid data into the index update buffer.
host. According to claim 1,
Characterized in that the host deletes data stored after a recent commit among data stored in the storage device after restoring the index update buffer.
host. A method of operating a host communicating with a storage device that processes data using a key-value pair, the method comprising:
setting, by the host, a recovery section including data corresponding to a versioning key that has not been updated in the index tree;
dividing, by the host, the recovery period into a plurality of threads;
reading data included in the recovery period from the storage device through the plurality of threads by the host; and
Restoring, by the host, the index update buffer by inserting at least some of the read data into the index update buffer;
The index tree stores an index including information identifying a key necessary for reading data stored in the storage device, and the index update buffer stores a write key included in write-requested data and the versioning code corresponding to the write key. characterized by storing the key
How the host behaves.

Images