seaniiio 블로그

현재 진행하는 프로젝트에서 검색 기능을 지원하기 위해 fulltext index를 사용중이다. 세 개의 컬럼에 fulltext index를 걸어주고 있고, n-gram size도 1로 설정했기 때문에, 인덱스 용량을 고려해보면 좋겠다고 생각했다. 인덱스 크기를 고려해야 하는 이유 중 하나가 버퍼풀 cache miss로 인한 disk i/o 과다 발생이라는 것을 알게 됐고, 해당 내용을 중심으로 검색 기능을 개선한 과정을 정리해봤다. 이 글의 모든 내용은 MySQL innodb 엔진 기준으로 설명할 것이다. 📍 디스크 I/O 데이터베이스의 데이터들은 디스크에 영속화된다. 그런데 디스크에 존재하는 데이터에 접근하는 시간은 메모리에 접근하는 시간에 비해 매우 느리다. 만약 HDD에 접근한다 하면 ..

현재 개발하고 있는 서비스에는 검색 기능이 존재한다. 콘텐츠 제목, 크리에이터의 이름, 콘텐츠에 나오는 장소들의 이름 중 하나에 걸리면 검색 결과로 나오는 구조이다. 현재는 데이터가 별로 없어서 검색이 느리다고 체감한 적이 없었다. 그런데 만약 많은 데이터가 쌓이면 검색 속도가 얼마나 느려질까? 많이 느리다면 속도를 어떻게 개선할 수 있을까? 이 글을 읽으면 좋은 대상은 아래와 같다.검색 기능을 구현하려는 사람, MySQL의 fulltext index과 전문 검색 기능을 도입하려는 사람LIKE 쿼리를 통해 검색 기능을 구현한 사람📍 쿼리 속도 테스트 환경 검색에 활용되는 테이블은 content, creator, place이고, 연관관계를 생각했을 때 총 4개의 테이블을 이용한다. t4g.small 볼륨..

나는 DB와 MySQL에 대해 한 번이라도 깊게 공부하지 않았고, 인덱스가 조회 성능을 향상시킨다는 정도로만 알고 있었다. 이번에 프로젝트에 검색 기능을 도입했는데, 아직은 느리다는 체감을 하지는 못했으나, 데이터가 쌓일수록 느려질 수 있겠다는 생각이 들어 인덱스를 찍먹해봤고, 그 내용을 공유하고자 한다. 이 글을 읽으면 좋은 대상은 다음과 같다.인덱스가 무엇인지 궁금하지만, 이름만 들어봤지 개념이나 사용법은 잘 모르는 사람MySQL에서 인덱스가 어떻게 저장되고, 그 구조가 탐색 속도를 어떻게 높여주는지 알고 싶은 사람, MySQL의 인덱스 종류가 궁금한 사람✏️ 인덱스인덱스는 데이터를 빠르게 찾기 위한 도구이다. 어떤 데이터를 찾기 위해 테이블 전체를 뒤지지 않아도 되게끔, 목차를 제공하는 것이다. 예..