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
'database' 카테고리의 다른 글
Redis 자료구조 (0) | 2025.06.22 |
---|---|
Redis 캐시 직렬화, 역 직렬화 구현체 (0) | 2025.05.19 |
CDC (Change Data Capture) 변경 데이터 캡처 (0) | 2025.05.11 |
PostgreSQL에 대해서 (0) | 2024.06.25 |
springboot 트랜잭션 AOP와 트랜잭션 전파 (0) | 2024.04.21 |