💡 의도
: 데이터 베이스 카테고리는 데이터베이스 설계 및 관리 능력을 평가합니다. RDBMS와 NoSQL의 차이를 이해하고, 데이터베이스 내에서 데이터를 어떻게 저장하고 조회할지에 대한 기본적인 이해를 확인하려는 의도입니다. 정규화, 인덱스, 트랜잭션 등의 개념을알고 있는지는 실무에서 중요한 데이터 처리 성능과 무결성을 보장하는 능력으로 이어집니다.
답변에 포함해야 할 키워드
- RDB vs NoSQL : 관계형데이터베이스와 비관계형 데이터 베이스의 차이
- 정규화(Normalization) : 데이터 중복을 최소화하여 데이터 구조를 최적화하는 과정
- 인덱스(Index) : 데이터를 빠르게 검색하기 위한 구조
- 트랜잭션(Transaction) : 일련의 데이터베이스 작업의 일관성을 보장하는 방법
- ACID 특성 : 데이터베이스 트랜잭션의 신뢰성을 보장하는 특성 (원자성, 일관성, 고립성, 지속성)
제가 사용할 줄 아는 관계형 데이터 베이스는 MySQL 입니다. 주로 MyBatis와 함계 사용하며, SQL 쿼리를 직접작성해 복잡한 JOIN, 서브쿼리 등도 다룰 수 있습니다. 또한 MongoDB 같은 NoSQL도 프로젝트에 적용해 본 경험이 있습니다.
스마트 팩토리 프로젝트 개발 시 MySQL + MyBatis 기반으로 주문, 생산, 설비 정보를 관리했습니다.
SQL 튜닝, 인덱스 적용, 정규화 등을 통해 성능을 개선한 경험도 있습니다. 실시간 데이터를 효율적으로 다루기 위해 몽고DB를 보조 저장소로 활용한 적도 있습니다.
- RDB(관계형 디비) : 정형화된 스키마 , SQL 사용, 트랜잭션 강함 (ex: MySQL, PostgreSQL)
- NoSQL : 유연한 스키마, 비정형/대량 데이터에 강함, 수평 확장에 유리 (ex: MongoDB, Redis)
RDB : 테이블 형태로 데이터를 저장하며, SQL이라는 언어로 데이터를 관리합니다. 스키마가 고정되어 있습니다.
NoSQL : 문서, 키-값, 그래프 등 다양한 형태로 데이터를 저장하며, 유연한 스키마를 제공합니다
인덱스를 사용하는 이유로는 검색 속도를 높이기 위해. 특정컬럼에 인덱스를 추가하면 WHERE, JOIN, ORDER BY 성능 향상.
성능에 미치는 영향으로는
- 읽기 성능 향상 (빠른 검색, 정렬)
- 쓰기 성능 낮아짐 ( INSERT/UPDATE 시 인덱스 갱신 비용 발생)
- 공간 사용 높아짐
예시로 주문 테이블에서 주문일자나 고객 ID에 인덱스를 적용한 후, 조회 시간이 수 초에서 수밀리초로 단축된 경험이 있습니다. 다만 과도한 인덱스는 오히려 성능 저하를 유발할 수 있어. 조회 빈도와 패턴을 고려해 설계했습니다.
인덱스는 데이터를 빠륵 찾을 수 있도록 도와주는 일종의 "책 목차"입니다. 검색 속도를 높여 성능을 향상시키지만, 데이터를 추가/수정할 때는 인덱스 업데이트가 필요해 성능이 조금 저하될 수도 있습니다.
정규화 : 중복 데이터 제거, 데이터 일관성 유지 (ex: 테이블 분리) -> 관리/수정에 유리하나, JOIN 많아져 성능 저하 가능
역정규화 : 성능 향상을 위해 일부 테이블을 합치거나 중복 허용 -> 읽기 성능 향상, 데이터 중복 관리 필요
정규화 : 데이터 중복을 줄이고 구조를 체계화합니다. (예 : 고객 테이블과 주문 테이블을 분리 )
역정규화 : 성능을 위해 중복을 허용하며 데이터 구조를 단순화합니다. (예 : 고객 정보와 주문 정보를 하나의 테이블에 저장)
예시로 MES 프로젝트 초기에는 정규화를 우선했지만, 보고서용 조회 성능 이슈가 있어 일부 테이블을 역정규화하여 조회 속도를 개선했습니다. 이는 비즈니스 요구사항(빠른 조회)에 따라 유연하게 선택했습니다.
트랜잭션을 정의하자면 하나의 작업 단위를 말하며, 모두 성공하거나 모두 실패해야 합니다.
A -> Atomicity(원자성) : 전부 성공 or 전부 실패
C -> Consistency(일관성) : 트랜잭션 전후 데이터 무결성 유지
I -> Isolation(고립성) : 동시에 수행되는 트랜잭션 간 간섭 방지
D -> Durability(지속성) : 커밋된 데이터는 장애 후에도 보존
트랜잭션 : 데이터베이스에서 실행되는 일련의 작업들을 하나의 단위로 처리.
ACID
- 원자성 : 작업이 모두 완려되거나, 전혀 실행되지 않아야 함.
- 일관성 : 데이터 무결성을 유지
- 격리성 : 동시에 수행되는 트랜잭션 간 간섭이 없어야 함.
- 지속성 : 완료된 작업은 시스템 장애 후에도 유지
예시로 주문-재고 차감 로직에서, 하나라도 실패하면 전체 트랜잭션을 롤백시켜 데이터 불일치 문제를 방지한경험이 있습니다. Spring의 @Transactuinal을 활용해 서비스 계층 단에서 트랜잭션을 제어했습니다.
JOIN은 두 개 이상의 테이블을 공통 컬럼을 기준으로 연결해 하나의 결과셋을 반환하는 SQL 연산입니다. 주로 정규화된 테이블 간 연관 데이터를 조회할 때 사용됩니다.
JOIN 종류 간략 정리
- INNER JOIN : 조건에 일치하는 행만 반환
- LEFT JOIN : 왼쪽 테이블의 모든 행 + 일치하는 오른쪽 테이블의 데이터 ( 없으면 NULL )
- RIGHT JOIN, FULL OUTER JOIN 등도 상황에 따라 사용
사용 사례로 MES 프로젝트에서 주문 테이블(Order)과 제품 정품 테이블을 INNER JOIN하여, 주문 내역과 함께 해당 제품의 이름과 사양정보를 함께 조회한 경험이 있습니다.
고려사항으로 JOIN은 조회 유연성을 높이지만 JOIN 대상 테이블이 크면 성능 저하가 발생할 수 있어, 인덱스 최적화 또는 역정규화 전략도 병행해 사용합니다.
Foreign Key(외래 키) : 한 테이블의 컬럼이 다른 테이블의 기본 키를 참조하는 제약 조건입니다. 테이블 간 관계를 명확히 정의하고, 데이터 일관성을 보장합니다.
Referential Integrity (참조 무결성) : 외래 키를 통해 참조된 값이 반드시 존재해야 함을 보장하는 제약. 예 : 존재하지 않는 고객 ID를 주문 테이블에 저장할 수 없음
예시로 FEMS 시스템에서 설비 테이블과 센서 데이터 테이블을 설계 할 때, 센서 데이터는 반드시 설비에 연결되어야 하므로, equipment_id를 외래 키로 두고 참조 무결성을 유지했습니다.
주의할 점
데드락은 2개 이상의 트랜잭션이 서로의 자원을 점유한 채 영원히 대기하게 되는 상태입니다. 주로 동시성 제어 중 락을 사용할 때 발생합니다.
- 방지 방법
- 락 획득 순서 일관성 유지
-> 모든 트랜잭션에서 동일한 순서로 테이블/리소스에 접근- 타임아웃 설정
-> 일정 시간 안에 락이 해제되지 않으면 트랜잭션 강제 종료- 락 최소화
-> 트랜잭션 범위를 줄이고, SELECT 시 가능하면 LOCK IN SHARE MODE 또는 NOLOCK- 낙관적 락/ 비관적 락 전략 적절히 사용
-> 비즈니스 상황에 따라 병행성과 안전성의 균형을 고려
실무 예시로는 MES의 주문처리 로직에서 동일한 설비 테이블에 여러 트랜잭션이 접근할 떄 데드락이 발생한 적 있었고, 락 순서를 통일하고 @Transactional(propagation = REQUIRES_NEW)를 전략적으로 사용해 해결한 경험이 있습니다.
방지 방법
- 자원 접근 순서를 정하기.
- 타임아웃을 설정해 오래 걸리는 작업은 중단.
- 데드락 탐지 알고리즘 사용.
샤딩(Sharding)은 대규모 데이터를 처리하기 위해 데이터를 물리적으로 여러 DB 인스턴스에 분산 저장하는 기술입니다.
샤딩 : 데이터베이스를 작위 단위로 나눠 저장해 성능을 높이는 기술. 예를 들어, 사용자 데이터를 지역별로 나눠 저장
특징
장점 : 데이터 처리량 증가, 트래픽 분산, 성능 향상
단점 : 샤드 간 JOIN 불가 또는 복잡 , 운영 난이도 증가 (데이터 이관, 샤드 키 설계 등)
예시로는 로그 데이터나 IoT 센서 데이터를 분산 처리하는 경우, 시간이나 설비 ID 기준으로 샤딩을 적용하면 성능과 안정성 모두 향상됩니다.
파티셔닝은 하나의 테이블을 논리적으로 분할해 성능 향상, 관리 효율을 도모하는 방법입니다.
-> 주로 대용량 테이블의 조회 성능 개선과 백업/보관/삭제 유연성 확보 목적
적용 이유
실무 예시로는 FEMS 프로젝트에서 센서 데이터 테이블을 시간 기준으로 수평 파티셔닝하여, 조회 성능을 5배 이상 향상시킨 경험이 있습니다. 또한, 분석 전용 컬럼은 수직 파티셔닝하여 운영 DB의 성능 영향을 줄였습니다.