관계형 데이터 베이스

• 관계형 데이터베이스는 데이터를 관계(relation)로 나타냄
• 일반적으로 DBMS라고 하면 RDBMS를 가리킴
• 오라클 데이터베이스 서버, 마이크로소프트 SQL, MySQL, MariaDB, PostgreSQL, SQLLite

특징: 데이터를 테이블(행과 열) 구조로 관리하며 스키마가 엄격함. SQL 언어 사용.
예시: Oracle, MySQL, PostgreSQL, Microsoft SQL Server.
용도: 은행 시스템, 주문 처리 등 데이터 무결성이 중요한 경우.

계층형 데이터 베이스

데이터를 트리(Tree) 구조로 조직하여 부모-자식 관계를 계층적으로 표현하는 데이터베이스 관리 시스템(DBMS)

1. 주요 특징

• 트리 구조: 데이터가 뿌리(Root)에서 파생된 가지(Branch) 형태로 연결되며, 최상위 노드부터 순차적으로 탐색
• 1:N 관계: 하나의 부모(Parent)는 여러 자식(Child)을 가질 수 있지만, 각 자식은 반드시 단 하나의 부모만 가질 수 있음
• 세그먼트 단위: 데이터는 '세그먼트'라는 논리적 단위로 저장되며, 이는 레코드와 유사한 개념

2. 장점과 단점

장점 - 구조가 단순하여 이해하기 쉽고, 정의된 경로를 따라가는 데이터 조회 속도가 매우 빠릅니다. 데이터 무결성(참조 무결성) 유지가 용이

단점 - 데이터 구조가 경직되어 있어 유연성이 떨어지며, 다대다(N:M) 관계 표현이 어렵습니다. 상위 데이터를 삭제하면 하위 데이터도 함께 삭제되는 등 수정 및 관리가 복잡할 수 있음

• IBM IMS: 1960년대 개발된 대표적인 계층형 DBMS로, 현재도 은행 및 통신 시스템 등에서 사용됩니다.
• 파일 시스템: 컴퓨터의 디렉토리(폴더)와 파일 구조가 대표적인 계층형 모델입니다.
• 마크업 언어: XML 및 HTML의 태그 구조, Windows 레지스트리 등이 이 방식을 따릅니다.
• 기타: 기업의 조직도, 지리 정보 시스템(GIS) 등 계층 구조가 명확한 데이터 관리에 적합합니다.

그래프 데이터 베이스

데이터를 노드(Node)와 엣지(Edge)로 구성된 그래프 구조로 저장하고 관리하는 NoSQL 데이터베이스의 한 종류

주요 활용 사례 - 데이터 간의 연결 고리를 분석해야 하는 분야에서 강력한 성능을 발휘

• 추천 엔진: 사용자 구매 이력과 선호도를 연결해 Amazon이나 Netflix 같은 맞춤형 상품 추천.
• 사기 탐지(Fraud Detection): 금융 거래 네트워크에서 의심스러운 자금 흐름이나 중복된 계정 연결 고리 식별.
• 소셜 네트워크 서비스(SNS): '친구의 친구' 찾기나 인플루언서 영향력 분석.
• 지식 그래프: 분산된 방대한 정보를 연결해 의미 있는 맥락을 제공하는 AI 및 검색 서비스.

대표적인 플랫폼

• Neo4j: 전 세계적으로 가장 인기 있는 기본(Native) 그래프 데이터베이스.
• Amazon Neptune: AWS에서 제공하는 완전 관리형 그래프 데이터베이스 서비스.
• ArangoDB: 문서(Document)와 그래프 모델을 동시에 지원하는 멀티 모델 DB.
• Cosmos DB: Microsoft Azure의 글로벌 분산형 멀티 모델 서비스.

NoSQL

관계형 데이터베이스 모델을 벗어난 몽고DB, 카산드라(Cassandra), Neo4J 등

스타일	데이터 구조 (시각화)	특징 및 용도	대표 사례	장점	단점
Key-Value	Key : Value	가장 단순한 형태. 속도가 매우 빨라 캐시, 세션 관리에 최적화	Redis, Amazon DynamoDB	- 매우 빠른 읽기/쓰기 - 수평 확장 쉬움 - 구조 단순 - 캐시/세션에 최적	- 복잡한 조회 불가 - 관계 표현 어려움 - 값 내부 검색 제한적
Document	{ "id": 1, "name": "..." }	JSON/XML 문서 형태 저장. 구조 유연, 콘텐츠 관리에 유리	MongoDB, CouchDB	- 스키마 유연성 - 중첩 데이터 표현 가능 - JOIN 없이 빠른 조회 - 개발 속도 빠름	- 데이터 중복 증가 가능 - 복잡한 트랜잭션 약함 - 관계형 분석에 불리
Wide-Column	Row [Column1, Column2]	열 단위 저장. 대용량 분산 처리에 강력	Apache Cassandra, Apache HBase	- 초대용량 데이터 처리 강함 - 높은 쓰기 성능 - 분산 확장성 뛰어남 - 장애 허용성 높음	- 설계가 어려움 (쿼리 기반 모델링) - JOIN 없음 - 즉석 질의에 약함
Graph	Node ↔ Edge	데이터 간 연결 관계 저장. SNS, 추천 시스템 특화	Neo4j, JanusGraph	- 관계 탐색 매우 빠름 - 다단계 연결 분석에 최적 - 추천 시스템에 강력	- 대규모 단순 조회에는 비효율적 - 수평 확장 상대적으로 어려움 - 일반 CRUD에는 과할 수 있음

NoSQL 스타일의 데이터베이스는 왜 마이그레이션이 어렵나? 그냥 똑같이 복사하면 되는게 아냐?

1. 스키마가 없거나(또는 느슨함)

관계형 DB(예: MySQL, PostgreSQL)는 고정된 스키마 (table, column, type) 가 있지만, NoSQL(예: MongoDB, Cassandra)는 스키마가 없거나 매우 유연함

예를 들어 MongoDB에서는:

{ "name": "Soo", "age": 30 }
{ "name": "Gwon", "email": "a@b.com" }

같은 컬렉션인데 필드가 다를 수 있음.

• 문제:
  실제 운영 데이터에는 “암묵적 스키마”가 존재함
  일부 문서에만 있는 필드
  타입이 제각각인 필드
  오래된 버전 문서와 최신 문서가 혼재
  다른 시스템으로 옮길 경우 구조를 그대로 이해하지 못할 수 있음

2. 데이터 구조 자체가 DB 의존적임

NoSQL은 설계 철학이 다 다르기 때문에 다른 종류의 DB로 옮길 경우, 데이터 구조를 다시 설계해야 함.

3. 분산 구조 문제

NoSQL은 대부분:

• Sharding
• Replication
• Eventual Consistency
  를 기본 전제로 설계되나...

예를 들어,

• Cassandra는 노드별로 데이터가 분산 저장됨
• MongoDB는 shard key 기준으로 분산됨

마이그레션 시 문제:

• shard key 변경 불가
• 파티션 전략이 달라지면 재분배 필요
• consistency 모델 차이

4. 데이터 무결성 보장이 애매함

RDB는:

• Foreign Key
• Constraint
• Transaction (ACID)

NoSQL은:

• 애플리케이션 레벨에서 무결성 관리

그러므로 마이그레이션할 때,

• 숨겨진 관계가 있음
• 코드 안에 로직이 있음
• DB만 옮겨서는 완전하지 않음

NoSQL 타입이 확장성이 좋고 처리가 빠른 이유는?

• JOIN 없음 → 디스크 I/O 감소
• 비정규화 → 읽기 한 번에 끝남
• 트랜잭션 단순화 → Lock 적음
• 수평 확장 기본 설계 → 대규모 처리 가능
• 제약조건 적음 → 쓰기 빠름

하지만...
NoSQL이 항상 빠른 건 아님

• 복잡한 관계 분석
• 금융 트랜잭션
• 강한 무결성 필요

이 경우는 RDB가 더 적합함.