시작하기 전에2편에서 메트릭 데이터를 MySQL과 ClickHouse에 똑같이 넣고 비교했을 때, 컬럼형인 ClickHouse가 대부분의 쿼리에서 크게 앞섰다.그런데 대규모 메트릭 데이터를 효과적으로 처리하는 방법이 이 둘만 있는 건 아니다. 이미 쓰던 MySQL에 사전집계를 더해볼 수도 있고, 시계열 전용으로 나온 TimescaleDB도 있고, Cassandra나 Druid를 떠올릴 수도 있다. 2편을 마무리하면서 이 선택지들이 계속 걸렸다. 같은 문제를 이 DB들로 풀면 어떻게 다를까 싶었다.그래서 3편에서는 2편과 같은 메트릭 수집 시나리오를 그대로 두고, 네 가지 방식을 하나씩 정리해봤다. 먼저 각각이 어떤 DB인지 개념을 살펴보고, 그중 직접 띄워볼 수 있는 두 가지(MySQL + 사전집계, T..
프로젝트를 하다 보면 Map이나 Set 같은 값을 그대로 DB에 넣고 싶을 때가 있다. 정규화하기는 애매한 값이라든가, 특정 row에 딸린 id 목록이라든가, 통째로 읽고 쓰는 설정 덩어리 같은 것들이다. 관계로 풀어서 별도 테이블을 만들기는 번거롭고, 마침 MySQL에는 JSON 타입이 있다. 그래서 엔티티 필드를 Map로 두고 JSON 컬럼에 직렬화해서 저장한다. 편하다.그런데 문득 궁금해졌다. 이게 DB 안에서는 실제로 어떻게 처리될까? 성능상 괜찮을까? "JSON 쓰지 마라" 같은 말은 들어봤지만, 정작 왜 그런지는 깊이 따져본 적이 없었다.결론부터 말하면, JSON 컬럼은 데이터를 어떻게 접근하고 얼마나 큰지에 따라 충분히 쓸 만하기도, 독이 되기도 한다.그래서 직접 MySQL 8.0을 띄워놓고..
시작하기 전에1편에서 컬럼형 DB가 왜 빠른지를 이론으로 정리했었다. 필요한 컬럼만 읽고, 같은 타입이 모여 있어 압축이 잘 되고, Zone Map으로 블록을 건너뛰고, 단건 쓰기는 약하지만 벌크는 강하다는 식의 이야기들이었다.이번 편에선 그게 실제로 그런지 직접 측정해봤다. MySQL과 ClickHouse를 같이 띄워서, 같은 데이터를 양쪽에 적재하고, 같은 쿼리를 던졌다. 결과는 1편 이론이 거의 그대로 입증된 부분이 많았고, 한두 가지는 미묘하게 어긋나기도 했다.전체 코드와 스크립트는 GitHub repo에 올려뒀다. 직접 재현해보고 싶으면 그대로 돌려보면 된다.시나리오 - 메트릭 모니터링비교 시나리오는 1편 마지막에 다뤘던 메트릭 모니터링 으로 정했다. 데이터 모양이 시계열이라 직관적이고, 1편에..
"대규모 시스템 설계 면접" 책을 보다 보면 메트릭 모니터링이나 광고 클릭 집계 챕터에서 컬럼형 DB(컬럼 지향 데이터베이스)가 해법으로 툭툭 나온다. 근데 "왜 하필 여기서 컬럼형이지?"가 잘 와닿지 않았다. 평소에 MySQL만 쓰다 보니 더 그랬던 것 같다.그래서 한 번 제대로 정리해보기로 했다. 글이 길어질 것 같아서 두 편으로 나눴는데, 이번 편은 이론이다. 컬럼형 DB가 뭔지, MySQL 같은 row DB와 내부적으로 뭐가 다른지, 어떤 워크로드에서 빨라지는지를 정리한다. 다음 편에서는 DB를 직접 띄워서 같은 데이터로 MySQL과 성능을 비교해볼 생각이다.컬럼형 DB란 - 디스크에 데이터를 늘어놓는 방식의 차이컬럼형 DB를 한 줄로 설명하면 이렇다.같은 테이블 데이터를, 디스크에 컬럼 단위로 ..
최근 서로 다른 트랜잭션에서 겹치지 않는 FK 값을 가진 엔티티들을 동시에 삽입할 때 데드락이 발생한 케이스가 있었다. 분명 범위가 겹치지 않는데 왜 데드락이 걸리는 걸까?1. 결론: 유니크/외래 키 제약조건이 데드락을 유발한다핵심 원인외래 키(Foreign Key)이거나 유니크 제약 조건(Unique Constraint)이 걸려 있다면, 데드락 발생 확률이 비약적으로 높아진다.데드락 발생 메커니즘상황: FK 에는 유니크 제약 조건이 걸려있고 기존 데이터는 10, 20 이 존재한다고 가정. 격리 수준은 REPEATABLE READ.트랜잭션 A (INSERT 12): 유니크 체크를 위해 10~20 사이에 공유 잠금(S-Lock, 갭 락)을 획득트랜잭션 B (INSERT 14): 마찬가지로 10~20 사이에..
일반 은행과 토스뱅크의 거래 내역 조회 방식 비교 및 시스템 아키텍처일반 은행 앱의 거래 내역 조회 방식의 불편함일반 은행 앱은 거래 내역 조회 시 상단에 기간 설정을 요구한다. 지정된 기간만큼만 스크롤하여 조회할 수 있으며, 그 이상을 조회하려면 유저가 직접 조회 기간을 변경해야 한다. 반면, 트위터, 인스타그램, 카카오톡 등 많은 인터넷 서비스들은 기간 설정을 요구하지 않고, 스크롤만 계속하면 십수 년 전의 글까지 나열되는 우아한 스크롤 UI를 제공한다. 일반 은행이 이러한 불편한 인터페이스를 제공하는 이유는 시스템 아키텍처 때문이다.은행 시스템의 일반적인 분리 구조 (채널계와 계정계)계정계 (Core Banking System)실제로 유저의 돈을 다루며 원본 데이터가 저장되는 영역이다. 장애나 오류..
만약 서버 → 클라이언트로 큰 크기의 파일을 생성해서 반환해야 된다고 생각해보자. 예를 들어 전체 유저에 대한 통계 데이터를 생성 + 압축해서 클라이언트에게 반환해야 한다고 해보자. 만약 완성된 전체 데이터의 크기가 3GB 라고 하면 메모리가 3GB 이하인 (혹은 그 이상이어도) 서버는 버티지 못하고 OOM 으로 죽어버릴 것이다. 또한 통계성으로 유저에 대한 이런저런 정보를 모두 모아야 해서, 생성하는데 시간이 오래걸리는 데이터라면 timeout 도 발생할 가능성이 있다. 이러한 문제를 어떻게 해결하면 좋을까??1. 스트리밍 다운로드가장 먼저 생각난 해결책은 스트리밍으로 파일을 반환하는 방법이다. 일반적으로라면 아래의 과정을 따를텐데, 1. 전체 유저에 대한 데이터 생성2. `.zip` 으로 압축3. 클..
끝내주는 회고를 쓰고 싶어 계속 미루고 있었지만 역시나 미뤄도 퀄리티는 크게 달라지지 않기에, 무작정 써보기로 합니다. 무엇보다 블루멜론이 될 순 없기 때문에 어서 2024 상반기 회고를 써보겠습니다.싸피아무래도 올해 상반기를 관통하는 가장 큰 키워드다. 1월에 싸피 11기 대전 캠퍼스에 입과했고 6개월 동안 알고리즘, 자바, 스프링 등 이론 학습과 한 개의 프로젝트를 진행했다. 아래처럼 노션에 내용을 정리하면서 공부했다. 각 페이지 별로 내용도 꽤 많고 개수도 70개가 넘는 것을 보고 그래도 열심히 공부했구나 하는 뿌듯함이 있었다. 싸피에는 각 반에 한 분씩 강의를 해주시고 학습에 도움을 주시는 선생님이 계신다. 작년, 졸업 후 혼자 공부하면서 가장 어려웠던 점을 꼽자면 '모르는 게 있을 때 물어볼 사..
세 번째이자 싸피 퇴소로 인해 마지막이 될 싸터-뷰(방금 정함) 인터뷰이는 싸피 1학기 마지막 관통 프로젝트를 함께 했던 김수영님이다. 수영이에 대한 나의 첫인상은 말하는 톤이나 태도가 되게 여유롭고 신뢰감을 준다는 것이었다. 자기소개 시간에 발표하는 것을 좋아한다고 해서 그런 강점을 잘 알고 활용하고 있구나 생각했다. 그때쯤에 내가 만들고 싶었던 나의 이미지가 '여유로운 사람' 이어서 저 사람의 어떤 부분이 그러한 느낌을 주는 걸까 생각해 봤던 기억이 있다. 나중에 친해지고 스터디와 등산, 싸각런(싸피 모여서 각자 러닝ㅎ), 1학기 마지막 프로젝트까지 함께하며 남들을 잘 배려하고 배움에 대한 열정을 기반으로 뭐든 열심히 하는 모습이 정말 배울 점이 많은 친구라는 생각이 들었다. 자기소개 때 본인은 개발..
지난달 첫 번째 인터뷰에 이어 두 번째 인터뷰를 진행하게 됐다. 이번 인터뷰이는 역시 같은 반의 고승희 님이다. 특히 승희님은 싸피셜로도 함께 활동하고 있고, 평소 기록에 관심이 많은 것 같아 보여서 궁금한 점들이 있었다. 풀스택을 지향하긴 하지만 백엔드를 중점으로 배우게 되는 싸피 과정에 프론트엔드 경험을 가지고 입과 하시기도 해서 요즘 어떤 생각과 고민을 하고 계신지 궁금해 인터뷰를 요청드렸다. 평소 개인적으로 어떻게 기록을 하고 있나요? 싸피 수업에서 배운 내용은 보통 노션에 기록하는 것 같아요. 환경 설정하는 방법까지도 최대한 적어 놓으려고 노력해요. 왜냐면 나중에 집 가서 혼자 하려고 하면 어렵거든요. 제가 사소한 거 많이 적어놓으니까 친구들이 뭐 기억 안나는 거 있으면 와서 물어보는데 제가 뭐..