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