Haze

오늘 하루 Hackers Pub iOS 앱에 작업한 것들

1. 긴 글을 잘라서 보여줄 때 HTML truncate할 때 HTML 태그 구조에 이상이 없게끔 안전하게 처리
2. 글 리스트 보여줄 때 렌더링 최적화
3. 글 리스트 / 상세 페이지에서 인용된 글도 제대로 보이도록 수정하고 인용 기능 추가
4. 글에 반응하기 기능 추가
5. 누가 글을 공유하거나 인용했는지 화면 추가

조금만 더 하면... 앱스토어 올려도 되겠다...

오랫만에 데이터베이스 관련 지뢰를 밟았다.

진행하고 있는 프로젝트는 도메인 특성에 맞게 용어들에 대한 fuzzy search 정도만 잘 구현하면 괜찮다보니 별도의 검색 엔진 없이 pg_trgm을 통해서 검색을 구현했다.

몇 주 전에 이미 pg_trgm을 위해 테이블에 GIN 인덱스를 추가하고 잘 돌아간다고 생각했는데 쿼리가 조금 더 복잡해지니까 로컬의 테스트 데이터베이스에선 굉장히 빠른데 실제 데이터베이스에선 한참 걸려서 사용이 어려울 정도가 되었다.

쿼리도 뽑고 EXPLAIN도 돌려보니까 당연하게도 실제 서버에서만 인덱스를 안 타고 있어서 왜 그런걸까 확인해보니...

1. PostgreSQL에는 개발자가 수동으로 vacuum이나 analyze 등을 돌리거나 할 수 있지만, 데이터베이스가 임계치 조건에 만족하면 자동으로 autovacuum(vacuum & analyze)이 동작한다.
2. autovacuum은 인덱스를 거는 것만으로는 작동하지 않으며 설정해둔 임계치만큼 일정 수준 데이터가 변경(추가, 수정)되어야 작동한다. ^[1] 하지만 해당 테이블에는 쉽게 내용이 추가되거나 업데이트될 일이 거의 없는 고정된 데이터가 담겨있었다. (e.g. 진단명, 약제 데이터, 병원체 등의 의학 용어)
3. 인덱스를 걸어뒀으니 알아서 반영될 것이라고 나이브하게 생각하고 있었고, 당연하게도 autovacuum이 걸릴 일이 없어서 인덱스를 걸고도 2주 이상 그 인덱스는 타지 않았다.

VACUUM은 굉장히 성능에 영향을 줄 수 있는 비싼 동작이지만 ANALYZE는 그렇지 않다. ANALYZE는 읽기 / 쓰기 락이 아닌 ShareUpdateExclusiveLock을 활용해 동작하니 동시에 같은 테이블 혹은 연결된 테이블의 DDL 쿼리가 돌고 있는게 아니라면 충돌이 없다. ^[2]

역시 Postgres를 쓸 때는 autovacuum같은 것만 믿지 말고 인덱스를 추가하거나 하는 상황에서는 재깍재깍 ANALYZE를 쓰자는 교훈을 받았다.

1. 문서 ↩︎

2. 문서 ↩︎