카우치베이스 서버 2.0의 압축 마법

카우치베이스의 추가 전용 스토리지 설계를 사용하면 업데이트가 파일의 끝 부분에만 진행되므로 데이터와 인덱스 파일이 손상될 수 없습니다. 제자리에서 파일을 업데이트하지 않으며 파일이 일관성 없는 상태가 되지 않습니다. 하지만 계속 확장되는 파일에 계속 쓰다 보면 결국 디스크 공간을 모두 차지하게 됩니다. 따라서 Couchbase 서버에는 압축이라는 프로세스가 있습니다. 압축은 오래된 데이터와 인덱스 값을 제거하여 디스크 공간을 정리함으로써 데이터와 인덱스 파일이 불필요하게 디스크 공간을 차지하지 않도록 합니다. 앱의 사용 사례가 대부분 읽기인 경우에는 괜찮을 수 있지만 쓰기 작업이 많은 워크로드가 있는 경우에는 Couchbase Server에서 자동 압축이 어떻게 작동하는지 알아볼 수 있습니다. 

설계상 Couchbase Server의 문서는 vBuckets(또는 파티션)으로 분할됩니다. 파티션당 데이터 파일('데이터 파일'), 디자인 문서당 여러 인덱스 파일(활성, 복제본 및 임시), 디자인 문서 및 보기 정의와 관련된 메타데이터가 있는 마스터 파일 등 여러 파일이 저장에 사용됩니다. 예를 들어, 아래 그림과 같이 Mac OSX에서 샘플 'gamesim' 버킷에는 다음이 포함됩니다. 64개의 개별 데이터 파일파티션당 하나씩(0.couch.1 ~ 63.couch.1), 디자인 문서 및 기타 뷰 메타데이터가 있는 마스터 파일(master.couch.1)이 있습니다.

 

카우치베이스 데이터 및 마스터 파일

인덱스 파일은 @indexes 폴더에 있으며 main_로 시작하는 활성 인덱스 파일, replica_로 시작하는 복제 인덱스 파일(인덱스 복제가 활성화된 경우), tmp_로 시작하는 인덱스 작성 및 업데이트 중에 사용되는 임시 파일로 구성됩니다.

카우치베이스 서버의 인덱스 파일

카우치베이스 서버의 데이터 및 인덱스 파일은 b-트리로 구성됩니다. 루트 노드(빨간색으로 표시됨)에는 중간 노드에 대한 포인터가 포함되어 있으며, 중간 노드에는 리프 노드(파란색으로 표시됨)에 대한 포인터가 포함되어 있습니다. 데이터 파일의 경우, 루트 노드와 중간 노드는 하위 트리 아래에 있는 문서의 크기를 추적합니다. 리프 노드는 문서 ID, 문서 메타데이터, 문서 콘텐츠에 대한 포인터를 저장합니다. 인덱스 파일의 경우, 루트 노드와 중간 노드는 출력된 맵 함수 결과와 하위 트리 아래의 축소 값을 추적합니다.

데이터 파일(왼쪽에 표시됨)과 인덱스 파일(오른쪽에 표시됨)을 위한 B-tree 스토리지

삽입, 업데이트, 삭제를 포함한 모든 변경 사항은 파일 끝에 기록되어 이전 데이터는 그대로 유지됩니다. 새 문서를 추가하시나요? b-트리가 끝에서 커집니다. 문서를 삭제하시나요? b-트리의 끝에 기록됩니다. 예를 들어, 아래 그림과 같이 문서 A가 변경된 후 문서 B가 변경되고 새 문서 D가 추가되고 문서 A에 또 다른 변경이 이루어진 경우, 이전 데이터는 아래 그림에서 빨간색 줄이 그어진 노드로 표시됩니다.

데이터 및 인덱스 파일을 위한 논리적 데이터 레이아웃

b-tree 파일 구조에서 루트 노드가 추적하는 문서의 크기를 검사하여 현재 파일 크기 대비 실제 크기의 비율을 계산합니다. 이 비율이 아래 그림과 같이 구성할 수 있는 특정 임계값에 도달하면 온라인 압축 프로세스가 트리거됩니다. 압축은 현재 데이터와 인덱스 파일을 스캔하고 정리할 항목 없이 새 데이터와 인덱스 파일을 만듭니다. 압축하는 동안 b-트리의 밸런스가 조정되고 새 트리에 대한 축소 값이 다시 계산됩니다. 또한 특정 노드에 속하지 않는 데이터도 정리됩니다.
마지막으로 압축하는 동안 이전 파티션 데이터 파일을 변경했을 수 있는 활성 워크로드를 따라잡기 위해, 압축 프로세스가 시작된 이후 추가된 데이터를 새 파티션 데이터 파일에 복사하여 최신 상태로 유지합니다. 새 인덱스 파일도 이러한 방식으로 업데이트됩니다. 그런 다음 이전 파티션 데이터 및 인덱스 파일이 삭제되고 새 데이터 및 인덱스 파일이 사용됩니다.
???일반적으로 압축은 전부 아니면 전무 작업이지만 카우치베이스의 압축은 파티션(v버킷) 단위로 이루어집니다.데이터 세트는 다음과 같을 수 있습니다. 점진적으로 압축 중단했을 때 변경한 내용을 그대로 유지합니다.

데이터 및 인덱스 파일의 설정 UI 탭에서 압축 임계값 구성하기

카우치베이스 서버의 압축은 온라인 운영. 기본적으로 조각화 임계값이 30%에 도달하면 자동 압축이 시작되지만 워크로드에 적합한 설정을 테스트하고 그에 따라 이 설정을 조정해야 합니다.

왜냐하면 압축은 리소스 집약적입니다. 를 사용하면 사용량이 많지 않은 시간대에 예약할 수도 있습니다. 데이터베이스 사용량이 많을 때 자동 압축이 수행되지 않도록 하려면 위에 표시된 UI를 사용하여 압축이 허용되는 사용량이 적은 시간대를 구성할 수 있습니다. 예를 들어, 여기서는 매일 오전 12시에서 새벽 1시 사이에 압축이 실행되도록 설정했습니다. 이 시간대에 압축 작업이 완료되지 않으면 압축 작업이 계속되지만 확인란을 선택하면 압축 작업을 중단할 수 있습니다.
아래 그림과 같이 버킷별 또는 디자인 문서별로 수동으로 압축을 트리거할 수도 있습니다.

Couchbase에서 수동으로 데이터 버킷 압축하기

Couchbase에서 디자인 문서 수동 압축하기

카우치베이스 서버의 압축 성능은 IO 용량과 적절한 클러스터 크기 조정. 클러스터는 필요한 수준의 성능을 유지하기 위해 시스템이 수행하는 다른 모든 작업을 지원할 수 있도록 다양한 영역에 충분한 용량을 확보할 수 있는 적절한 크기가 되어야 합니다. 그렇다면 카우치베이스 서버에서 압축을 어떻게 조정할 수 있을까요?
여기에는 마법의 총알이 없습니다... 애플리케이션의 IOPS 요구 사항에 따라 클러스터의 크기를 적절히 조정해야 하며 다양한 스토리지 하드웨어에서 워크로드를 테스트해야 할 수도 있습니다. 앱의 쓰기 비율이 높은 경우 SSD가 가장 적합할 수 있지만 읽기 비율이 높은 경우 EBS가 저렴한 비용으로 좋은 솔루션이 될 수 있습니다.
기본적으로 데이터 및 뷰 인덱스가 모두 자동 압축을 사용하도록 구성된 경우 압축은 먼저 데이터베이스에서, 그다음에 뷰에서 순차적으로 작동합니다. 병렬 압축을 사용하도록 설정하면 데이터베이스와 뷰를 동시에 압축할 수 있습니다. 이렇게 하면 더 많은 CPU 및 디스크 I/O가 필요하지만 데이터베이스와 뷰 인덱스가 서로 다른 물리적 디스크 장치에 저장되어 있는 경우(어쨌든 우리의 모범 사례와 마찬가지로)를 사용하면 인덱스와 데이터 파일이 지나치게 커지지 않도록 두 작업을 동시에 완료할 수 있습니다.
결론
결국 모든 데이터베이스는 정기적인 유지 관리가 필요합니다. 온라인 압축은 큰 장점이지만 시스템 부하에 영향을 미치지 않도록 시스템을 테스트하고 압축 설정을 적절하게 구성해야 합니다.
이 문서 공유하기
받은 편지함에서 카우치베이스 블로그 업데이트 받기
이 필드는 필수 입력 사항입니다.

작성자

게시자 카우치베이스 팀

의 선임 웹 관리자입니다. 웹 사이트 관리자로서 디자인, 구현, 콘텐츠 및 성능을 포함한 웹 사이트 자산에 대한 전반적인 책임을 맡고 있습니다.

댓글 하나

  1. 데이비드 밀리캉가스 1월 13, 2014에서 9:25 오전

    좋은 글입니다. 압축이 어떻게 작동하는지, 그리고 \"디스크 정리\"가 무엇인지 또는 같은 것인지에 대해 조금 더 자세히 설명해 주시겠습니까? 저희는 \"쓰기 집중\" 설치를 실행하고 있습니다. 하루에 16시간 동안 압축 작업을 실행하고 압축 프로세스를 중지하려는 \"오프 피크\"가 있다고 가정해 보겠습니다. 압축은 한 번에 하나의 vBucket에서 이루어지며, 16시간 동안 압축이 완료된 vBucket은 압축이 완료되고 다음 유지 관리 시 압축되지 않은 vBucket은 계속 진행되나요? 가장 파편화된 vBucket부터 압축을 시작할 수 있을까요?

  2. 안녕하세요 David,

    이 글을 읽어주셔서 감사드리며, 좋은 질문이 많았습니다.

    Q1 : 압축은 한 번에 하나의 vBucket으로 이루어지나요?

    예. 압축을 수행할 때 vBuckets을 하나씩 처리합니다.

    Q2 : 16시간 동안 압축이 완료된 vBuckets는 압축이 완료되며, 다음 유지보수 시 압축이 완료되지 않은 vBuckets는 계속 유지되나요?

    예, 압축이 다시 시작되면 압축이 멈춘 마지막 체크포인트에서 다시 시작하여 압축 프로세스를 계속합니다.

    Q3: 가장 파편화된 vBuckets부터 압축을 시작할 수 있나요?

    v버킷과 카우치베이스 클러스터에 무작위로 분산되어 있으며, 가장 일반적인 경우에는 거의 동일한 속도로 조각화가 누적되는 경향이 있습니다. 하나 이상의 vBucket이 더 조각화될 수 있는 최악의 시나리오에서는 단일 압축 패스로 조각화 수준을 균일화할 수 있습니다.

    도움이 되었기를 바랍니다!

    -Don

  3. "데이터베이스 및 뷰 인덱스가 서로 다른 물리적 디스크 장치에 저장됩니다."에 대해 자세히 설명해 주시겠습니까? 어떻게 구성할 수 있나요? 다른 장치에서 지속되도록 인덱스에 대한 심볼릭 링크를 만들려고 시도했지만 결국에는 뷰 조각화가 계속 증가했습니다. 들어오는 트래픽을 중지한 후에도 조회 조각화는 80%(조각화 임계값은 30%)로 스택이 쌓였습니다.

    감사합니다,
    Kostas

  4. [...] 디스크 파일을 압축하려면 어느 정도의 추가 디스크 IO가 필요합니다. 이 블로그는 압축을 이해하는 데 도움이 될 수 있습니다 [...].

  5. [...] 압축은 Couchbase의 애플릿 전용 아키텍처를 고려할 때 공간을 확보하기 위해 항상 실행되는 중요한 프로세스입니다. 또한 예약할 수도 있습니다. 여기에서 압축에 대해 자세히 알아보세요. [...]

댓글 남기기

카우치베이스 카펠라를 시작할 준비가 되셨나요?

구축 시작

개발자 포털에서 NoSQL을 살펴보고, 리소스를 찾아보고, 튜토리얼을 시작하세요.

카펠라 무료 사용

클릭 몇 번으로 Couchbase를 직접 체험해 보세요. Capella DBaaS는 가장 쉽고 빠르게 시작할 수 있는 방법입니다.

연락하기

카우치베이스 제품에 대해 자세히 알고 싶으신가요? 저희가 도와드리겠습니다.