두 가지 배출 방법 이야기: 가치 전용 대 전체

소개

이 글에 큰 도움을 주고 제 모든 질문에 대해 끝없는 인내심을 보여준 Couchbase Server 엔지니어링 팀, 특히 Dave Rigby와 Jim Walker에게 감사의 말씀을 전하고 싶습니다. 방대한 지식과 이를 기꺼이 공유해 주셔서 정말 감사합니다!

카우치베이스 서버에서 데이터는 버킷에 저장됩니다. 기본 버킷 유형 - 창의적으로 호출되지 않은 카우치베이스 유형 - 디스크에 비동기식 데이터 지속성을 보장합니다. 서버는 모든 데이터(활성 세트 및 복제본 세트)를 메모리에 저장하려고 시도합니다. 그러나 인메모리 데이터가 버킷 메모리 할당량의 85%에 도달하면(이 수준을 하이 워터 마크)을 초과하면 서버는 최근 사용하지 않은 문서 중 일부를 메모리에서 꺼내기(퇴출)하기 시작합니다. 활성 문서는 401조분의 3의 확률로, 복제 문서는 601조분의 3의 확률로 퇴출됩니다. 그 이유는 다음과 같습니다. 활성 문서를 메모리에 상주시키는 것이 더 중요하지만, 노드가 장애 조치되어 복제본이 활성 상태가 되어야 할 경우를 대비해 복제본 문서도 메모리에 일부 남겨두어야 하기 때문입니다. 퇴거 프로세스는 인메모리 데이터가 버킷 메모리 할당량의 75% 이하로 내려갈 때까지 계속됩니다(이 수준을 저수위 표시).

Couchbase에 저장된 문서의 구조에 대해 간략히 설명합니다:

• 문서 키 또는 ID가변 길이 - 최대 250바이트, 동일한 버킷에 저장된 문서에 대해 고유해야 합니다.
• 문서 메타데이터고정 길이 - 카우치베이스 버킷 유형에 저장된 문서의 경우 56바이트, 임시 버킷 유형에 저장된 문서의 경우 72바이트(이 버킷 유형은 이 글의 범위를 벗어남)
• 문서 값가변 길이 - 최대 20MB, 일반적으로 JSON, 다른 형식도 사용할 수 있습니다.

두 가지 배출 방법

기본적으로 카우치베이스 버킷은 다음을 사용합니다. 가치 전용 퇴출(또는 퇴거) 방법을 사용할 수 있습니다. 여러 버전 이전에는 이 방법이 유일한 옵션이었습니다. 이름에서 알 수 있듯이 퇴출 프로세스는 다음과 같습니다. 값만 제거합니다. 의 문서와 는 문서 키와 메타데이터를 항상 메모리에 보관합니다..

버전 3.0부터(카우치베이스 서버 이 글을 쓰는 시점에 버전 6.5.1에 있음), 우리는 전체 배출 방법. 전체 배출을 위해 구성된 버킷은 다음과 같이 쉽게 추측할 수 있습니다. 은 문서의 키, 메타데이터 및 값을 제거합니다. 를 삭제할 수 있습니다.

트레이드 오프: 성능 대 메모리 크기

그렇다면 버킷에 어떤 옵션을 선택해야 할까요? 최신 카우치베이스 서버 버전의 GUI에서 툴팁이 설명하는 내용은 다음과 같습니다:

• 가치 배출: 내보내는 동안에는 값만 내보내집니다(키와 메타데이터는 메모리에 남아 있음).
• 전체 배출: 내보내는 동안 키, 메타데이터, 값을 포함한 모든 항목이 내보내집니다.
  값 배출은 더 많은 시스템 메모리가 필요하지만 최상의 성능을 제공합니다. 전체 배출을 사용하면 메모리 오버헤드 요구 사항이 줄어듭니다.

더 정확히 말하자면, 어느 쪽도 메서드 "시스템 메모리가 더 필요합니다.“: 전체 배출을 사용하면 데이터 세트가 메모리를 크게 초과할 수 있지만 가치 를 사용하면 키와 메타데이터를 메모리에 보관해야 하므로 데이터 세트가 메모리보다 어느 정도 커질 수 있습니다.

만약 일관된 읽기 지연 시간 의 데이터로 작업하는 애플리케이션이 (매우) 중요하므로 값 내보내기를 고수해야 합니다. 이를 위해서는 다음을 수행해야 합니다. 클러스터 크기 조정 적절하게 할당하고 충분한 메모리 할당량 를 버킷에 구현하고 문서 보존 정책(오래된 문서를 정기적으로 보관하거나 제거)과 메모리 사용량 모니터링.

다음과 같은 경우 예산 또는 기존 기술의 한계 가 (매우) 중요하다면 대용량 버킷에 대한 전체 퇴거를 고려해야 합니다. 온프레미스 하드웨어 리소스가 최대치에 도달하여 더 이상 카우치베이스 노드에 RAM을 확보할 방법이 없는 경우에 해당할 수 있습니다. 온프레미스 또는 클라우드 기술 지출에 대한 자금이 빠듯한 경우, 성능 절충을 통해 하루를 절약할 수 있습니다.

전체 삭제를 고려해야 하는 또 다른 이유는 데이터 집합이 다음과 같을 것으로 예상되는 경우입니다. large를 사용하여 초과 합리적인 메모리 구성. 얼마나 큰 large? 수십억 개(예, 복수!)의 문서와 수십 테라바이트(역시 복수!)의 데이터가 있다고 가정해 봅시다. 솔루션 엔지니어와 솔루션 아키텍트가 언제나 도와드립니다. 카우치베이스 클러스터 크기 조정 제대로 알려주세요.

한 배출 방법에서 다른 배출 방법으로 전환하는 것은 가능하지만, 버킷을 다시 시작해야 하는 몇 안 되는 작업 중 하나이므로 약간의 가동 중단이 발생할 수 있습니다. 배출 방법을 변경하려고 하면 UI에 다음과 같은 경고가 빨간색 글꼴로 표시됩니다: 퇴거 정책을 변경하면 버킷이 다시 시작됩니다. 그러면 열려 있는 모든 연결이 닫히고 일부 다운타임이 발생합니다.. 따라서 버킷을 생산에 투입하기 전에 버킷의 배출 방법을 결정하는 것이 현명합니다.

성능 차이가 나는 이유는 무엇인가요?

버킷 내보내기 방법과 데이터 잔류에 대한 다양한 시나리오를 살펴보겠습니다. 이를 통해 성능에 어떤 영향을 미치는지 이해하는 데 도움이 될 것입니다.

1. 전체 데이터 레지던시

데이터가 완전히 상주하는 경우(즉, 버킷 메모리 할당량의 ~85%에 맞는 경우), 값 전용 버킷과 전체 내보내기 버킷의 성능은 비슷해야 합니다. 문서 작업은 아래와 같이 작동합니다:

• 키 = profile::john-doe::123으로 문서 가져오기(읽기)
  • FAST이 키가 있는지 메모리에서 확인합니다.
    • FAST: '예'인 경우 메모리에서 문서를 반환합니다.
    • FAST: 그렇지 않으면 "문서가 존재하지 않습니다" 오류를 반환합니다.
• 키 = profile::john-doe::123으로 문서를 삽입합니다.
  • FAST이 키가 있는지 메모리에서 확인합니다.
    • FAST: 그렇다면 "문서가 이미 존재합니다" 오류를 반환합니다.
    • FAST: 그렇지 않은 경우 문서를 메모리에 기록합니다. 그런 다음 비동기적으로 유지 및 복제합니다.
• 문서를 = = profile::john-doe::123 키로 바꾸기
  • FAST이 키가 있는지 메모리에서 확인합니다.
    • FAST: 예인 경우 변경 내용을 메모리에 저장합니다. 그런 다음 비동기적으로 유지 및 복제합니다.
    • FAST: 그렇지 않으면 "문서가 존재하지 않습니다" 오류를 반환합니다.

2. 부분 데이터 잔류, 값만 내보내기

버킷의 데이터 잔존 기간이 100% 미만인 경우 값 전용 배출, 카우치베이스 서버는 다음을 알고 있습니다. 문서 키와 메타데이터가 여전히 메모리에 남아 있습니다.. 따라서 문서 작업은 다음과 같이 표시됩니다:

• 키 = profile::john-doe::123으로 문서 가져오기(읽기)
  • FAST이 키가 있는지 메모리에서 확인합니다.
    • FAST: 그렇다면 문서 값이 메모리에 있는지 확인합니다.
      • FAST: '예'인 경우 메모리에서 문서를 반환합니다.
      • SLOW: 그렇지 않은 경우 디스크에서 메모리로 문서를 읽고 반환합니다.
    • FAST: 그렇지 않으면 "문서가 존재하지 않습니다" 오류를 반환합니다.
• 키 = profile::john-doe::123으로 문서를 삽입합니다.
  • FAST이 키가 있는지 메모리에서 확인합니다.
    • FAST: 그렇다면 "문서가 이미 존재합니다" 오류를 반환합니다.
    • FAST: 그렇지 않은 경우 문서를 메모리에 기록합니다. 그런 다음 비동기적으로 유지 및 복제합니다.
• 문서를 = = profile::john-doe::123 키로 바꾸기
  • FAST이 키가 있는지 메모리에서 확인합니다.
    • FAST: 예인 경우 변경 내용을 메모리에 저장합니다. 그런 다음 비동기적으로 유지 및 복제합니다.
    • FAST: 그렇지 않으면 "문서가 존재하지 않습니다" 오류를 반환합니다.

3. 부분 데이터 잔류, 전체 배출

버킷의 데이터 잔존 기간이 100% 미만인 경우 전체 배출, 카우치베이스 서버 의존할 수 없습니다 메모리에 있는 문서 키와 메타데이터의 존재 여부에 따라 달라질 수 있습니다. 따라서 문서 작업은 다음과 같이 진행됩니다:

• 키 = profile::john-doe::123으로 문서 가져오기(읽기)
  • FAST이 키가 있는지 메모리에서 확인합니다.
    • FAST: 그렇다면 문서 값이 메모리에 있는지 확인합니다.
      • FAST: '예'인 경우 메모리에서 문서를 반환합니다.
      • SLOW: 그렇지 않은 경우 디스크를 확인하세요.
        • SLOW: 문서가 디스크에 있는 경우 디스크에서 메모리에 있는 문서를 읽고 반환합니다.
        • SLOW: 그렇지 않으면 "문서가 존재하지 않습니다" 오류를 반환합니다.
• 키 = profile::john-doe::123으로 문서를 삽입합니다.
  • FAST이 키가 있는지 메모리에서 확인합니다.
    • FAST: 그렇다면 "문서가 이미 존재합니다" 오류를 반환합니다.
    • SLOW: 그렇지 않은 경우 디스크를 확인하세요.
      • SLOW: 그렇지 않은 경우 문서를 메모리에 기록합니다. 그런 다음 비동기적으로 유지 및 복제합니다.
      • SLOW: 그렇다면 "문서가 이미 존재합니다" 오류를 반환합니다.
• 문서를 = = profile::john-doe::123 키로 바꾸기
  • FAST이 키가 있는지 메모리에서 확인합니다.
    • FAST: 예인 경우 변경 내용을 메모리에 저장합니다. 그런 다음 비동기적으로 유지 및 복제합니다.
    • SLOW: 그렇지 않은 경우 디스크를 확인하세요.
      • SLOW: 그렇지 않으면 "문서가 존재하지 않습니다" 오류를 반환합니다.
      • SLOW: 그렇다면 문서를 메모리에 씁니다. 그런 다음 비동기적으로 유지 및 복제합니다.

100% 메모리에 상주하지 않는 전체 퇴거 버킷을 사용합니다, 많은 존재 작업은 디스크로 이동해야 합니다.. 백그라운드 가져오기(디스크에서 메모리로 문서 읽기, "캐시 미스"라고도 함)의 횟수도 전체 배출 버킷의 경우 더 많을 수 있습니다.

성능을 개선할 수 있는 방법이 있나요?

다음과 더불어 삽입 그리고 교체 운영, 카우치베이스 SDK 지원 업서트. . 업서트 연산은 문서가 없는 경우 문서를 삽입하거나 기존 문서를 대체합니다. 카우치베이스 서버에서 데이터 변형을 처리하는 것은 추가 전용이기 때문입니다, 의 업서트 작업 필요하지 않습니다. 해당 존재 작동합니다.  따라서 업서트 대신 삽입 그리고 대체 사용 사례에서 이러한 대체를 허용하는 경우 애플리케이션 성능을 향상시킬 수 있습니다.

전용 고속 디스크는 전체 이젝션 버킷의 성능도 향상시킵니다. 가상화된 스토리지를 통한 노드별 전용 디스크는 Couchbase 노드에 권장되는 구성 중 하나입니다.

가치 전용에서 전체 배출로 전환해야 하는 경우

다음 상황을 고려해 보겠습니다:

• 값만 배출하도록 구성된 버킷이 있습니다.
• 버킷이 권장되는 최소 상주 비율인 15-20% 미만의 데이터가 메모리에 상주하는 지점까지 커졌습니다.
• 더 많은 데이터가 들어올 것으로 예상되고, 사용 사례 요구 사항에 따라 이미 문서를 보관/삭제하고 있으며, 버킷에 더 많은 RAM을 제공할 방법이 없습니다.

전체 배출 방식으로 전환해야 하나요?

이 질문에 답하는 데 도움이 되는 좋은 지표가 있는데, 바로 동일한 버킷에 대한 RAM의 사용자 데이터와 비교한 RAM의 메타데이터의 양입니다. "메타데이터"란 문서 키 + 메타데이터를 의미합니다. "이 경우 '사용자 데이터'는 문서 값.

이러한 메트릭은 아래에서 찾을 수 있습니다. vBucket 리소스 섹션으로 이동합니다. 아래 스크린샷을 보면 메타데이터가 인메모리 버킷 데이터의 약 42%를 차지하는 것을 확인할 수 있습니다:

메타데이터 오버헤드 통계

특정 시점에 UI와 Couchbase 로그에 아래와 같은 메시지가 표시되기 시작할 수 있습니다:

메타데이터 오버헤드 경고

문서 키와 메타데이터가 메모리 할당량의 대부분을 차지하기 때문에 문서 값을 보관할 공간이 거의 없거나 전혀 없습니다. 이 경우 사용 가능한 메모리가 너무 적기 때문에 서버가 디스크에서 메모리로 데이터를 로드하기 위해 많은 백그라운드 가져오기를 수행하는 것을 볼 수 있으며, 이는 가까운 시일 내에 제거될 것입니다.

클러스터에 노드를 더 추가하거나 다른 버킷에서 메모리를 재할당할 수 없는 경우에는 현재 버킷의 전체 배출 방법으로 전환하는 것이 좋습니다. 버킷이 다시 시작되고 워밍업 과정을 거치는 동안 약간의 다운타임이 발생할 수 있다는 점만 기억하세요.

마무리

• 가치 전용 배출/제거는 메모리에서 문서 값만 제거하지만 전체 퇴거는 문서 키와 메타데이터도 제거합니다.
• 다음과 같이 정보에 입각한 선택 버킷을 생산에 투입하기 전에 배출 방법을 검토하세요. 수백만 개의 문서가 있는 쓰기 작업량이 많은 사용 사례는 전체 배출 방식에 적합한 후보입니다. 프로덕션 후반에 추출 방법을 변경하면 가동 중단으로 인해 비용이 많이 들 수 있습니다.
• Upsert 작업과 전용 고속 디스크는 항상 애플리케이션 성능을 향상시키며, 전체 배출 버킷의 경우 더욱 중요합니다.
• 버킷 모니터링 메타데이터 오버헤드. 이는 클러스터에 더 많은 RAM이 필요할 수 있다는 좋은 지표입니다. Couchbase 클러스터에 더 많은 메모리를 확보할 수 없고 메타데이터 오버헤드가 40% 이상입니다.로 설정되어 있다면 쓰기량이 많은 대용량 버킷을 전체 배출로 전환하는 것이 좋습니다.