Database가 쿼리에서 요구하는 데이터를 검색하기 위해 테이블에 접근하는 방식에는 다양한 종류가 있다. 크게는 인덱스의 활용 여부에 따라 갈리고, 인덱스를 어떤 방식으로 스캔할지에 대해서도 종류가 나뉜다. 이렇게 나뉜 테이블 스캔 방식은 대략 아래와 같이 나타낼 수 있다. Table Full Scan(Sequential Scan) Index Range Scan Index Full Scan Index Unique Scan Index Skip Scan Index Fast Full Scan 이 때 각 스캔 방식들은 내부적인 작동 방식에 따라 서로 다른 Block IO 전략을 갖게 되는데, 이러한 내부 작동의 차이를 이해하면 왜 DB가 해당 방식을 사용했는지에 대한 이해도를 높일 수 있다. 따라서 해당 글에..

실제로 DB를 다루게 되는 상황에서 빠질 수 없는 것이 바로 인덱스이다. 인덱스를 통하면 특정 조건에서 데이터의 조회 성능이 비약적으로 증가한다는 것은 누구나 알고 있는 사실이다. 그러면서도, 인덱스를 남발하면 안된다는 것 또한 다들 알고있다. 이 때 등장하는 논리가 바로 인덱스가 차지하는 공간적 비용과 데이터 삽입 시 추가적으로 발생하는 시간적 비용에 대한 비중을 무시할 수 없다는 것이다. 그런데 막상 이렇게 겁만 주고 실제로 그 정도가 어느 정도인지 알려주는 자료는 많이 없어서 이에 대해 실제로 확인해보려고 한다. 테스트 환경은 Mysql이고, 아무런 릴레이션이 존재하지 않는 독립된 테이블에서 테스트를 진행하였다. -- 테이블 생성 create table item ( id BIGINT NOT NULL..

일반적인 서버 - 클라이언트 모델에서 서버 측은 데이터의 영속성을 위해 Database를 활용한다. 이러한 상황에서 데이터의 흐름은 간략하게 표현하면 클라이언트 - WAS - DB 의 형태가 되는데, 일반적인 RDB 기준 데이터들은 모두 Disk에 적재되기 때문에 시스템 콜을 유발하게 되고 서버 환경 내 병목이 가장 많이 발생하는 지점 중 하나가 된다. 결국 WAS - DB 간 응답 속도의 개선이 전체 응답 속도의 개선으로 이어지는 경우가 많기 때문에 쿼리의 개선을 이루어내는 것은 몹시 중요하다. 여기까지 오고나면 개선이 중요하다는 것은 이해가 되는데, 쿼리 수정을 통해 개선이 이루어지고 있는지 판단하는 기준은 무엇으로 삼아야할까? 물론 클라이언트 측에서 개발자 도구를 통해 응답 속도가 어떻게 변화하는지..

들어가기 앞서 해당 질문은 언젠가 면접에서 직접 요청 받았던 질문이기도 하고, 구글링을 해보아도 일종의 면접 단골 질문으로 불린다. 마침 스터디의 주제가 되기도 했고, 앞으로도 이에 대해 고민하고 또 대답할 일이 많다고 여겨 이를 정리한다. RDB RDB란 전통적인 형태의 관계형 데이터베이스를 의미한다. 일반적으로 많이 쓰이는 MySQL, PostgreSQL 등이 이에 해당한다. 기본적으로 데이터를 2차원 행렬(테이블) 형태로 관리하며, 데이터의 형식을 일정하게 유지하기 위한 스키마가 존재한다. 데이터의 조회, 삽입, 수정, 삭제에 SQL을 이용하는데, 어떤 DB를 사용하느냐에 따라 세부적인 함수의 사용법 등이 달라질 수는 있지만 큰 틀은 서로 동일하다. DB의 수평적 확장이 어려운 편인데, 이는 RDB..

트랜잭션 격리 수준이란? DB에서 트랜잭션이란 특정 작업을 위한 DB 연산들의 모임으로, 하나의 작업 단위이다. 트랜잭션은 ACID로 불리는 4가지 특징을 갖는다. 다만 이를 완벽하게 지키기 위해서는 트랜잭션들이 완전히 격리되어야 하는데, 이 과정에서 DB의 동시성이 과도하게 희생되기 때문에 성능의 저하로 이어질 수 있다. 그렇다고 트랜잭션 간 격리를 포기해버리면 DB의 무결성, 일관성 측면에서 많은 문제들이 발생할 수 있다. 따라서, DB의 일관성과 성능을 모두 고려하여 트랜잭션 간 격리되는 정도를 적절히 유지하는 것이 중요하다. 이를 트랜잭션의 격리 수준(Isolation Level)이라고 한다. 격리 수준을 고려하지 않으면 발생하는 문제 1. Dirty Read Dirty Read란 트랜잭션이 아직..

이전에 NodeJS Express와 MySql2를 연동하여 토이 프로젝트를 진행한 적이 있다. 그때 사용자의 이메일을 가지고 해당 이메일을 갖는 계정이 존재하는지에 대한 여부를 확인하는 함수를 작성한 일이 있는데, 다음과 같이 구성했다. 당시 서로 코드 리뷰를 해주던 그룹이 있었는데, 한분께서 위 코드를 보시고는 "SQL Injection 공격에 취약해 보인다"라고 피드백을 해주신 기억이 있다. 지금이야 저런 식으로 코드를 구성하는 것이 위험하다는 것을 알고있지만 당시에는 아는 것이 별로 없었기 때문에 SQL Injection을 따로 공부했던 기억이 있다. SQL Injection 이란? SQL Injection은 해커가 프로그래머의 의도에 벗어난 방법을 통해 SQL문을 재구성, DB에 질의하여 사용자의..