DATABASE
데이터 스토어 관련 학습 기록. 관계형·검색엔진·캐시를 모두 포함한다.
[초안] DB Connection Pool Saturation과 Thread Pool 격리
시니어 백엔드 면접에서 "장애 경험"을 물었을 때 가장 자주 등장하는 시나리오 중 하나가 DB Connection Pool Saturation으로 시작되는 전체 서비스 다운이다. 평소엔 평균 응답 50ms로 잘 돌던 주문 API가 어느 순간 P99 30s로 늘어지고, 헬스체크는 통과하는데 사용자 트래픽은 503으로 죽어나가는 상황. 표면 증상만 보면 "DB...
[초안] JPA N+1과 커머스 조회 모델: 주문/메뉴/쿠폰 도메인에서 살아남기
커머스 백엔드에서 가장 많이 깨지는 지점은 의외로 결제도, 동시성도 아닌 조회 쿼리다. 주문 한 건을 화면에 띄우려면 다음 57개 테이블이 엮인다. - 주문 헤더 - 주문 라인 - 메뉴 - 메뉴 옵션 - 쿠폰 - 매장 - 회원 JPA를 쓰는 팀이라면 이 시점에서 거의 반드시 N+1 쿼리 문제를 만난다. 더 나쁜 점은 N+1이 단위 테스트에서는 안 보인다는...
[초안] MyBatis 기본기 — XML Mapper, resultMap, 동적 SQL, 운영 패턴 정리
JPA 위주로 작업해 왔더라도, 레거시 비중이 큰 SI/유통 도메인에서는 MyBatis 코드를 읽고 고치는 능력이 곧 합류 첫 달의 생산성을 결정한다. 외식 프랜차이즈처럼 메뉴/매장/가격/영양 같은 도메인 데이터가 다양한 외부 시스템과 맞물리는 환경에서는 단순 CRUD보다 동적 조건 검색, 다중 RESULT 매핑, 대량 INSERT/UPDATE, 통계 집계...
[초안] MyBatis와 JPA/Hibernate 트레이드오프 — 레거시 백엔드를 다루는 시니어 관점
한국 SI/엔터프라이즈 도메인, 특히 외식·유통·리테일 도메인의 백엔드는 여전히 MyBatis 기반 레거시가 다수다. 신규 프로젝트는 JPA/Hibernate로 출발하더라도, 실제 운영에서 마주치는 코드의 절반 이상은 XML Mapper, 동적 SQL, 수십 줄짜리 JOIN 쿼리로 구성된 MyBatis 코드일 가능성이 높다. 디지털 채널(주문, 결제, 멤버...
데이터 베이스 정규화
- https://3months.tistory.com/193 - 정규화 : 데이터베이스의 설계를 재구성하는 테크닉 - 정규화를 통해 불필요한 데이터(redundancy)를 없앨 수 있다 - 또한 삽입/갱신/삭제 시 발생할 수 있는 각종 이상현상(Anamolies)들을 방지할 수 있다 - 정규화의 목적 1. 불필요한 데이터 제거 2. 데이터 저장을 "논리적"...
벡터 DB 5종은 안이 어떻게 다른가 — 아키텍처 심층 비교
벡터 DB 후보들을 비교하다 보면 표면 기능은 다 비슷해 보인다. 다섯 제품 모두 HNSW 로 ANN 검색을 제공하고, 다 메타데이터 필터링을 한다. 그런데 막상 운영에 올리면 메모리가 터지는 지점, 노드를 늘리는 방식, 인덱스를 굳히는 시점이 제품마다 전혀 다르다. 그 차이가 어디서 오는지 궁금해서 OpenSearch · Milvus · Qdrant ·...
벡터 DB 어떻게 고를까 — OpenSearch · Milvus · Qdrant · Vespa 비교
RAG 를 만들면 임베딩한 벡터를 어딘가에 저장하고 검색해야 한다. 처음엔 쓰던 검색엔진(OpenSearch)에 벡터 기능을 얹어 시작했는데, 전용 벡터 DB 로 옮길지 고민이 생기면서 후보들을 제대로 비교해 봤다. 결론부터 말하면, 규모가 크지 않으면 뭘 골라도 성능은 충분하고 선택을 가르는 건 성능이 아니라 기능과 운영이라는 것이었다. 이 글은 Open...
벡터 DB를 실제로 도입한 사례 — 빅테크 프로덕션
벡터 DB를 공부하다 보면 "실제 큰 서비스가 전용 벡터 DB를 운영에 올린 사례"가 궁금하다. ANN 라이브러리(FAISS·Annoy)나 임베딩 모델이 아니라, 벡터 DB 제품을 프로덕션에 도입한 사례를 회사 엔지니어링 블로그(1차 출처) 중심으로 모았다. | 회사 | 도입 | 규모 | use case | | --- | --- | --- | --- | |...
역정규화 (Denormalization)
정규화된 테이블 구조를 의도적으로 되돌려 조회 성능을 개선하는 기법. 데이터 중복을 감수하고 JOIN을 줄이거나 집계 연산을 미리 계산해두는 방식이다. --- 정규화는 데이터 무결성과 저장 공간 효율을 위한 것이다. 하지만 정규화가 높을수록 조회 시 여러 테이블을 JOIN해야 한다. 데이터가 많아지면 이 JOIN 비용이 성능 병목이 된다. 정규화 우선: 쓰...
인덱스 - DB 성능 최적화의 핵심
- 인덱스와 실행 계획은 DB 성능의 80%를 결정짓는 핵심 분야 - 인덱스의 가장 기본이 되는 B+Tree 구조부터 시작해보자. - B+Tree는 이진 트리(Binary Tree)를 확장하여 하다의 노드가 가질 수 있는 자식 노드의 개수를 늘린 B-Tree의 변형 구조이다 - 핵심 특징: - 모든 키 값은 Leaf Node에만 존재: - Root와 Int...
커넥션 풀 크기는 얼마나 조정해야 할까?
직관과 반대다. 동시 사용자가 많아지면 풀을 키워야 할 것 같지만, 실제로는 작게 유지하는 쪽이 더 빠르다. 커넥션은 결국 DB 측 자원(워커 프로세스/스레드, 디스크 I/O)을 점유하는데, 그 자원의 수가 한정되어 있기 때문이다. > 다른 변경 없이 커넥션 풀 크기만 줄였더니 애플리케이션 응답 시간이 약 100ms에서 약 2ms로, 50배 이상 단축됐다...