벡터 쿼리와 잘못될 수 있는 것들

Couchbase 7.6은 다음을 도입합니다. 카우치베이스 아키텍처로의 벡터 검색를 추가하여 검색 기능을 비약적으로 확장했습니다. 이 문서에서는 검색 쿼리에 어떤 영향을 미치는지, 특정 상황에서 어떻게 적응해야 하는지, 그리고 이 최신 기능을 효율적으로 사용하는 방법을 소개합니다. 벡터 검색을 최상의 상태로 유지하려면 비효율적인 인덱스, 비효율적인 쿼리 또는 자주 변경되는 데이터로 인한 쿼리 속도 저하와 같은 문제와 시간 초과, 일관성 오류, 앱 허더 등의 기타 장애 사례를 알고 있어야 합니다.

벡터 쿼리 소개

벡터를 사용할 수 있도록 검색 쿼리를 조정해야 했습니다. 벡터는 기본적으로 다음을 허용하는 새로운 쿼리 유형입니다. 유사도 검색 를 사용합니다. 차이점은 벡터의 경우 더 이상 정확히 일치하는 것을 찾는 것이 아니라 쿼리에 지정된 벡터에 가장 가까운 벡터를 찾는다는 점입니다:

이것은 벡터 쿼리입니다. 일반 쿼리와는 상당히 다릅니다. 쿼리의 모든 벡터 부분은 다음과 같은 새 키 아래에 있습니다. knn벡터 쿼리 전용으로 도입되었습니다. 벡터 쿼리를 위해 도입된 k 값에 따라 결과에서 원하는 문서 수가 결정됩니다. 이는 정확히 일치하는 문서를 찾는 것이 아니라 k 쿼리 벡터에 가장 가까운 벡터를 반환합니다. 이 쿼리는 결국 검색이 쿼리 벡터에 가장 가깝다고 생각하는 세 개의 벡터를 반환합니다.

또한 벡터 쿼리를 일반 쿼리와 결합하여 하이브리드 검색. 이 경우 검색은 두 단계로 쿼리를 수행합니다. 첫 번째 단계에서는 벡터 검색을 수행하여 서로 다른 파티션의 모든 결과를 병합하고, 두 번째 단계에서는 첫 번째 단계의 결과를 활용하여 일반 검색을 수행합니다. 이 접근 방식은 노드 간에 전달되는 데이터의 양과 시간 측면에서 더 나은 성능을 제공합니다.

이제 벡터를 쿼리하는 방법을 알았으니 가장 일반적인 실패 시나리오를 살펴보겠습니다. 벡터 쿼리 중 무엇이 잘못될 수 있나요?

느린 쿼리 식별

가장 일반적인 쿼리 실패 유형 중 하나는 느린 쿼리입니다. 시스템에서 오랫동안 처리가 중단되는 쿼리를 느린 쿼리라고 합니다. 이 쿼리에 설정된 시간 제한에 따라 쿼리가 오랫동안 실행될 수 있습니다.

이런 일이 발생하는 데는 여러 가지 이유가 있습니다. 쿼리 속도가 느려지는 가장 간단한 이유 중 하나는 쿼리를 실행하는 데 너무 많은 비용이 들기 때문입니다. 이는 너무 많은 문서를 참조하거나 색인되는 문서 수가 너무 많거나 쿼리 유형이 비교적 비효율적이기 때문일 수 있습니다.

벡터 측면에서 쿼리 속도가 느려지는 가장 일반적인 원인은 인덱스 크기가 크고 파티션 수가 충분하지 않거나 쿼리의 K 값이 크거나 심지어 데이터 수집 속도가 높기 때문입니다.

이제 느린 쿼리가 무엇인지 알았으니 다음 질문은 느린 쿼리가 여전히 실행 중인지 어떻게 알 수 있을까요? 이를 확인하는 가장 좋은 방법 중 하나는 로그를 확인하는 것입니다. 느린 쿼리는 5초마다 기록됩니다. 이 타이머는 관리자 옵션을 사용하여 변경할 수 있으며 로그 줄은 다음과 같이 표시됩니다:

또 다른 방법은 통계를 살펴보는 것입니다. 통계는 /api/nsstats 호출된 엔드포인트 총_쿼리_슬로우 는 느린 쿼리가 감지된 횟수를 기록합니다:

또한 동일한 엔드포인트에서 관찰할 수 있는 몇 가지 통계가 더 있어 내부적으로 쿼리에 어떤 일이 일어나고 있는지, 문제가 어디에 있는지 단서를 제공할 수 있습니다:

• • AVG_GRPC_INTERNAL_QUERYS_LATENITY - 지연 시간 다른 노드에서 들어오는 쿼리를 처리하는 데 grpc 수준에서 걸리는 평균 시간
  • AVG_GRPC_QUERYS_LATENITY - 동일한 노드에서 시작된 쿼리를 처리하는 데 grpc 수준에서 걸린 평균 시간
  • 평균_내부 쿼리 지연 시간 - 평균 내부 쿼리 지연 시간 다른 노드에서 들어오는 쿼리를 처리하는 데 걸리는 평균 시간
  • 평균 쿼리 지연 시간 - 평균 쿼리 지연 시간 - 동일한 노드에서 시작된 쿼리를 처리하는 데 걸리는 평균 시간

쿼리 속도 저하의 요인

이제 느린 쿼리를 식별하는 방법을 알았으니 다음 단계는 느린 쿼리가 발생하는 이유와 이를 최소화하기 위해 무엇을 할 수 있는지 이해하는 것입니다.

비효율 지수

주요 요인 중 하나는 인덱스 자체, 인덱싱된 벡터의 수, 파티션 수 또는 노드 수입니다. 이러한 각 요소는 쿼리 성능에 있어 매우 중요합니다.

인덱싱되는 벡터의 수는 매우 자명하며, 벡터의 수가 많을수록 쿼리하는 데 시간이 더 오래 걸립니다. 7.6.0 버전에서는 문서 수로 대략적으로 유추할 수 있지만 다음 유지 관리 패치에서는 정확한 값을 알려주는 통계가 추가될 예정입니다.

파티션과 노드의 수는 다소 직관적으로 설명할 수 있습니다. 책상 위에 놓인 서류 뭉치를 훑어보는 사람의 예를 들어 보겠습니다.

서류는 많은데 사람은 한 명뿐이라 원하는 것을 찾는 데 시간이 오래 걸립니다. 이제 같은 책상에서 절반의 문서를 검토하는 사람을 한 명 더 추가해 보겠습니다. 이렇게 하면 정확한 문서를 찾는 데 걸리는 시간이 확실히 줄어듭니다.

같은 책상에 계속 사람을 추가할 수는 있지만, 어느 시점이 지나면 사람들이 앉을 책상이 부족해지고 일부 사람들은 책상이 너무 붐비기 때문에 대기하고 있습니다.

가장 간단한 해결책은 책상을 하나 더 추가하거나 더 큰 책상을 구하는 것인데, 이렇게 하면 더 많은 사람이 한 번에 앉아서 서류를 검토할 수 있습니다.

이 예는 검색 생태계와 유사합니다. 사람은 파티션, 논문은 벡터, 책상은 노드입니다. 책상의 수가 많다는 것은 더 많은 사람을 처리하기 위해 더 많은 리소스가 필요하다는 것을 의미합니다. 사람이 많다는 것은 검색 속도가 빨라진다는 것을 의미하지만, 사람이 너무 많다는 것은 결과를 얻기 위해 그들 사이에 더 많은 커뮤니케이션이 필요하다는 것을 의미하며, 이는 다시 생산성에 반하는 결과를 초래합니다. 모든 시스템에는 적절한 균형이 존재하며, 효율성을 위해 그 균형을 찾는 것이 중요합니다.

비효율적인 쿼리

벡터 쿼리가 시스템에서 소요되는 시간을 결정하는 또 다른 주요 요소는 K 값입니다. K 값이 클수록 각 인덱스 파티션이 쿼리를 처리하는 데 더 오래 걸리고, 노드 간에 더 많은 양의 데이터를 전송해야 하며, 각 파티션의 K 결과를 압축하기 위해 이 모든 데이터를 보관하는 데 더 큰 버퍼가 필요하다는 의미입니다(총 K * 결과의 파티션 수)를 최종 K 결과값으로 변환합니다. 이러한 각 단계는 K 값이 증가함에 따라 점점 더 오래 걸립니다.

이전 예로 돌아가서, K 값이 크면 각 사람이 더 많은 문서 더미를 추적해야 하고, 모든 사람이 작업을 마치면 이제 후보에 오른 모든 문서 더미를 비교하여 최고의 문서 K 개를 찾아야 합니다.

끊임없이 변화하는 데이터

이 퍼즐의 마지막 조각은 문서 자체입니다. 검색은 추가 전용 아키텍처를 따릅니다. 즉, 기존 문서 항목을 다시 작성하는 대신 문서의 모든 변경 사항이 추가되고 색인화되어 별도로 저장됩니다. 실제 문서가 많이 변경되면 세그먼트가 계속 생성되고 이러한 세그먼트가 계속 병합되어 매우 바쁜 색인을 갖게 됩니다. 이러한 작업은 많은 리소스를 차지하므로 작업할 수 있는 공간이 많지 않아 쿼리에 영향을 미칩니다.

원하는 것을 찾으려고 노력하는 동안 사람들이 새로운 서류 더미를 가져다주는 것과 같다고 생각해보세요. 지저분하고, 책상 공간이 부족하고, 새 서류가 계속 들어오고, 업데이트된 서류일 경우 중복된 서류도 추적해야 합니다.

기타 문제

쿼리 속도가 느린 것만이 쿼리가 실패하는 유일한 이유는 아닙니다. 다른 실패 시나리오에는 다음이 포함됩니다:

쿼리 시간 초과

사용자가 설정한 최대 시간 제한에 도달하는 느린 쿼리입니다. 느린 쿼리와 동일한 이유로 발생하며 총_쿼리_타임아웃으로 추적됩니다.

최대 결과 창 초과

클러스터에 설정된 maxResultWindow 제한보다 더 많은 조회 수가 필요한 쿼리가 있을 때 이 문제가 발생합니다. 이 값은 기본적으로 10000이지만 관리자 옵션 API를 통해 구성할 수 있습니다. 이 값은 대량의 데이터가 실수로 스트리밍되는 것을 방지하기 위해 존재합니다.

일부 결과

이는 파티션 중 하나를 사용할 수 없고 쿼리를 받은 노드로 결과를 보내지 않은 경우에 발생합니다.

앱 허더에 의해 거부됨

앱 허더는 시스템 리소스가 주어진 한도 내에서 유지되도록 하기 위한 최종 체크포인트입니다. 대규모 쿼리 로드 또는 인덱싱 로드, 리밸런싱 작업 또는 이 세 가지의 조합으로 인해 쿼리가 한도를 초과할 위험이 있는 경우, 앱 허더는 선제적으로 쿼리를 종료하여 실행을 방지합니다.

컨텍스트 내 검색 실패

여기에는 인덱스 파일과의 상호 작용 문제 등 블레브 내에서 발생할 수 있는 모든 오류가 포함됩니다.

일관성 오류

일관성 매개변수 지정에 오류가 있으면 쿼리가 실패합니다. 이러한 매개변수에는 데이터의 일관성 수준, 결과 및 기타 관련 변수가 포함됩니다.

나쁜 요청

이것은 기본적으로 쿼리 작성 시 사용자 실수인 가장 간단한 오류입니다. 오타, 잘못된 JSON 구조부터 잘못된 쿼리 문자열까지 다양합니다.

벡터 검색의 도입으로 카우치베이스의 검색 기능은 이전의 경계와 사용 사례를 넘어 확장되었습니다. 이 기능을 효과적으로 활용하려면 사용자는 다양한 조건에서 데이터 쿼리, 색인화, 시스템 동작 관리 등의 기능을 이해해야 합니다. 벡터 검색과 그 기능 및 성능에 대해 더 깊이 이해하려면 사이트의 다른 블로그를 살펴보세요.

다음 단계

• • 자세히 알아보기 벡터 검색 개념 블로그에서 튜토리얼과 개념 등 다양한 정보를 확인할 수 있습니다.
  • 카우치베이스 카펠라 무료 체험판 에는 벡터 검색을 비롯한 다양한 기능이 포함되어 있습니다. 지금 바로 사용해 보세요.