Apache Ignite의 데이터 압축. 스베르의 경험

대용량 데이터를 작업할 때 디스크 공간 부족 문제가 발생할 수 있습니다. 이 문제를 해결하는 한 가지 방법은 압축입니다. 덕분에 동일한 장비에서 저장 용량을 늘릴 수 있습니다. 이 기사에서는 Apache Ignite에서 데이터 압축이 어떻게 작동하는지 살펴보겠습니다. 이 문서에서는 제품 내에 구현된 디스크 압축 방법만 설명합니다. 구현 여부에 관계없이 다른 데이터 압축 방법(네트워크를 통해, 메모리에서)은 범위를 벗어납니다.

따라서 지속성 모드가 활성화되면 캐시의 데이터 변경으로 인해 Ignite가 디스크에 쓰기를 시작합니다.

1. 캐시 내용
2. 미리 쓰기 로그(이하 간단히 WAL)

WAL 압축이라는 WAL 압축 메커니즘이 꽤 오랫동안 존재해 왔습니다. 최근 출시된 Apache Ignite 2.8에는 디스크의 데이터를 압축할 수 있는 두 가지 메커니즘이 추가로 도입되었습니다. 캐시 콘텐츠를 압축하기 위한 디스크 페이지 압축과 일부 WAL 항목을 압축하기 위한 WAL 페이지 스냅샷 압축입니다. 이 세 가지 메커니즘 모두에 대한 자세한 내용은 아래를 참조하세요.

디스크 페이지 압축

이거 어떻게 작동 시켜요

먼저 Ignite가 데이터를 저장하는 방법을 간단히 살펴보겠습니다. 페이지 메모리는 저장에 사용됩니다. 페이지 크기는 노드 시작 시 설정되며 이후 단계에서 변경할 수 없습니다. 또한 페이지 크기는 XNUMX의 거듭제곱과 파일 시스템 블록 크기의 배수여야 합니다. 페이지는 필요에 따라 디스크에서 RAM으로 로드됩니다. 디스크의 데이터 크기가 할당된 RAM의 양을 초과할 수 있습니다. RAM에 디스크에서 페이지를 로드할 공간이 충분하지 않으면 오래되고 더 이상 사용되지 않는 페이지가 RAM에서 제거됩니다.

데이터는 다음과 같은 형태로 디스크에 저장됩니다: 각 캐시 그룹의 각 파티션에 대해 별도의 파일이 생성되고, 이 파일에서 페이지는 오름차순 인덱스 순서로 차례로 나타납니다. 전체 페이지 식별자에는 파일의 캐시 그룹 식별자, 파티션 번호 및 페이지 인덱스가 포함됩니다. 따라서 전체 페이지 식별자를 사용하면 각 페이지에 대한 파일과 파일의 오프셋을 고유하게 결정할 수 있습니다. Apache Ignite Wiki 기사에서 페이징 메모리에 대한 자세한 내용을 읽을 수 있습니다. Ignite Persistent Store - 내부적으로.

이름에서 짐작할 수 있듯이 디스크 페이지 압축 메커니즘은 페이지 수준에서 작동합니다. 이 메커니즘이 활성화되면 RAM의 데이터는 압축 없이 있는 그대로 처리되지만 페이지가 RAM에서 디스크로 저장되면 압축됩니다.

그러나 각 페이지를 개별적으로 압축하는 것은 문제에 대한 해결책이 아니며 결과 데이터 파일의 크기를 어떻게든 줄여야 합니다. 페이지 크기가 더 이상 고정되지 않으면 더 이상 파일에 페이지를 차례로 쓸 수 없습니다. 이로 인해 여러 가지 문제가 발생할 수 있기 때문입니다.

• 페이지 인덱스를 사용하면 파일에서 해당 페이지가 위치한 오프셋을 계산할 수 없습니다.
• 파일 끝에 있지 않고 크기가 변경된 페이지를 어떻게 처리해야 하는지 명확하지 않습니다. 페이지 크기가 줄어들면 확보된 공간도 사라집니다. 페이지 크기가 커지면 파일에서 새 위치를 찾아야 합니다.
• 페이지가 파일 시스템 블록 크기의 배수가 아닌 바이트 수만큼 이동하는 경우 페이지를 읽거나 쓰려면 파일 시스템 블록을 하나 더 터치해야 하므로 성능이 저하될 수 있습니다.

자체 수준에서 이러한 문제를 해결하지 않기 위해 Apache Ignite의 디스크 페이지 압축은 스파스 파일이라는 파일 시스템 메커니즘을 사용합니다. 희소 파일은 XNUMX으로 채워진 일부 영역을 "구멍"으로 표시할 수 있는 파일입니다. 이 경우 이러한 홀을 저장하기 위해 파일 시스템 블록이 할당되지 않으므로 디스크 공간이 절약됩니다.

파일 시스템 블록을 해제하려면 구멍의 크기가 파일 시스템 블록보다 크거나 같아야 하며, 이는 페이지 크기 및 Apache Ignite에 추가 제한을 적용하는 것이 논리적입니다. 페이지 크기는 반드시 파일 시스템 블록의 크기보다 커야 합니다. 페이지 크기가 블록 크기와 같은 경우 단일 블록을 해제하려면 압축된 페이지가 0바이트를 차지해야 하므로 단일 블록을 해제할 수 없습니다. 페이지 크기가 2 또는 4 블록 크기와 같을 경우 페이지가 각각 최소 50% 또는 75%로 압축되면 이미 최소 하나의 블록을 확보할 수 있습니다.

따라서 메커니즘 작동 방식에 대한 최종 설명은 다음과 같습니다. 페이지를 디스크에 쓸 때 페이지를 압축하려고 시도합니다. 압축된 페이지의 크기로 인해 하나 이상의 파일 시스템 블록을 해제할 수 있는 경우 페이지는 압축된 형식으로 기록되고 해제된 블록 대신 "구멍"이 생성됩니다(시스템 호출이 실행됨) fallocate() 펀치 홀 플래그 포함). 압축된 페이지의 크기로 인해 블록을 해제할 수 없는 경우 페이지는 압축되지 않은 상태로 저장됩니다. 모든 페이지 오프셋은 페이지 색인에 페이지 크기를 곱하여 압축하지 않은 것과 동일한 방식으로 계산됩니다. 페이지를 직접 재배치할 필요가 없습니다. 압축하지 않은 경우와 마찬가지로 페이지 오프셋은 파일 시스템 블록의 경계에 속합니다.

현재 구현에서 Ignite는 Linux OS의 스파스 파일에 대해서만 작동할 수 있습니다. 따라서 디스크 페이지 압축은 이 운영 체제에서 Ignite를 사용할 때만 활성화할 수 있습니다.

디스크 페이지 압축에 사용할 수 있는 압축 알고리즘: ZSTD, LZ4, Snappy. 또한, 나머지 데이터를 압축하지 않고 페이지 내 사용되지 않은 공간만 버리는 동작 모드(SKIP_GARBAGE)가 있어 앞서 나열된 알고리즘에 비해 CPU 부하가 줄어든다.

성능에 미치는 영향

불행하게도 우리는 이 메커니즘을 생산에 사용할 계획이 없기 때문에 실제 스탠드에서 실제 성능 측정을 수행하지 않았지만 이론적으로 우리가 잃을 곳과 이길 곳을 추측할 수 있습니다.

이렇게 하려면 액세스할 때 페이지를 읽고 쓰는 방법을 기억해야 합니다.

• 읽기 작업을 수행할 때 먼저 RAM에서 검색되고, 검색에 실패하면 읽기를 수행하는 동일한 스레드에 의해 페이지가 디스크에서 RAM으로 로드됩니다.
• 쓰기 작업이 수행되면 RAM의 페이지는 더티로 표시되지만 쓰기를 수행하는 스레드에 의해 페이지가 디스크에 즉시 저장되지는 ​​않습니다. 모든 더티 페이지는 나중에 체크포인트 프로세스에서 별도의 스레드로 디스크에 저장됩니다.

따라서 읽기 작업에 미치는 영향은 다음과 같습니다.

• 양수(디스크 IO), 읽기 파일 시스템 블록 수가 감소했기 때문입니다.
• 희소 파일 작업을 위해 운영 체제에 필요한 추가 로드로 인해 네거티브(CPU)입니다. 더 복잡한 희소 파일 구조를 저장하기 위해 추가 IO 작업이 여기에 암시적으로 나타날 수도 있습니다(불행히도 저는 희소 파일이 작동하는 방식에 대한 모든 세부 정보를 잘 모릅니다).
• 페이지 압축을 풀어야 하기 때문에 네거티브(CPU)입니다.
• 쓰기 작업에는 영향이 없습니다.
• 체크포인트 프로세스에 미치는 영향(여기서 모든 것은 읽기 작업과 유사합니다):
• 양수(디스크 IO), 기록된 파일 시스템 블록 수가 감소했기 때문입니다.
• 희소 파일 작업으로 인해 부정(CPU, 디스크 IO 가능).
• 네거티브(CPU), 페이지 압축이 필요하기 때문입니다.

저울의 어느 쪽이 저울을 기울게 합니까? 이 모든 것은 환경에 따라 크게 다르지만 디스크 페이지 압축이 대부분의 시스템에서 성능 저하로 이어질 가능성이 높다고 생각합니다. 또한 스파스 파일과 유사한 접근 방식을 사용하는 다른 DBMS에 대한 테스트에서는 압축이 활성화되면 성능이 저하되는 것으로 나타났습니다.

활성화 및 구성 방법

위에서 언급했듯이 디스크 페이지 압축을 지원하는 Apache Ignite의 최소 버전은 2.8이며, Linux 운영체제만 지원합니다. 다음과 같이 활성화하고 구성합니다.

• 클래스 경로에 ignite-compression 모듈이 있어야 합니다. 기본적으로 이는 libs/ional 디렉토리의 Apache Ignite 배포판에 있으며 클래스 경로에는 포함되지 않습니다. 디렉터리를 libs로 한 수준 위로 이동한 다음 ignite.sh를 통해 실행하면 자동으로 활성화됩니다.
• 지속성을 활성화해야 합니다(다음을 통해 활성화됨). DataRegionConfiguration.setPersistenceEnabled(true)).
• 페이지 크기는 파일 시스템 블록 크기보다 커야 합니다(다음을 사용하여 설정할 수 있음). DataStorageConfiguration.setPageSize() ).
• 데이터를 압축해야 하는 각 캐시에 대해 압축 방법과 (선택적으로) 압축 수준(방법)을 구성해야 합니다. CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).

WAL 압축

이거 어떻게 작동 시켜요

WAL은 무엇이며 왜 필요한가요? 매우 간략하게 설명하면 이는 궁극적으로 페이지 저장 공간을 변경하는 모든 이벤트를 포함하는 로그입니다. 주로 넘어졌을 때 회복할 수 있도록 하는 것이 필요합니다. 모든 작업은 사용자에게 제어권을 주기 전에 먼저 WAL에 이벤트를 기록해야 합니다. 그래야 실패할 경우 로그에서 재생할 수 있고 사용자가 성공적인 응답을 받은 모든 작업을 복원할 수 있습니다. 디스크의 페이지 저장소에 반영될 시간이 없었습니다(이미 페이지 저장소에 대한 실제 쓰기는 별도의 스레드에 의해 약간의 지연이 있는 "체크포인팅"이라는 프로세스에서 수행된다고 설명했습니다).

WAL의 항목은 논리적 항목과 물리적 항목으로 구분됩니다. 부울은 키와 값 자체입니다. 물리적 - 페이지 저장소의 페이지 변경 사항을 반영합니다. 논리적 레코드는 일부 다른 경우에 유용할 수 있지만 물리적 레코드는 충돌 시 복구에만 필요하며 레코드는 마지막 성공적인 체크포인트 이후에만 필요합니다. 여기서는 이것이 왜 이런 식으로 작동하는지 자세히 설명하지 않겠습니다. 관심 있는 분들은 Apache Ignite Wiki에서 이미 언급한 기사를 참조하세요. Ignite Persistent Store - 내부적으로.

논리적 레코드당 여러 개의 물리적 레코드가 있는 경우가 많습니다. 즉, 예를 들어 캐시에 대한 한 번의 넣기 작업은 페이지 메모리의 여러 페이지(데이터 자체가 있는 페이지, 인덱스가 있는 페이지, 사용 가능 목록이 있는 페이지)에 영향을 미칩니다. 일부 종합 테스트에서 물리적 기록이 WAL 파일의 최대 90%를 차지하는 것으로 나타났습니다. 그러나 매우 짧은 시간 동안만 필요합니다(기본적으로 체크포인트 간 간격은 3분입니다). 관련성을 잃은 후 이 데이터를 제거하는 것이 논리적입니다. 이것이 바로 WAL 압축 메커니즘이 수행하는 작업입니다. 물리적 레코드를 제거하고 zip을 사용하여 나머지 논리적 레코드를 압축하는 동시에 파일 크기가 매우 크게(때로는 수십 배까지) 줄어듭니다.

물리적으로 WAL은 고정된 크기(기본적으로 10MB)의 여러 세그먼트(기본적으로 64개)로 구성되며 순환 방식으로 덮어쓰여집니다. 현재 세그먼트가 채워지자마자 다음 세그먼트가 현재 세그먼트로 할당되고 채워진 세그먼트는 별도의 스레드에 의해 아카이브에 복사됩니다. WAL 압축은 이미 아카이브 세그먼트에서 작동합니다. 또한 별도의 스레드로서 체크포인트 실행을 모니터링하고 물리적 레코드가 더 이상 필요하지 않은 아카이브 세그먼트에서 압축을 시작합니다.

성능에 미치는 영향

WAL 압축은 별도의 스레드로 실행되므로 수행되는 작업에 직접적인 영향을 미치지 않습니다. 하지만 여전히 CPU(압축)와 디스크(아카이브에서 각 WAL 세그먼트를 읽고 압축된 세그먼트에 쓰기)에 추가 백그라운드 로드가 발생하므로 시스템이 최대 용량으로 실행되는 경우 성능 저하도 발생합니다.

활성화 및 구성 방법

속성을 사용하여 WAL 압축을 활성화할 수 있습니다. WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). 또한, 기본값(BEST_SPEED)에 만족하지 못할 경우 DataStorageConfiguration.setWalCompactionLevel() 메소드를 사용하여 압축 수준을 설정할 수 있습니다.

WAL 페이지 스냅샷 압축

이거 어떻게 작동 시켜요

우리는 이미 WAL 레코드가 논리적 레코드와 물리적 레코드로 구분된다는 것을 알아냈습니다. 각 페이지가 변경될 때마다 물리적 WAL 레코드가 페이지 메모리에 생성됩니다. 물리적 레코드도 페이지 스냅샷 레코드와 델타 레코드라는 2가지 하위 유형으로 나뉩니다. 페이지의 내용을 변경하고 클린 상태에서 더티 상태로 전환할 때마다 이 페이지의 전체 복사본이 WAL(페이지 스냅샷 레코드)에 저장됩니다. WAL에서 90바이트만 변경하더라도 레코드는 페이지 크기보다 약간 더 커집니다. 이미 더티 페이지에서 무언가를 변경하면 WAL에 델타 레코드가 형성됩니다. 이는 페이지의 이전 상태와 비교한 변경 사항만 반영하고 전체 페이지는 반영하지 않습니다. 페이지 상태를 더티에서 클린으로 재설정하는 작업은 체크포인트 프로세스 중에 수행되므로 체크포인트 시작 직후에는 거의 모든 물리적 레코드가 페이지의 스냅샷으로만 구성됩니다(체크포인트 시작 직후의 모든 페이지는 클린이므로). , 다음 체크포인트에 접근하면 델타 레코드 부분이 커지기 시작하고 다음 체크포인트 시작 부분에서 다시 재설정됩니다. 일부 종합 테스트에서 측정한 결과 전체 물리적 기록에서 페이지 스냅샷이 차지하는 비중이 XNUMX%에 달하는 것으로 나타났습니다.

WAL 페이지 스냅샷 압축의 개념은 기성 페이지 압축 도구를 사용하여 페이지 스냅샷을 압축하는 것입니다(디스크 페이지 압축 참조). 동시에 WAL에서는 레코드가 추가 전용 모드로 순차적으로 저장되며 레코드를 파일 시스템 블록의 경계에 바인딩할 필요가 없으므로 여기서는 디스크 페이지 압축 메커니즘과 달리 스파스 파일이 필요하지 않습니다. 따라서 이 메커니즘은 Linux OS에서만 작동하는 것이 아닙니다. 또한 페이지를 얼마나 압축할 수 있었는지는 더 이상 중요하지 않습니다. 1바이트를 해제하더라도 이는 이미 긍정적인 결과이며, 1개 이상의 파일 시스템 블록을 해제한 경우에만 압축된 페이지를 저장하는 디스크 페이지 압축과 달리 WAL에 압축된 데이터를 저장할 수 있습니다.

페이지는 압축률이 높은 데이터이고 전체 WAL 볼륨에서 차지하는 비율이 매우 높으므로 WAL 파일 형식을 변경하지 않고도 크기를 크게 줄일 수 있습니다. 논리적 레코드를 포함한 압축에는 형식 변경과 호환성 손실이 필요합니다. 예를 들어 논리적 레코드에 관심이 있을 수 있지만 파일 크기가 크게 줄어들지는 않는 외부 소비자의 경우입니다.

디스크 페이지 압축과 마찬가지로 WAL 페이지 스냅샷 압축은 ZSTD, LZ4, Snappy 압축 알고리즘과 SKIP_GARBAGE 모드를 사용할 수 있습니다.

성능에 미치는 영향

WAL 페이지 스냅샷 압축을 직접 활성화하면 페이지 메모리에 데이터를 쓰는 스레드, 즉 캐시에서 데이터를 변경하는 스레드에만 영향을 미친다는 사실을 아는 것은 어렵지 않습니다. WAL에서 물리적 레코드를 읽는 것은 노드가 추락 후 올라가는 순간(그리고 체크포인트 중에 떨어지는 경우에만) 한 번만 발생합니다.

이는 다음과 같은 방식으로 데이터를 변경하는 스레드에 영향을 미칩니다. 디스크에 쓰기 전에 매번 페이지를 압축해야 하기 때문에 부정적인 효과(CPU)를 얻고, 작성된 데이터입니다. 따라서 여기에서는 모든 것이 간단합니다. 시스템 성능이 CPU에 의해 제한되면 약간 저하되고, 디스크 I/O에 의해 제한되면 증가합니다.

간접적으로 WAL 크기를 줄이는 것은 WAL 세그먼트를 아카이브 및 WAL 압축 스트림으로 덤프하는 스트림에도 (긍정적으로) 영향을 미칩니다.

합성 데이터를 사용한 우리 환경의 실제 성능 테스트에서는 약간의 증가가 나타났습니다(처리량 10%-15% 증가, 대기 시간 10%-15% 감소).

활성화 및 구성 방법

최소 Apache Ignite 버전: 2.8. 다음과 같이 활성화하고 구성합니다.

• 클래스 경로에 ignite-compression 모듈이 있어야 합니다. 기본적으로 이는 libs/ional 디렉토리의 Apache Ignite 배포판에 있으며 클래스 경로에는 포함되지 않습니다. 디렉터리를 libs로 한 수준 위로 이동한 다음 ignite.sh를 통해 실행하면 자동으로 활성화됩니다.
• 지속성을 활성화해야 합니다(다음을 통해 활성화됨). DataRegionConfiguration.setPersistenceEnabled(true)).
• 압축 모드는 다음 메소드를 사용하여 설정해야 합니다. DataStorageConfiguration.setWalPageCompression(), 압축은 기본적으로 비활성화됩니다(DISABLED 모드).
• 선택적으로 다음 메소드를 사용하여 압축 수준을 설정할 수 있습니다. DataStorageConfiguration.setWalPageCompression(), 각 모드에 유효한 값에 대한 방법은 javadoc을 참조하세요.

결론

Apache Ignite에서 고려된 데이터 압축 메커니즘은 서로 독립적으로 사용될 수 있지만 이들의 조합도 허용됩니다. 작동 방식을 이해하면 해당 환경에서 작업에 얼마나 적합한지, 사용할 때 무엇을 희생해야 하는지 결정할 수 있습니다. 디스크 페이지 압축은 주 저장소를 압축하도록 설계되었으며 중간 압축 비율을 제공할 수 있습니다. WAL 페이지 스냅샷 압축은 WAL 파일에 대한 평균 압축 수준을 제공하며 성능도 향상시킬 가능성이 높습니다. WAL 압축은 성능에 긍정적인 영향을 미치지 않지만 물리적 레코드를 제거하여 WAL 파일의 크기를 최대한 줄입니다.

출처 : habr.com