Couchbase에서 외부 분석 컬렉션의 성능 최적화

이제 외부 Couchbase Analytics 컬렉션이 지원되므로 성능 최적화 및 리소스 활용 계획을 세우는 것이 중요합니다(AWS S3 그리고 Azure 블롭 스토리지). 외부 카우치베이스 애널리틱스 컬렉션은 외부 저장소에서 데이터를 읽고 로컬에 저장하지 않으므로 최적화하지 않으면 비용이 많이 드는 작업이 될 수 있습니다.

이 도움말에서는 외부 저장소에서 데이터를 쿼리할 때 성능과 리소스 사용률에 큰 영향을 미치는 요인에 대해 설명합니다. 또한 자세한 예시를 통해 최적화가 얼마나 효과적인지 살펴봅니다.

다음 항목을 고려하고 성능 및 리소스 활용에 미치는 영향에 대해 논의합니다:

• 인터넷 대역폭 및 외부 스토리지와의 거리
• 외부 스토리지에 있는 Couchbase Analytics 노드 및 파티션 수와 파일 수
• 접두사 및 필터 포함/제외하기

인터넷 대역폭 및 거리

외부 데이터는 카우치베이스 애널리틱스의 기본 저장소에 저장되지 않기 때문에 각 쿼리 요청은 네트워크를 통해 데이터의 현재 버전을 전송합니다. 따라서 네트워크 대역폭이 이러한 쿼리 성능에 중요한 요소가 됩니다. 네트워크 지연 시간은 또 다른 요인으로, 데이터가 이동해야 하는 거리가 지연 시간에 영향을 미칩니다. 따라서 대상 스토리지를 가까운 지역에서 호스팅하는 것이 좋습니다.

참고: 일부 스토리지 서비스 제공업체는 애플리케이션과 호스트 스토리지가 같은 지역에 있는 경우 전송 비용을 청구하지 않으므로 성능이 향상되고 비용이 절감됩니다.

파티션과 파일 수 비교

외부 카우치베이스 애널리틱스 컬렉션을 쿼리할 때 데이터 스캔 워크로드는 사용 가능한 애널리틱스 노드와 파티션에 고르게 분산되어 데이터를 병렬로 읽게 됩니다. (이는 내부 스토리지가 병렬 읽기). 이 병렬 읽기 기능을 최대한 활용하려면 외부 스토리지의 데이터를 다음 위치에 저장해야 합니다. 여러 파일 하나 또는 몇 개의 대용량 파일로 저장하지 않습니다.

예를 들어 노드당 4개의 파티션이 있는 3개의 Analytics 노드가 있다고 가정해 보겠습니다. 이 구성은 병렬 정도가 12(총 12개의 파티션)가 됩니다. 외부 Analytics 컬렉션이 쿼리될 때 외부 저장소에서 12개의 파일을 병렬로 읽을 수 있어야 합니다.

데이터가 여러 파일로 구성되어 있는 경우 위의 설정은 한 번에 12개의 파일을 읽지만, 파일이 몇 개만 있는 경우(예: 5개의 대용량 파일) 5개의 파티션만 작업을 수행하고 나머지 사용 가능한 Analytics 리소스는 유휴 상태로 유지됩니다.

분석은 노드가 아닌 전체 파티션 수에 스캔 작업 부하를 균등하게 분산하는 것을 목표로 합니다. 위의 예에서 12개의 파티션 각각은 전체 워크로드의 1/12를, 각 노드는 1/3의 부하를 갖게 됩니다. 어떤 이유로 노드의 파티션 수가 다르면 파티션당 워크로드는 균일하게 유지되지만 노드 자체의 부하가 균일하지 않게 됩니다. 그렇기 때문에 데이터를 여러 파일에 분산시켜 워크로드를 분산시키는 것이 좋습니다. 

그러나 다음과 같은 사항을 피하는 것도 마찬가지로 중요합니다. 너무 많은 작은 파일 파일 메타데이터 처리와 너무 많은 파일 열기/닫기 작업으로 인해 성능이 저하될 수 있기 때문입니다.

접두사 및 필터 포함/제외하기

데이터 구성

설명을 위해 여기서 작업할 데이터의 구조를 살펴보는 것부터 시작하겠습니다. 3년 분량의 리뷰 데이터. 데이터를 연도별, 분기별, 월별로 정리합니다. 데이터는 2018년, 2019년, 2020년에 대한 것입니다.

다음은 디렉토리 레이아웃과 일반적인 문서의 샘플입니다:

문서 샘플:

위의 구조를 통해 데이터를 월 단위로 세분화할 수 있으며, 이는 추후 예제에서 활용될 것입니다.

3년간 데이터의 총 크기가 720GB라고 가정해 보겠습니다. 이렇게 하면 연간 약 240GB(3년), 월 20GB(3년 36개월)의 데이터를 사용할 수 있습니다.

외부 컬렉션은 어떻게 작동하나요?

데이터 구성이 성능에 큰 영향을 미칠 수 있으므로 Couchbase Analytics가 외부 저장소에서 데이터를 읽는 방법을 다시 살펴 보겠습니다.

외부 분석 수집 데이터는 AWS S3, Azure Blob/Data Lake 또는 Google Cloud Storage와 같은 원격 외부 스토리지에 저장됩니다. Azure Blob 스토리지 및 Google Cloud Storage는 다음과 같습니다. 현재 개발자 프리뷰 중. 

외부 링크 및 외부 Analytics 컬렉션이 생성되면 다음과 같이 됩니다. 정의 외부 소스에서 데이터를 읽도록 구성된 엔티티의 수이지만 데이터는 저장 로 설정합니다. 이렇게 하면 애널리틱스에서 항상 최신 버전의 외부 데이터를 볼 수 있지만 속도가 느려질 수도 있습니다. 다음을 사용하여 읽기 프로세스를 최적화할 수 있습니다. 접두사 및 기타 필터를 사용하여 시간과 리소스 절약.

다음 예제에서는 필터를 잘 정리된 데이터와 함께 신중하게 사용할 경우 얼마나 큰 차이를 만들 수 있는지 살펴볼 것입니다.

요구 사항

다음의 간단한 쿼리 요청을 통해 필터링이 있는 경우와 없는 경우의 성능 차이를 살펴보겠습니다:

• 2018년, 2019년, 2020년 고객으로부터 받은 총 리뷰 수를 확인하세요.
• 2019년 한 해 동안 고객으로부터 받은 총 리뷰 수를 확인하세요.
• 2020년 1월 한 달간 고객의 총 리뷰 수를 확인하세요.

필터링되지 않은 솔루션

다음과 같이 가정해 보겠습니다. 이미 사용 가능한 외부 링크가 있습니다. 호출 myLink (참조 외부 데이터 집합: Couchbase 분석에서 AWS S3에 액세스하기 를 참조하세요(링크 생성 방법의 예). 먼저 접두사나 포함/제외 필터 없이 모든 리뷰 데이터에 대한 외부 애널리틱스 컬렉션을 만듭니다. 구문은 간단합니다:

이 외부 애널리틱스 컬렉션이 생성되었으므로 다음과 같이 간단하고 직관적인 쿼리를 작성해 보겠습니다:

인터넷 대역폭과 서비스 제공업체와의 거리를 고려할 때 다음과 같은 결과를 얻을 수 있고 실제로도 얻었습니다:

• 이러한 쿼리에는 다음과 같은 시간이 걸렸습니다. 435, 448 그리고 430 초로 거의 동일한 성능을 보였다는 것을 알 수 있습니다.
• 각 쿼리 결과는 다음과 같습니다. 720GB 상당의 데이터를 전송할 수 있습니다.

여기서 일어나는 일은 이러한 각 쿼리가 모든 데이터 레코드를 읽은 다음(즉, 모든 데이터가 전송된 다음) 올바른 결과를 제공하는 데 필요한 필터링을 적용하는 것입니다. 그러나 데이터가 필터링될 때는 이미 데이터가 전송된 후입니다. 이것이 위 예제에서 성능을 결정하는 주요 요인입니다.

추가 최적화가 이루어지지 않으면 리뷰에 대한 모든 쿼리는 전체 데이터 세트를 반복해서 읽게 되므로 비용이 매우 많이 들 수 있습니다. 외부 데이터에 자주 액세스하지 않는 경우에는 이러한 방식이 허용될 수 있지만, 원하는 경우 훨씬 더 나은 방법을 사용할 수 있습니다.

필터링된 솔루션

이제, 이제 어떻게 하면 접두사 그리고 포함/제외 외부 애널리틱스 컬렉션에 사용할 수 있는 필터와 쿼리 성능을 개선하기 위해 데이터를 구조화하는 방법에 대해 설명합니다.

첫 번째 쿼리는 모든 데이터를 읽어야 하므로 그대로 두겠습니다. 대신 쿼리 2와 3을 살펴보겠습니다.

쿼리 2에서 필요한 데이터는 2019년에 대한 데이터만 있으므로 새 외부 Analytics 컬렉션을 만들고 이 때 접두사로 연도를 사용할 수 있습니다:

DDL은 지정된 접두사(즉, "리뷰/2019". 이 컬렉션은 다음 사항에 유의하는 것이 중요합니다. 가상라는 이름으로 저장된 동일한 외부 데이터에 대한 또 다른 진입점일 뿐입니다. (데이터가 복제되지 않으며, 이 추가 외부 컬렉션의 생성으로 인해 추가 공간이 사용되지 않고 메타데이터만 사용됩니다.)

어떤 일이 일어나는지 이해하기 위해 내부적으로 어떤 일이 일어나는지 살펴봅시다. 외부 Analytics 컬렉션이 쿼리되면 쿼리 엔진은 다음과 같은 정보만 포함된 파일의 메타데이터를 검색하는 것으로 시작합니다. 약 파일입니다. 파일의 내용을 아직 읽지 못했습니다. 반환된 메타데이터 정보 중 일부는 파일의 전체 이름/경로와 콘텐츠 크기입니다.

애널리틱스는 이 정보를 활용하여 두 단계를 수행합니다:

• 파일 이름에 접두사, 포함/제외 필터링을 적용하여 각 파일을 포함할지 아니면 모두 제외할지 결정하므로 리소스를 절약할 수 있습니다.
• 데이터의 전체 크기를 계산하여 병렬 액세스 및 처리를 위해 Analytics 노드의 모든 파티션에 작업 부하를 균등하게 분산합니다.

위의 내용을 적용하여 내2019컬렉션 접두사가 붙은 파일만 읽습니다.리뷰/2019'라고 입력하면 33%의 데이터만 포함됩니다. 이제 관련 쿼리를 다음과 같이 작성할 수 있습니다:

위의 쿼리를 실행하면 다음을 관찰할 수 있습니다:

• 이제 총 실행 시간은 기존 448초에서 160초로 줄어들어 원래 시간의 35%에 불과합니다. 이는 33%의 데이터만 읽었기 때문에 예상된 결과입니다.
• 전송되는 총 데이터 용량은 기존 720GB에서 줄어든 240GB입니다.

이는 성능과 리소스 사용률 모두에서 상당한 개선입니다.

동일한 패턴에 따라 외부 컬렉션의 포함/제외 필터 기능을 사용해 보겠습니다. 쿼리 3은 2020년 1월의 데이터에만 관심이 있습니다.

다음과 같이 적절한 외부 애널리틱스 컬렉션을 만들어 보겠습니다:

위의 컬렉션에서 데이터를 읽으면 접두사가 "리뷰/2020"를 입력하여 2020년 데이터만 효과적으로 포함시킨 다음 (데이터를 읽기 전에도!) Analytics에서 포함 필터도 적용합니다. 결과적으로 쿼리는 "" 패턴과 일치하는 파일만 검색합니다.*/Jan/*.json'로 쿼리하여 1월의 JSON 파일만 포함합니다. 쿼리 대상 파일이 결정되면 쿼리 엔진은 파티션에 작업 부하를 분산하고 데이터 읽기를 시작합니다.

이 새 컬렉션에 대해 작성된 세 번째 쿼리를 실행합니다:

우리는 다음을 준수합니다:

• 이제 총 실행 시간은 12초에 불과하며, 2.78%의 데이터만 효과적으로 읽고 있습니다.
• 이제 전송되는 총 데이터 양은 20GB에 불과합니다.

포함/제외 필터는 와일드카드 표현식도 지원할 수 있으며, 예를 들어 한 번에 여러 개의 필터를 지정할 수 있습니다:

1월과 3월의 데이터만 포함하는 데 사용할 수 있습니다.

다음 단계

외부 데이터에 액세스하는 데는 비용이 많이 들 수 있으므로 데이터 구성 모범 사례와 해당 외부 수집 정의를 적용하는 것이 좋습니다. 이렇게 하면 Couchbase Analytics가 사용 가능한 리소스를 최대한 병렬로 활용하고 쿼리 실행과 관련된 비용을 최소화하여 최상의 성능을 얻는 데 큰 도움이 됩니다.

이 문서에 사용된 다음 링크를 따라 Couchbase 애널리틱스에 대해 자세히 알아보세요:

• 발견하기 이 기사에서 고객이 카우치베이스 애널리틱스를 사용하는 방법.
• 다음과 함께 분석 컬렉션 사용 AWS S3 그리고 Azure 블롭 스토리지.
• 다중 디스크를 사용하여 카우치베이스 애널리틱스 쿼리 속도 높이기
• JSON 분석 - NoSQL 및 Couchbase를 사용한 NoETL
• 사용 분석용 SQL++(JSON용 SQL)