[Redis] ch.19 RediSearch로 데이터 쿼리하기

https://github.com/HongHyeongJu/StudySpace/blob/main/database/Redis/Redis_%ED%95%99%EC%8A%B5%EB%85%B8%ED%8A%B8_06.md

유데미 Redis : 개발자를 위한 Redis 완벽 가이드

ch.19 - RediSearch로 데이터 쿼리하기

모듈 소개

• 모듈
  • Redis에 로딩할 별도의 프로그램
  • 모듈을 로딩할 때 데이터 구조를 추가하고 그 구조를 다루기 위한 명령들을 추가함
  • 쉽고 간단하게 Redis의 능력을 향상시킬 수 있음
• 이 강의에서 다룰 모듈 : RedisJSON, RediSearch 모듈

  RedisJSON

• Redis 안에서 JSON 쉽게 저장하고 다룰 수 있음
• 진짜 JSON 데이터 저장 가능함 : 중첩 배열, 중첩 객체, 원하는 거의 모든 JSON 구조물 저장 가능

  RediSearch

• Redis 데이터 저장소 전체에 걸쳐 완벽한 텍스트 검색과 다양한 키에 대한 쿼리 및 필터링 기능 제공
• 수많은 해시들을 동시에 살펴보고, 특정 필터링 기준을 이욯하여 아주 구체적인 해시를 찾을 수 있음

Redis 코어와 Redis Stack

• REDIS
  • Redis 코어
  • 아주 기본적인 Redis 버전
  • 아주 간단한 데이터 유형들만 포함되어 있음
• Redis Stack
  • 기본적인 Redis 사본과 함께 그 안에 미리 로딩된 많은 모듈들을 함께 받게 됨
  • RediSearch, RedisJSON, 그리고 RedisGraph나 RedisTimeSeries, RedisBloom 같은 몇 가지 다른 모듈 포함됨
• 일반적으로 가능할 경우에는 Redis Stack을 선호함(추가적인 많은 설정을 하지 않아도 이 모든 추가 기능이 이미 포함되어 있기 때문)

프로덕션 환경에서 모듈 사용하기

• 위에서 긍정적으로 말한 Redis Stack을 강의 초반에 설치하지 않은 이유
  • 애플리케이션을 배포하는 방식, 혹은 더 구체적으로는 프로덕션 환경에서 Redis를 실행하는 방식에 따라서는 모듈을 사용하지 못할 수 있기 때문에
  • 애플리케이션을 배포할 때 Redis의 프로덕션 인스턴스에 접속해야함 -> 문제는 그 인스턴스를 어떻게 생성하느냐

    [1] AWS나 Google Cloud가 우리 대신에 Redis의 사본을 실행하도록 요청하기

• 장점 : 관리형 Redis사본이라고 부름, AWS나 Google Cloud는 설정, 보안 업데이트, 일반 업데이트, 백업 등을 Redis 관리에 관련된 모든 걸 처리해줌
• 단점 : Redis 모듈을 사용할 수 없음
  • 만일 AWS나 Google Cloud에서 애플리케이션을 실행한다면 지금까지 배운 기본 데이터 유형들을 모두 이해하는 게 중요함
  • 모듈을 사용할 수 없을 경우에 기본 구조물에 의존해야함

    [2] 직접 Redis를 실행하기, 즉 직접 버추얼 머신이나 컨테이너를 만들고 Redis를 실행

• 장점 : 모듈을 사용할 수 있음(자유롭게 RedisJSON이나 RediSearch를 로딩, 원하는 어느 모듈이나 사용할 수 있음)
• 단점 : 많은 추가적인 설정을 우리가 직접 해야 함. 최초 설정 + 이 모듈들을 설치하고 보안 업데이트를 하고 백업 등도 처리해함.
  • 모든 인프라를 설정하는 데만 추가 개발 시간이 많이 듦.

    [3] Redis라는 회사에 의지해서 회사가 우릴 대신해서 Redis를 실행하도록 하기

• 강의 초반에 우리는 redis.com으로 가서 계정을 등록 및 대시보드에서 무료 Redis 인스턴스를 생성함
  • 무료 Redis 인스턴스를 생성할 때 그 인스턴스는 실제로 AWS나 Google Cloud 또는 Microsoft Azure에서 생성되었음
  • 즉 그 Redis 인스턴스는 여전히 그 클라우드 제공사에서 실행되는 것
  • 이것들은 관리형 인스턴스 (사용자가 보안업데이트나 백업 등에 신경 쓸 필요가 없음)
  • 유일한 차이점: 다른 누군가가 관리함 (AWS나 Google Cloud가 직접 관리하는 게 아니라)
• 장점 : 모듈 사용 가능
  • Redis 사본을 실행하기 위해 redis.com을 이용한다면 여전히 AWS나 Google Cloud에서 호스팅되므로
  • 애플리케이션은 다른 외부 클라우드 제공사를 이용할 필요 없이 직접 그 회사들에 연결될 수 있음

모듈

검색 개요

• RediSearch
  • RediSearch를 이용하면 다양한 해시로 구성된 컬렉션에 임의로 쿼리를 실행할 수 있음
  • RediSearch를 사용하기 위한 2단계
    • [1] 인덱스 생성
      • 인덱스는 검색하려는 다양한 모든 레코드를 지시하는 일종의 데이터 유형
      • 검색하려는 어떤 레코드 그룹에 대해 한 번만 인덱싱을 하면 됨
      • 인덱스 만들기
        • 1. 첫 번째는 우리가 검색할 레코드를 지정
        • 2. 접두어를 제공해서 그것을 지정하기 = 어떤 문자열로 시작되는 모든 해시를 검색한다는 의미
          • ex) 'items#a1' 'items#b2' : items#라는 키를 가진 모든 해시를 검색할 수 있음
          • RediSearch는 인덱스를 생성할 때마다 접두어를 제공해서 그걸 지정
          • RediSearch는 그 해시, 이름, 색상, 가격에 관한 작은 정보를 기록하게 됨
      • 인덱스가 생성되었다면 -> 원하는 횟수만큼 사용하여 쿼리를 실행할 수 있음
      • 쿼리를 실행하고 특정한 이름, 색상, 가격 등을 가진 항목을 검색 가능
      • FT.CREATE
    • [2] 인덱스 사용
      • FT.SEARCH

인덱스

인덱스 만들고 사용하기

• 새로운 인덱스 만드는 명령어 FT.CREATE
• 두번째 줄 추가하기 위해서는 들여쓰기해야함(탭)
• 이름이 idx:cars 인 인덱스 만들기

  idx:cars ON HASH PREFIX 1 cars#
  SCHEMA name TEXT year NUMERIC color TAG

• 인덱스 사용해보기
  • name이 fast car인 해시 찾기
    • FT.SEARCH idx:cars '@name: (fast car)'
  • color이 blue인 자동차 찾기
    • FT.SEARCH idx:cars '@color:{blue}'
  • year이 1955이거나 1980인 자동차 찾기
    • FT.SEARCH idx:cars '@year: [1955 1980]'

      인덱스 자세히 알아보기

• 쿼리와 검색의 차이점
  • 쿼리
    • 쿼리를 작성할 때는 보통 언제나 기존의 정확한 기준과 일치하는 레코드 세트를 찾으려고 함
    • 쿼리는 우리가 정확한 결과 세트를 찾는 경우
  • 검색
    • 검색을 이용하여 받는 모든 결과는 기준에 정확히 부합하지 않을수도 있지만, 찾으려는 것에 아주 근접한 추측 같은 것
    • 검색은 결함이 있을 수 있는 사용자 입력이나 결함 있는 문자열을 해석하고, 가능한 최선의 결과를 보여주려는 경우
    • ex) 아마존 쇼핑몰 검색 예시
• 쿼리와 검색의 개념 꼭 구분해서 이해하기!
  • RediSearch 공식 문서에서는 둘을 모호하게 말함
  • 쿼리형 작업에 대해 이야기 하기도 하지만, 검색형 작업에 대해 얘기하는 부분도 있음
  • 구분하고 있으면 읽기가 수월함

    인덱스 명령어 분해해서 이해하기

• idx:cars ON HASH PREFIX 1 cars# SCHEMA name TEXT year NUMERIC color TAG
  • idx:cars
    • 만들고자 하는 인덱스 이름
    • idx + : + 찾는대상
    • 인덱스 삭제시 FT.DROPINDEX 사용
  • ON HASH
    • 옵션은 HASH or JSON만 가능함(JSON은RedisJSON 모듈 사용시)
  • PREFIX 1 cars#
    • 검색하려는 레코드의 인덱스를 알려주기
    • FT.CREATE는 내부적으로 cars#라는 문자열로 시작하는 모든 키를 찾음
    • 1은 찾기위해 제공하는 인덱스의 개수
    • 다른 예시 PREFIX 2 cars# trucks#
  • SCHEMA
    • RediSerach가 검사할 모든 각각의 해시의 안에서 RediSearch가 찾아보길 원하는 다양한 속성을 설명하는데 사용함
  • name TEXT year NUMERIC color TAG
    • SCHEMA 바로 뒤에 필드의 이름 나열하고 그 안에 있는 값의 타입을 나열함
    • 이름, 타입 + 이름데이터, 타입데이터
    • 만약 color부분 검색 생략하고 싶다면 명시 하지 않으면 됨

      인덱스 필드 타입

  • name TEXT, year NUMERIC, color TAG에서 TEXT, NUMERIC, TAG 등
• NUMERIC
  • 인덱스에 대해 숫자를 이용한 쿼리를 하려고 할 때 해시 안의 필드에 숫자를 저장함
• GEO
  • 지리적 좌표가 포함된 경우 필드를 표시할 때
• VECTOR
  • 레코드들 간의 유사성을 찾을 수 있게 해주는 고급쿼리
• TAG
  • 쿼리에 사용
  • 해시 안의 문자열을 쿼리 용어로 사용할 때
• TEXT
  • 검색에 사용
  • 해시 안의 필드를 검색작업에 사용할 때

    인덱스 필드 TAG와 TEXT의 차이

• TAG
  • 정확히 같은거나, 정확히 같지 않은 것을 찾을 때
  • 정답이 있는 필드
• TEXT
  • 검색작업
  • 사용자가 직접 데이터를 입력하는 경우
  • 제품 이름이나 리뷰 등
  • 정답이 없는 필드
  • 예상치 못한 문자열을 입력하는 부분

SEARCH 명령어

• 명령어 FT.SEARCH 관련 공식 문서
  • redis.io/commands/ft.search
  • 페이지를 내리다 보면 Parameters섹션에 쿼리에 관한 섹션 있음
  • 설명의 Query Syntax를 검색하면 별도의 페이지 이동이 가능함
  • https://redis.io/docs/interact/search-and-query/query/
  • 쿼리 작성 시 어려움이 있을 때 이 문서를 찾아보기!
• 검색의 예시
  • @name:(fast car), @color:{blue}, @year:[1955 1980]
  • 1955나 1980년에 생성된 자동차이면서 + 색깔이 blue인 자동차 찾기 znjfl
  • FT.SEARCH idx:cars '@year:[1955 1980] @color:{blue}'
• 쿼리 작성시 주의점
  • 쿼리는 항상 따옴표 안에 작성해야함
  • 설령 문서에 특별히 표시되어 있지 않아도 항상 쿼리를 따옴표 안에 넣기
  • 문서의 예시에서는 쿼리에 따옴표 표시를 생략한 부분도 있어서 조심하기
  • 쿼리 안에 따옴표를 사용해야 할 경우에는 바깥쪽 문자열에 사용하지 않은 따옴표를 사용하기(쿼리 바깥은 '', 쿼리 안쪽은 "")

숫자형 쿼리

• @year:[1955 1980]
  • 1955 <= year <= 1980
• @year:[(1955 (1980]
  • 1955 < year < 1980
• @year:[1955 +inf]
  • 1955 <= year
• @year:[-inf 1955 ]
  • year <= 1955
• -@year:[1955 1980]
  • year < 1955
  • 1980 < year

태그 쿼리

• @color:{blue}
  • 색상이 blue인 레코드 찾기
• @color:{blue}
  • 색상이 blue가 아닌 레코드 찾기
• @color:{red|blue}
  • red거나 blue인 모든 레코드
• @color:{light\blue}
  • 'light blue'라는 문자열이 있을 때
• 주의점
  • 불용어를 포함하면 Redis는 자동으로 필터링하여서 제거함
  • ex) @cities:{to | a | or} => Redis는 @cities:{} 로 인식함
  • 텍스트 쿼리에서도 마찬가지임

텍스트 쿼리

• 전처리 단계를 거침
  • 해시필드에 있는 텍스트 뿐만 아니라 실제 쿼리 텍스트도 약간의 전처리 단계를 거치게 됨
  • 모든 다양한 불용어들이 삭제됨 ex)a, the
• 스테밍 (stemming)이라는 기법을 쿼리에 적용함
  • 검색을 위해 어떤 어어를 쓰든지 접두어나 접미어가 있을 수 있는 복잡한 단어의 경우에는 그 단어의 더 흔한 형태로 축약됨
  • 이해를 돕는 링크 snowballstem.org/demo.html
  • 검색어를 유연하게 만들어주는 것
  • 사용자가 단어 압에 접두어를 추가해도 그 단어의 접두어가 없는 더 흔한 버전을 매칭하게 될 것임
• fast
  • @를 쓰지 않으면 해당 문자열을 이용해서 타입이 TEXT로 표시된 모든 필드에 걸쳐 검색함
• @name:(fast car)
  • fast AND car
• @name:(fast|car)
  • fast OR car (+ fast AND car)
• -@name:(fast)
  • fast를 포함하지 않은 것

퍼지 검색

• 퍼지 매칭에는 퍼센트(%) 기호를 사용함
• 와일드 카드가 아니고, 사용자가 입력한 것과 그들이 실제로 검색하려는 것 가이에 불일치하는 문자의 개수를 구하는 것
• ex) car를 검색하려던 사용자가 실수로 dar라고 입력함 => 문자 1개가 불일치함
• 문자 1개 불일치도 검색
  • FT.SEARCH idx:cars '@name:(%dar%)'
  • FT.SEARCH idx:cars '@name:(%gast%)'
• 문자 2개 불일치도 검색
  • FT.SEARCH idx:cars '@name:(%%dar%%)'
• 양쪽에 최대 3개까지 % 기호를 넣을 수 있음
• 오탈자 한두 개를 넣어도 스마트한 결과를 받을 수 있도록 하는 기법

접두어 검색

• 접두어 검색시 최소한 문자가 2개 있어야 함
  • 불가능한 경우: f, a, b*
• fa* 라고 입력하면 자동으로 쿼리가 확장되어 fast, far, fact, fawn, fantastic 등이 포함됨

검색어 전처리 기준

• 검색 작업 단계
  • [1] 자동완성 옵션 리스트를 표시하는 단계
    • 선택사항
    • fa라고 입력하면 far, fast 등의 자동완성을 표시
  • [2] 사용자가 쿼리를 제출하는 단계
    • 사용자가 fast 라고 입력하면 퍼지검색 사용
• 사용자의 오타 처리 ex) fast fasty fast car
• 검색로직은 만드는 애플리케이션에 따라 최적이 다르다 (159강. 04:00 다시 확인)