[백엔드] timestamp를 압축 시켜보자

Contents

대부분의 서비스에서 timestamp를 압축할 필요성은 없다.

물론 하면 좋겠지만, 굳이 안하는 경우가 많다.

 

전자제품 카테고리의 물품리스트를 한페이지에 30개 정도씩 뿌려준다고 가정해보자.

전체 개수가 30개 인것이니까, "created_at": 2025-12-17T01:00:00+00:00 정도의 문자열이 30개만 반복되는 것이다.

 

 

 

 

 

그런데, 실시간 시스템이나 하드웨어 센서 등의 데이터를 차트로 보여줘야하는 대시보드 서비스라면 얘기가 달라진다.

 

생각해보자, 5분마다 측정된 센서 A, B, C에 대해서, 총 3일치의 데이터를 한개의 차트에 그려야 한다고 가정한다.

 

하루를 기준으로

288(5분마다 측정) * 3(센서 3개) 이므로, 864개의 데이터가 하루에 쌓인다. 3일간의 데이터임으로 2592개의 데이터를 하나의 차트에 뿌려줘야 한다.

 

자료구조상, 값 1개당 created_at을 뿌려준다고 하면, 2592개의 created_at를 보내주게 된다.

 

자 그러면, 2025-12-17T01:00:00+00:00 문자열은 약 25byte 이다. 즉, 2592개를 보내면, 64800 bytes 약 63.3KB를 전송하게 된다.

실제로는 json형태로 보낼 가능성이 높으니까, json을 표현하기 위한 따옴표, 콤마, 대괄호 등이 포함되면, 더 많은 용량을 네트워크로 태우게 된다.

 

 

 

 

별로 안된다고 생각할 수 있다.

그러나, 센서 값이 아니라, 날짜/시간을 표시하는데에만 64KB가 사용된 것이고, 다른 정보도 포함된다면 더 많은 양을 사용하게 될 것이다.

무엇보다, 센서의 주파수가 5분에 1개 측정인 것인데, 주파수를 올려서 1분에 1개라면?, 1초에 1개라면? 더 많은 용량을 "날짜/시간"을 표시하는데 사용될 것이다.

 

 

 

 

timestamp의 용량을 줄여보자

가장 간단하면서도 확실하게 날짜/시간 용량을 줄일 수 잇는 방법은, Epoch를 이용하는 것이다.

Unix Epoch 혹은 Unix timestamp라고 부르기도 하는데, 1970-01-01T00:00:00Z을 기준으로 얼마나 많은 시간이 흘렀는 가? 를 표현한다.

 

 

시간이라는 개념이 결국, 순서와 간격이 있는 데이터라는 점을 감안하면, 기준 시점으로 부터 얼마나 지났는가?를 표현할 수 있다.

 

Unix timestamp에는 2가지 표현방법이 있는데, 초 단위 표현, 밀리초 단위 표현 2개로 나누어 진다.

 

• Unix timestamp(s)
  • ex) 1734416625
  • 길이: 10bytes
• Unix timestamp(ms)
  • ex) 1734416625123
  • 길이: 13bytes

단순히 보기만 해도 알겠지만, 거의 2배의 압축 효과를 보인다.

 

 

다시 동일한 상황을 가정해보겠다.

5분마다 측정된 센서 A, B, C에 대해서, 총 3일치의 데이터를 한개의 차트에 그려야 한다고 가정한다.

 

Unix timestamp(ms)를 기준으로, 13 * 2592(센서 데이터 개수) = 33,696 bytes 즉, 약 34KB이다.

 

64KB -> 34KB 약 50%가 절약 된 것을 볼 수 있다.

 

datetime.now().timestamp() * 1000
# 1765986916147.323

 

 

 

범위

32bit 시스템에서 부호 있는 32bit호환 모드로 작성된 프로그램은 1901년 12월 13일 ~ 2038년 1월 19일 이후의 날짜를 나타낼 수가 없다.

 

그래서, 그 유명한 2038년 문제가 이 문제이다.

 

그런데, 64bit 시스템에서는 부호가 있다고 해도 1970년을 기준으로 2920억년 이상 표현이 가능하기 때문에, Epoch가 시간대를 표현하지 못하는 것을 걱정하기 전에, 내 서비스가 2920억년 이후에도 있을지 고민해봐야 한다.

 

 

최적화

더욱 압축시킬 수 있는 방법이 있는데, 바로 base timestamp를 정하는 것이다.

예를 들면, 제공할 수 있는 데이터가 기준 timestamp인 1734416000000 이후로 들어온 데이터라는 가정이 있다면,

base_at: 1734416000000

data: [
    {created_at: 625123},
    {created_at: 625124},
    {created_at: 625125},
]

 

 

위와 같은 방식으로 더 줄일 수 있을 것이다.

 

목적은 다르지만, snowflake에서도 timestamp를 넣기 위해서, epoch 기반으로 비트 효율적으로 구성한다.

 

결론

대부분의 경우 실시간, 센서, 차트 서비스 등은 timestamp를 epoch 방식을 사용하는 것이 대부분 좋다.