시계열 데이터를 90% 넘게 압축하는 법 — TimescaleDB 하이퍼코어 뜯어보기

시계열 데이터는 왜 이렇게 빨리 쌓일까

서버 모니터링, IoT 센서, 주식 시세, 사용자 이벤트 로그... 이런 데이터들의 공통점이 뭘까요? 바로 '시간 순서대로 끝없이 쌓인다'는 거예요. 이런 걸 시계열(time-series) 데이터라고 불러요. 센서 하나가 1초에 한 번씩만 값을 보내도 하루면 8만 6천 건, 센서가 천 개면 하루 8천만 건이 쌓이죠. 디스크가 순식간에 가득 차요.

TimescaleDB는 이 문제를 잘 푸는 걸로 유명한 PostgreSQL 확장(extension)이에요. 그냥 PostgreSQL에 기능을 얹은 거라, 기존 SQL을 그대로 쓰면서도 시계열에 특화된 압축을 받을 수 있어요. 이번 글에서는 그 압축 엔진인 '하이퍼코어(Hypercore)'가 어떻게 데이터를 90% 넘게 줄이는지 풀어볼게요.

행을 눕혀서 열로 만든다

일반 데이터베이스는 데이터를 '행(row)' 단위로 저장해요. 한 줄에 시간, 센서ID, 온도, 습도가 쭉 들어가는 식이죠. 그런데 압축에는 이 방식이 불리해요. 서로 다른 종류의 값들이 섞여 있으니까요.

하이퍼코어의 핵심 아이디어는 오래된 데이터를 '열(column)' 방식으로 눕히는 것이에요. 약 1000개의 행을 모아서 하나의 압축된 묶음으로 만드는데, 이때 같은 컬럼끼리 모아요. 온도는 온도끼리, 습도는 습도끼리 배열로 쭉 늘어놓는 거죠. 이렇게 같은 종류의 값이 모이면 패턴이 비슷해서 압축이 훨씬 잘 돼요.

데이터 종류마다 다른 압축 기술

여기서 진짜 똑똑한 부분이 나와요. 하이퍼코어는 컬럼의 성격에 따라 다른 압축 알고리즘을 골라 써요.

시간 값에는 '델타의 델타(delta-of-delta)'를 써요. 이게 뭐냐면, 타임스탬프는 보통 일정 간격(예: 10초마다)으로 들어오잖아요. 그래서 값 자체 대신 '이전 값과의 차이'를 저장하면 전부 10으로 똑같아지고, 거기서 또 차이를 구하면 전부 0이 돼요. 0이 잔뜩이면 압축은 식은 죽 먹기죠.

소수점 숫자(온도 같은 측정값)에는 고릴라(Gorilla) 압축을 써요. 연속된 두 값을 XOR 연산으로 비교해서 달라진 비트만 저장하는 방식이에요. 온도가 21.3도에서 21.4도로 조금씩 변할 때, 바뀐 부분만 기록하니 용량이 확 줄어요.

반복되는 값에는 런렝스 인코딩(RLE)과 사전 압축을 써요. 센서ID처럼 같은 값이 계속 나오면 '이 값이 500번 반복'이라고 한 줄로 줄이는 거예요.

여기에 더해 'segment by'와 'order by' 설정으로 효율을 더 끌어올려요. 예를 들어 센서ID로 묶고(segment by) 시간순으로 정렬(order by)해두면, 같은 센서의 비슷한 값들이 한곳에 모여서 압축률도 좋아지고, 나중에 '3번 센서 데이터만 줘' 같은 쿼리도 빨라져요.

압축했는데 수정도 된다?

예전 컬럼 저장소들의 약점은 '한번 압축하면 수정이 어렵다'는 거였어요. 하이퍼코어가 영리한 건, 최신 데이터는 일반 행 방식으로 빠르게 받아두고(쓰기·수정이 잦으니까), 시간이 지나 잘 안 바뀌는 데이터만 압축 열 방식으로 옮긴다는 점이에요. 게다가 압축된 영역에도 나중에 데이터를 끼워 넣거나 수정할 수 있게 해줘서, '압축=박제'라는 기존 한계를 많이 풀었어요.

한국 개발자에게

IoT, 핀테크, 게임 로그 분석처럼 시계열 데이터를 다루는 곳이라면 솔깃할 거예요. 새 DB를 배울 필요 없이 쓰던 PostgreSQL에 확장만 얹으면 되니 도입 장벽이 낮거든요. InfluxDB 같은 전용 시계열 DB도 좋지만, 이미 PostgreSQL 생태계(백업, 모니터링, ORM)에 익숙한 팀이라면 TimescaleDB가 마음 편한 선택일 수 있어요. 다만 압축은 '잘 안 바뀌는 오래된 데이터'에 가장 효과적이라는 점, 그리고 segment·order 설정을 우리 쿼리 패턴에 맞게 잘 잡아야 진가가 나온다는 점은 꼭 기억하세요.

저장 비용이 곧 돈인 시대에, 데이터의 성격을 이해하고 거기 맞는 압축을 고르는 건 정말 큰 무기예요. 여러분 서비스에는 압축하면 효과 볼 만한 시계열 데이터, 어떤 게 있나요?