SQL을 사용하여 문서를 쿼리해야 하는 경우 Couchbase에서 사용할 수 있는 옵션은 두 가지입니다. The 쿼리 서비스 및 분석 서비스. 블로그, N1QL: 쿼리할까요, 분석할까요? 에서 두 서비스에 대한 자세한 개요를 확인할 수 있습니다. 이 블로그에 앞서 읽어보시기를 적극 권장합니다. 이 글은 이전 블로그에서 몇 가지 구체적인 실습 예제를 추가하여 확장하는 것을 목표로 합니다. 각 예제마다 두 서비스에서 쿼리를 작성하는 방법을 다루고 성능 차이를 살펴보겠습니다. 독자들이 각 서비스에 가장 적합한 패턴과 사용 사례를 빠르게 식별하는 데 도움이 되는 더 많은 지식을 얻고 돌아가실 수 있도록 하는 것이 목표입니다.
요약
예시를 살펴보기 전에 두 서비스의 개괄적인 주요 특징을 다시 한 번 살펴보겠습니다.
쿼리 서비스 |
분석 서비스 |
애플리케이션 로직 내에서 데이터 조작에 사용됩니다. | 보고서, 분석(기록, 대화형) 및 대시보드에 사용됩니다. |
소량의 데이터를 검색하거나 조작하는 짧고 조작적인 쿼리에 가장 효율적입니다. | 일반적으로 대량의 데이터를 검색하고 처리하는 길고 복잡한 애드혹 쿼리에 가장 효율적입니다. |
선택, 삽입, 업데이트, 삭제, 병합 작업을 지원합니다. | SELECT 작업만 지원합니다. |
참조 https://www.couchbase.com/blog/n1ql-to-query-or-to-analyze/ 를 클릭해 전체 표를 확인하세요.
설정
이 튜토리얼에서는 Couchbase 6.5와 Couchbase 관리 UI에 제공된 샘플 데이터를 사용합니다. 제 환경은 분석 서비스에 1536MB가 할당된 3노드 Couchbase 6.5 클러스터입니다. 다른 모든 설정은 기본값입니다. 클러스터에 액세스할 수 없는 경우 다음 명령을 실행하여 Docker 컨테이너에서 Couchbase 6.5를 빠르게 실행할 수 있습니다:
1 |
도커 실행 -d --이름 db -p 8091-8096:8091-8096 -p 11210-11211:11210-11211 카우치베이스:엔터프라이즈-6.5.0 |
Docker 경로를 사용하는 경우 컨테이너가 시작된 후 브라우저에서 http://localhost:8091 으로 이동하여 각 단계의 기본 옵션을 사용하여 Couchbase 인스턴스를 설정하세요. Couchbase 인스턴스에 어떤 이름을 지정하는지는 중요하지 않습니다.
성능 면책 조항
다음 예제의 응답 시간을 살펴보겠습니다. Couchbase 환경 설정 방식에 따라 성능이 크게 달라질 수 있다는 점에 유의하세요. 그러나 환경에 관계없이 쿼리 및 분석 서비스 간에 유사한 차이를 관찰할 수 있습니다.
여행 샘플 버킷 설치
카우치베이스 관리자 대시보드에서 설정 -> 샘플 버킷으로 이동합니다. 여행 샘플 버킷을 설치합니다. 이 작업에 대한 자세한 설명은 다음 문서에서 확인할 수 있습니다. 문서 사이트.
쿼리 서비스 설정
샘플 버킷을 설치하면 필요한 인덱스도 생성됩니다. 즉, 쿼리 서비스에 대한 추가 설정이 필요하지 않습니다.
애널리틱스 서비스 설정
애널리틱스 서비스의 경우 버킷에 문서의 각 '유형'에 대한 데이터 집합을 채워야 합니다. 애널리틱스 워크벤치(http://localhost:8091/ui/index.html#!/cbas/workbench)로 이동하여 다음 쿼리를 실행하여 데이터 집합을 만듭니다:
1 2 3 4 5 6 |
만들기 데이터 세트 경로 켜기 `여행-샘플` 어디 `유형` = "경로"; 만들기 데이터 세트 랜드마크 켜기 `여행-샘플` 어디 `유형` = "랜드마크"; 만들기 데이터 세트 호텔 켜기 `여행-샘플` 어디 `유형` = "호텔"; 만들기 데이터 세트 항공사 켜기 `여행-샘플` 어디 `유형` = "항공사"; 만들기 데이터 세트 공항 켜기 `여행-샘플` 어디 `유형` = "공항"; 연결 링크 로컬; |
그러면 여행 샘플 버킷을 사용하여 경로, 랜드마크, 호텔, 항공사 및 공항에 대한 데이터 세트가 생성됩니다. 마지막으로 CONNECT 문을 실행하면 각 데이터 세트가 채워지기 시작합니다.
다음 예제에서는 간단한 N1QL 쿼리를 사용하겠습니다. 쿼리와 분석 간의 N1QL 언어 차이에 대한 자세한 분석은 다음을 참조하세요. 분석용 N1QL과 쿼리용 N1QL 비교 참조 페이지를 참조하세요.
사용 사례: LAX에서 SFO로 가는 모든 노선 보기
이제 첫 번째 쿼리를 작성할 준비가 되었습니다. 이 사용 사례에서는 주어진 출발지와 목적지 공항에서 이용 가능한 모든 경로를 찾고자 합니다.
어떤 서비스가 가장 좋을까요?
이것은 확실히 제한된 양의 데이터를 반환하는 연산 쿼리입니다. 데이터에 대한 집계나 복잡한 함수를 수행하지 않는 단순한 쿼리입니다. 소스 및 대상에 대한 간단한 필터만 있습니다. 따라서 쿼리 서비스(http://localhost:8091/ui/index.html#!/query/workbench)가 확실한 선택입니다.
1 2 3 4 |
선택 * 에서 `여행-샘플` 어디 유형 = "경로" 그리고 소스공항 = "LAX" 그리고 목적지공항 = "SFO" |
성능: 4밀리초
이 쿼리는 간단한 쿼리이며 7개의 문서만 반환합니다. 이것은 애플리케이션이 Couchbase에 보낼 수 있는 일반적인 운영 쿼리입니다. 성능은 안정적으로 빠르고 일관적입니다.
분석 서비스 등가물
데모를 위해 애널리틱스 서비스에도 동일한 쿼리를 작성해 보겠습니다. 이와 같은 간단한 쿼리에는 애널리틱스 서비스가 과잉입니다. 따라서 이 사용 사례를 위한 애플리케이션을 구축하는 경우 Analytics 서비스를 선택하지 않을 것입니다. 쿼리 서비스보다 성능이 떨어질 것으로 예상됩니다.
1 2 3 |
선택 * 에서 경로 어디 소스공항 = "LAX" 그리고 목적지공항 = "SFO" |
성능: ~36밀리초
이 예제에서 볼 수 있듯이 이 사용 사례에서는 예상대로 쿼리 서비스가 가장 우수한 성능을 보입니다. 부하가 많은 경우 쿼리 서비스는 이 간단한 테스트에서 보여준 30밀리초 이상의 차이보다 훨씬 더 나은 성능을 보일 것으로 예상됩니다.
사용 사례: 호텔이 가장 많은 도시 찾기
어떤 서비스가 가장 좋을까요?
이 사용 사례에서는 각 도시에서 이용 가능한 호텔 수를 파악하고 가장 많은 호텔이 있는 도시를 기준으로 결과를 먼저 정렬하려고 합니다. 이를 위해서는 모든 호텔을 스캔하여 국가 및 도시별로 호텔 수를 수집한 다음 정렬해야 합니다. 처음에 설명한 논리에 따르면 이 사용 사례에서는 분석 서비스(http://localhost:8091/ui/index.html#!/cbas/workbench)가 더 나은 성능을 보여야 합니다. 이 이론을 테스트해 보겠습니다.
1 2 3 4 5 6 7 |
선택 국가, 도시, 카운트(id) 에서 호텔 그룹 by 국가, 도시 주문 by 카운트(id) desc |
성능: ~36밀리초
흥미롭게도 이 쿼리의 성능은 이전 쿼리가 훨씬 더 간단하고 계산적으로 더 작았음에도 불구하고 이전 Analytics 예제(36ms)와 거의 동일합니다. 이는 3노드 환경의 기본 성능이 Analytics 쿼리의 경우 약 36밀리초가 될 수 있음을 의미합니다. 이 쿼리는 첫 번째 예제보다 더 복잡하지만, 여전히 Analytics 서비스에서는 비교적 간단한 쿼리입니다.
쿼리 서비스 등가물
쿼리 서비스에 대해 동일한 쿼리를 작성해 보겠습니다. 이론적으로 이것은 이전 쿼리 서비스 예제보다 더 무거운 쿼리입니다. 또한 첫 번째 예제보다 훨씬 더 많은 데이터를 처리하고 반환합니다. 쿼리 서비스는 분석 서비스만큼 성능이 좋지 않을 것으로 예상됩니다.
1 2 3 4 5 6 7 8 |
선택 국가, 도시, 카운트(id) 에서 `여행-샘플` 어디 유형 = "호텔" 그룹 by 국가, 도시 주문 by 카운트(id) desc |
성능: ~90밀리초
여기서 성능에 큰 차이가 있음을 알 수 있습니다. 예상대로 분석 서비스는 쿼리 서비스보다 평균 2배 더 빠르게 쿼리를 처리할 수 있습니다.
사용 사례: 가장 많은 노선을 운항하는 항공사 찾기
어떤 서비스가 가장 좋을까요?
이 쿼리는 이전 예제와 비슷한 질문을 하고 있습니다. 하지만 여기서는 항공사 데이터가 버킷의 노선 데이터와 다른 유형의 문서에 있기 때문에 조인이 필요하다는 점이 다릅니다. 우리는 분석 서비스 를 사용하면 집계와 조인을 수행하므로 이 쿼리에서 더 나은 성능을 얻을 수 있습니다.
1 2 3 4 5 6 7 8 9 10 |
선택 a.id, a.콜사인, a.이름, a.국가, 카운트(r.id) as route_count 에서 항공사 a join 경로 r on CONCAT("airline_", to_string(a.id)) = r.airlineid 그룹 by a.id, a.콜사인, a.이름, a.국가 주문 by route_count desc limit 100 |
성능: 82밀리초
여기에서 이 쿼리가 실제로 애널리틱스 서비스를 조금씩 밀어내기 시작하고 있음을 알 수 있습니다. 첫 번째 Analytics 쿼리는 평균 36밀리초가 걸렸지만 이 쿼리는 82밀리초까지 빨라졌습니다. 이 쿼리의 가장 큰 차이점은 JOIN이 추가되었다는 것입니다.
쿼리 서비스 등가물
처음에 여행 샘플 데이터의 각 문서 유형에 대해 별도의 분석 '데이터 세트'를 만들었음을 기억하세요. 각 데이터 집합은 자체 테이블처럼 작동합니다. 따라서 이전에 SQL 조인을 작성해 본 적이 있다면 쿼리에서 이들을 조인하는 것은 간단합니다. 쿼리 서비스에는 분석 서비스와 같은 방식으로 '데이터 집합'이라는 개념이 없습니다. 따라서 동일한 버킷에 있는 모든 데이터를 설명하기 위해 쿼리를 약간 다르게 작성해야 합니다. 유형 = "항공사"의 문서를 유형 = "노선"의 문서에 조인해야 합니다. 이를 위해서는 하위 쿼리가 필요합니다.
1 2 3 4 5 6 7 8 9 10 11 |
선택 a.id, a.콜사인, a.이름, a.국가, 카운트(r.id) as route_count 에서 `여행-샘플` a join (선택 id, airlineid 에서 `여행-샘플` 어디 유형 = "경로") r on CONCAT("airline_", to_string(a.id)) = r.airlineid 어디 a.유형 = "항공사" 그룹 by a.id, a.콜사인, a.이름, a.국가 주문 by route_count desc limit 100 |
성능: 2초
이 사용 사례의 경우 JOIN으로 인해 분석 서비스의 성능이 크게 향상되었습니다. 이 사례에 대한 분석 서비스의 또 다른 추가 이점은 조인할 하위 쿼리를 만들 필요가 없기 때문에 JOIN을 작성하는 것이 더 간단하다는 것입니다.
사용 사례: 가장 많은 노선을 운항하는 항공사의 백분위수 순위 얻기
어떤 서비스가 가장 좋을까요?
이 예제는 경로 수의 백분위수 순위를 추가하여 이전 예제를 기반으로 합니다. 다음과 같은 경우 성능이 향상될 것으로 예상됩니다. 분석 쿼리에 훨씬 더 많은 복잡성과 계산을 추가하기 때문입니다. 쿼리에 창 함수를 추가하는 것이 얼마나 큰 영향을 미치는지 살펴보겠습니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
선택 a.id, a.콜사인, a.이름, a.국가, 카운트(r.id) as route_count, PERCENT_RANK() OVER ( 주문 BY 카운트(r.id) ) AS `순위` 에서 항공사 a join 경로 r on CONCAT("airline_", to_string(a.id)) = r.airlineid 그룹 by a.id, a.콜사인, a.이름, a.국가 주문 by route_count desc limit 100 |
성능: 85밀리초
창 기능을 추가해도 성능 차이를 거의 확인할 수 없었기 때문에 애널리틱스 서비스에는 큰 문제가 없었습니다.
쿼리 서비스 등가물
1 2 3 4 5 6 7 8 9 10 11 12 |
선택 a.id, a.콜사인, a.이름, a.국가, 카운트(r.id) as route_count, PERCENT_RANK() OVER ( 주문 BY 카운트(r.id) ) AS `순위` 에서 `여행-샘플` a join (선택 id, airlineid 에서 `여행-샘플` 어디 유형 = "경로") r on CONCAT("airline_", to_string(a.id)) = r.airlineid 어디 a.유형 = '항공사' 그룹 by a.id, a.콜사인, a.이름, a.국가 주문 by route_count desc limit 100 |
성능: 2초
쿼리 서비스 쿼리에 Window 함수를 추가해도 성능 저하를 감지할 수 없습니다. 이 결과에서 유추할 수 있는 주요 내용은 JOIN이 가장 큰 성능 요소이고 집계(이 경우 COUNT)가 두 번째로 큰 성능 요소라는 것입니다.
결론
이 문서가 Couchbase의 두 가지 SQL 옵션과 적용 시기를 이해하는 데 도움이 되었기를 바랍니다. 쿼리 및 분석에 관한 다음 리소스도 꼭 확인해 보세요.
- 블로그: N1QL: 쿼리할까요, 분석할까요?
- 언어 참조: 분석용 N1QL과 쿼리용 N1QL 비교
- 문서화: 애널리틱스 소개
- 문서화: 쿼리 기본 사항