2023/04/12 ~ 2023/04/26

[danbi5228]

다음 스터디

2023-04-~17~ 26 pm 10:10 ~월요일~ 수요일

정리 범위

1. 11.8
2. 12장 ~ 12.1.1

[github-actions[bot]]

정리 범위 무작위 선택 봇 🔎

1. 단비
2. 장현

[danbi5228]

11.8 쿼리 성능 테스트

• 작성된 쿼리가 얼마나 효율적이고, 더 개선할 부분은 없는지 확인하려면 먼저 실행 계획을 살펴보고 문제될 만한 부분이 있는지 검토
• 쿼리를 직접 실행해 보면서 눈으로 성능을 체크할 때는 여러 가지 방해 요소가 있어서 이를 간과하고 성능을 판단하는 것은 매우 위험함
• 성능 판단을 위해 고려해야하는 부분과 어떤 영향 요소가 있는지 살펴보는 것이 필요

11.8.1 쿼리의 성능에 영향을 미치는 요소

11.8.1.1 운영체제의 캐시

• MySQL 서버는 운영체제의 파일 시스템 관련 기능 (시스템 콜)을 이용해 데이터 파일을 읽어옴
  • InnoDB 스토리지 엔진은 일반적으로 파일 시스템의 캐시나 버퍼를 거치지 않는 Direct I/O를 사용하므로 운영체제의 캐시가 큰 영향을 미치지 않음
  • MyISAM 스토리지 엔진은 운영체제의 캐시에 대한 의존도가 높기 때문에 운영체제의 캐시에 따라 성능의 차이가 큰 편
• 운영체제가 관리하는 캐시나 버퍼는 공용공간이므로 MySQL 서버와 같은 응용 프로그램이 종료된다고 해도 여전히 남아있을 수 있음
• 캐시나 버퍼가 전혀 없는 상태에서의 쿼리 성능 테스트를 하려면 캐시 제거 후 진행하는 것이 좋음
  • 리눅스 기준
  • sync; 캐시나 버퍼의 내용을 디스크와 동기화
  • echo 3 > /proc/sys/vm/drop_caches; 운영체제에 포함된 캐시의 내용을 초기화

11.8.1.2 MySQL 서버의 버퍼 풀(InnoDB 버퍼 풀과 MyISAM의 키 캐시)

• 운영체제의 버퍼나 캐시와 마찬가지로 MySQL 서버에서도 데이터 파일의 내용을 페이지(또는 블록)단위로 캐시하는 기능을 제공
  • 버퍼 풀: InnoDB 스토리지 엔진이 관리하는 캐시
  • 인덱스 페이지를 포함해 데이터 페이지까지 캐시하고, 쓰기 작업을 위한 버퍼링 작업까지 겸해서 처리
  • 키 캐시: MyISAM 스토리지 엔진이 관리하는 캐시
  • 주로 읽기를 위한 캐시 역할을 수행. 제한적으로 인덱스 변경만을 위한 버퍼 역할을 수행
  • 인덱스를 제외한 테이블 데이터는 모두 운영체제의 캐시에 의존
• MySQL 서버가 한 번 시작되면 스토리지 엔진의 캐시 내용을 삭제할 수 있는 방법이 없음. 초기화하려면 서버 재시작이 필요
• InnoDB 버퍼 풀은 MySQL 서버가 종료될 때 자동으로 덤프됐다가 다시 시작될 때 자동으로 적재됨
  • 자동으로 덤프되고 적재되지 않길 원하는 경우; SET GLOBAL Innodb_buffer_pool_load_at_startup=OFF;
  • 버퍼 풀의 내용을 덤프하지 않고자 하는 경우; SET GLOBAL Innodb_buffer_pool_dump_at_startup=OFF;

11.8.1.3 독립된 MySQL 서버

• MySQL 서버가 기동 중인 장비에 웹 서버나 다른 배치용 프로그램이 실행되고 있다면 테스트하려는 쿼리의 성능에 영향을 미침
• 서버 외에도 테스트 쿼리를 실행하는 클라이언트 프로그램이나 네트워크 영향 요소도 고려해야 함

11.8.1.4 쿼리 테스트 횟수

• 실제 쿼리의 성능 테스트를 MySQL 서버의 상태가 워밍업된 상태(위에서 언급한 캐시나 버퍼가 필요한 데이터로 준비된 상태)에서 진행할지 아니면 콜드 상태(캐시나 버퍼가 모두 초기화된 상태)에서 진행할지도 고려해야 함
  • 일반적으로 워밍업된 상태를 가정하고 테스트하는 편
  • 실제 서비스 환경의 쿼리는 대부분 콜드 상태보다는 워밍업 상태에서 실행된다고 볼 수 있음
• 운영체제의 캐시나 MySQL의 버퍼 풀, 키 캐시는 그 크기가 제한적이므로 쿼리에서 필요로 하는 데이터나 인덱스 페이지보다 크기가 작을 경우 플러시 작업과 캐시 작업이 반복해서 발생하기 때문에 한 번 실행해서 나온 결과를 그대로 신뢰해서는 안됨
• 테스트하려는 쿼리를 번갈아 가면서 6-7회 정도 실행 후 처음 한두번의 결과를 제외한 나머지 결과의 평균값을 기준으로 비교하는 것을 권장
  • 처음 실행된 쿼리는 운영체제의 캐시나 MySQL의 버퍼 풀, 키 캐시가 준비되지 않을 때가 많아서 대체로 많은 시간이 소요될 수 있음
• 쿼리 성능 비교도 결국 상대적인 비교이므로 어떤 서버에서도 그 시간 내에 처리된다고 보장할 수 없음
• 실제로는 많은 쿼리가 동시 실행중인 상태로, 자원을 점유하기 위한 경합 등으로 인해 항상 테스트보다는 느린 처리 성능을 보이는 것이 일반적

[mojh7]

12. 확장 검색

MySQL 서버의 대표적인 확장 검색기능인 전문 검색과 공간 검색 기능

12.1 전문 검색

전문 검색은

• MySQL 서버 같은 RDBMS에서 인덱스라고 하면 보통 B-TREE 자료 구조를 사용해 짧은 단어를 검색하는 것으로 생각한다

• 하지만 예전부터 용량이 큰 문서를 단어 수준으로 잘게 쪼개어 문서 검색을 하게 해주는 기능이 있었고 이러한 검색을 전문 검색이라 한다

8.0 이전 버전에서는 일부 스토리지 엔진을 사용하는 테이블만 전문 검색을 활용할 수 있었고

8.0에서는 가장 사용률이 높은 InnoDB 스토리지 엔진에서도 사용할 수 있게 개선됨

문서의 단어들을 분리해서 형태소를 찾고 그 형태소를 인덱싱하는 방법은 서구권 언어에 적합하지 한국어, 중국어, 일본어에는 적합하지 않다

이런 단점을 보완하기 위해 8.0버전에서 n-gram 파서가 도입됐다

• 형태소나 어원과 관계없이 특정 길이의 조각(Token)으로 인덱싱하는 방법
• 한글의 경우 형태소 분석 자체만으로 비용이 많이 소모되기에 n-gram 검색 기능은 한글 문석 검색에서 이용차기가 매우 높다

12.1.1 전문 검색 인덱스의 생성과 검색

MySQL 서버에서는 2가지 알고리즘을 이용해 인덱싱할 토큰을 분리해낸다

• 형태소 분석(서구권 언어의 경우 어근 분석)
• n-gram 파서

형태소 분석

• 문장의 공백과 같은 띄어쓰기 단위로 단어를 분리하고, 각 단어의 조사를 제거해서 명사 또는 어근을 찾아서 인덱싱

• 하지만 MySQL 서버에서는 단순히 띄어쓰기 기준으로 토큰을 분리해서 인덱싱

  • 형태소 분석이나 어근 분석기능은 구현 되어있지 않음

n-gram

• 문장 자체에 대한 이해 없이 띄어쓰기 단위로 분리하고, 그 단어를 주어진 길이(1~10)로 쪼개서 인덱싱

• n 값은 ngram_token_size 시스템 변수로 설정할 수 있다

  • 기본값은 2이고 1 ~ 10 사이의 값 설정할 수 있음

• 읽기 전용이며, MySQL 서버의 설정 파일을 이용해 서버가 시작될 때만 변경할 수 있다

• 길이에 따라서 1이면 uni-Gram, 2이면 bi-gram, 3이면 tri-gram이라고 함

• 가장 일반적으로 bi나 tri-gram이 사용됨

주의할 점

• 테이블의 전문 검색 인덱스를 생성할 때 WITH PARSER ngram 옵션이 있어야 n-gram 파서를 사용하는데 없으면 기본 파서(공백으로 구분)를 사용하게됨

책에 쿼리를 보면, 조회가 된 경우

• ngram_token_size와 같은 길이, '단편적인' 글자에서
  • 선행 2글자 검색 '단편'
  • 후행 2글자 검색 '적인'
• 단어 전체 검색 '단편적인'

조회가 안된 경우

• ngram_token_size보다 작은 길이로 '이', '책'

결론은

• 검색 불가능 : 검색어의 길이 < ngram_token_size

• 검색 가능 : 검색어의 길이 >= ngram_token_size

그리고 단어의 시작 부분이 아니고 중간이나 마지막 부분도 n-gram이 검색할 수 있다는 것이 중요한 특징이다

218~219p 표를 보면 ngram_token_size=2 일 때 1글자인 '이'는 버려짐

n-gram 파서는 전문 검색 인덱스를 생성할 때 말고도 쿼리의 전문 검색에서도 사용된다

SELECT COUNT(*) FROM tb_bi_gram
WHERE MATCH(title, body) AGAINST ('단편적인' IN BOOLEAN MODE);

ngram_token_size=2 일 때 이미 2글자씩 토큰을 잘라서 인덱스에 저장하고 있는데

어떻게 4글자의 검색어를 이용해서 결과를 찾을 수 있나?

• 검색할 때도 ngram_token_size 시스템 변수값에 맞게 토큰을 잘라냄
• '단편', '편적', '적인' 이렇게 전문 검색 인덱스를 이용해 동등 비교 조건으로 검색
• 검색한 결과들의 도큐먼트 ID로 그루핑하고, 그루핑된 결과에서 각 단어의 위치를 이용해 최종 검색어를 포함하는지를 식별
  • 전문 검색 인덱스의 경우 PK와 별개로 레코드별로 id를 가지는데, 이를 도큐먼트 ID 라고 한다
  • 서버의 전문 검색 인덱스에서 도큐먼트는 레코드 또는 row와 동의어로 사용됨

주의할 점

• 한 번 전문 검색 인덱스가 생성되면 ngram_token_size 시스템 변수는 변경하면 안된다
• 생성했을 때와 쿼리를 했을 때 다르면 검색 결과가 기대한 값과 다름