Docker와 가상머신(Vertual Machine, VM)
로컬에서는 잘 동작하던 코드가 서버에서는 동작하지 않거나, 같은 프로젝트인데도 개발자마다 실행 환경이 달라 문제가 발생하는 경우가 있다. 이러한 문제를 해결하기 위해 등장한 것이 바로 Docker이
Recently Updated
N+1 문제(with. TypeORM)
ORM을 사용하다 보면 N+1 문제라는 말을 자주 듣게 된다. 특히 TypeORM, JPA, Sequelize, Prisma 같은 ORM을 사용해서 연관 관계 데이터를 조회할 때 자주 발생하는 성능
인덱스(Index)
데이터베이스를 사용하다 보면 데이터가 적을 때는 별문제 없이 동작하던 쿼리가, 데이터가 많아지는 순간 갑자기 느려지는 상황을 자주 마주하게 된다. 예를 들어 회원 테이블에 데이터가 100개 있을 때
MySQL vs PostgreSQL 트랜잭션 격리 수준 차이와 실제 장애 사례(Phantom Read 중심으로)
트랜잭션 격리 수준을 공부하다 보면 한 가지 의문이 생긴다.
분산락(Distributed Lock)과 데드락(Dead Lock)
앞선 글에서는 하나의 데이터베이스 내부에서 동시성을 제어하는 방법으로 낙관적 락과 비관적 락을 살펴보았다. 하지만 실제 서비스는 대부분 여러 서버로 구성된 분산 환경에서 동작한다. 이 경우 단순히
낙관적 락(Optimistic Lock), 비관적 락(Pessimistic Lock)
데이터베이스를 다루다 보면 동시에 여러 요청이 하나의 데이터를 수정하려는 상황을 자주 마주하게 된다. 이러한 상황에서 데이터의 정합성을 유지하기 위해 사용하는 개념이 바로 락(Lock) 이다. 락은
트랜젝션(Transaction) 격리 수준(Isolation Level)
데이터베이스를 다루다 보면 한 번쯤 이런 상황을 마주하게 된다.
트랜잭션(Transaction)의 개념과 ACID 원칙
데이터베이스를 다루다 보면 '이 작업은 반드시 함께 성공해야 한다'라는 상황을 자주 마주하게 된다. 단순히 데이터를 하나 수정하는 수준이 아니라, 여러 개의 작업이 하나의 흐름으로 묶여야 하는 경우