스포티파이 (Spotify)

이 스키마에 대하여

눈여겨볼 관계

tracks ↔ albums (album_tracks)

disc_number 와 position 이 연결 테이블에 있습니다. 트랙이 아니라 그 앨범에서의 자리이기 때문입니다. 같은 트랙이 한 발매에서는 3번, 다른 발매에서는 11번일 수 있습니다.

tracks → track_features

트랙마다 한 행, 분석 작업이 씁니다. 떼어 두어야 카탈로그 행이 좁게 유지되고, 특징 벡터를 다시 계산할 때 그 행을 건드리지 않습니다.

artists ↔ users (artist_members)

아티스트 프로필을 계정들이 역할과 함께 관리합니다. 밴드는 한 프로필에 접근하는 여러 사람이고, 레이블 담당자는 또 다른 사람입니다.

playlists → playlist_tracks

added_by 가 항목에 있어서 is_collaborative 가 의미를 갖습니다 — 공동 플레이리스트에 누가 무엇을 넣었는지 보입니다.

users → listening_history

context_type·context_id 가 재생이 어디서 시작됐는지를 적습니다 — 앨범, 플레이리스트, 라디오. 없으면 재생은 숫자일 뿐이고, 있으면 사람들이 실제로 무엇을 끝까지 듣는지에 대한 증거가 됩니다.

설계 판단

자주 묻는 것

tracks 에 album_id 가 왜 없나요?

한 녹음이 여러 발매에 실릴 수 있기 때문입니다 — 싱글, 정규, 컴필레이션, 디럭스. 컬럼으로 두면 실릴 때마다 중복 행이 생기고, 같은 곡의 재생 수와 좋아요가 사본마다 쪼개집니다.

오디오 특징을 왜 따로 두나요?

분석 작업이 한 번 쓰고 추천만 읽기 때문입니다. 아무도 필요로 하지 않는 컬럼 열한 개를 자주 읽히는 카탈로그 행에서 빼 두면 그 행이 좁게 유지되고, 특징을 독립적으로 다시 계산할 수 있습니다.

팟캐스트는 음악과 어떻게 같이 두나요?

타입을 가진 트랙이 아니라 podcasts·podcast_episodes 라는 자기 테이블로 둡니다. 음악과 공유하는 것이 거의 없습니다 — 앨범도 없고 아티스트 크레딧도 없고 오디오 특징도 없으며 진행 개념도 다릅니다. 한 테이블에 두면 타입 컬럼과 많은 null 이 남습니다.

listening_history 의 context_type 은 무엇에 쓰나요?

재생이 어디서 시작됐는지를 적습니다 — 앨범, 플레이리스트, 라디오. "이 곡이 인기다" 와 "이 플레이리스트가 먹힌다" 를 가르는 값이고, 대부분의 청취 로그가 필요해지기 전까지 빠뜨리는 신호입니다.

liked_songs 를 그냥 플레이리스트로 두면 안 되나요?

닮아 보이지만 순서가 없고, 사용자 외의 주인이 없고, 공유나 공동 편집이 안 됩니다. 합치면 모든 플레이리스트 질의가 진짜 플레이리스트가 아닌 한 행을 예외 처리하게 되는데, 작은 테이블 하나보다 코드가 많아집니다.