database

DB의 특성과 장단점 정리

HJHStudy 2025. 5. 25. 01:01
728x90

RDBMS

 

Mysql

핵심 특성 - 정형 데이터 저장: 테이블 기반의 명확한 스키마 구조
- SQL 지원: 표준 SQL을 이용한 복잡한 쿼리 및 트랜잭션 처리
- ACID 트랜잭션: 원자성, 일관성, 격리성, 지속성을 보장
- 인덱스 기반 접근 최적화: B-Tree, Hash 인덱스 등
Query 모델 최적화 핵심 전략 - 정규화 및 조인 설계: 중복 최소화 및 참조 무결성 확보
- 복합 인덱스 설계: 쿼리 조건과 정렬 기준에 맞춘 인덱스 구성
- Slow Query 로그 분석: 쿼리 튜닝을 통한 성능 향상
- 파티셔닝/샤딩 고려: 대용량 테이블 분산 처리
- 커버링 인덱스 활용: SELECT 성능 개선
장점 - 트랜잭션 안정성 보장
- 복잡한 조인, 집계 쿼리 가능
- 다양한 도구와 ORM 지원
- MySQL InnoDB 엔진으로 충돌 회피 및 동시성 제어 우수
단점 - 수직 확장에 의존 → 수평 확장 어려움
- 실시간 대규모 트래픽 처리 한계
- 복잡한 스키마 설계 필요
- 읽기/쓰기 분리 없으면 확장성 저하

 

 

은행, 결제 시스템 등 정합성 중심 서비스, 복잡한 조인/집계 쿼리를 자주 사용하는 서비스, 관리 도구, 백오피스, 통계 시스템 등에 사용된다.

 

 

PostgreSQL

핵심 특성 - 정형 데이터 + 객체 지향 기능 지원
- 표준 SQL + 고급 기능 (CTE, Window Function 등)
- ACID 트랜잭션 보장, MVCC 기반 동시성 제어
- 확장성 강점: 사용자 정의 타입, 함수, 확장 플러그인(HStore, PostGIS 등)
Query 모델 최적화 전략 - 인덱스 전략 다각화: B-Tree, Hash, GIN, GiST 등 다양한 인덱스 선택
- Explain/Analyze로 쿼리 계획 분석
- JSONB 컬럼으로 반정형 데이터 유연하게 처리
- Partitioning으로 대용량 테이블 최적화
- Materialized View로 고비용 집계 쿼리 캐싱
장점 - ANSI SQL 완전 지원 + 고급 쿼리 기능
- 반정형 데이터(JSON, XML)도 효율적 처리
- MVCC 기반 높은 동시성 처리 성능
- 확장성과 유연성이 우수 (사용자 정의 타입/함수/연산자 등)

- 서브쿼리, 복잡한 조인, 트랜잭션 처리 강력
단점 - 복잡한 기능 활용에는 학습 필요
- 고도화된 성능 튜닝에는 경험 필요
- 기본 설정으로는 대규모 트래픽 처리에 한계 (튜닝 필요)
- 일부 운영도구나 클라우드 호환성이 MySQL보다 낮은 경우도 있음

 

 

GIS, 금융, 분석 시스템 등 복잡한 쿼리 및 정합성 중시, JSON + SQL 병행 사용 환경 (ex. 반정형 로그 저장), OLAP 성격의 고급 집계 처리가 필요한 서비스에 사용된다.

 

Oracle Database

핵심 특성 - 엔터프라이즈급 신뢰성, 확장성, 보안
- PL/SQL 기반 프로시저/트리거/패키지 풍부
- 고급 파티셔닝, 샤딩, RAC(클러스터링) 지원
- Flashback, Data Guard 등 고급 복구 기능
Query 모델 최적화 전략 - Cost-Based Optimizer 기반 쿼리 계획
- 인덱스 힌트 / 통계 분석을 통한 성능 튜닝
- Materialized View를 통한 미리 계산된 결과 제공
- Partition + Subpartition 조합으로 대규모 데이터 분산 처리
장점 - 미션 크리티컬 환경에 적합한 높은 안정성
- 오랜 기간 검증된 상용 기술과 운영 도구
- 고급 보안, 감사, 롤백, 복구 기능 탁월
- 병렬 처리 및 대규모 병렬 쿼리 성능 우수
단점 - 라이선스 비용 매우 높음
- PL/SQL 의존성이 높아 타 DB로 마이그레이션 어려움
- 운영, 튜닝이 복잡하여 전문가 필요

 

 

 

Microsoft SQL Server

핵심 특성 - Windows 친화적인 GUI 중심 관리 도구 (SSMS) 제공
- T-SQL 지원- 통합 BI 도구 (SSRS, SSIS, SSAS) 포함
- Always On, 미러링, 스냅샷 복제 지원
Query 모델 최적화 전략 - 인덱스 및 통계 기반 자동 쿼리 최적화
- 인덱스 포함 컬럼 (INCLUDE)로 covering index 활용
- 파티셔닝 및 병렬 쿼리 최적화로 대규모 데이터 대응
- View, Indexed View, Temp Table 적극 활용
장점 - 개발/운영/BI 통합 툴 체계 우수
- Windows Server 기반 업무 환경과 궁합이 좋음
- 정형 쿼리 + 데이터 시각화 + ETL 지원 환경 완비

- 트랜잭션 처리 및 보안 설정 용이
단점 - 윈도우 환경 종속성이 강함 (리눅스 지원은 최근에 도입)
- 버전 간 기능 차이 큼 (표준 vs 엔터프라이즈)
- 라이선스 비용 존재
- 오픈소스 커뮤니티는 PostgreSQL보다 약함

 

이 두 DB는 특히 금융, 공공기관, 대기업 ERP 시스템 등에서 자주 사용된다.

 

NoSQL

 

Redis, Valkey(인메모리 캐시)


핵심 특성 - 인메모리 저장으로 마이크로초 단위 응답 시간
- 다양한 데이터 구조 지원: 문자열, 해시, 리스트, 셋, 정렬 셋
- 원자적 연산 가능: 단일 명령어로 복잡한 작업 수행
Query 모델 최적화 전략 - 캐싱 레이어로 활용: 자주 조회되는 데이터 캐싱
- 적절한 데이터 구조 선택: 
 • 해시: 객체  
 • 정렬 셋(ZSet): 랭킹 
 • 리스트: 히스토리
- TTL(Time To Live) 전략: 적절한 만료 시간 설정
- 캐시 무효화 정책: 데이터 갱신 시 일관성 유지
장점 - 초고속 읽기/쓰기 성능
- 다양한 자료구조로 유연한 데이터 모델링
- TTL 기반 자동 만료 기능 내장
단점 - 높은 메모리 비용: 모든 데이터를 메모리에 유지
- 영속성 제한적: 캐시 용도에 적합
- 복잡한 쿼리 불가: 조인/조건 필터링 등 불가능
- 단일 스레드 모델: 병렬 처리에 한계 있음

세션 캐시, 인기글 랭킹, 실시간 댓글 등에 사용된다.

DynamoDB 키값 및 문서형 NoSQL

핵심 특성 - 고성능 키-값 접근: 단일 자릿수 밀리초 응답 시간
- 완전 관리형 서비스: 운영 부담 최소화
- 무제한 확장성: 테이블 크기 제한 없이 자동 확장
- 유연한 데이터 모델: 키-값, 문서형 모두 지원
Query 모델 최적화 전략 - 액세스 패턴 중심 설계: 쿼리 사용 패턴부터 설계
- 단일 테이블 디자인: 다양한 엔티티를 한 테이블로 통합
- 복합 정렬 키: TYPE#ID#DATE 구조로 계층적 표현
- GSI (글로벌 보조 인덱스): 다양한 쿼리 패턴 대응
- 희소 인덱스: 일부 조건의 데이터만 인덱싱하여 비용 절감
장점 - 서버리스 확장성: 수십억 항목, 수 PB까지 자동 확장
- 다중 리전 복제 및 자동 백업- 온디맨드 / 프로비저닝 용량 모드 선택 가능
- 항목 수준 TTL: 데이터 수명 주기 제어
- DynamoDB Streams: 변경 데이터 캡처(CDC) 가능
단점 - 쿼리 중심 데이터 모델링 필요: 유연성 부족
- 트랜잭션 제한: 단일 항목 위주, 일부 제약 있음
- 최대 항목 크기 400KB 제한
- GSI/LSI 설계 복잡: 성능과 비용 최적화 어려움

- 쿼리 비용: 접근 패턴에 따라 크게 달라짐

 

세션 관리, 이벤트 로그 저장, 주문 기록 등에 사용된다.

 

Neo4j 그래프 데이터베이스

핵심 특성 - 그래프 모델: 노드와 관계(Edges)로 데이터 표현
- Cypher 쿼리 언어: 패턴 매칭 기반의 직관적 쿼리
- 경로 탐색 최적화: 다단계 관계 탐색에 최적화
Query 모델 최적화 전략 - 관계 중심 모델링: 엔티티 간 관계를 명시적으로 표현
- 인덱스 전략: 노드 및 관계 속성에 인덱싱 적용
- 효율적인 그래프 순회: 시작점 최소화, 방향성 고려
장점 - 복잡한 관계 쿼리에 뛰어난 성능
- 실시간 추천 시스템 및 네트워크 분석에 적합
- 유연한 스키마: 스키마 자유도 높음

- ACID 트랜잭션 지원
단점 - 대용량 집계 성능 제한: OLAP 작업에는 부적합
- 수평적 확장 어려움: 클러스터 구성 및 분산 처리 복잡
- 학습 곡선 존재: Cypher 쿼리 언어와 그래프 모델 이해 필요
- 운영 도구 및 생태계 제한

 

소셜 그래프, 권한 시스템, 추천 시스템 등에 사용된다.

 

Milvus 벡터 데이터베이스

핵심 특성 - 벡터 유사도 검색: 임베딩(embedding) 기반 의미적 유사 검색
- 고차원 데이터 처리: 수백~수천 차원의 벡터 지원
- AI/ML 통합: 딥러닝 모델과 자연스러운 연동 (예: HuggingFace, OpenAI 등)
Query 모델 최적화 전략 - 인덱스 알고리즘 선택: IVF, HNSW 등 정확도 vs 성능 균형
- 하이브리드 검색 활용: 벡터 유사도 + 메타데이터 필터 조합
- 배치 처리 지원: 대규모 벡터 유사도 검색 시 유리
장점 - 의미 기반 검색 지원: 키워드가 아닌 의미 유사성 기반 검색
- 대규모 벡터 데이터 처리 효율적
- 다양한 인덱스 알고리즘 지원
- 하이브리드 검색 지원: 벡터 + 스칼라 속성 조합 쿼리 가능
단점 - 높은 메모리 사용량: 대량 벡터 및 인덱스 메모리 요구
- 전통적 SQL-style 쿼리 기능 제한
- 인덱스 구축 시간 소요: 벡터 수 증가 시 인덱싱 비용 증가

- 벡터 변환 오버헤드: 원시 데이터 → 임베딩 단계 필요

 

 

이미지/영상/음성 유사 검색, 문서 의미 기반 검색 (Semantic Search), AI 기반 추천 시스템에 사용된다.

 

 

 

저장소 선택 기준

기준 RDBMS NoSQL 검색엔진
데이터 구조 정형 (스키마 기반 테이블) 비정형/반정형 (JSON, 키-값, 그래프 등) 문서 기반 (역색인 구조)
쿼리 유형 복잡한 조인, 집계, 트랜잭션 중심 단순 조회, 키 기반 액세스, 계층적 데이터 전체 텍스트 검색, 조건 필터링, 통계 집계
응답 시간 밀리초 수준 마이크로초 ~ 밀리초 수준 밀리초 수준
확장성 수직 확장 중심 수평 확장에 최적화 (샤딩, 파티셔닝) 수평 확장 가능 (분산 클러스터 기반)
일관성 강한 일관성 (ACID 트랜잭션 지원) 일관성 수준 조정 가능 (Eventually Consistent 등) 비동기 색인, 약한 일관성
데이터 볼륨 중~대용량 대규모 데이터 적합 초대용량 색인 처리 가능
대표적 사용 사례 금융, ERP, 트랜잭션 중심 앱 세션 캐시, IoT 로그, 유저 이벤트, 키-값 저장 검색, 로그 분석, 추천 시스템
모델링 전략 정규화, 조인, 명시적 관계 액세스 패턴 기반 설계, 중복 허용 인덱싱 최적화, 검색 필드 중심 설계
장점 안정성, 신뢰성 높은 트랜잭션 처리 유연성, 고속 성능, 다양한 구조 지원 고속 검색, 다양한 필터/집계 지원, 분산 처리
단점 확장성 제약, 초기 설계 복잡 일관성/쿼리 유연성 한계, 스키마 없음 실시간 쓰기 부적합, 복잡한 조인 불가

 

 

 

728x90