기존 RDB(Relational Database)의 한계관계형 데이터베이스(RDB)는 오랫동안 안정적인 데이터 저장소로 사용되어 왔다. 스키마가 명확하고, 트랜잭션과 정합성을 보장한다는 점에서 여전히 많은 시스템의 핵심 구성 요소다. 하지만 서비스 규모가 커질수록, RDB가 가진 구조적인 한계도 점점 분명해진다. 가장 먼저 마주치는 문제는 스키마 변경의 부담이다. 새로운 기능을 추가하면서 컬럼을 하나 더 넣어야 하는 상황이 생기면, RDB에서는 테이블 스키마 자체를 변경해야 한다.ALTER TABLE users ADD COLUMN profile_image_url TEXT; 데이터가 적을 때는 큰 문제가 되지 않지만, 이미 수백만 건 이상의 데이터가 쌓인 테이블이라면 이러한 스키마 변경은 락(lock)을 ..

서비스를 운영하다 보면 데이터베이스의 크기는 자연스럽게 커진다. 사용자 수가 늘고, 로그와 이력 데이터가 쌓이며, 하나의 테이블에 수백만 건 이상의 데이터가 들어가게 된다. 이 시점부터는 단순히 “인덱스를 잘 잡으면 된다”는 접근만으로는 성능 문제를 해결하기 어려워진다. 테이블이 커질수록 읽기와 쓰기 비용은 증가하고, 인덱스 역시 함께 커지면서 쿼리 처리 시간이 점점 늘어난다. 이런 상황에서 데이터베이스 구조 자체를 나누는 전략이 필요해지는데, 그 대표적인 방법이 Partitioning, Sharding, 그리고 Replication이다.Vertical PartitioningVertical Partitioning은 컬럼(column) 기준으로 테이블을 분리하는 방식이다. 하나의 테이블에 너무 많은 컬럼이..

백엔드 애플리케이션과 DB 서버 사이에서 벌어지는 일백엔드 애플리케이션은 클라이언트로부터 요청을 받으면 비즈니스 로직을 처리합니다. 그 과정에서 DB 서버에 쿼리를 요청한 뒤 결과를 받아 다시 클라이언트에게 전달하는데, 이때 두 서버는 대부분 서로 다른 컴퓨터이기 때문에 네트워크 통신을 하게 됩니다. 그리고 이 통신은 일반적으로 데이터 송수신의 신뢰성을 보장하는 TCP 기반으로 이루어집니다. TCP는 매우 안정적인 프로토콜이지만 이러한 안정성은 공짜가 아닙니다. 연결 지향적 프로토콜이기 때문에 통신을 시작할 때 연결을 맺는 과정이 필요하고, 통신이 끝날 때는 연결을 종료하는 과정이 필요합니다. 문제는 이 연결과 해제 과정이 생각보다 많은 비용을 요구한다는 점입니다. 만약 백엔드 서버가 DB 서버에 쿼리를..

애플리케이션을 개발할 때, 데이터베이스 성능은 전체 서비스의 응답 속도에 큰 영향을 미칩니다. 여러 성능 저하 원인 중, 개발자가 인지하지 못한 채 반복적인 쿼리를 날려 발생하는 N+1 쿼리 문제는 가장 흔하면서도 치명적인 원인 중 하나입니다.N+1 문제가 뭐지..?N+1 문제란, 첫 번째 쿼리의 결과(N개)를 기반으로, 연관된 데이터를 얻기 위해 N번의 추가 쿼리가 발생하는 상황을 말합니다. 즉, 원래는 하나의 쿼리로 끝낼 수 있는 작업을 1 + N개의 쿼리로 처리하여 데이터베이스에 불필요한 부하를 주는 비효율적인 데이터 조회 방식입니다. 간단한 예시를 통해 자세히 알아보겠습니다. 모든 회원의 주문 내역을 조회하고 싶어!쇼핑몰의 회원(user) 테이블과 주문(orders) 테이블이 있다고 가정해봅시다...

트랜잭션이란?트랜잭션은 데이터베이스에서 하나의 작업을 이루는 여러 SQL 연산을 하나로 묶은 것이다. 여러 쿼리를 실행하더라도 사용자는 그것을 하나의 작업 단위처럼 다룬다. 예를 들어 송금 기능을 생각해보자. A 계좌에서 10만 원을 출금하고, B 계좌에 10만 원을 입금한다고 할 때 이 두 동작이 모두 성공해야만 “송금”이라는 하나의 작업이 완료된다. 만약 하나라도 실패하면 전체가 취소되어야 하며, 이를 보장해주는 것이 트랜잭션이다. 전체 흐름을 간단히 보자면, WAS나 데이터베이스 접근 도구에서 DB에 접속한다고 해보자.이때 DB 서버와 접근 도구 사이에 커넥션(Connection)이 생성되고, 이 커넥션을 통해 DB 서버에 쿼리가 전달된다. DB 서버는 이에 대응되는 세션(Session)을 생성하여..

스프링에서 엔티티의 TYPE을 지정할 때 자바 enum을 사용하는 건 사실 개발 편의성이 크다. 코드 차원에서는 안전하게 타입을 보장해주니까 실수도 줄고 가독성도 좋다. 그런데 DB 차원에서는 이야기가 조금 다르다.MySQL이나 PostgreSQL처럼 ENUM 타입을 지원하는 DBMS도 있지만, MS SQL Server나 Oracle에서는 기본적으로 제공하지 않는다. 그래서 MySQL/PostgreSQL을 쓴다면 “괜찮지 않나?” 하고 쉽게 생각할 수 있다. 하지만 실제로는 고려해야 할 점들이 꽤 있다. Enum의 속성을 변경하려면..?MySQL의 ENUM은 컬럼 정의 자체에 값 집합을 포함한다. 즉 새로운 값을 추가하거나 수정하려면 단순히 데이터를 넣는 것이 아니라 ALTER TABLE을 통해 컬럼을 ..