KR20220127080A - Cache management apparatus and method - Google Patents

Abstract

According to the present invention, a cache management device comprises: a main buffer using a volatile memory; an additional buffer using a non-volatile memory and having the same processing speed as the main buffer; a storage using a non-volatile memory having a storage capacity larger than a storage capacity of the main buffer; and a buffer controller which selectively stores, in the additional buffer or the storage on the basis of temporal locality, write asymmetry, and circular accessibility, a victim page that cannot be stored in the main buffer. Accordingly, the amount of writing to a storage device such as an SSD may be reduced.

Description

CACHE MANAGEMENT APPARATUS AND METHOD

The present invention relates to a cache management apparatus and method using a non-volatile bidirectional inline memory module, and more particularly, by reducing the amount of write induced in a storage device such as an SSD by using NVDIMM while maintaining the code or implementation system of the RDBMS. It's all about caching methods to improve overall performance.

With the announcement of Intel 3D X-point and Optane technologies, research on technologies utilizing NVM (Non-Volatile Memory), a non-volatile memory, is being actively conducted centering on the database community. However, NVM has slower access speed than DRAM and is more expensive per unit capacity than SSD. Therefore, in the current flash-based computing environment, NVM cannot completely replace flash memory storage devices such as DRAM or SSD.

Meanwhile, NVDIMM (Non-Volatile DIMM) with flash storage device and battery backup (BBU) function has appeared in DRAM module. NVDIMM can read and write byte unit at the same speed as DRAM and is non-volatile. However, considering the economic aspect, NVDIMM cannot replace DRAM, and it is most efficient to operate as a heterogeneous system in which NVDIMM is added to a flash memory-based storage architecture.

Most DBMSs maintain an area called a buffer pool in DRAM memory to cache table and index data in memory. Since disk I/O operations for data access take a considerable amount of time compared to operations on memory, caching the data once read from disk in the buffer pool allows for faster access to the data in the future and improves the overall performance of the DBMS. can be improved When the buffer pool is full and there is no free space or the transaction log area is insufficient, the buffer manager selects pages to be evicted according to the buffer replacement policy and makes free space. At this time, if the evicted page is a dirty page whose modifications are not reflected on disk, the page must be written from memory to disk, which has a significant adverse effect on the transaction throughput of the DBMS. In particular, OLTP benchmark workloads such as TPC-C have temporal locality, and 20% of the total data requests I/O equivalent to 80% of the total I/O. That is, since the size of the active write set at a specific time is limited, a method is required to reduce a large amount of write requests by caching these pages in a separate buffer.

In order to solve the above-mentioned problems, an embodiment of the present invention provides a method for improving system performance by absorbing a large amount of write requests using a small amount of NVDIMM buffer and reducing the write requests caused to the Flash SSD. There is a purpose.

In addition, an embodiment of the present invention provides a method of caching in an NVDIMM buffer by discriminating a page that is hot from a write point of view in a given workload.

A cache management apparatus according to an embodiment of the present invention for achieving the above object includes: a main buffer using a volatile memory; an additional buffer using a non-volatile memory and having the same processing speed as the main buffer; storage using a non-volatile memory having a larger storage capacity than the main buffer; and a buffer controller selectively storing a victim page that cannot be stored in the main buffer in the additional buffer or storage based on temporal locality, write asymmetry, and circular accessibility.

In an embodiment, the buffer controller determines that a page within a preset time window, a page having a write asymmetry greater than a preset reference, and a page accessed cyclically, is determined as a hot page and storing in the additional buffer. characterized.

In one embodiment, when the buffer controller receives a data page request from the database server, it searches for a requested page based on a buffer list, and the buffer list stores management information of pages stored in the main buffer and the additional buffer. characterized in that

In one embodiment, the management information is characterized in that it includes a tablespace identifier, an offset, and a buffer pool number to which the page belongs.

In an embodiment, when the cache of the additional buffer is full, the buffer controller flushes the page that has not been accessed for a long time to the storage.

In an embodiment, when the capacity of a page having write asymmetry exceeds a preset criterion, the buffer controller determines a hot page based on a log sequence number (LSN) value.

In one embodiment, the main buffer is DRAM, and the additional buffer is a non-volatile bidirectional inline memory module (NVDIMMM).

In a cache management method of a cache management apparatus including a main buffer, an additional buffer, and a storage according to another embodiment of the present invention, when a victim page that cannot be stored in the main buffer occurs, the victim page is temporally locality and write asymmetry , determining whether the page is a hot page based on circular accessibility; and storing in the additional buffer when it is determined that the page is a hot page, and storing in the storage when it is determined that the page is not a hot page, wherein the main buffer uses a volatile memory, and the write-once buffer has the same processing speed as the main buffer. A non-volatile memory having a

According to an embodiment of the present invention, by distinguishing one hot page that generates a large amount of write requests and caching it in the NVDIMM area, it is possible to reduce the amount of writes occurring in a storage device such as an SSD.

1 is a diagram illustrating a configuration of a buffer management apparatus according to an embodiment of the present invention.
2 is a configuration diagram illustrating a caching operation of a caching management apparatus according to an embodiment of the present invention.
3 is a diagram for explaining time delay described in an embodiment of the present invention.
4 is a graph showing the LSN gap calculation result of the Stock table of the TPC-C workload according to an embodiment of the present invention.
5 and 6 are graphs showing the performance of the caching management apparatus according to an embodiment of the present invention.

Since the present invention can have various changes and can have various embodiments, specific embodiments are illustrated in the drawings and described in detail in the detailed description. However, this is not intended to limit the present invention to specific embodiments, and should be understood to include all modifications, equivalents and substitutes included in the spirit and scope of the present invention. In describing each figure, like reference numerals have been used for like elements.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Terms such as those defined in a commonly used dictionary should be interpreted as having a meaning consistent with the meaning in the context of the related art, and should not be interpreted in an ideal or excessively formal meaning unless explicitly defined in the present application. does not

Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. It should be noted that the same components in the drawings are denoted by the same reference numbers and reference numerals as much as possible even though they are indicated in different drawings. In addition, in describing the present invention, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the gist of the present invention, the detailed description thereof will be omitted.

1 is a diagram illustrating a configuration of a buffer management apparatus according to an embodiment of the present invention.

Referring to FIG. 1 , the caching management apparatus 100 according to the present embodiment may include a main buffer 110 , an additional buffer 130 , a buffer controller 150 , and a storage 170 .

The buffer management apparatus according to the present embodiment may be utilized in a general-purpose or special-purpose computer system, such as a main frame computer, a server computer, a personal computer, a mobile device, and a programmable home appliance.

The main buffer 110 is a volatile memory, and stores cached data. The main buffer 110 may be a dynamic random access memory (DRAM).

The additional buffer 130 is a nonvolatile memory having a structure different from that of the main buffer 110 , and the additional buffer 130 may have an access speed similar to that of the main buffer 110 . The additional buffer 130 stores hot pages among pages evicted from the main buffer 110 according to an instruction of the buffer controller 150 to be described later. The additional buffer 130 may be a non-volatile double in-line memory module (NVDIMM). Even if the additional buffer 130 adopts a non-volatile double in-line memory module (NVDIMM), it is used as a buffer of the DBMS like a DRAM buffer, and thus data is stored in page units.

The buffer controller 150 stores, deletes, and moves data in the main buffer 110 and the additional buffer 130 . A victim page that cannot be stored in the main buffer of the buffer controller 150 is selectively stored in the additional buffer 130 or the storage 170 based on temporal locality, write asymmetry, and circular accessibility. The buffer controller 150 may instruct the main buffer 110 to migrate data between the main buffer 110 and the additional buffer 130 . A detailed operation of the buffer controller 150 will be described later with reference to FIG. 2 .

The storage 170 may include at least one of a hard disk drive (hereinafter, HDD) and a solid state drive (SSD). Compared to the main buffer 110 and the additional buffer 130 , the storage 170 has a slow access speed, that is, a write and read speed, but a storage capacity may be larger.

In this case, the storage is a storage medium for long-term storage.

The storage 170 may store an operating system (OS) of a computer system, an application program, program data, and the like.

2 is a configuration diagram illustrating a caching operation of a caching management apparatus according to an embodiment of the present invention.

The caching management device may use a code or implementation system of a relational database management system (RDBMS), for example, Oracle, MySQL, Access, or MsSql.

The buffer controller of the caching management device selects a page to be cached in an additional buffer among pages evicted from the main buffer in order to improve overall performance by reducing the amount of writes induced to storage.

Hereinafter, when any one of a page within a micro-set time window, a page having a write asymmetry greater than a preset reference, and a page accessed cyclically is satisfied, the buffer controller regards it as a hot page and stores it in the additional buffer.

In an embodiment, the buffer controller determines that the page within the preset time window is a hot page with high temporal locality, and caches the page with high temporal locality from the main buffer to an additional buffer so that the hot page is not stored in the storage. This is because a page with high temporal locality receives multiple write requests within a specific time window, and is not accessed again after that point has elapsed or is accessed after a long time.

3 is a diagram for explaining time delay described in an embodiment of the present invention.

3 (a) and (b) are graphs showing the temporal locality of the Order-Line and Orders tables of the TPC-C workload. 3 (c) and (d) are graphs showing the temporal locality of the Counttable and the Linktable of the LinkBench workload. The X-axis means the time difference between write requests for each page, and the Y-axis means the ratio of the accumulated pages to the total number of pages. As can be seen from the graphs of (a) and (b) of FIG. 3 , more than 80% of pages have a very short time difference. That is, these pages are pages with high temporal locality because write requests are requested multiple times within a short period of time.

As can be seen from the graphs of FIG. 3 (c) and (d), most of the tables have high temporal locality. Thus, by caching these pages in NVDIMM buffers, multiple write requests can be reduced to half or less.

That is, the buffer controller can select TPC-C workloads and LinkBench workloads as hot pages.

The next buffer controller may determine a page having write asymmetry greater than or equal to a preset reference as a hot page.

For OLTP workloads like TPC-C, 80% of all write requests come from 20% of all pages. These pages generate constant and uniform write requests rather than temporal locality. TPC-C's Stock table has this characteristic, and 40% of the total write requests generated by the TPC-C workload belong to this table. Therefore, the buffer controller can reduce large write requests by determining which hot pages are hot based on the OLTP workload and the Stock table and caching them in additional buffers.

However, since the capacity of the Stock table is quite large, considering the capacity of the additional buffer, the entire table cannot be cached, so the criteria can be set to cache only the top 10% of pages based on the amount of writes.

For this purpose, based on the Log Sequence Number (LSN) value stored in each page frame, “LSN Gap = LSN when the page was first updated after flushing - LSN when the page was previously flushed” Calculated. A small LSN gap value means that the time difference between the last flush to the storage device and the next time a page is read and updated into the main buffer is short. It's a good idea to cache these pages in an additional buffer because write requests occur even though they are pages that will be accessed soon. That is, when the LSN gap is smaller than a preset reference, the buffer controller may determine that it is a hot page having write asymmetry.

4 is a graph showing the LSN gap calculation result of the Stock table of the TPC-C workload according to an embodiment of the present invention.

Referring to FIG. 4 , the X-axis means the average LSN gap value for each page, and the Y-axis means the number of write requests. In the graph of FIG. 4 , pages with a short LSN gap have a large Y value, that is, the number of write requests. In other words, the shorter the LSN gap, the more times the write is requested, which can be considered hot from the write point of view. Therefore, the buffer controller according to an embodiment calculates the LSN gap for a table with high write asymmetry and large capacity, such as the Stock table, and caches only pages with a short LSN gap in the additional area.

Finally, if the buffer controller satisfies any one of the circularly accessed pages, it is regarded as a hot page and stored in the additional buffer.

Circularly accessed pages are accessed periodically during transaction execution. Therefore, it is possible to reduce the amount of writes caused to the SSD by keeping it in the additional buffer cache as much as possible and preventing unnecessary Eviction. In the TPC-C workload, the New-Order table has this characteristic.

Returning to FIG. 3 again, when the caching management device receives a request for a data page from the database server, it searches for a corresponding page in the main buffer and the additional buffer. If a page is found, it is used immediately. Otherwise, the page is read from the storage device.

When a specific page is replaced in the main buffer, the caching management device selects a victim page according to a preset page replacement algorithm. Here, the page replacement algorithm may be an LRU algorithm. The LRU algorithm is a method of determining which of the currently allocated pages to be replaced in order to allocate a new page when a page fault occurs in the operating system that manages memory using the paging technique. Whenever a process accesses the main memory, the referenced page record the time for

The caching management unit's buffer controller must write to the SSD or write to the NVDIMM buffer cache when a victim page is both a dirty page and a hot page. That is, it is necessary to select where to store the page, which is based on the criteria selected in the above-mentioned hot page. That is, the buffer controller stores the victim page in an additional buffer cache if it is a page that has high temporal locality or write asymmetry or is accessed cyclically. Otherwise, save the page to storage. When the cache of the additional buffer is full, the buffer controller of the caching management device flushes the page that has not been accessed for a long time to the storage according to the LRU replacement policy. There is no other option, such as saving back to an additional buffer, in which case it will unconditionally save to storage.

As described above, the buffer controller manages both the main buffer and the additional buffer, and the main buffer and the additional buffer act as an optional cache buffer for storage. That is, when a page is evicted from the main buffer, it is stored in an additional buffer or storage by determining how hot the page is from a write point of view.

The buffer controller manages the main and additional buffers based on MySQL.

MySQL can use two types of lists. One is the LRU list, which manages pages currently being used in the buffer pool. The second is a free list, which manages pages that are not currently being used by the buffer pool. In the case of InnoDB, MySQL's storage engine, it already knows information about the new page to read when traversing the LRU list to find available pages. That is, InnoDB searches the LRU list while already storing information about the page to be read, such as tablespace ID, offset, and the number of the buffer pool to which the page belongs. The inventors of the present invention implemented the NVDIMM caching technique in MySQL using this buffer management method.

Since the buffer cache of MySQL is basically allocated to the DRAM area, the caching management apparatus according to an embodiment of the present invention additionally implements an additional buffer cache module in the conventional buffer manager structure.

The caching management apparatus according to an embodiment of the present invention allocates the buffer cache to the NVDIMM area by applying the existing buffer allocation code. In addition, since pages are updated in the NVDIMM buffer cache, data structures necessary for buffer management such as a hash table used for page navigation, lock data for page consistency, and metadata are also allocated. The size of the NVDIMM buffer cache is 4% of the total database size, which is a very small amount.

The existing read request processing module reads the page from the DRAM buffer pool if the page that is the target of the read request exists in the DRAM buffer pool. Otherwise, it reads the page from the storage device. Basically, pages are searched in the buffer based on a hash table.

In the caching management apparatus according to an embodiment of the present invention, some of the pages expelled from the DRAM buffer, which is the main buffer, are not used in storage and are stored in the NVDIMM buffer cache, which is an additional buffer. Therefore, a module that handles read requests for pages cached in the NVDIMM buffer is required. The latest version of these pages is in the NVDIMM buffer, so reading the page from storage means reading an older version of the page. Therefore, in one embodiment, when a read request for pages in the NVDIMM buffer is received, the corresponding page is read from the NVDIMM buffer. Since NVDIMM buffers can update data like DRAM buffers, both buffers operate the same in terms of buffer management, except that the location to find and read data is different.

In one embodiment, when a page is evicted from the DRAM buffer, the buffer controller determines whether to cache the page in the NVDIMM buffer or write it to storage. Pages are moved to the NVDIMM buffer only when it is determined to be hot enough to cache in the NVDIMM buffer.

To do this, the buffer controller first checks that when a page is evicted from the DRAM buffer, it meets at least one of three previously devised criteria. If the criteria are met, one free buffer frame is taken from the free list of the NVDIMM buffer cache. Then, after copying the contents of the page to be moved to the imported buffer frame, insert the corresponding buffer page into the NVDIMM buffer. Pages that have the corresponding page frame contents in the existing DRAM buffer are immediately deleted, and empty pages are inserted into the free list of the DRAM buffer.

In one embodiment, since the NVDIMM buffer is additionally implemented, it includes a background flusher that flushes dirty pages of the NVDIMM buffer to the storage device. In this way, the pages of the NVDIMM buffer can be written to the storage device as a background task.

This background flusher flushes every 1000ms or when it receives an event to flush. That is, if a flush operation is performed periodically, but the free list is empty when a page is inserted into the NVDIMM buffer, the foreground thread sends an event to the background flusher to flush. As the flusher scans the NVDIMM buffer, it frees up a certain amount (by default, 1024) of pages. In the case of a clean page, the contents of the page are deleted and the page is directly inserted into the free list so that other threads can use it. In the case of dirty pages, the page is first flushed to the storage device, and after it has been written, the page contents are erased and the page is inserted into the free list.

5 is a flowchart illustrating an algorithm for NVDIMM caching criteria according to an embodiment of the present invention.

Referring to FIG. 5 , in step S100 , the buffer controller starts determining the storage location of the victim page evicted from the DRAM buffer cache.

In step S110, it is checked whether the temporal locality of the victim page is high, and if it is determined that the temporal locality is high, it is determined to be stored in the NVDIMM buffer, and the algorithm is terminated.

If it is determined in step S110 that the temporal locality of the victim page is not high, the process proceeds to step S120 and it is checked whether the write asymmetry of the victim page is high. If it is determined that the write asymmetry of the victim page is high, it decides to store it in the NVDIMM buffer and terminates the algorithm.

If it is determined in step S120 that the write asymmetry of the victim page is not high, the process proceeds to step S130 to determine whether the victim page is cyclically accessed. If it is determined that the victim page is being accessed circularly, it decides to store it in the NVDIMM buffer and terminates the algorithm.

In step S130, if it is determined that the victim page is not cyclically accessed, it is stored in the SSD.

As described above, in an embodiment of the present invention, since pages to be cached are stored separately in the NVDIMM, data stored in the DRAM and the NVDIMM are different in characteristics. The data requested by the database server is stored in the DRAM buffer regardless of whether the page is hot or cold. On the other hand, data that is considered hot from a write point of view on the current workload is stored in the NVDIMM buffer based on the above three criteria (time locality, write asymmetry, and circular accessibility). In other words, both buffer caches are buffer caches used in the database server, but the location where the data is finally stored varies depending on the characteristics of the data.

6 is a graph showing the performance of the caching management apparatus according to an embodiment of the present invention. 6 is a result of performing TPC-C while changing the size of DRAM and NVDIMM of the caching management device according to an embodiment of the present invention.

The experiment was conducted by separating log and data. A Samsung 970 PRO NVMe SSD was used as a data storage device, and a Samsung 850 PRO SSD was used as a log storage device. The detailed experimental environment is as follows.

● OS: Ubuntu 16.04.5 LTS

● CPU: Intel Xeon(R) CPU E5-2640 v3 @ 2.60GHz, Total 32 cores

● Memory: 32GB

● Netlist NVDIMM-N 16G

● MySQL version: 5.7.24

● Logging device: Samsung 850 PRO SSD 256GB

● Device for data: Samsung 970 PRO NVMe SSD 512GB

● Workload: TPC-C (tpcc-mysql), LinkBench

To verify the effectiveness of the NVDIMM caching technique, TPC-C workload and LinkBench workload were used. TPC-C is a traditional OLTP workload and LinkBench is a workload based on Facebook's social network graph data. The detailed experimental environment settings for each workload are as follows.

● TPC-C

I created a TPC-C database with 500 warehouses, and the size is about 50 GB. There are 32 users running at the same time, and the time to run the benchmark is 5,400 seconds.

● LinkBench

We have created a LinkBench database with 50 million nodes, which is about 64 GB in size. We have 32 concurrent users, and we set it to handle 500,000 requests per user.

Performance evaluation result

In performance evaluation, the price per unit capacity of NVDIMM is about three times that of DRAM. Therefore, it is necessary to compare the performance difference when adding 3GB of DRAM instead of 1GB of NVDIMM. The main items of performance evaluation are transaction throughput and write reduction. As an indicator of transaction throughput, TpmC (Transactions per minute Count) value is used in TPC-C, and TPS (Transactions Per Second) value is used in LinkBench. In addition, to check the overall system performance and I/O processing performance, the CPU usage rate, read and write bandwidth, and I/O usage rate were measured with the iostat tool of Linux. The detailed experimental results are as follows.

Table 1 below shows the results of NVDIMM caching technique performance evaluation on TPC-C.

Type 11GB DRAM 5GB DRAM
+ 2GB NVDIMM 8GB DRAM
+ 1GB NVDIMM Final TPS 541 1403 (2.59x) 2112 (3.90x) TpmC 36278 70330 (1.94x) 127053 (3.50x) Avg. rMB/s 14.77 46.00 71.80 Avg. rKB/s/Trx 4.52 7.27 (+61%) 6.28 (+39%) Avg. wMB/s 26.36 43.20 65.30 Avg. wKB/s/Trx 8.07 6.82 (-15%) 5.71 (-29%) Avg. I/O Utilization 57.74 72.54 70.21 Avg. CPU Utilization 20.47 49.86 64.29

The results of performing the performance evaluation of the NVDIMM caching technique using the TPC-C workload are shown in FIG. 5 and Table 1. In FIG. 5 , the X-axis means time in units of 10 seconds, and the Y-axis means the amount of transactions processed for 10 seconds. In other words, the larger the Y-axis value, the better the performance by processing more transactions in the same time. As mentioned above, the price per unit capacity of NVDIMM is three times that of DRAM. Therefore, in this experiment, considering the economic cost, the performance of DRAM 5G + NVDIMM 2G, DRAM 8G + NVDIMM 1G, and DRAM 11G was compared. In the case of DRAM 11G, NVDIMM area is not used, so it is the same as not using NVDIMM caching technology.

As a result of the experiment, when only DRAM was used, the performance was significantly lower than the other two cases using the NVDIMM caching technique. In the case of DRAM 5G + NVDIMM 2G, performance is improved up to 2.6 times compared to DRAM 11G, and the amount of writes per transaction is reduced by 15%. For DRAM 8G + NVDIMM 1G, performance is improved up to 3.9 times compared to DRAM 11G, and the amount of writes per transaction is reduced by 29%. That is, when the NVDIMM caching technique using an additional buffer according to an embodiment of the present invention is applied, the amount of writes per transaction is reduced, so not only the amount of writes induced to the SSD is reduced, but also the transaction throughput is increased by 2.6 to 3.9 times. In addition, it can be seen that the I/O utilization rate of the system increased from 58% to 73% as the transaction throughput increased, and the CPU utilization rate also improved from 21% to 64%.

7 is a graph showing the performance of the caching management apparatus according to an embodiment of the present invention. 7 is a result of performing LinkBench while changing the size of DRAM and NVDIMM of the caching management device according to an embodiment of the present invention.

The X-axis of FIG. 7 means time in units of one second, and the Y-axis means the amount of transactions processed in one second. In other words, the larger the Y-axis value, the better the performance by processing more transactions in the same time. Similar to the TPC-C experiment, the performance of DRAM 5G + NVDIMM 2G, DRAM 8G + NVDIMM 1G, and DRAM 11G was compared in consideration of economic costs. In the case of DRAM 11G, NVDIMM area is not used, so it is the same as not using NVDIMM caching technology.

As a result of the experiment, even in the LinkBench workload, the DRAM-only performance was inferior to the NVDIMM caching technique. For DRAM 5G + NVDIMM 2G, performance is improved up to 2.8 times compared to DRAM 11G, and the amount of writes per transaction is reduced by 51%. In the case of DRAM 8G + NVDIMM 1G, performance is up to 2.9 times higher than that of DRAM 11G, and the amount of writes per transaction is reduced by 50%. In other words, by applying the NVDIMM caching technique on LinkBench workloads, not only the amount of writes induced to the SSD was reduced, but also the transaction throughput was improved by 2.8 to 2.9 times. The system's I/O utilization has increased from 46% to 78%, and the CPU utilization has also improved from 20% to 47%.

Table 2 below shows the results of NVDIMM caching technique performance evaluation on LinkBench.

[Table 2]

Referring to Table 2, as a result of performance evaluation, both TPC-C and LinkBench workloads improved performance by at least 2.6 times and up to 3.9 times when NVDIMM caching was applied compared to the case where NVDIMM caching was not applied. In addition to improving transaction throughput, it also improved the system's CPU and I/O utilization, demonstrating that the NVDIMM caching technique has benefits for overall system performance. And it can be seen that the amount of writes caused to the SSD was reduced from 15% to a maximum of 51% per transaction, not only improving performance, but also achieving the ultimate goal.

As described above, according to the caching management apparatus and method according to an embodiment of the present invention, by discriminating a hot page that generates a large amount of write requests and caching it in the NVDIMM area, writes occurring in a storage device such as an SSD quantity can be reduced. By reducing the amount of writes, the read blocking problem that occurs when running the database on the SSD is solved, and the latency of the transaction is shortened. Ultimately, the amount of transactions processed per unit time increases, improving overall performance. In addition, the system's I/O and CPU utilization are improved because transactions are actively processed.

In addition, by utilizing the non-volatile NVDIMM area between DRAM and SSD as a buffer cache, it is possible to absorb a large amount of updates while fully utilizing the existing DRAM + SSD infrastructure. Through this, NVDIMM can be utilized in the same way on other databases other than MySQL used for implementing the technology of the present invention.

In addition, since the NVDIMM area is non-volatile, it is not necessary to write the redo log for the pages written to the NVDIMM, so the overhead for logging is reduced and thus the performance is improved. problems can be avoided.

The criteria for distinguishing hot pages from a write point of view can be applied to other layers as well. For example, in the present invention, the standard designed for determining the page to be cached in the NVDIMM area at the storage engine level of the database is used, but the standard of the present invention is also applied at the lower OS level or FTL level. It can be used to cache hot pages separately or to store them in a specific block.

The above description is merely illustrative of the technical idea of the present invention, and a person of ordinary skill in the art to which the present invention pertains may make various modifications and variations without departing from the essential characteristics of the present invention. Accordingly, the embodiments carried out in the present invention are not intended to limit the technical spirit of the present invention, but to explain, and the scope of the technical spirit of the present invention is not limited by these embodiments. The protection scope of the present invention should be construed by the following claims, and all technical ideas within the equivalent range should be construed as being included in the scope of the present invention.

Claims (13)

a main buffer using volatile memory;
an additional buffer using a non-volatile memory having the same processing speed as the main buffer;
storage using a non-volatile memory having a larger storage capacity than the main buffer; and
A buffer controller that selectively stores a victim page that cannot be stored in the main buffer in the additional buffer or storage based on temporal locality, write asymmetry, and circular accessibility
A cache management device comprising a.
The method of claim 1,
The buffer controller determines to be a hot page when any one of a page within a preset time window, a page having a write asymmetry greater than a preset reference, and a page accessed cyclically, is determined and stored in the additional buffer. Device.
According to claim 1,
When the buffer controller receives a data page request from the database server, it searches for the requested page based on the buffer list,
The buffer list stores management information of pages stored in the main buffer and the additional buffer.
4. The method of claim 3,
wherein the management information includes a tablespace identifier, an offset, and a buffer pool number to which the page belongs.
According to claim 1,
and the buffer controller flushes the page that has not been accessed for a long time to the storage when the cache of the additional buffer is full.
According to claim 1,
and the buffer controller determines a hot page based on a log sequence number (LSN) value when a capacity of a page having write asymmetry exceeds a preset criterion.
The method of claim 1,
The main buffer is a dynamic random access memory (DRAM),
The additional buffer is a cache management device, characterized in that NVDIMMM (Non-Volatile Double In-line Memory Module).
A cache management method of a cache management device including a main buffer, an additional buffer, and storage, the method comprising:
when a victim page that cannot be stored in the main buffer occurs, determining whether the victim page is a hot page based on temporal locality, write asymmetry, and circular accessibility; and
If it is determined that the page is a hot page, storing it in the additional buffer, and if it is determined that it is not a hot page, storing it in the storage.
including,
The main buffer uses a volatile memory, the write-once buffer uses a nonvolatile memory having the same processing speed as the main buffer, and the storage uses a nonvolatile memory having a larger storage capacity than the main buffer How to manage cache.
9. The method of claim 8,
The step of determining whether the page is a hot page,
A cache management method, characterized in that, when any one of a page within a preset time window, a page having write asymmetry greater than or equal to a preset criterion, and a page being cycledly accessed is satisfied, it is determined as a hot page.
9. The method of claim 8,
retrieving the requested page based on the buffer list when the data page is requested from the database server
further comprising,
The buffer list stores management information of pages stored in the main buffer and the additional buffer.
9. The method of claim 8,
In the storing step
When the hot page is to be stored in the additional buffer, if the cache of the additional buffer is full, the page that has not been accessed for a long time is flushed to the storage.
10. The method of claim 9,
The step of determining whether the hot page is the
A cache management method, comprising: determining a hot page based on a log sequence number (LSN) value when a capacity of a page having write asymmetry exceeds a preset criterion.
9. The method of claim 8,
The main buffer is a dynamic random access memory (DRAM),
The additional buffer is a cache management method, characterized in that NVDIMMM (Non-Volatile Double In-line Memory Module).

Images