서론 TiketeerTiketeer has 5 repositories available. Follow their code on GitHub.github.com현재 저는 지인 3분과 함께 간단한 팀 프로젝트를 진행 중인데, 그 곳에서 진행 중인 ‘티케팅 서비스’ 프로젝트에서 한순간 부하가 몰리는 티케팅 환경에서도 구매의 정합성을 보장하기 위해 노력하고 있습니다. 뿐만 아니라 성능적인 개선도 이루어내기 위해 다양한 논의들을 진행하고 있습니다. 해당 글에서는 성능 개선을 위해 데이터베이스 내에서 티켓 레코드를 읽어오는 방식을 개선하고 기존 방식과 성능적으로 비교한 내용을 다루고, 최종적으로는 이를 통해 저희 서비스에 미친 영향에 대해 이야기해보도록 하겠습니다. 들어가기 앞서본격적인 성능 비교에 앞서 현재 프로..

가장 손쉽게 테이블에서 사용할 PK를 생성하는 방법은 테이블을 생성할 때 PK가 될 수치 칼럼에 AUTO_INCREMENT(MySql 기준)를 걸어주는 것이다. 이를 통하면, 개발자는 레코드를 생성할 때 PK 칼럼을 신경 쓸 필요가 없으며 DB가 알아서 순차적으로 증가시킨 값이 레코드에 포함되게 된다. 인덱스는 결국 DB에서 사용하기 위한 개념이고, 그 값을 DB가 직접 생성해주어 개발자가 신경 쓸 필요가 없다면 그걸로 된 것 아닌가? 라고 생각할 수 있으나 이러한 방식에도 결국 특정 관점에서는 한계가 존재한다. 이번 글에서는 이 한계들에 대해 알아보고 이를 극복할 수 있는 또다른 방식들에 대해 살펴보겠다. DB가 직접 관리하는 PK의 문제점 1. 분산처리 환경에서 PK 값 채번의 어려움 최근에는 대규모..

이번 글에서는 MVCC의 개념과 어떻게 동작하는 것인지, 그리고 트랜잭션 격리수준을 구현할 때 이를 어떻게 활용하고 있는지에 대해 가장 많이 쓰이는 데이터베이스 중 하나인 Mysql을 통해 정리하고자 한다. 들어가기 앞서 이번 글에서 중점적으로 다루게 될 MVCC 주제로 들어가기 전에, 먼저 트랜잭션 격리수준에 대한 배경지식이 필요하다. 트랜잭션 격리수준이란, 데이터베이스 내에서 트랜잭션들이 동시다발적으로 실행될 때 해당 트랜잭션의 조회 결과가 다른 트랜잭션에 얼마나 영향을 받게할지에 대한 수준을 의미한다. READ UNCOMMITED, READ COMMITED, REPEATABLE READ, SERIALIZABLE의 총 4가지 수준으로 구성되고 언급한 순서의 역순으로 격리 수준이 높아진다. (READ ..

페이지네이션이란? OLTP 환경에서 사용자에게 반환되는 데이터들은 대부분 특정 기준으로 정렬된 일부 데이터이다. 예를 들면 웹개발의 가장 흔한 예시인 게시판이 그렇다. 게시판은 일반적으로 한 페이지에 약 20개의 게시글들을 최신순으로 노출시키고, 사용자가 다음 페이지로 넘어가게 되면 21 ~ 40번째 데이터가 그제서야 조회되는 방식으로 구현된다. 이 상황에서 서버는 사용자에게 전체 게시글 데이터를 전달하는 것이 아닌, 사용자가 위치한 페이지에 해당하는 데이터만을 반환하도록 API 설계가 이루어지는데 이를 페이지네이션 방법론이라고 부른다. 페이지네이션 종류 일반적으로 많이 사용되는 페이지네이션 기법에는 Offset 기반 페이지네이션과 Cursor(Keyset) 기반 페이지네이션이 존재한다. Offset 기..

개인적으로 SQL의 Exists 연산자에 대한 이해도가 낮았고 이로 인해 실제로 활용을 거의 못하고 있었는데, DB 스터디를 위해 책을 읽는 도중 해당 연산자에 대한 내용이 등장해서 이 기회에 이를 확실히 정리하고 넘어가고자 한다. Exists 연산자란? Exists 연산자는 연산자 이후에 등장하는 서브쿼리에 대해 결과 데이터가 존재할 경우 True, 그렇지 않을 경우 False를 반환하는 역할을 수행한다. 말로만 설명하면 이해가 어려우니 실제 예시를 들어보면 아래와 같다. SELECT post.id, post.name FROM post WHERE post.user_id = 10 AND EXISTS ( SELECT 1 FROM comment WHERE comment.post_id = post.id AND..

개인적인 경험 상, 취업을 준비하는 개발자 지망생 분들이나 혹은 신입 내지 주니어 개발자 분들 사이에는 서브 쿼리를 사용하면 데이터의 검색 성능이 드라마틱하게 나빠질 것이라는 통념이 존재하는 것 같다. 나 또한 그렇게 생각해왔었는데 이게 정말 맞는지, 아니면 오해인 것인지 확인해보려한다. 서브 쿼리란? 서브 쿼리란 메인 쿼리가 존재하는 상황에서 메인 쿼리 내에 포함된 또 다른 쿼리를 의미한다. 어떤 절에 포함된 쿼리인지에 따라 스칼라 서브 쿼리(SELECT 문), 인라인 뷰(FROM 절), 서브 쿼리(WHERE 절, 그냥 서브 쿼리라고 하는 듯...) 등의 명칭으로 불린다. 아래는 서브 쿼리의 예시이다. -- 스칼라 서브 쿼리 SELECT p.id AS id, (SELECT email FROM accou..