한 테이블에 담은 이벤트 로그

사용자 행동 로그를 뽑아야 해서 관련 테이블을 찾아봤다. 종류별로 나뉘어 있을 것으로 생각했는데 테이블이 하나였고 이벤트 종류가 컬럼 하나로 구분되고 있었다.

Open Table of contents

하나뿐인 로그 테이블

이 구조에서는 새 종류의 행동을 기록하려고 해도 테이블을 안 만들어도 된다. 값 하나를 새로 쓰면 그것이 새 이벤트가 된다.

기록하는 쪽 코드도 종류에 상관없이 같은 자리로 들어가므로 단순하다. 새 기능을 붙일 때 스키마 변경이 없다는 것이 이 설계의 핵심적인 이점이었다.

스키마가 안 바뀌면 배포할 때 DB 작업이 없고 되돌리기도 쉽다. 로그를 남기는 것 때문에 배포가 무거워지지 않는다.

조회하는 쪽에서도 여러 종류를 한 번에 가져올 때는 오히려 편하다. 시간 순서로 사용자의 행동을 늘어놓는 것이 조인 없이 된다.

대신 특정 종류만 뽑을 때는 그 컬럼의 값을 문자열로 맞춰야 한다. 이 문자열을 틀리게 적어도 아무도 안 알려 주고 결과만 0건이 된다.

그래서 이벤트 이름을 코드에서 상수로 뽑아 쓰게 했다. 문자열을 직접 적는 자리가 남아 있으면 언젠가 오타가 조용히 들어간다.

어떤 이벤트가 있는지를 스키마가 알려 주지 않으므로 그 목록은 사람이 문서로 만들어야 했다. 실제로 어떤 값이 쓰이는지를 집계해 보니 문서에 없던 것이 몇 개 나왔다.

조회가 전부 그 컬럼을 조건으로 쓰므로 인덱스도 거기에 몰린다. 게다가 이 테이블은 모든 이벤트가 들어오니 가장 빨리 자라므로 조회할 때 기간 조건을 함께 걸게 했다.

기존 조회 중에 특정 계정들을 제외하는 것이 있었는데 그 계정을 식별자로 박아 두고 있었다. 그런 계정이 하나 늘어나면 조건이 조용히 부족해진다.

그래서 역할을 기준으로 거르도록 조건을 손봤다. 다른 DB의 테이블과 조인하는 조회도 있었는데 그것은 두 DB가 같은 곳에 있다는 전제에 기대므로 그 전제를 문서에 명시했다.