WO2020105785A1 - 스냅샷을 이용한 인메모리 데이터베이스의 데이터 처리 방법 및 인메모리 데이터베이스 - Google Patents

스냅샷을 이용한 인메모리 데이터베이스의 데이터 처리 방법 및 인메모리 데이터베이스

Info

Publication number
WO2020105785A1
WO2020105785A1 PCT/KR2018/015545 KR2018015545W WO2020105785A1 WO 2020105785 A1 WO2020105785 A1 WO 2020105785A1 KR 2018015545 W KR2018015545 W KR 2018015545W WO 2020105785 A1 WO2020105785 A1 WO 2020105785A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
temporary
memory
log
memory database
Prior art date
Application number
PCT/KR2018/015545
Other languages
English (en)
French (fr)
Inventor
박상현
진민화
성한승
최원기
Original Assignee
연세대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 연세대학교 산학협력단 filed Critical 연세대학교 산학협력단
Publication of WO2020105785A1 publication Critical patent/WO2020105785A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/60—Information retrieval; Database structures therefor; File system structures therefor of audio data

Definitions

  • the technical field to which the present invention pertains relates to an in-memory database and a data processing method of the in-memory database.
  • This study is a research project carried out with the support of the Information and Communication Technology Promotion Center, funded by the Ministry of Science and ICT (Government) in 2018, and research and development of a high-performance flash memory storage-based in-memory distributed DBMS for SW Star Lab IoT environment (No. 1711065240).
  • An in-memory database is a database that holds all data in memory, not on disk. Since the storage medium is volatile, there is a problem in that data in the medium is deleted when the power of the database server is turned off.
  • the in-memory database records the values inserted / updated / deleted in memory as a log to ensure persistence.
  • the in-memory database When the in-memory database is restarted, it reads log files from disk and rebuilds all data structures in memory.
  • command records are written in a log format and stored in a log buffer in a memory space, and command records are flushed to a file from the log buffer. Flushing is the operation of rewriting data in memory to another storage medium to match it.
  • disk I / O occurs, and if data is continuously input, the log file linearly increases.
  • the file size is rebuilt, but the process of rebuilding the file size affects the performance of the database and uses excessive memory.
  • Patent Document 1 Korean Patent Publication No. 10-2017-0045928 (2017.04.28.)
  • a temporary log file in a text file format is generated on a block device, and a temporary log file is created
  • a storage location flushed from a log buffer in memory is set to point to the temporary log file, and the temporary log file is generated.
  • the main object of the invention is to minimize the disk I / O burden during flushing log records by creating a temporary snapshot file in binary file format on the block device after setting it to point.
  • a data processing method of an in-memory database generating a temporary log file in a text file format on a block device, and when the temporary log file is generated, a storage location flushed from a log buffer in memory In-memory, comprising setting a memorized log file descriptor to point to the temporary log file, and creating a temporary snapshot file in binary file format on the block device if set to point to the temporary log file.
  • the temporary log file is generated in the block device, and the log record may be key-value based data.
  • the processor of the in-memory database may generate a child process in the memory by operating a parent process, and the child process may be created as the temporary snapshot file to store a set of instructions at the current time.
  • the processor of the in-memory database may store a newly input command in the log buffer by operating a parent process while the child process creates the temporary snapshot file.
  • the processor of the in-memory database may delete the canonical log file stored in the block device and change the name of the temporary log file to the canonical log file.
  • the processor of the in-memory database may change the name of the temporary snapshot file to a regular snapshot file.
  • the memory uses a single log buffer, and the block drive can store and manage the canonical log file and the canonical snapshot file separately.
  • a processor, a memory, and a block drive are included, and the block device generates a temporary log file in a text file format, and when the temporary log file is generated, the processor receives a log buffer from the memory.
  • a log file descriptor storing a storage location to be flushed is set to point to the temporary log file, and when set to point to the temporary log file, the block device generates a temporary snapshot file in binary file format.
  • a computer program for data processing recorded on a non-transitory computer readable medium including computer program instructions executable by a processor, wherein the computer program instructions are in-memory database Generating a temporary log file in a text file format on a block device when executed by at least one processor of, a log file descriptor that stores a storage location flushed from a log buffer in memory when the temporary log file is generated It provides a computer program for performing operations including the step of setting to point to the temporary log file, and creating a temporary snapshot file in a binary file format on the block device when set to point to the temporary log file.
  • a temporary log file in a text file format is generated on a block device
  • the storage location flushed from the log buffer of the memory points to the temporary log file.
  • point to a temporary log file create a temporary snapshot file in binary file format on the block device, and periodically flush log records in small units to reduce memory usage and reduce memory volatility. It has the effect of minimizing and improving the processing speed of the database.
  • FIG. 1 is a block diagram illustrating an in-memory database according to an embodiment of the present invention.
  • FIGS. 2 and 3 are views illustrating an operation of backing up data in an in-memory database according to an embodiment of the present invention.
  • FIG. 4 is a flowchart illustrating a data processing method of an in-memory database according to another embodiment of the present invention.
  • the existing in-memory database has a method of creating a temporary log file in order to secure persistence.
  • the command entered while the temporary log file is being generated is stored in the Rewrite Buffer.
  • the command records accumulated in the write buffer are released to a temporary log file, and the log file descriptor is set to point to the temporary log file.
  • Securing memory in an in-memory system is important. These methods increase the memory usage by using the write buffer, and the problem of rapidly increasing disk I / O in the process of releasing the accumulated command history in the write buffer have.
  • the in-memory database does not use a rewrite buffer, stores and manages log files and snapshot files, and creates temporary log files before creating a temporary snapshot file. Set the file descriptor to point to a temporary log file.
  • the in-memory database 10 includes a processor 100, a memory 200, and a block device 300.
  • the in-memory database 10 may omit some components or additionally include other components among various components exemplarily illustrated in FIG. 1.
  • the in-memory database 10 according to the present embodiment does not include a rewrite buffer and backs up data using a general log buffer.
  • the in-memory database 10 is a database that holds all data in memory, not on disk.
  • the processor 100 transmits predefined commands to the memory 200 and the block device 300 to control various signals and data flows.
  • the memory 200 may be implemented as volatile memory.
  • volatile memory includes dynamic random access memory (DRAM).
  • DRAM dynamic random access memory
  • the block device 300 is a storage medium that can be randomly accessed in units of blocks.
  • block devices include hard disk drives (HDDs) and solid state drives (SSDs).
  • the recorded write / update operation is sequentially executed again to recover data.
  • the Everysec method that performs flushing every 1 second in the background thread
  • the Always method that performs flushing each time a command is input from the main thread
  • the method that performs flushing at the time set by the OS And so on is sequentially executed again to recover data.
  • the in-memory database 10 stores data on a key-value basis. It stores the key and value in a pair, and you can use the key to retrieve the value, store the value, delete the value, or call the value.
  • the data type of the value can be variously defined as a hash, sorted set, linked list, string, and the like.
  • the memory 200 has a log buffer 210 and the log buffer 210 stores log records in which commands are recorded.
  • the log record can be key-value based data.
  • the memory 200 may include an address list having a key-value address.
  • the block device 300 stores temporary log files in a text file format and temporary snapshot files in a binary file format.
  • the log file can be AOF (Append Only File) and the snapshot file can be written to the disk using RDB.
  • the AOF method is recorded each time an input / modify / delete command is executed, and is continuously added. When added, the file size continues to grow during recording, so the entire data is rewritten at a specific point in time. When rewriting is performed, the file size is reduced. For example, if the SET command has the same key and the value is executed 5 times under different conditions, only the last executed value remains in memory. When rewriting is performed, all previous records are lost and the final data is recorded.
  • AOF files are text files and can be edited.
  • the RDB method stores the entire data in memory at a specific point in time as a binary file. It is smaller than AOF file, and loading speed is faster than AOF file.
  • the in-memory database 10 reads data stored in the AOF file and / or RDB file stored in the block device 300 and reconstructs the data in the memory 200 to recover the system normally.
  • the processor 100 reads a log file or a snapshot file and executes key-value based processing instructions recorded in the log file or snapshot file.
  • the in-memory database may set a certain percentage of the capacity of the memory as the data storage space.
  • the in-memory database releases some or all of the data to the block device when the log record in which the command is written exceeds a predetermined size or ratio.
  • Log recording can be implemented with key-value based data.
  • the in-memory database creates temporary log files on the block device. Temporary log files are saved in text file format.
  • the processor sets a log file descriptor that points to a temporary log file that stores a storage location flushed from a log buffer in memory.
  • the processor runs a parent process in memory, creating child processes in memory. That is, a fork is performed.
  • the child process creates a temporary snapshot file in binary file format on the block device.
  • the child process stores a set of instructions at the current time in a temporary snapshot file.
  • the instruction set is a data set in which the final data of the values input in duplicate for the same key are matched based on the key-value.
  • Everysec method performs flushing every 1 second and has unstable data persistence, but does not affect processing speed because it performs flushing in the background thread.
  • the Always method performs flushing each time a command is input, and maintains data persistence, but reduces processing speed because it performs flushing in the main thread.
  • the processor deletes the canonical log file stored in the block device and changes the name of the temporary log file to the canonical log file.
  • the processor changes the name of the temporary snapshot file to a regular snapshot file. That is, the block drive changes the temporary log file to a regular log file, and the temporary snapshot file to a regular log file.
  • the in-memory database stores and manages a regular log file and a regular snapshot file separately, thereby periodically flushing log records in small units to minimize disk I / O burden, reduce memory usage, and reduce memory It can minimize the variability of use and improve the processing speed of the database.
  • the components included in the in-memory database are illustrated separately in FIG. 1, a plurality of components may be combined with each other and implemented as at least one module.
  • the components are connected to a communication path connecting a software module or a hardware module inside the device to operate organically with each other. These components communicate using one or more communication buses or signal lines.
  • the in-memory database may be implemented in a logic circuit by hardware, firmware, software, or a combination thereof, or may be implemented using a general purpose or special purpose computer.
  • the device may be implemented using a fixed-wired device, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or the like.
  • FPGA field programmable gate array
  • ASIC application specific integrated circuit
  • the device may be implemented as a System on Chip (SoC) including one or more processors and controllers.
  • SoC System on Chip
  • the in-memory database may be mounted on a computing device provided with hardware elements in the form of software, hardware, or a combination thereof.
  • Computing devices include various devices or communication devices such as communication modems for performing communication with wired and wireless communication networks, memory for storing data for executing programs, and microprocessors for executing and calculating and executing programs. It can mean a device.
  • FIG. 4 is a flowchart illustrating a data processing method of an in-memory database according to another embodiment of the present invention.
  • the data processing method may be performed by an in-memory database, and detailed descriptions of operations performed by the in-memory database will be omitted.
  • step S410 the in-memory database creates a temporary log file in a text file format on the block device.
  • step S420 when a temporary log file is generated, the in-memory database sets the log file descriptor that stores the storage location flushed from the log buffer of the memory to point to the temporary log file.
  • step S430 if the in-memory database is set to point to a temporary log file, a temporary snapshot file in a binary file format is generated on the block device.
  • the processor operates the parent process to create a child process in the memory, and the child process stores the instruction set at the current point in time as a temporary snapshot file. While the child process is saving the temporary snapshot file, the processor stores the newly input command in the log buffer by operating the parent process. Memory uses one log buffer, and no write buffer.
  • the processor deletes the canonical log file stored on the block device, renames the temporary log file to the canonical log file, and renames the temporary snapshot file to the canonical snapshot file.
  • the block drive stores and manages the canonical log file and canonical snapshot file separately.
  • the algorithm for the operation of rebuilding the database is as follows.
  • AOF_Current_Size is the current AOF file size
  • AOF_LESS_Min_Size is the minimum AOF file size at the start of the algorithm
  • TempRDB is the name of the temporary RDB file
  • TempAOF is the name of the temporary AOF file
  • rdbSaveInfo is metadata about the RDB file.
  • the simulated computer system has 64GB of DDR3 RAM, runs the Intel Xeon E5-2660 CPU, and uses a 250G * 3 SSD.
  • the key was frequently updated by adjusting the ratio between SET and GET.
  • the database LESS according to the present embodiment reduces the memory usage to 1/5 level and has little volatility than the conventional method.
  • FIG. 6 it can be easily understood that the database (LESS) according to the present embodiment can improve the processing speed by 2 to 3 times compared to the conventional method.
  • FIG. 4 describes that each process is executed sequentially, this is merely illustrative, and a person skilled in the art changes and executes the sequence described in FIG. 4 without departing from the essential characteristics of the embodiments of the present invention. Or, it may be applied by various modifications and variations by executing one or more processes in parallel or adding other processes.
  • Computer readable media refers to any media that participates in providing instructions to a processor for execution.
  • Computer-readable media may include program instructions, data files, data structures, or combinations thereof. For example, there may be a magnetic medium, an optical recording medium, a memory, and the like.
  • the computer program may be distributed over a networked computer system to store and execute computer readable code in a distributed manner. Functional programs, codes, and code segments for implementing the present embodiment can be easily inferred by programmers in the technical field to which this embodiment belongs.

Abstract

본 실시예들은 블록 디바이스에 텍스트 파일 형식의 임시 로그 파일을 생성하고, 임시 로그 파일을 생성하면 메모리의 로그 버퍼로부터 플러싱하는 저장 위치를 임시 로그 파일을 가리키도록 설정하고, 임시 로그 파일을 가리키도록 설정한 후에 블록 디바이스에 바이너리 파일 형식의 임시 스냅샷 파일을 생성하고, 로그 기록을 작은 단위로 주기적으로 플러싱함으로써, 메모리 사용량을 감소시키고 메모리 사용의 변동성을 최소화하고 데이터베이스의 처리 속도를 향상시키는 인메모리 데이터베이스를 제공한다.

Description

스냅샷을 이용한 인메모리 데이터베이스의 데이터 처리 방법 및 인메모리 데이터베이스
본 발명이 속하는 기술 분야는 인메모리 데이터베이스의 데이터 처리 방법 및 인메모리 데이터베이스에 관한 것이다. 본 연구는 2018년도 과학기술정보통신부(정부)의 재원으로 정보통신기술진흥센터의 지원을 받아 수행된 연구사업인 SW스타랩 IoT 환경을 위한 고성능 플래시 메모리 스토리지 기반 인메모리 분산 DBMS 연구개발(No. 1711065240)과 관련된다.
이 부분에 기술된 내용은 단순히 본 실시예에 대한 배경 정보를 제공할 뿐 종래기술을 구성하는 것은 아니다.
인메모리 데이터베이스는 디스크가 아닌 메모리에 모든 데이터를 보유하고 있는 데이터베이스이다. 저장매체가 휘발성이기 때문에, 데이터베이스 서버의 전원이 꺼지면 매체에 있는 자료들이 삭제되는 문제가 있다.
인메모리 데이터베이스는 지속성을 보장하기 위해서 메모리에 삽입/갱신/삭제된 값들을 디스크에 로그로 기록하며, 인메모리 데이터베이스가 재구동될 때 디스크로부터 로그 파일을 읽고 메모리에 데이터 구조를 모두 재구축한다. 로그 기록 방식은 명령 기록을 로그 형태로 작성하여 메모리 공간의 로그 버퍼에 저장하고, 로그 버퍼로부터 명령 기록을 파일에 플러싱한다. 플러싱은 메모리의 데이터를 다른 저장매체에 다시 써서 일치화하는 동작이다.
로그 파일을 기록하는 과정에서 디스크 I/O를 발생시키며, 지속적으로 데이터가 입력되면 로그 파일이 선형적으로 증가하는 문제가 있다. 일정 크기 이상으로 로그 파일이 증가하면 파일 크기를 재구축하지만 파일 크기를 재구축하는 과정은 데이터베이스의 성능에 영향을 주고 과도한 메모리를 사용하는 문제가 있다.
(특허문헌1) 한국공개특허공보 제10-2017-0045928호 (2017.04.28.)
본 발명의 실시예들은 블록 디바이스에 텍스트 파일 형식의 임시 로그 파일을 생성하고, 임시 로그 파일을 생성하면 메모리의 로그 버퍼로부터 플러싱하는 저장 위치를 임시 로그 파일을 가리키도록 설정하고, 임시 로그 파일을 가리키도록 설정한 후에 블록 디바이스에 바이너리 파일 형식의 임시 스냅샷 파일을 생성함으로써, 로그 기록을 플러싱하는 동안 소요되는 디스크 I/O 부담을 최소화하는 데 발명의 주된 목적이 있다.
본 발명의 명시되지 않은 또 다른 목적들은 하기의 상세한 설명 및 그 효과로부터 용이하게 추론할 수 있는 범위 내에서 추가적으로 고려될 수 있다.
본 실시예의 일 측면에 의하면, 인메모리 데이터베이스의 데이터 처리 방법에 있어서, 블록 디바이스에 텍스트 파일 형식의 임시 로그 파일을 생성하는 단계, 상기 임시 로그 파일을 생성하면 메모리의 로그 버퍼로부터 플러싱하는 저장 위치를 기억하는 로그 파일 서술자가 상기 임시 로그 파일을 가리키도록 설정하는 단계, 및 상기 임시 로그 파일을 가리키도록 설정하면 상기 블록 디바이스에 바이너리 파일 형식의 임시 스냅샷 파일을 생성하는 단계를 포함하는 인메모리 데이터베이스의 데이터 처리 방법을 제공한다.
상기 메모리의 로그 버퍼에 명령어가 기록된 로그 기록이 기 설정된 크기 또는 비율 이상으로 증가하면, 상기 블록 디바이스에 상기 임시 로그 파일을 생성하며, 상기 로그 기록은 키-값 기반의 데이터일 수 있다.
상기 메모리의 로그 버퍼로부터 상기 블록 디바이스로 기 설정된 단위 시간마다 주기적으로 플러싱할 수 있다.
상기 인메모리 데이터베이스의 프로세서는 부모 프로세스를 동작시켜 상기 메모리에 자식 프로세스를 생성하고, 상기 자식 프로세스는 현재 시점에서의 명령어 집합을 저장하도록 상기 임시 스냅샷 파일로 생성할 수 있다.
상기 인메모리 데이터베이스의 프로세서는 상기 자식 프로세스가 상기 임시 스냅샷 파일을 생성하는 동안에, 새로 입력된 명령어를 부모 프로세스를 동작시켜 상기 로그 버퍼에 저장할 수 있다.
상기 인메모리 데이터베이스의 프로세서는 상기 임시 스냅샷 파일의 생성이 완료되면, 상기 블록 디바이스에 저장된 정식 로그 파일을 삭제하고, 상기 임시 로그 파일의 이름을 상기 정식 로그 파일로 변경할 수 있다.
상기 인메모리 데이터베이스의 프로세서는 상기 임시 스냅샷 파일의 생성이 완료되면, 상기 임시 스냅샷 파일의 이름을 정식 스냅샷 파일로 변경할 수 있다.
상기 메모리는 하나의 로그 버퍼를 사용하고, 상기 블록 드라이브는 상기 정식 로그 파일과 상기 정식 스냅샷 파일을 별도로 저장하여 관리할 수 있다.
본 실시예의 다른 측면에 의하면, 프로세서, 메모리, 및 블록 드라이브를 포함하며, 상기 블록 디바이스는 텍스트 파일 형식의 임시 로그 파일을 생성하며, 상기 임시 로그 파일을 생성하면 상기 프로세서는 상기 메모리의 로그 버퍼로부터 플러싱하는 저장 위치를 기억하는 로그 파일 서술자가 상기 임시 로그 파일을 가리키도록 설정하며, 상기 임시 로그 파일을 가리키도록 설정하면 상기 블록 디바이스는 바이너리 파일 형식의 임시 스냅샷 파일을 생성하는 것을 특징으로 하는 인메모리 데이터베이스를 제공한다.
본 실시예의 또 다른 측면에 의하면, 프로세서에 의해 실행 가능한 컴퓨터 프로그램 명령어들을 포함하는 비일시적(Non-Transitory) 컴퓨터 판독 가능한 매체에 기록되어 데이터 처리를 위한 컴퓨터 프로그램으로서, 상기 컴퓨터 프로그램 명령어들이 인메모리 데이터베이스의 적어도 하나의 프로세서에 의해 실행되는 경우에, 블록 디바이스에 텍스트 파일 형식의 임시 로그 파일을 생성하는 단계, 상기 임시 로그 파일을 생성하면 메모리의 로그 버퍼로부터 플러싱하는 저장 위치를 기억하는 로그 파일 서술자가 상기 임시 로그 파일을 가리키도록 설정하는 단계, 및 상기 임시 로그 파일을 가리키도록 설정하면 상기 블록 디바이스에 바이너리 파일 형식의 임시 스냅샷 파일을 생성하는 단계를 포함한 동작들을 수행하는 컴퓨터 프로그램을 제공한다.
이상에서 설명한 바와 같이 본 발명의 실시예들에 의하면, 블록 디바이스에 텍스트 파일 형식의 임시 로그 파일을 생성하고, 임시 로그 파일을 생성하면 메모리의 로그 버퍼로부터 플러싱하는 저장 위치를 임시 로그 파일을 가리키도록 설정하고, 임시 로그 파일을 가리키도록 설정한 후에 블록 디바이스에 바이너리 파일 형식의 임시 스냅샷 파일을 생성하고, 로그 기록을 작은 단위로 주기적으로 플러싱함으로써, 메모리 사용량을 감소시키고 메모리 사용의 변동성을 최소화하고 데이터베이스의 처리 속도를 향상시키는 효과가 있다.
여기에서 명시적으로 언급되지 않은 효과라 하더라도, 본 발명의 기술적 특징에 의해 기대되는 이하의 명세서에서 기재된 효과 및 그 잠정적인 효과는 본 발명의 명세서에 기재된 것과 같이 취급된다.
도 1은 본 발명의 일 실시예에 따른 인메모리 데이터베이스를 예시한 블록도이다.
도 2 및 도 3은 본 발명의 일 실시예에 따른 인메모리 데이터베이스가 데이터를 백업하는 동작을 예시한 도면이다.
도 4는 본 발명의 다른 실시예에 따른 인메모리 데이터베이스의 데이터 처리 방법을 예시한 흐름도이다.
도 5 및 도 6은 본 발명의 실시예들에 따라 수행된 모의실험 결과를 도시한 것이다.
이하, 본 발명을 설명함에 있어서 관련된 공지기능에 대하여 이 분야의 기술자에게 자명한 사항으로서 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략하고, 본 발명의 일부 실시예들을 예시적인 도면을 통해 상세하게 설명한다.
기존의 인메모리 데이터베이스는 지속성을 확보하기 위해서 임시 로그 파일을 생성하는 방식이 있다. 임시 로그 파일이 생성되는 동안에 입력되는 명령어를 다시 쓰기 버퍼(Rewrite Buffer)에 저장한다. 다시 쓰기 버퍼에 누적된 명령어 기록을 임시 로그 파일로 방출하고, 로그 파일 서술자가 임시 로그 파일을 가리키도록 설정한다.
임시 로그 파일 대신에 임시 스냅샷 파일을 생성하는 방식이 있으나, 이러한 방식 역시 임시 스냅샷 파일이 생성되는 동안에 입력되는 명령어를 다시 쓰기 버퍼(Rewrite Buffer)에 저장한다. 다시 쓰기 버퍼에 누적된 명령어 기록을 임시 스냅샷 파일로 방출하고, 임시 스냅샷 파일을 로그 파일로 변경하고 파일 서술자가 로그 파일을 가리키도록 설정한다.
인메모리 시스템에서 메모리를 확보하는 것은 중요한데, 이러한 방식들은 다시 쓰기 버퍼를 사용함에 따라 메모리 사용량이 증가하고, 다시 쓰기 버퍼에 누적된 명령어 기록을 방출하는 과정에서 디스크 I/O를 급격히 증가시키는 문제가 있다.
본 실시예에 따른 인메모리 데이터베이스는 이러한 문제를 해결하기 위해서 다시 쓰기 버퍼를 사용하지 않고, 로그 파일과 스냅샷 파일을 각각 저장하고 관리하며, 임시 스냅샷 파일을 생성하기 전에 임시 로그 파일을 생성하고 파일 서술자가 임시 로그 파일을 가리키도록 설정한다.
도 1은 본 실시예에 따른 인메모리 데이터베이스를 예시한 블록도이다. 도 1에 도시한 바와 같이, 인메모리 데이터베이스(10)는 프로세서(100), 메모리(200), 및 블록 디바이스(300)를 포함한다. 인메모리 데이터베이스(10)는 도 1에서 예시적으로 도시한 다양한 구성요소들 중에서 일부 구성요소를 생략하거나 다른 구성요소를 추가로 포함할 수 있다. 본 실시예에 따른 인메모리 데이터베이스(10)는 다시 쓰기 버퍼를 포함하지 않고 일반 로그 버퍼를 사용하여 데이터를 백업한다.
인메모리 데이터베이스(10)는 디스크가 아닌 메모리에 모든 데이터를 보유하고 있는 데이터베이스이다. 프로세서(100)는 메모리(200) 및 블록 디바이스(300)에 기 정의된 명령어를 전송하여, 각종 신호 및 데이터 흐름을 제어한다. 메모리(200)는 휘발성 메모리로 구현될 수 있다. 예컨대, 휘발성 메모리로는 DRAM(Dynamic Random Access Memory) 등이 있다. 블록 디바이스(300)는 블록 단위로 임의 접근이 가능한 저장매체이다. 예컨대, 블록 디바이스로는 HDD(Hard Disk Drive), SSD(Solid State Drive) 등이 있다.
인메모리 데이터베이스(10)가 모든 쓰기(Write)/갱신(Update) 연산을 로그 파일에 기록하고 재 시작될 때, 기록된 쓰기/갱신 동작을 순차적으로 재 실행하여 데이터를 복구한다. 파일을 쓰는 시점에 관한 옵션으로 백그라운드 쓰레드에서 1초마다 플러싱을 수행하는 Everysec 방식, 메인 쓰레드에서 명령이 입력될 때마다 매번 플러싱을 수행하는 Always 방식, 또는 OS에 의해 설정된 시점에 플러싱을 수행하는 방식 등으로 설정할 수 있다.
인메모리 데이터베이스(10)는 키-값 기반으로 데이터를 저장한다. 키와 값을 한 쌍으로 저장하며, 키를 사용하여 값을 검색하거나 값을 저장하거나 값을 삭제하거나 값을 호출할 수 있다. 값의 데이터 타입은 해시(Hash), 정렬 집합(Sorted Set), 연결 리스트(Linked List), 스트링(String) 등으로 다양하게 정의될 수 있다.
메모리(200)는 로그 버퍼(210)를 갖고 로그 버퍼(210)는 명령어가 기록된 로그 기록을 저장한다. 로그 기록은 키-값 기반의 데이터일 수 있다. 메모리(200)는 키-값의 주소를 갖는 주소 리스트를 포함할 수 있다.
블록 디바이스(300)는 텍스트 파일 형식의 임시 로그 파일과 바이너리 파일 형식의 임시 스냅샷 파일을 각각 저장한다. 로그 파일은 AOF(Append Only File) 방식으로 스냅샷 파일은 RDB 방식으로 디스크 쓰기를 수행할 수 있다.
AOF 방식은 입력/수정/삭제 명령이 실행될 때 마다 기록되며, 계속 추가하면서 기록된다. 추가하면 기록되는 동안 파일 사이즈가 계속 커지기 때문에, 특정 시점에 데이터 전체를 다시 쓰기(rewrite)를 수행한다. 다시 쓰기를 수행하면, 파일 사이즈가 작아 지게 된다. 예를 들어, SET 명령이 key는 같고 값을 다른 조건에서 5번 수행되었다고 하면, 메모리에는 마지막 수행된 값만 남는다. 다시 쓰기를 수행하면 이전 기록은 모두 사라지고 최종 데이터가 기록된다. AOF 파일은 텍스트 파일이며, 편집이 가능하다.
RDB 방식은 특정 시점의 메모리에 있는 데이터 전체를 바이너리 파일로 저장한다. AOF 파일보다 사이즈가 작고, 로딩 속도가 AOF 파일보다 빠르다.
인메모리 데이터베이스(10)는 블록 디바이스(300)에 저장된 AOF 파일 및/또는 RDB 파일에 저장된 데이터를 읽고 메모리(200)에 데이터를 재구축하여 시스템을 정상 복구한다. 프로세서(100)는 로그 파일 또는 스냅샷 파일을 읽고 로그 파일 또는 스냅샷 파일에 기록된 키-값 기반의 처리 명령을 실행한다.
이하에서는 도 2 및 도 3을 참조하여, 인메모리 데이터베이스가 데이터를 백업하는 동작을 설명하기로 한다.
인메모리 데이터베이스는 메모리의 용량 중에서 일정 비율만큼의 용량을 데이터 저장 공간으로 설정할 수 있다. 인메모리 데이터베이스는 명령어가 기록된 로그 기록이 기 설정된 크기 또는 비율을 초과하면, 일부 또는 전부 데이터를 블록 디바이스로 방출한다. 로그 기록은 키-값 기반의 데이터로 구현될 수 있다.
인메모리 데이터베이스는 블록 디바이스에 임시 로그 파일을 생성한다. 임시 로그 파일은 텍스트 파일 형식으로 저장된다.
임시 로그 파일이 생성되면, 프로세서는 메모리의 로그 버퍼로부터 플러싱하는 저장 위치를 기억하는 로그 파일 서술자가 임시 로그 파일을 가리키도록 설정한다.
임시 로그 파일을 가리키도록 설정하면, 프로세서는 메모리 상에서 부모 프로세스를 동작시켜 메모리에 자식 프로세스를 생성한다. 즉, 포크(fork)를 수행한다. 자식 프로세스는 블록 디바이스에 바이너리 파일 형식의 임시 스냅샷 파일을 생성한다. 자식 프로세스는 현재 시점에서의 명령어 집합을 임시 스냅샷 파일에 저장한다. 명령어 집합은 동일한 키에 대해서 중복으로 입력된 값의 최종 데이터가 키-값 기반으로 매칭된 데이터 집합이다.
프로세서는 자식 프로세스가 임시 스냅샷 파일을 생성하는 동안에, 새로 입력된 명령어를 부모 프로세스를 동작시켜 로그 버퍼에 저장한다. 메모리는 다시 쓰기 버퍼가 사용하지 않는다. 즉, 메모리는 하나의 로그 버퍼를 사용한다.
프로세서는 메모리의 로그 버퍼로부터 블록 디바이스로 기 설정된 단위 시간마다 주기적으로 플러싱을 수행한다. 주기적으로 플러싱하는 방식은 크게 Everysec 방식과 Always 방식이 있다. Everysec 방식은 1초마다 플러싱을 수행하며, 불안정한 데이터 지속성을 갖지만 백그라운드 쓰레드에서 플러싱을 수행하기 때문에 처리속도에 영향을 주지 않는다. Always 방식은 명령이 입력될 때마다 매번 플러싱을 수행하며, 데이터 지속성을 유지하지만 메인 쓰레드에서 플러싱을 수행하기 때문에 처리속도를 저감시킨다.
프로세서는 임시 스냅샷 파일의 생성이 완료되면, 블록 디바이스에 저장된 정식 로그 파일을 삭제하고, 임시 로그 파일의 이름을 정식 로그 파일로 변경한다. 프로세서는 임시 스냅샷 파일의 생성이 완료되고 로그 파일의 이름이 변경되면, 임시 스냅샷 파일의 이름을 정식 스냅샷 파일로 변경한다. 즉, 블록 드라이브는 임시 로그 파일을 정식 로그 파일로 변경하고, 임시 스냅샷 파일을 정식 로그 파일로 변경한다.
본 실시예에 따른 인메모리 데이터 베이스는 정식 로그 파일과 정식 스냅샷 파일을 별도로 저장하여 관리함으로써, 로그 기록을 작은 단위로 주기적으로 플러싱하여 디스크 I/O 부담을 최소화하고, 메모리 사용량을 감소시키고 메모리 사용의 변동성을 최소화하고 데이터베이스의 처리 속도를 향상시킬 수 있다.
인메모리 데이터베이스에 포함된 구성요소들이 도 1에서는 분리되어 도시되어 있으나, 복수의 구성요소들은 상호 결합되어 적어도 하나의 모듈로 구현될 수 있다. 구성요소들은 장치 내부의 소프트웨어적인 모듈 또는 하드웨어적인 모듈을 연결하는 통신 경로에 연결되어 상호 간에 유기적으로 동작한다. 이러한 구성요소들은 하나 이상의 통신 버스 또는 신호선을 이용하여 통신한다.
인메모리 데이터베이스는 하드웨어, 펌웨어, 소프트웨어 또는 이들의 조합에 의해 로직회로 내에서 구현될 수 있고, 범용 또는 특정 목적 컴퓨터를 이용하여 구현될 수도 있다. 장치는 고정배선형(Hardwired) 기기, 필드 프로그램 가능한 게이트 어레이(Field Programmable Gate Array, FPGA), 주문형 반도체(Application Specific Integrated Circuit, ASIC) 등을 이용하여 구현될 수 있다. 또한, 장치는 하나 이상의 프로세서 및 컨트롤러를 포함한 시스템온칩(System on Chip, SoC)으로 구현될 수 있다.
인메모리 데이터베이스는 하드웨어적 요소가 마련된 컴퓨팅 디바이스에 소프트웨어, 하드웨어, 또는 이들의 조합하는 형태로 탑재될 수 있다. 컴퓨팅 디바이스는 각종 기기 또는 유무선 통신망과 통신을 수행하기 위한 통신 모뎀 등의 통신장치, 프로그램을 실행하기 위한 데이터를 저장하는 메모리, 프로그램을 실행하여 연산 및 명령하기 위한 마이크로프로세서 등을 전부 또는 일부 포함한 다양한 장치를 의미할 수 있다.
도 4는 본 발명의 다른 실시예에 따른 인메모리 데이터베이스의 데이터 처리 방법을 예시한 흐름도이다.
데이터 처리 방법은 인메모리 데이터베이스에 의하여 수행될 수 있으며, 인메모리 데이터베이스가 수행하는 동작에 관한 상세한 설명과 중복되는 설명은 생략하기로 한다.
단계 S410에서, 인메모리 데이터베이스는 블록 디바이스에 텍스트 파일 형식의 임시 로그 파일을 생성한다.
단계 S420에서, 인메모리 데이터베이스는 임시 로그 파일을 생성하면, 메모리의 로그 버퍼로부터 플러싱하는 저장 위치를 기억하는 로그 파일 서술자가 임시 로그 파일을 가리키도록 설정한다.
단계 S430에서, 인메모리 데이터베이스는 임시 로그 파일을 가리키도록 설정하면, 블록 디바이스에 바이너리 파일 형식의 임시 스냅샷 파일을 생성한다.
프로세서는 부모 프로세스를 동작시켜 상기 메모리에 자식 프로세스를 생성하고, 자식 프로세스는 현재 시점에서의 명령어 집합을 임시 스냅샷 파일로 저장한다. 프로세서는 자식 프로세스가 임시 스냅샷 파일을 저장하는 동안에, 새로 입력된 명령어를 부모 프로세스를 동작시켜 로그 버퍼에 저장한다. 메모리는 하나의 로그 버퍼를 사용하고, 다시 쓰기 버퍼를 사용하지 않는다.
프로세서는 임시 스냅샷 파일의 저장이 완료되면, 블록 디바이스에 저장된 정식 로그 파일을 삭제하고, 임시 로그 파일의 이름을 정식 로그 파일로 변경하고, 임시 스냅샷 파일의 이름을 정식 스냅샷 파일로 변경한다.
블록 드라이브는 정식 로그 파일과 정식 스냅샷 파일을 별도로 저장하여 관리한다.
데이터베이스를 재구축하는 동작에 관한 알고리즘은 다음과 같다.
Figure PCTKR2018015545-appb-I000001
AOF_Current_Size는 현재 AOF 파일 크기이고, AOF_LESS_Min_Size는 알고리즘 시작시 최소 AOF 파일 크기이고, TempRDB는 임시 RDB 파일의 이름이고, TempAOF는 임시 AOF 파일의 이름이고, rdbSaveInfo는 RDB 파일에 관한 메타데이터이다.
도 5 및 도 6은 본 발명의 실시예들에 따라 수행된 모의실험 결과를 도시한 것이다. 시뮬레이션한 컴퓨터 시스템은 64GB의 DDR3 RAM을 갖고, 인텔 제온 E5-2660 CPU를 동작시키고, 250G*3의 SSD를 사용하였다. SET과 GET의 비율을 조절하여 키를 빈번하게 갱신하였다.
도 5를 참조하면, 본 실시예에 따른 데이터베이스(LESS)가 기존 방식보다 메모리 사용량을 1/5 수준으로 감소시키고, 변동성이 거의 없음을 쉽게 파악할 수 있다. 도 6을 참조하면, 본 실시예에 따른 데이터베이스(LESS)가 기존 방식보다 처리속도를 2~3배 향상시킬 수 있음을 쉽게 파악할 수 있다.
도 4에서는 각각의 과정을 순차적으로 실행하는 것으로 기재하고 있으나 이는 예시적으로 설명한 것에 불과하고, 이 분야의 기술자라면 본 발명의 실시예의 본질적인 특성에서 벗어나지 않는 범위에서 도 4에 기재된 순서를 변경하여 실행하거나 또는 하나 이상의 과정을 병렬적으로 실행하거나 다른 과정을 추가하는 것으로 다양하게 수정 및 변형하여 적용 가능할 것이다.
본 실시예들에 따른 동작은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능한 매체에 기록될 수 있다. 컴퓨터 판독 가능한 매체는 실행을 위해 프로세서에 명령어를 제공하는 데 참여한 임의의 매체를 나타낸다. 컴퓨터 판독 가능한 매체는 프로그램 명령, 데이터 파일, 데이터 구조 또는 이들의 조합을 포함할 수 있다. 예를 들면, 자기 매체, 광기록 매체, 메모리 등이 있을 수 있다. 컴퓨터 프로그램은 네트워크로 연결된 컴퓨터 시스템 상에 분산되어 분산 방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수도 있다. 본 실시예를 구현하기 위한 기능적인(Functional) 프로그램, 코드, 및 코드 세그먼트들은 본 실시예가 속하는 기술분야의 프로그래머들에 의해 용이하게 추론될 수 있을 것이다.
본 실시예들은 본 실시예의 기술 사상을 설명하기 위한 것이고, 이러한 실시예에 의하여 본 실시예의 기술 사상의 범위가 한정되는 것은 아니다. 본 실시예의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 실시예의 권리범위에 포함되는 것으로 해석되어야 할 것이다.

Claims (3)

  1. 인메모리 데이터베이스의 데이터 처리 방법에 있어서,
    블록 디바이스에 텍스트 파일 형식의 임시 로그 파일을 생성하는 단계;
    상기 임시 로그 파일을 생성하면, 메모리의 로그 버퍼로부터 플러싱하는 저장 위치를 기억하는 로그 파일 서술자가 상기 임시 로그 파일을 가리키도록 설정하는 단계; 및
    상기 임시 로그 파일을 가리키도록 설정하면, 상기 블록 디바이스에 바이너리 파일 형식의 임시 스냅샷 파일을 생성하는 단계
    를 포함하는 인메모리 데이터베이스의 데이터 처리 방법.
  2. 제1항에 있어서,
    상기 인메모리 데이터베이스의 프로세서는 부모 프로세스를 동작시켜 상기 메모리에 자식 프로세스를 생성하고, 상기 자식 프로세스는 현재 시점에서의 명령어 집합을 저장하도록 상기 임시 스냅샷 파일로 생성하며,
    상기 인메모리 데이터베이스의 프로세서는 상기 자식 프로세스가 상기 임시 스냅샷 파일을 생성하는 동안에, 새로 입력된 명령어를 부모 프로세스를 동작시켜 상기 로그 버퍼에 저장하는 것을 특징으로 하는 인메모리 데이터베이스의 데이터 처리 방법.
  3. 제1항에 있어서,
    상기 메모리는 하나의 로그 버퍼를 사용하고,
    상기 블록 드라이브는 정식 로그 파일과 정식 스냅샷 파일을 별도로 저장하여 관리하는 것을 특징으로 하는 인메모리 데이터베이스의 데이터 처리 방법.
PCT/KR2018/015545 2018-11-23 2018-12-07 스냅샷을 이용한 인메모리 데이터베이스의 데이터 처리 방법 및 인메모리 데이터베이스 WO2020105785A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2018-0146224 2018-11-23
KR1020180146224A KR102160527B1 (ko) 2018-11-23 2018-11-23 스냅샷을 이용한 인메모리 데이터베이스의 데이터 처리 방법 및 인메모리 데이터베이스

Publications (1)

Publication Number Publication Date
WO2020105785A1 true WO2020105785A1 (ko) 2020-05-28

Family

ID=70774357

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/015545 WO2020105785A1 (ko) 2018-11-23 2018-12-07 스냅샷을 이용한 인메모리 데이터베이스의 데이터 처리 방법 및 인메모리 데이터베이스

Country Status (2)

Country Link
KR (1) KR102160527B1 (ko)
WO (1) WO2020105785A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160050930A (ko) * 2014-10-31 2016-05-11 에스케이텔레콤 주식회사 대용량 분산 파일 시스템에서 데이터의 수정을 포함하는 트랜잭션 처리 장치 및 컴퓨터로 읽을 수 있는 기록매체
KR101765517B1 (ko) * 2016-04-06 2017-08-08 한양대학교 산학협력단 데이터베이스를 저널링하는 장치 및 방법
KR20170106626A (ko) * 2017-08-03 2017-09-21 주식회사 티맥스데이터 메인 메모리 데이터 베이스를 관리 하기 위한 방법 및 컴퓨팅 장치
KR20170129959A (ko) * 2013-03-15 2017-11-27 아마존 테크놀로지스, 인크. 인 플레이스 스냅샷들
KR20170133866A (ko) * 2016-05-27 2017-12-06 삼성에스디에스 주식회사 데이터 이관 장치 및 방법

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160121819A (ko) * 2015-04-13 2016-10-21 한국전자통신연구원 이종 메모리 기반 데이터 관리 장치
KR20170045928A (ko) 2015-10-20 2017-04-28 삼성에스디에스 주식회사 인메모리 데이터베이스를 이용한 데이터 관리 방법 및 그 장치

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170129959A (ko) * 2013-03-15 2017-11-27 아마존 테크놀로지스, 인크. 인 플레이스 스냅샷들
KR20160050930A (ko) * 2014-10-31 2016-05-11 에스케이텔레콤 주식회사 대용량 분산 파일 시스템에서 데이터의 수정을 포함하는 트랜잭션 처리 장치 및 컴퓨터로 읽을 수 있는 기록매체
KR101765517B1 (ko) * 2016-04-06 2017-08-08 한양대학교 산학협력단 데이터베이스를 저널링하는 장치 및 방법
KR20170133866A (ko) * 2016-05-27 2017-12-06 삼성에스디에스 주식회사 데이터 이관 장치 및 방법
KR20170106626A (ko) * 2017-08-03 2017-09-21 주식회사 티맥스데이터 메인 메모리 데이터 베이스를 관리 하기 위한 방법 및 컴퓨팅 장치

Also Published As

Publication number Publication date
KR102160527B1 (ko) 2020-09-28
KR20200060970A (ko) 2020-06-02

Similar Documents

Publication Publication Date Title
Matsunobu et al. Myrocks: Lsm-tree database storage engine serving facebook's social graph
US10983955B2 (en) Data unit cloning in memory-based file systems
US9361187B2 (en) File system metadata capture and restore
US8407438B1 (en) Systems and methods for managing virtual storage disk data
Bailey et al. Exploring storage class memory with key value stores
US9058195B2 (en) Virtual machines failover
US10649897B2 (en) Access request processing method and apparatus, and computer device
US10452491B2 (en) Scalable log partitioning system
US11487706B2 (en) System and method for lazy snapshots for storage cluster with delta log based architecture
US9047221B2 (en) Virtual machines failover
US10445236B2 (en) Method to consistently store large amounts of data at very high speed in persistent memory systems
US11210319B2 (en) Replication progress for UPIT snapshots
US10409692B1 (en) Garbage collection: timestamp entries and remove reference counts
US20190079834A1 (en) Database Transaction Log Migration
US9892041B1 (en) Cache consistency optimization
US9785641B2 (en) Reducing a backup time of a backup of data files
KR20150053720A (ko) 논리 블록 주소의 아토믹 스왑 및 트림을 위한 swat 커맨드 및 애플리케이션 프로그래밍 인터페이스
US11960442B2 (en) Storing a point in time coherently for a distributed storage system
JP2019537097A (ja) Ｉノードのアクセスパターンの追跡及びｉノードの先取り
US11971825B2 (en) Managing granularity of a metadata structure for a storage system
WO2020105785A1 (ko) 스냅샷을 이용한 인메모리 데이터베이스의 데이터 처리 방법 및 인메모리 데이터베이스
US11200210B2 (en) Method of efficient backup of distributed file system files with transparent data access
Schindler Profiling and analyzing the I/O performance of NoSQL DBs
WO2021085717A1 (ko) 비휘발성 메모리를 이용한 로그 구조 병합 트리 기반의 데이터 베이스의 데이터 처리 방법
KR20190141371A (ko) 비휘발성 메모리를 이용한 인메모리 데이터베이스의 데이터 처리 방법 및 인메모리 데이터베이스

Legal Events

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

Ref document number: 18941055

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18941055

Country of ref document: EP

Kind code of ref document: A1