KR101936503B1 - Data storing method - Google Patents

Abstract

The data storing method according to the present embodiment includes (a) a write step of storing data requested to be written from an application in a high-speed buffer and providing metadata about the data to a dirty queue, (b) A flush step of obtaining metadata from a clean queue, providing data to a data storing member, and providing metadata about the data to a clean queue, and (c) And provides a free queue with a reclaim step.

Description

{DATA STORING METHOD}

The present technique relates to a data storage method.

Modern storage devices such as solid-state drives (SSDs) are trying to minimize I / O latency, but the latency difference between memory and storage remains an inevitable barrier, It serves as a major cause of performance limitations.

Today's high-performance systems have tens or hundreds of cores that can run an unprecedented number of I / Os simultaneously, and storage devices perform up to gigabytes of data input / output (I / O) every second.

Korean Patent Publication No. 10-2015-0010574 Korean Patent Publication No. 10-2014-0063279 US Published Patent 2011-0078214

Currently developed nonvolatile memory based storage systems have a lower file writing performance of applications due to the inefficiency of the system managing nonvolatile memory resource access when writing data to several files at the same time. As an example, a simple coarse synchronization scheme, such as using global locking, causes a new performance bottleneck in multicore systems with multiple high performance storage devices (e.g., NVMe SSDs). This degradation occurs more severely in server systems with multiple CPUs and multiple storage devices.

It is one of the main objects of the present embodiment to solve the problems of the prior art.

The data storing method according to the present embodiment includes (a) a write step of storing data requested to be written from an application in a high-speed buffer and providing metadata about the data to a dirty queue, (b) A flush step of obtaining metadata from a clean queue, providing data to a data storing member, and providing metadata about the data to a clean queue, and (c) And provides a free queue with a reclaim step.

According to the present invention, since the data provided from the application is provided to the queue by the pseudo parallel process and stored, the bottleneck phenomenon occurring in the data storage process does not occur as in the prior art.

FIG. 1 is a flowchart for explaining an overview of a data storing method according to the present embodiment.
FIG. 2 is a block diagram showing an outline of a data recording module and a periphery thereof for performing a data storing method in this embodiment.
3 is a schematic diagram for explaining a write step of the data storing method according to the present embodiment.
4 is a schematic diagram for explaining the flushing step of the data storing method according to the present embodiment.
5 is a schematic diagram for explaining a reclaiming step of the data storing method according to the present embodiment.
6 is a view schematically showing that the data storing method according to the present embodiment is driven in a pipeline format.
7 is a diagram showing a comparison between the data storage method according to the present embodiment and the YCSB benchmark results of the related art.
FIG. 8 is a diagram showing a comparison between the microbench mark results of the data storing method and the conventional technique according to the present embodiment.

Hereinafter, a data storage method according to the present embodiment will be described with reference to the accompanying drawings. FIG. 1 is a flowchart for explaining an overview of a data storing method according to the present embodiment. Referring to FIG. 1, a data storage method according to an embodiment of the present invention includes: (a) a write operation for storing data requested to be written from an application in a high-speed buffer and providing metadata for data to a dirty queue (b) providing a data store member with metadata from the dirty queue and providing metadata for the data to a clean queue; (c) providing a meta data from the clean queue and providing the meta data to a free queue (step S300).

FIG. 2 is a block diagram showing an outline of a data recording module 10 for performing a data storing method according to the present embodiment and a periphery thereof. A writer 100, a flusher 200, a reclaimer 300, and a dirty queue 150, a clean queue 250, and a dummy queue 150 for illustrative and illustrative purposes in FIG. A writer 100, a flusher 200 and a freezer 300 are shown at the operating system kernel (K) level, although the elements such as a free queue 350 are shown as physical configurations. And the dirty queue 150, the clean queue 250 and the free queue 350 may be data structures operating at the operating system kernel (K) level. Also, the file system (FS), the device driver (DD), etc. may be threads operating at the operating system kernel (K) level.

Referring to FIG. 2, the data storage according to the present embodiment includes three steps: a write step S100, a flushing step S200, and a reclaiming step S300. In the write step SlOO, the applications app1, app2, ..., app4 call the writer 100 triggered by the system call and provide user data. Writer 100 writes the provided user data to the high-speed buffer 400. [

In the flushing step (S200), the flusher (200) flushes the data of the high-speed buffer (400) to a data storing member. The reclaimer 300 reclaims a block of data flushed to be usable for a write request, in a reclaim step S300. In this embodiment, three states of dirty, free and clean are used to distinguish the states of the data blocks, each of which is a latch free queue, a dirty queue 150 ), A clean queue 150, and a free queue 350, as shown in FIG.

Hereinafter, each step of the data storing method according to the present embodiment will be described with reference to FIGS. 3 to 5. FIG. FIG. 3 is a schematic diagram for explaining a write step (S100) in the data storing method according to the present embodiment. 3, the writer 100 stores the data D1 and D2 provided by the applications app1 and app2 in the high-speed buffer 400 and the metadata M1 and D2 for the data D1 and D2, M2 to the dirty queue 150.

In one embodiment, the process by which the writer 100 provides the metadata M1, M2 to the dirty queue 150 may be performed in a pseudo parallel process. In one embodiment, the pseudo-parallel process is performed by an atomic operation.

As an example, operations performed at the operating system level are performed and require hundreds to thousands of CPU clock units to complete. On the other hand, considering that the atomic operation requires several to several tens of CPU clock units from the start to the completion of the operation, the operation performed by the atomic operation is the same at the operating system level As shown in Fig.

In this embodiment, the metadata M1 of the data requested by one application app 1 and the metadata M2 of another application app 2 requested to be stored are pseudo-parallel Dirty queue 150 as shown in FIG. In the write step S100 of providing the meta data M1 and M2 to the dirty queue 150, the sequence of the process is determined by the atomic operation and is provided to the queue by the atomic operation, As shown in FIG. Therefore, the dirty queue 150 according to the present embodiment can be implemented as a latch free queue that does not need to lock the queue and does not fix the queue.

In the prior art, a latch queue is used to hold the queue until the data provided by the application is stored in the storage device. That is, after the data provided by the application is stored in the storage device, the queue is unfixed and the data is received. Therefore, data storage was performed sequentially, and a long time was consumed in the storage process, resulting in a bottleneck in data storage.

However, according to the present embodiment, since the queue is not fixed and the data is provided to the queue through the pseudo parallel process using the atomic operation, the bottleneck occurring in the data storage process according to the prior art can be reduced.

A plurality of lighters 100 may be operated as illustrated in FIG. If a plurality of applications provide a storage request for a plurality of data with a single writer 100, a bottleneck may occur in a data write step. Therefore, the plurality of writers 100 can be executed to increase the speed in the write step S100.

FIG. 4 is a schematic diagram for explaining the flushing step (S200) of the data storing method according to the present embodiment. 4, a flusher 200 receives metadata M1 and M2 from a dirty queue 150 and stores data D1 and D2 corresponding to the metadata in a data storing member. And performs the flushing step S200. Also, in the flushing step 200, the flusher 200 provides the clean queue 250 with metadata (M1, M2) corresponding to the flushed data D1, D2.

In one embodiment, the flusher 200 may wait until the number of meta-data provided from the dirty queue 150 reaches a certain threshold, and when the threshold is reached, collectively storing the data in a data store member. The overhead of the flusher (S200) can be reduced by performing the batch flush described above.

In one embodiment, in the case of a continuous write to reduce the overhead of the flusher, the writer 100 sequentially provides the metadata for the sequential data to the dirty queue 150, The sequential data on the metadata provided from the dirty queue 150 may be collectively provided to a data storage member and flushed.

In one embodiment, a data storage member includes a file system (FS) for inputting and outputting data in an operating system, a hard disk drive (HDD) or a solid state drive (SSD) A storage device such as a mass storage device such as a hard disk drive and a storage device such as a physical storage device and a device driver DD associated with an operating system.

The flusher 200 may have an overhead larger than the lighter 100 and the reclaimer 300 to be described later so that a bottleneck may occur in the flushing process S200. A plurality of flushers 200 may be placed as shown in FIG. 4 to reduce the overhead of the flusher 200 and to reduce the bottleneck that may occur in the flushing process S200.

FIG. 5 is a schematic diagram for explaining a reclaiming step (S300) in the data storing method according to the present embodiment. Referring to FIG. 5, the reclaimer 300 receives metadata M1 and M2 for a data block written to the storage device from the clean queue 250 and provides the meta data M1 and M2 to the free queue 350 . The meta data M1 and M2 are retrieved by the reclaimer 300 and provided to the free queue 350. [ The metadata M1 and M2 provided to the free queue 350 are provided to the writer 100. [

6 is a view schematically showing that the data storing method according to the present embodiment is driven in a pipeline format. In Fig. 6, the abscissa indicates the step performed simultaneously, and the ordinate indicates the flow of time. As shown in FIG. 6, while one of the two steps is being performed, the other two steps may be driven and driven in a pipeline manner. For example, the flushing step S200 is performed by the flusher 200 while the write step S100 is performed by the writer 100, and the reclaiming step S300 is performed by the reclaimer S300 . As shown in FIG. 6, the data storage method may be performed in a pipelined manner to minimize data bottlenecks.

Experiment result

The data recording module 10 according to the present embodiment has been implemented in the Linux kernel 4.8.7. The high-speed buffer 400 is implemented as NVDRAM, and its storage capacity is constituted by 4 GB of 16 KB blocks. The high-speed buffer, NVDRAM, is emulated as the continuous physical memory space of the DRAM. We tested two Samsung NVMe SSD devices with two sockets of 18-core Intel Xeon E5-2699 v3 and 488GiB DRAMs and 3.5GB / s of maximum I / O speeds.

A widely deployed configuration for multiple database server instances, called database sharding, distributes partitioned data for reasons of load balancing, scalability, high performance, and high availability. In this experiment, in a key-value workload evaluation, a number of processes imitated database sharding by having their database instances run separately.

The YCSB benchmark was run using transactions each containing 50% put / set queries. Workloads were deployed in three key-value DBMS engines: WiredTiger, RocksDB, and Redis. In this experiment, the logging to the NVMe SSD based on the existing EXT-4 is compared with the logging based on this embodiment, and the comparison result is as shown in FIG. Figure 7 shows the number of transactions per second for each DBMS engine. In FIG. 7, the logging according to this embodiment, shown as AutoBahn, shows a result similar to the tmpfs result similar to purely writing to memory, showing good throughput characteristics over the conventional logging characteristics (white) Can be confirmed.

In the microbenchmark, I have run multiple threads that repeatedly write 16KB blocks to their own files. Three different writing tasks, append, random, and skewed, were performed separately for the I / O operations based on the present embodiment and the conventional vanilla kernel. As the buffer cache grows, buffered asynchronous file I / O is favored, so non-durability tests are performed by driving vanilla in a 16GB DRAM.

The maximum I / O bandwidth aggregated in the experimental environment is approximately 7 GB / s and the appended workload of this embodiment is limited within the bandwidth starting from two threads. The average I / O throughput increases as more threads are written to each file, but in most cases it is seen in FIG. 8 that the performance of this embodiment is superior.

Through the experiments described above, it can be seen that the data storage method according to the present embodiment provides the synchronous write I / O performance and can utilize the maximum bandwidth of the high performance storage medium.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is clearly understood that the same is by way of illustration and example only and is not to be taken by way of illustration, It will be appreciated that other embodiments are possible. Accordingly, the true scope of the present invention should be determined by the appended claims.

10: data recording module 100: writer
150: Dirty queue 200: Flusher
250: clean queue 300: reclaimer
350: Free queue FS: File system
DD: device driver K: operating system kernel
data storing member

Claims (11)

(a) a write step of storing data requested to be written from an application in a buffer and providing metadata about the data to a dirty queue;
(b) a flush step of obtaining the metadata from the dirty queue, providing the data to a data storing member, and providing metadata about the data to a clean queue; ,
(c) receiving the metadata from the clean queue and providing the meta data to a free queue. The method according to claim 1,
In the writing step,
Wherein data requested to be written from the application is provided to the dirty queue in a pseudo parallel process. 3. The method of claim 2,
The pseudo-parallel process
A method for storing data in a dirty queue, the method comprising the steps of: determining, in an atomic operation, a relationship between data provided by the application and providing the data to the dirty queue. The method according to claim 1,
Wherein the dirty queue is a lock free queue. The method according to claim 1,
Wherein in the flushing step, the number of metadata provided in the dirty queue reaches a threshold value and is provided to a data storing member to perform the flushing step. The method according to claim 1,
The data store includes a file system, a device driver, and a main storage,
Wherein the flushing comprises:
(b1) providing the file system with the data stored in the buffer;
(b2), the file system providing the data to the device driver, and
(b3) the device driver storing the data in the main storage device. The method according to claim 1,
Wherein the data storage method is performed by an operating system (OS). The method according to claim 1,
Wherein the writing step, the flushing step and the reclaiming step are each performed by a back ground thread. The method according to claim 1,
Wherein the data storing method is performed in a pipeline in which the writing step, the flushing step and the reclaiming step are performed in a pipeline. The method according to claim 1,
Wherein the buffer is a non-volatile memory. 11. The method of claim 10,
Wherein the non-volatile memory is non-volatile dynamic random access memory (NVDRAM).

Images