3. 저장소와 검색

항상 주변을 단정히 정돈하는 사람은 단지 찾기를 너무 귀찮아하는 사람이다.

데이터베이스는 기본적으로 데이터를 저장하고 요청하는 기능을 제공합니다.

아래에서는 관계형 데이터베이스와 소위 NoSQL라 불리는 데이터베이스에 사용되는 저장소 엔진에 대해 설명합니다. 로그 구조(log-structured) 장소 엔진과 B-tree 같은 페이지 지향(page-oriented) 계열 저장소에 엔진에 대해 이야기합니다.

데이터베이스를 강력하게 만드는 데이터 구조#

많은 데이터베이스는 내부적으로 추가 적용 데이터 파일인 로그(log) 를 사용합니다.
색인을 통해서 데이터베이스에서 특정 키의 값을 효율적으로 찾습니다.
색인을 잘 쓰면 읽기 쓰기를 올릴 수 있으나, 모든 색인은 쓰기 속도를 떨어트립니다.

해시 색인#

키-값 저장소는 대부분의 프로그래밍 언어에서 볼 수 있는 사전 타입(dictionary type) 과 매우 유사합니다.
일반적으로 해시 색인을 구성하는 방법은 오프셋을 사용해서 저장하는 방식과 특정 크기의 세그먼트로 로그를 나누는 방식으로 나눠집니다.
- 오프셋을 사용하면 단순하지만, 키 값 갱신이 자주 일어날 때 장점을 가집니다. 그러나 용량에서 단점을 가집니다.
- 특정 크기의 세그먼트로 나누는 방식을 통해 컴팩션을 수행할 수 있습니다. 즉 최신 정보만 유지합니다.이 경우는 키 파일 오프셋 매핑 자체 인메모리 해시 테이블을 가집니다.

해시 색인의 추가 전용 로그 장점#

추가와 세그먼트 병합은 순차적인 쓰기 작업이기에 무작위 쓰기보다 빠릅니다.
세그먼트 파일이 추가 전용이거나 불변이면 동시성과 고장 복구가 훨씬 간단합니다.
오래된 세그먼트 병합은 시간이 지남에 따라 조각화되는 데이터 파일 문제를 피할 수 있습니다.

해시 색인의 단점#

해시 테이블은 메모리에 저장해야 하므로 키가 너무 많으며 문제가 됩니다.
해시 테이블은 범위 질의(range query)에 비효율적입니다.

SS테이블과 LSM 트리#

위와 같이 세그먼트는 최선 버전만 유지하고 추가적으로 키로 정렬한 형식을 정렬된 문자열 테이블(Sorted String Table) 혹은 SS테이블이라고 합니다.

SS테이블 생성과 유지#

디스크 상에 정렬된 구조를 유지하는 방법은 B트리, 레드 블랙 트리, AVL 트리등을 사용합니다.
저장소 엔진은 다음과 같이 만듭니다.
- 쓰기가 들어오면 위의 트리에 추가합니다. (이 인메모리 트리는 맴테이블, memtable 이라고 합니다.)
- 맴 테이블이 보통 수 메가바이트 정도의 임곗값 보다 커지면 SS테이블 파일로 디스크에 기록합니다.
- 읽기 요청을 제공하면 먼저 멤테이블에서 키를 찾은 후, 그 다음 디스크 상의 가장 최신 세그먼트에서 찾습니다.
- 읽기 요청을 제공시 맴테이블에서 키를 찾고 최신의 세그먼트에서 순서대로 찾습니다.
- 때로는 세그먼트 파일을 합치고 덮어 쓰거나 삭제된 값을 버리는 병합과 컴팩션 과정을 수행합니다.

SS테이블에서 LSM 트리 만들기#

위의 색인 구조는 로그 구조화 병합 트리(Log-Structured Merge-Tree, LSM 트리)입니다.
정렬된 파일 병합과 컴팩션 원리를 기반으로 하는 저장소 엔진을 LSM 저장소 엔진이라 부릅니다.
전문 색인은 키-값 색인보다 어려우며 키를 단어로 값은 단어를 포함한 모든 문서의 ID 목록으로 하는 키-값 구조로 구현합니다.

LSM 트리

LSM 트리

LSM 트리 출처

성능 최적화#

키가 존재하지 않는다는 사실을 확인하기 위해서는 오래된 세그먼트까지 봐야하는 수고가 있으므로 블룸 필터(Bloom filter) 를 추가적으로 사용합니다.
블룸 필터는 키가 데이터에비스에 존재하지 않음을 알려주므로 존재하지 않는 키를 위한 불필요한 디스크 읽기를 많이 절약할 수 있습니다.
SS 테이블을 압축하고 병합하는 순서와 시기를 결정하는 전략인 크기 계층(size-tiered) 와 레벨 컴팩션(lveled compaction) 가 있습니다.
- 레벨 컴팩션은 키 범위를 더 작은 SS테이블로 나누고 오래된 데이터는 개별 레벨로 이동하며 디스크 공간을 덜 사용합니다.
LSM 트리의 기본 개념은 데이터셋이 가능한 메모리보다 훨씬 더 크더라도 효과적이며 정렬되어 저장되어 있기 때문에 범위 질의를 효율적으로 실행하기에 높은 쓰기 처리량을 보장합니다.

B트리#

가장 보편적인 색인 구조입니다.
대부분의 관계형 데이터베이스에서 표준 색인 구현이며 비관계형 데이터베이스에서도 많이 사용합니다.
앞의 로그 구조화 색인은 데이터베이스를 수 메가바이트 이상의 가변 크기를 가진 세그먼트로 나눴다면 B트리는 4KB (혹은 더 큰) 크기의 고정 크기 블록이나 페이지로 나누고 한 번에 하나의 페이지에 읽기 또는 쓰기를 합니다.
한 페이지는 B 트리의 루트(root)로 지정되며 색인에서 키를 찾으려면 루트에서 시작합니다.
페이지는 여러 키와 하위 페이지의 참조를 포함합니다. 하위 페이지는 키가 계속 이어지는 범위를 담당하고 참조 사이의 키는 해당 범위 경계를 나타냅니다.
이러한 순서로 아래를 내려가며 개별 키(리프 페이지, leaf page) 를 포함하는 페이지에 도달합니다.
B 트리의 한 페이지에서 하위 페이지를 참조하는 수를 분기 계수(branching facotr) 라고 부릅니다.
B 트리에 존재하는 키의 값을 갱신하려면 키를 포함하고 있는 리프 페이지를 검색하고 페이지의 값을 바꾼 다음 페이지를 디스크에 다시 기록합니다.
이러한 알고리즘을 통해 트리는 계속 균형을 유지하고 깊이는 항상 O(log N)이 됩니다.

B 트리

B 트리

B 트리 출처

신뢰할 수 있는 B 트리 만들기#

B 트리의 기본적인 쓰기 동작은 새로운 데이터를 디스크 상의 페이지에 덮어씁니다.
페이지 관리를 잘못하면 고아 페이지(어떤 페이지와 부모 관계가 없는 페이지)가 생길 수 있습니다.
데이터베이스가 고장 상황에서 스스로 복구할려면 쓰기 로그(write-ahead log, WAL) 혹은 재실행 로그(redo log)라고 하는 데이터 구조를 사용합니다.
동시성 제어는 보통 래치(latch) 로 트리의 데이터 구조를 보호합니다.

B 트리 최적화#

페이지 덮어 쓰기와 고장 복구를 위한 WAL 유지보다 일부 데이터베이스는 쓰기 시 복사 방식을 사용합니다.
페이지에 전체 키를 저장하는 것이 아닌 키를 축약해 써서 공간을 절약합니다.
일반적으로 페이지는 디스크 상 어디에나 위치할 수 있습니다.
트리에 포인터를 추가합니다.
프랙탈 트리 등을 사용합니다.

B트리와 LSM 트리 비교#

B트리가 LSM 트리보다 일반적으로 구현 성숙도가 더 높으나 LSM 트리도 장점이 있습니다.
LSM트리는 보통 쓰기에서 더 빠른 반면 B트리는 읽기에서 더 빠르다고 여겨집니다.

LSM 트리의 장점#

B트리 색인은 모든 데이터 조각을 최소한 두 번 기록해야하며 몇바이트만 바뀌어도 한 번에 전체 페이지를 기록해야 하는 오버헤드가 있습니다. LSM도 비슷하지만, 순차적인 컴팩션된 SS테이블 파일만 씁니다.
일반적으로 LSM 트리는 보통 B 트리보다 쓰기 처리량을 높게 유지할 수 있습니다. (저장소 엔진 설정과 작업부하에 따라 다르나.)
LSM 트리는 압축률이 좋습니다. 그렇기 때문에 B트리보다 디스크에 더 적은 파일을 생성합니다.
데이터를 밀집해서 표현하면 I/O 대역폭 내에서 더 많은 읽기와 쓰기 요청이 가능합니다.

LSM 트리의 단점#

LSM의 단점은 컴팩션 과정이 때로는 진행 중인 읽기와 쓰기의 성능에 영향을 준다는 점입니다. (디스크의 자원이 한정적이기 때문에)
또 다른 컴팩션 문제로 높은 쓰기 처리량에서 발생하며 디스크의 쓰기 대역폭은 유한하기 때문에 발생합니다.
쓰기 처리량이 높더라도 컴팩션 설정을 주의 깊게 하지 않으면 컴팩션이 유입 쓰기 속도를 따라갈 수 없습니다.
B 트리의 장점은 각 키가 색인의 한 곳에만 정확하게 존재한다는 점입니다. 반면 LSM 저장소엔진은 다른 세그먼트에 같은 키의 다중 복사본이 존재할 수 있습니다.

B트리와 LSM 트리의 미래

B 트리는 데이터베이스 아키텍처에서 깊게 사용되고 있습니다. 그리고 많은 작업 부하에 대해 지속적으로 좋은 성능을 제공합니다. 그러나 새로운 데이터 저장소에서는 로그 구조화 색인이 인기를 얻고 있습니다.

기타 색인 구조#

앞에서는 키-값 색인을 살펴보았으며, 대표적인 예시는 관계형 모델의 기본키(primary key) 색인입니다.
보조 색인(secondary index) 를 사용하는 방식도 매우 일반적입니다.
보조 색인은 키-값 색인에서 쉽게 생성할 수 있으며 기본키 색인과의 주요 차이점은 키가 고유하지 않다는 점입니다. B트리나 로그 구조화 색인 둘다 사용가능합니다.

색인 안에 값 저장하기#

색인에서는 키는 질의가 검색하는 대상이지만 값은 실제 로우나 혹은 로우를 가리키는 참조인 2개로 나눠집니다.
후자의 경우는 로우가 저장된 곳을 힙 파일(heap file) 이라고 하고 특정 순서 없이 데이터를 저장합니다.
힙 파일 접근 방식은 키를 변경하지 않고 값을 갱신할 때 꽤 효율적입니다.
색인에서 힙 파일로 다시 이동하는 일은 읽기 성능에 불이익이 있으므로 색인에 바로 색인된 저장하는 경우가 바람직하며 이를 클러스터드 색인(clustered index) 이라고 합니다.
클러스터드 색인(색인 안에 모든 로우 데이터를 저장)과 비클러스터드 색인(색인 안에 데이터의 참조만 저장) 사이의 절충안을 커버링 색인(covering index) 이나 포괄열이 있는 색인(index with included column) 이라고 합니다. 이러한 색인은 색인 안에 테이블의 컬럼 일부를 저장합니다.
클러스터드 색인과 커버링 색인은 읽기 성능을 높일 수 있지만, 추가적인 저장소가 필요하고 쓰기 과정에 오버헤드가 발생합니다.

다중 칼럼 색인#

앞에서 나온 내용은 하나의 키만 값에 대응을 합니다. 다만 이 방식은 테이블의 다중 컬럼에 동시에 질의를 하는 경우 충분하지 않습니다.
다중 칼럼 색인의 가장 일반적인 유형은 결합 색인(concatenated index) 라고 합니다. (ex. (성, 이름)으로 키를 하기)
다차원 색인은 한 번에 여러 칼럼에 질의하는 조금 더 일반적인 방법입니다.

SELECT * FROM restaurants WHERE latitude > 51.4946 AND latitude < 51.56079 AND longitude > -0.1162 AND longitude < -0.1004;

B트리나 LSM 트리 색인은 이러한 유형의 질의에 효율적인 응답이 불가능합니다.
이를 해결하기 위한 방법은 이차원 위치를 공간 채움을 이용해 단일 숫자로 변환한 다음 일반 B트리 색인을 사용하는 것이며 일반적인 방법은 R트리처럼 전문 공간 색인(specialized spatial index)를 사용하는 것입니다.

전문 검색과 퍼지 색인#

위의 경우 유사 한 키에 대해서는 검색이 불가능합니다. 즉, 애매모호한(fuzzy) 질의에는 다른 기술이 필요합니다.
일반적으로 전문 검색 엔진은 특정 단어를 검색할 때 해당 단어의 동의어로 질의를 확장합니다. 또한 텍스트를 분석해 특정 편집 거리 등을 구현하는 경우도 있습니다.
- 루씬에서 인메모리 색인은 여러 키 내 문자에 대한 유한 상태 오토마톤으로 트라이(trie)와 유사하게 사용합니다.
- 그 외에도 문서 분류 및 머신러닝의 방향으로도 해결합니다.

모든 것을 메모리에 보관#

위에서 나온 데이터 구조는 모두 디스크 한계에 대한 해결책이었습니다. 디스크는 메인메모리와 비교해 다루기 어렵습니다.
HDD와 SDD를 사용할 때 읽기와 쓰기에서 좋은 성능을 원한다면 주의해서 데이터를 디스크에 배치해야합니다. 왜냐하면 디스크는 지속성과 비용에서의 장점이 있습니다.
그러나 현재는 램의 가격인하로 인메모리 데이터베이스가 등장하였으며 지속성을 목표로 합니다.
디스크 기록 방식은 쉽게 백업이 가능하고 외부 유틸리티를 이용해 검사와 분석이 가능하다는 장점이 있고, 인메모리는 성능의 장점을 가집니다.
- 대표적인 예시로 레디스와 카우치베이스는 비동기로 디스크에 기록하기 때문에 약한 지속성을 제공합니다.
인메모리 데이터베이스는 디스크 기반 색인으로는 구현하기 힘든 데이터 모델을 제공합니다. (redis는 우선순위 큐와 셋 등을 인터페이스로 제공합니다.)
안티 캐싱(anti-caching) 접근 방식은 메모리가 충분하지 않을 때 가장 최근에 사용하지 않은 데이터를 메모리에서 디스크로 내보내고 나중에 다시 접근할 때 메모리에 적재하는 방식으로 동작합니다.

트랜잭션 처리나 분석#

초기 비지니스 데이터 쓰기는 커머셜 트랜잭션(commercial transaction, 상거래)에 해당했습니다.
현재는 데이터베이스가 확장되었으나 트랜잭션이란 용어는 변하지 않고 논리 단위 형태로 사용되고 있습니다.
트랜잭션이 반드시 ACID 속성을 가질 필요는 없습니다.
트랜잭션 처리의 의미는 배치와 달리 클라이언트가 지연 시간(low-latency)가 낮은 읽기와 쓰기를 가능하게 한다는 의미입니다.
레코드는 사용자 입력을 기반으로 삽입되고 갱신하며 이러한 대화식 접근 패턴을 온라인 트랜잭션(OLTP, online transaction processing) 이라고 합니다.
데이터 분석(data analytic)은 일반적인 트랜잭션과 접근 패턴이 다르며 회사 경영진이 더 나은 의사결정을 하도록 돕게하는 보고서를 제공합니다.(비지니스 인텔리전스, business intelligence) 이러한 사용 패턴을 온라인 분석 처리(OLAP, online analytic processing) 라고 합니다.

특성	트랜잭션 처리 시스템(OLTP)	분석 시스템(OLAP)
주요 읽기 패턴	질의당 적은 수의 레코드, 키 기준	많은 레코드에 대한 집계
주요 쓰기 패턴	임의 접근, 사용자 입력을 낮은 지연 시간으로 기록	대규모 불러오기 혹은 이벤트 스트림
주요 사용처	웹 애플리케이션을 통한 최종 사용자/소비자	의사결정 지원을 위한 내부 분석가
데이터 표현	데이터의 최신 상태(현재 시점)	시간이 지나며 일어난 이벤트 이력
데이터셋 크기	GB ~ TB	TB ~ PB

OLTP르 시스템을 분석 목적으로 사용하지 않고 개별데이터에서 분석하는데 이러한 개별 데이터베이스를 데이터 웨어하우스(data warehouse) 라고 합니다.

데이터 웨어하우징#

기업은 수십 가지의 트랜잭션 처리 시스템을 가지고 있습니다.
OLTP 시스템은 대개 사업 운영에 대단히 중요하기 때문에 일반적으로 높은 가용성과 낮은 지연 시간의 트랜잭션 처리를 기대합니다.
데이터 웨어하우스는 분석가들이 OLTP 작업에 영향을 주지 않고 마음껏 질의할 수 있는 개별 데이터베이스이며 일반적으로 OLTP 시스템의 읽기 전용 복사본입니다.
데이터베 웨어하우스로 데이터를 가져오는 과정을 ETL(Extract-Transform-Load) 라고 하며 데이터베이스에서 추출-스키마로 변환-웨어하우스에 적재 하는 순으로 진행됩니다.

OLTP 데이터베이스와 데이터 웨어하우스의 차이점#

SQL은 일반적으로 분석 질의에 적합하므로 데이터 모델은 일반적인 관계형 모델을 사용합니다.
데이터를 작업(drill-down, slicing, dicing과 같은 작업)을 통해데이터를 탐색할 수 있게 해주는 여러 그래픽 데이터 분석 도구가 있습니다.
대표적인 예시로 Hadoop, Apache Hive, Spark SQL 등이 있습니다.

분석용 스키마: 별 모양 스키마와 눈꽃송이 모양 스키마#

데이터 모델은 트랜잭션 처리 영역에서 애플리케이션의 필요에 따라 광범위하고 다양하게 사용되나, 분석에서는 데이터 모델이 다양하지 않습니다.
많은 경우 별 모양 스키마(star schema)(차원 모델링, dimensional modeling)이라고 불리는 상당히 정형화된 방식을 사용합니다.
별 모양 스키마란 이름은 테이블 관계가 시각화 될 때 사실 테이블이 가운3데에 있고 차원 테이블로 둘러싸고 있다는 사실에서 비록됩니다.
별 모양 스키마의 템플릿 변형을 눈꽃송이 모양 스키마(snowflake schema)라고 하며 차원이 하위 차원으로 더 분리가 됩니다.
일반적인 데이터 웨어하우스에서 테이블은 보통 폭이 작습니다.

칼럼 지향 저장소#

테이블에 데이터가 너무 많으면 효율적으로 저장하고 질의하기 어렵습니다.
일반적인 데이터 웨어하우스 질의는 한번에 4개 혹은 5컬럼을 질의합니다.
ex) 사람들이 요일에 따라 신선 과일을 사고 싶어하는지 사탕을 더 사고 싶어하는지 분석

SELECT
  dim_date.weekday, dim_product.category,
  SUM(fact_sales.quantity) AS quantity_sold
FROM fact_sales
  JOIN dim_date   ON fact_sales.date_key = dim_date.date_key
  JOIN dim_product ON fact_sales.product_sk = dim_product.product_sk
WHERE
  dim_date.year = 2013 AND
  dim_product.category IN ('Fresh fruit', 'Candy')
GROUP BY
  dim_date.weekday, dim_product.category;

대부분의 OLTP 데이터베이스에서 저장소는 로우 지향 방식으로 데이터를 배치합니다.
칼럼 지향 저장소의 기본 개념은 간단하며 모든 값을 하나의 로우에 함께 저장하지 않는 대신 각 칼럼별로 모든 값을 함께 저장합니다.
칼럼 파일에 포함된 로우는 모두 같은 순서에 의존이고 로우 전체를 모을 때는 형태로 함께 모아 구성합니다.

date_key file contents    140102, 140102, ...
product_sk file contents  69, 69, ...
store_sk file contents    4, 5, ...
...

칼럼 압축#

칼럼 지향 저장소는 대개 압축에 적합합니다.
대표적인 예시로 비트맵 부호화(bitmap encoding) 이 있습니다.
비트맵 색인은 데이터 웨어하우스에서 일반적으로 사용되는 질의 종류에 매우 적합합니다.

칼럼 지향 저장소와 칼럼 패밀리

카산드라와 HBase는 빅테이블로부터 내려오는 칼럼 패밀리 개념이 있습니다.
각 칼럼 패밀리 안에는 로우 키에 따라 로우와 모든 칼럼을 함께 저장하며 칼럼 압축을 사용하지 않습니다.

메모리 대역폭과 벡터화 처리#

수백만 로우를 스캔해야 하는 데이터 웨어하우스 질의는 디스크로부터 메모리로 데이터를 가져오는 대역폭이 큰 병목입니다.
디스크로부터 적재한 데이터 양 줄이기 외에도 칼럼 저장소 배치는 CPU 주기를 효율적으로 사용하기에 적합합니다.
칼럼 압축을 통해 L1 캐시에 더 많은 로우를 저장하고, 비트 AND와 OR 같은 연산자를 통해 압축된 칼럼 데이터 덩어리를 많이 연산할 수 있습니다. 이를 벡터화 처리(vectorized processing) 이라고 합니다.

칼럼 저장소의 순서 정렬#

칼럼 저장소에서 로우가 저장되는 순서가 반드시 중요하지 않습니다.
각 칼럼을 독립적으로 정렬할 수 없습니다.
칼럼별로 저장되더라도 데이터는 한번에 전체 로우를 정렬해야합니다.
정렬된 순서의 장점은 질의에 도움이 되며 칼럼 압축에 도움이 됩니다.
이러한 압축은 첫 번째 정렬 키에서 가장 강력합니다.

다양한 순서 정렬#

칼럼 지향 저장에서 여러 정렬 순서를 갖는 것은 로우 지향 저젱서 여러 2차 색인을 갖는 것과 약간 비슷합니다.
컬럼 저장에서는 일반적으로 데이터를 가리키는 포인터가 없고, 단지 값을 포함한 칼럼만 존재합니다.

칼럼 지향 저장소에 쓰기#

데이터 웨어하우스에서 이런 최적화는 합리적입니다.
질의는 디스크의 칼럼 데이터와 메모리의 최근 쓰기를 모두 조사해 두 가지를 결합해야합니다.

집계: 데이터 큐브와 구체화 뷰#

모든 데이터 웨어하우스가 칼럼 저장이 필수는 아닙니다.
데이터 웨어하우스의 다른 측면으로 구체화 집계(materialized aggregate)
이런 캐시를 만드는 한 가지 방법이 구체화 뷰(materialized view) 입니다.
데이터 큐브(data cube) 또는 OLAP 큐브 라고 알려진 구체화 뷰는 일반화된 구체화 뷰의 특별 사례입니다.
구체화 뷰는 특정 질의를 효과적으로 미리 계산했기 때문에 해당 질의를 수행할 필요없이 매우 빠릅니다.
데이터 큐브의 단점은 원시 데이터에 질의하는 것과 동일한 유연성이 없습니다.

정리#

고소준에서 저장소 엔진은 트랜잭션 처리 최적화(OLTP) 와 분석 최적화(OLAP) 라는 큰 두가지 범주로 나뉩니다.

트랜잭션 처리 최적화(OLTP)
- OLTP 시스템은 보통 사용자 대면이기 때문에 대량의 요청을 받을 수 있습니다.
- 부하를 처리하기 위해 보통 애플리케이션이 각 질의마다 작은 수의 레코드만 다룹니다.
- 애플리케이션은 키의 일부만 사용하는 레코드를 요청하고 저장소 엔진은 요청한 키의 데이터를 찾기 위해 색인을 사용합니다. (이 경우는 디스크 탐색이 병목입니다.)
분석 최적화(OLAP)
- 데이터 웨어하우스와 유사한 분석 시스템은 적은 질의를 다루지만 질의는 매우 다루기 어렵고, 짧은 시간에 레코드를 스캔해야합니다.
- 일반적으로 디스크 대역폭이 병목입니다.
- 칼럼 지향 저장소가 주로 사용됩니다.
OLTP 측면에서는 다음의 두가지 중요한 관점이 있습니다.
- 로그 구조화 관점에서 파일에 추가와 오래된 파일의 삭제만 허용하고 한 번 쓰여진 파일은 절대 갱신하지 않습니다. (비트캐스크, SS테이블, LSM 트리, 레벨DB, 카산드라, HBase, 루씬 등)
- 제자리 갱신 관점에서 덮었긔 할 수 잇는 고정 크기 페이지의 셋으로 디스크를 다룹니다. 이 관점에서 가장 큰 예가 B트리입니다.

로그 구조화 저장소 엔진은 비교적 최근에 개발됩니다. 핵심 내용은 임의 접근 쓰기를 체계적으로 디스크에 순차 쓰기로 바꿉니다. 하드디스크와 SSD의 성능 특성에 맞춰 쓰기 처리량을 높이는 것이 가능합니다.