가장 손쉽게 테이블에서 사용할 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 ..

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

Q. 역정규화를 수행하는 이유가 무엇인가요? A. 테이블이 쪼개져 조인 연산이 쿼리 내 포함되면 성능이 안좋아지기 때문에, 조회 성능을 개선하기 위해서 역정규화를 고려할 수 있습니다. 최근 면접 스터디 중, 역정규화에 대해 이야기를 하다가 나온 문답이다. 질문은 내가, 답변은 스터디원이 해주셨는데 만약 서로 입장이 바뀌었어도 똑같이 대답했을 것 같다. Database를 공부하면서, 혹은 개발을 진행하면서 통념처럼 받아들이게 되는 말이 바로 조인은 느리다.이다. 그런데 최근에 들어서는 Database에 대해 더 깊게 공부할 일들이 생기면서 이에 의문이 생겼다. 조인이 만약 진짜 느린거라면, 왜 그런건데? 보통 이렇게 까지 물어보면 테이블 여러개를 봐야하니까.라고 답변이 돌아오는데 이런 대답은 내가 원하는 ..

느린 쿼리를 개선하는 것은 사용자의 입장에서도 중요하지만 DB 레벨의 효율적 자원관리를 위해서도 꼭 필요한 일이다. 어떻게 쿼리의 실행 시간들을 확인할 수 있을까? 직접 일일이 실행시켜보면서 시간을 재야 하나? 다행히도 일부 DB들은 그들 서버에서 수행되는 쿼리 중 서버에 악영향을 미칠 수 있는 Slow Query(슬로우 쿼리)들을 따로 저장해두고, 이를 개발자들이 확인할 수 있도록 하고 있다. 이 글에서는 슬로우 쿼리의 확인이 용이한 두 DB, Mysql과 Postgresql에서 이를 설정하고 확인하는 법을 다루려고 한다. Mysql 설정법 Mysql에서는 아래 내용을 my.cnf에 추가하면 1초 이상 걸리는 쿼리를 슬로우 쿼리로 상정하고 이에 대한 수집이 시작된다. 물론 설정 파일을 수정했기 때문에 ..

일반적으로 Index Scan이라고 불리우는 기법들(Index Range Scan, Index Unique Scan 등)은 Single Block IO를 활용한다. (해당 내용에 대한 이해도가 부족하다면 이전 글 참조 -> 테이블 스캔 방식에 따른 DB Block IO 전략) 뒤에 설명하겠지만, 읽어야 할 블록이 버퍼에 존재한다고 해도 해당 블록에 접근하기 위한 메모리 상의 포인터를 획득하는 과정이 필요하다. 따라서 읽어야 할 인덱스 레코드가 많은 경우엔, 그 수 만큼 논리적 IO가 발생한다고 볼 수 있고 매번 포인터를 새롭게 획득한다고 생각할 수 있다. 만약 인덱스 리프 노드에서 읽어낸 테이블 ROWID가 대부분 동일한 블록을 가리키고 있다면? 그럼에도 불구하고 인덱스 레코드 수 만큼 포인터 획득 과정..