https://www.youtube.com/watch?v=ZVuHZ2Fjkl4

description: |-

1. 이건 꼭 알아야 한다[^1]

[? 질문] 새로운 서비스 개발/취업 준비 과정에서 “데이터베이스(DB)를 뭘 골라야 하냐”는 상황에서, 너무 많은 DB 종류 중 어떤 기준으로 선택해야 하는가[^1][^2]
[= 답] 대부분의 일반적인 서비스라면 관계형 DB(RDB) 또는 도큐먼트 DB(Document DB) 둘 중 하나를 우선 후보로 두고, “데이터 정확도(트랜잭션) 중요 vs 대량 입출력/분산 중요” 기준으로 고르면 된다.[^39][^40][^41]

[? 질문] 키-밸류, 그래프, 컬럼 패밀리, 시계열, 검색(인덱스) 등 특수 목적 DB들은 언제 쓰는가[^3][^22][^33]
[= 답] 각 DB는 저장 구조와 강점이 달라서 “캐싱/서브 DB(레디스)”, “관계 중심 데이터(그래프 DB)”, “유연한 테이블+분산(컬럼 패밀리)”, “시간 기록/분석(시계열)”, “검색 인덱스/검색 기능(엘라스틱서치)”처럼 목적이 뚜렷할 때 보조적으로 선택한다.[^6][^16][^26][^35]

[? 질문] “관계형 DB는 관계를 잘 표현한다”는 인식이 맞는가[^18]
[= 답] ‘관계형’의 ‘관계’는 실제 세계의 관계를 뜻하기보다 수학의 릴레이션(relation)(행렬/테이블 개념)에서 온 용어이며, 실제 관계(연결)를 저장하는 건 가능하지만 번거로운 면이 있어 “관계 자체를 중심으로 저장”하려면 그래프 DB가 더 적합하다.[^18][^19][^21]

2. 큰 그림[^1]

이 콘텐츠는 개발자가 새 서비스를 만들거나 취업 준비 등으로 DB를 선택해야 할 때, 너무 많은 데이터베이스 종류를 한 번에 정리해 “언제 무엇을 쓰는지” 선택 기준을 제공한다.[^1][^2] 또한 “일반적으로 무엇을 기본 선택지로 두고, 특수 목적 DB는 어떤 역할로 붙이는지”를 예시와 함께 설명한다.[^39][^6]

• 일반 해법: 대부분은 관계형 DB 또는 도큐먼트 DB 중 하나를 고르면 큰 문제가 없다.[^39]
• 정확도 vs 처리량: 데이터 정확도/트랜잭션이 중요하면 관계형 DB를, 입출력이 많고 분산이 쉬워야 하면 도큐먼트 DB(또는 분산 친화 DB)를 고려한다.[^15][^16][^41]
• 특수 목적 DB의 자리: 레디스(캐시/서브 DB), 그래프 DB(관계/방향), 검색 DB(인덱스) 등은 “메인 DB를 대체”하기보다 목적 기능을 위해 함께 쓰이는 경우가 많다.[^6][^26][^35]

3. 하나씩 살펴보기[^1]

3.1 왜 DB 선택이 어려운가: 새 서비스/취업 준비에서 “하나 골라야 하는” 상황[^1][^2]

화자는 영상 시작에서, 시청자가 DB 선택을 고민하게 되는 대표 상황을 든다.[^1]

• “새로운 서비스를 만들 때” DB가 필요해진다.[^1]
• 혹은 “개발자 취업 준비(공부)” 과정에서도 DB를 하나 정해야 하는 상황이 생긴다.[^1]
  그런데 DB 종류가 너무 많다 보니 “뭘 골라야 할지 모르겠다”가 문제로 제시된다.[^2]
  그래서 이번 영상에서 “가장 쉽고 간단한 DB들부터” 종류를 정리해보겠다고 방향을 잡는다.[^2]

3.2 키-밸류(Key-Value) 데이터베이스: 가장 단순한 형태와 한계[^3][^4]

화자는 “키-밸류 데이터베이스”를 가장 단순한 형태의 DB로 소개한다.[^3]

• 저장 방식: 데이터를 키(key)-값(value) 형태로 저장한다.[^3]
• 예시: “이름”과 “나이”를 저장하고 싶다면, 특정 키에 값을 매달아 기록하면 끝이라는 식으로 설명한다.[^3]

이어서 화자는 이런 단순함 때문에 실용성이 낮아 보인다는 시청자 반응을 먼저 언급한다.[^4]

• “너무 간단해 보여서 실용성은 딱히 없을 것 같다”는 인상을 짚고[^4]
• 그 판단이 “실은 맞다”고 말하며, 키-밸류 DB는 보통 “서브 용도” 정도로 쓰인다고 정리한다.[^5]

[!NOTE] 키-밸류 DB의 포지션
화자 설명에서 키-밸류 DB는 “범용 메인 DB”라기보다, 단순 저장이 필요하거나 보조 용도일 때 떠올리는 계열로 묘사된다.[^5]

3.3 레디스(Redis): “키-밸류인데 많이 쓰는” 이유 = RAM 기반 + 캐싱/서브 DB 활용[^6][^7][^8][^9][^10][^11]

화자는 “특수한 기능을 가진 키-밸류 DB”로 **레디스(Redis)**를 별도로 강조한다.[^6]
레디스는 동일하게 키-밸류 형태로 저장할 수 있지만, “되게 많이 쓴다”고 말한다.[^6][^7]

3.3.1 레디스가 빠른 이유: 하드디스크가 아니라 RAM에 우선 저장[^8][^9]

화자는 레디스가 많이 쓰이는 이유를 성능 구조로 설명한다.[^7]

• 레디스는 데이터를 “하드디스크에 저장하지 않고”
• “1차적으로 램(RAM)에 저장”한다.[^8][^9]
  그리고 RAM이 하드디스크보다 “몇십, 몇백 배 빠르다”는 점을 들어 속도 이점을 뒷받침한다.[^10]

3.3.2 레디스 활용 방식: 메인 DB + 자주 쓰는 데이터 복사(캐시) → 필요할 때 레디스에서 조회[^11][^12][^13]

화자는 레디스를 “어떤 식으로 활용하냐면”이라는 흐름으로 전형적인 아키텍처를 제시한다.[^11]

• “메인 DB”를 하나 둔다.[^11]
• 사람들이 “자주 쓰는 데이터”는 레디스에 “추가로 복사해 둔다.”[^12]
• 데이터가 필요할 때 메인 DB 대신 레디스에서 “꺼내 보여주는” 경우가 있다.[^13]
  그 결과 “되게 빠른 서비스를 만들 수 있다”고 결론짓는다.[^14]

[!TIP] 캐싱 설계의 직관
“전체 데이터의 진짜 원본은 메인 DB에, 자주 조회되는 핫 데이터는 레디스에 복사”라는 구조로 설명하면서, 레디스의 대표 용도를 **캐싱(cache)**으로 제시한다.[^11][^12][^13]

3.3.3 레디스의 용도 요약: 캐싱, 서브 DB, Pub/Sub 구현[^14][^15]

화자는 이런 활용을 “캐싱 용” 또는 “퍼섭(pub/sub) 구현” 같은 용도의 “서브 DB”로 쓰는 경우가 있다고 말한다.[^15]
즉 레디스는 단독 메인 저장소라기보다, 서비스 속도를 높이거나 메시징 패턴(pub/sub) 등을 위해 결합되는 그림으로 제시된다.[^15]

3.3.4 “레디스 하나로 모든 걸” 업그레이드 버전 언급(하지만 잘 안 쓰는 분위기)[^16]

화자는 “요즘은 레디스 하나로 모든 걸 다 할 수 있는 레디스 업글 버전도 나와 있긴 한데”라고 덧붙인다.[^16]
다만 “아무도 안 쓰는 것 같다”는 코멘트로, 일반적인 선택/현업 주류와는 거리가 있음을 암시한다.[^16]

3.4 관계형 데이터베이스(RDB): 표(테이블) 형태, SQL, 정규화 집착, 트랜잭션으로 정확도 확보[^17][^18][^19][^20][^21]

화자는 “데이터도 표 형태로 저장하고 싶으면” 전통적인 관계형 데이터베이스를 쓰라고 말한다.[^17]

3.4.1 저장 방식: 테이블(열 정의 + 행 단위 저장), 엑셀 비유[^18][^19]

관계형 DB의 저장 방식을 다음 흐름으로 설명한다.

• 먼저 “테이블을 하나 만들고”[^18]
• 위쪽(열/컬럼)에 “어떤 데이터를 저장할지 이름을 써 두고”[^18]
• “하나의 행(row)마다 데이터를 보관”하는 식으로 저장한다.[^19]
  그리고 “엑셀도 관계형 데이터베이스라고 할 수 있겠”다는 비유로, 표 형태 저장이라는 직관을 강화한다.[^20]

3.4.2 대량 데이터 저장용 DBMS 예시와 시장 점유율 상위권 언급[^20][^21]

다만 엑셀은 대량 데이터에 한계가 있으므로, “대량의 데이터를 저장하려면” 다음 같은 DBMS를 많이 사용한다고 든다.[^20]

• 오라클(Oracle)
• MySQL
• 포스트그레스(Postgres)
  또한 관계형 DB는 “다양한 곳에서 일반적으로 사용할 수” 있어, DB 점유율 상위권이 “다 관계형 DB”라는 식으로 보편성을 강조한다.[^21]

3.4.3 관계형 DB에서의 언어: SQL은 쉽다[^22]

관계형 DB에 데이터를 저장/조회하려면 SQL이라는 문법을 써야 한다고 말한다.[^22]
화자는 SQL이 “쉬워서 세 살짜리 애들도 할 수” 있다고 과장 섞인 표현으로 난이도가 낮다고 전달한다.[^22]

3.4.4 관계형 DB의 ‘정규화’ 집착: 중복 제거 → 테이블 쪼개기 → 쿼리가 길고 복잡해질 수 있음[^23][^24]

화자는 관계형 DB를 사용할 때 “광적으로 집착하는 게 하나”가 있다고 말하며 그것을 **정규화(normalization)**로 지목한다.[^23]

• 관계형 DB 진영은 “데이터 중복을 너무 싫어”해서[^23]
• 중복이 생기면 “다른 테이블로 다 쪼개 버리는” 식의 설계를 한다고 설명한다.[^24]
• 이 행위를 전문용어로 “정규화”라고 부른다.[^24]

그리고 정규화의 부작용(또는 비용)으로, 나중에 데이터를 입/출력하는 문법(쿼리)이 “길고 복잡해지”는 단점이 생길 수 있다고 말한다.[^25]

[!IMPORTANT] 정규화에 대한 콘텐츠의 관점
정규화는 “중복을 싫어해 테이블을 쪼개는 것”으로 설명되며, 그 결과 조회/입출력 문법이 복잡해질 수 있다는 트레이드오프가 강조된다.[^23][^25]

3.4.5 트랜잭션으로 안전한 구현: 돈 거래 등 “정확도”가 중요할 때 유리[^26][^27]

화자는 관계형 DB에는 기본적으로 트랜잭션(transaction) 기능이 들어 있어, “돈 거래 같은 중요한 기능”을 “안전하게 구현”할 수 있다고 말한다.[^26]
그래서 “입출력 속도보다 데이터 정확도가 매우 중요”하면 관계형 DB를 쓰는 경우가 많다는 선택 기준을 제시한다.[^27]

3.5 “관계형”이라는 이름의 오해: 관계 표현 vs 수학의 ‘릴레이션’에서 온 말[^28][^29]

화자는 많은 사람들이 이름 때문에 “관계형 데이터베이스가 관계를 잘 표현한다고 생각”한다고 지적한다.[^28]
하지만 실제로 ‘관계’라는 표현은 수학 용어인 릴레이션(relation), 즉 “행렬 배울 때 쓰는 용어”를 그대로 따온 것이라고 설명한다.[^28]
즉 이름이 ‘관계형’이라고 해서, SNS 친구관계 같은 “관계 자체”를 핵심 강점으로 삼는다는 뜻은 아니라는 맥락을 깔아준다.[^28]

이어서 화자는 관계 표현이 “가능하긴” 하지만, 관계 자체를 저장하기에는 “좀 귀찮은 점들이 있다”고 말하며 다음 섹션(그래프 DB)으로 넘어갈 연결고리를 만든다.[^29]

3.6 그래프 데이터베이스(Graph DB): 관계/방향 저장에 특화, Neo4j, 쿼리 언어로 방향까지 표현[^30][^31][^32][^33]

화자는 “관계를 주로 저장하고 싶으면” 그래프 데이터베이스를 사용한다고 제안한다.[^30]
그중 유명한 것으로 **네오4j(Neo4j)**를 언급한다.[^31]

3.6.1 저장 모델: 노드(node) + 노드 간 관계를 기록[^32]

그래프 DB는 “노드”를 만들고 그 안에 데이터를 저장한다고 설명한다.[^32]
그리고 핵심적으로 “노드끼리 어떤 관계인지도 기록”해 둘 수 있다는 점을 특징으로 든다.[^32]
이는 앞에서 말한 “관계 자체 저장”을 편하게 만든다는 문제의식에 대한 답으로 배치된다.[^29][^32]

3.6.2 입출력 언어: 그래프 쿼리 언어, 방향 표현 가능[^33]

이런 데이터를 입/출력할 때는 “그래프 쿼리 랭귀지”를 사용한다고 말한다.[^33]
그리고 이 언어를 통해 “방향 같은 것도 표현”할 수 있다고 덧붙인다.[^33]
즉 관계의 존재뿐 아니라 방향성(예: A→B)을 다루는 데 적합하다는 뉘앙스를 준다.[^33]

3.6.3 그래프 DB는 어디에 쓰나: 노선, SNS 친구 관계, 전염 관계, 추천 서비스[^34]

화자는 “어디다 쓰냐”고 묻고, “자료 간의 관계/방향”을 중점적으로 저장하고 싶을 때 쓴다고 정리한다.[^34]
그리고 구체 예시를 나열한다.[^34]

• 비행기 “노선” 같은 연결 구조
• SNS의 “친구 관계”
• “어떤 사람한테 코로나를 전염시켰는지” 같은 전파 관계
• 대기업이 “추천 서비스” 만들 때 가끔 그래프 DB를 쓰는 경우

+++ 상세 예시(콘텐츠가 제시한 ‘관계 중심’ 상황의 공통점) 위 사례들은 모두 “개별 데이터(사람/공항/사용자/감염자)” 자체보다,
그들 사이의 연결(관계) 및 때로는 **방향(누가 누구에게/어디에서 어디로)**이 핵심 질의 대상이 되는 상황으로 묶인다.[^34] +++

3.7 도큐먼트 데이터베이스(Document DB): JSON 문서, 스키마 유연, 비정규화(중복 허용), 분산 쉬움 → 대량 입출력에 활용[^35][^36][^37][^38]

화자는 그래프 DB 같은 “특수한 것 말고”, 보다 “일반적인 상황”에서는 관계형 DB를 쓰면 되지만, “조금 더 자유로운” 선택지로 도큐먼트 데이터베이스도 가능하다고 말한다.[^35]
대표 예시로 다음 제품들을 언급한다.[^35]

• 몽고DB(MongoDB)
• 카우치DB(CouchDB)
• 파이어스토어(Firestore)

3.7.1 저장 방식: 컬렉션(폴더) + 도큐먼트(파일) + JSON 형태[^36]

도큐먼트 DB는 다음 구조로 저장한다고 설명한다.[^36]

• “컬렉션”이라는, 폴더 같은 것을 만든다.[^36]
• 그 안에 “도큐먼트”라고 부르는 파일을 만든다.[^36]
• 파일 안에 JSON 형태로 데이터를 저장할 수 있다.[^36]

JSON을 모르는 시청자를 위해, “그냥 키-밸류 형태랑 똑같다고 생각”하면 된다고 연결해 설명한다.[^37]

3.7.2 스키마 유연성: 미리 정의 불필요, 필드 추가해도 에러가 안 나는 성격[^38]

관계형 DB와 달리, 도큐먼트 DB는 “어떤 데이터를 저장할지 미리 정의해 놓을 필요”가 없다고 말한다.[^38]
예시로, 기존 데이터에 “갑자기 연락처까지 집어넣어 버려도” 에러를 내지 않는다고 하면서 유연함을 강조한다.[^38]
화자는 이를 “되게 착”하다고 표현하며 개발 편의성을 강조한다.[^38]

3.7.3 가장 큰 특징: 중복 제거를 하지 않음 = 정규화를 안 함 → 입출력 문법이 간단[^39]

화자는 도큐먼트 DB의 “가장 큰 특징”으로 “데이터 중복 제거를 하지 않는다”고 말한다.[^39]
이를 전문용어로 “정규화 같은 걸 안 한다”는 뜻이라고 풀어준다.[^39]
그리고 그 결과로, 데이터 입출력 문법이 “훨씬 간단”한 편이라고 설명한다.[^40]

3.7.4 분산을 염두에 둔 설계: 분산이 쉽다 → 입출력이 많은 서비스에 활용[^41]

도큐먼트 DB들은 “대부분 분산을 염두”에 두고 만들어졌기 때문에, DB를 “분산시켜 놓는 게 되게 쉽”다고 말한다.[^41]
그래서 데이터 입/출력이 “되게 많은 서비스”에 주로 활용된다고 용도를 정리한다.[^41]

3.7.5 분산의 단점: DB 간 정확도(일관성) 저하 가능[^42][^43]

화자는 분산을 하면 “당연히 단점도 있다”고 전제한 뒤[^42]
“DB 간에 정확도 같은 게 떨어질 수 있다”고 말한다.[^43]
다만 이런 정확도가 “중요하지 않으면” 분산시켜도 “전혀 상관 없다”는 식으로 트레이드오프를 정리한다.[^44]

[!WARNING] 도큐먼트 DB 선택 시의 경고 포인트(콘텐츠 기준)
분산이 쉬운 대신, DB 간 정확도/일관성이 떨어질 수 있다는 점을 고려해야 한다는 메시지가 명시된다.[^43][^44]

3.8 컬럼 패밀리(Column Family) 데이터베이스: 테이블 형태를 유지하면서 유연 + 비정규화 + 분산 강점[^45][^46][^47][^48][^49]

화자는 “관계형 DB처럼 표 형식으로 저장하고 싶은데, 조금 유연하게 쓰고 싶다”면 컬럼 패밀리 데이터베이스를 사용하면 된다고 말한다.[^45]
대표 예시로 다음을 든다.[^45]

• 카산드라(Cassandra)
• 구글 빅테이블(Google Bigtable)

3.8.1 저장 방식: 테이블/로우 + 칼럼을 자유롭게 만들어 기입[^46]

컬럼 패밀리 DB는 “똑같이 테이블을 만들고”, “로우(행)를 만들고”, 그다음 “자유롭게 칼럼을 만들어서 데이터를 기입”하는 식으로 저장한다고 설명한다.[^46]
화자는 “표랑 똑같”다고 말해, 형태는 테이블이지만 스키마 유연성이 더 있다는 인상을 준다.[^46][^47]

3.8.2 쿼리 언어: SQL이 아니라 제품별 언어(Cassandra는 CQL)[^48]

데이터를 입/출력하려면 SQL이 아니라 “자기들이 만든 언어”를 써야 한다고 말한다.[^48]
카산드라의 경우 “CQL”을 쓰면 된다고 예시를 든다.[^49]

3.8.3 정규화(중복 제거) 안 함 + 분산 처리 강함 → 입출력 많은 환경에 사용[^50][^51]

화자는 컬럼 패밀리 DB도 “정규화 이런 거 안 해요”, 즉 “중복 제거를 안 한다”는 소리라고 정리한다.[^50]
그래서 데이터 입출력 문법이 “더 쉽”다고 말하고[^50]
“분산 처리도 매우 잘” 해주기 때문에 “많은 입출력을 감당”해야 하면 이런 DB를 쓰는 경우가 있다고 설명한다.[^51]
또한 앞에서 말했듯 분산에는 단점이 있다고 했으니 참고하라고 덧붙인다.[^52]

3.9 시계열(Time-series) 데이터베이스: 시간 기록을 쉽게 해주는 기능 → 시계열 저장/분석에 사용[^53][^54]

화자는 “가끔 데이터 저장을 할 때 시간 기록 같은 걸 되게 쉽게 해주는 기능”이 있어서[^53]
“시계열 데이터 저장하고 분석할 때” 특정 DB를 쓰는 경우도 있다고 언급한다.[^54]
(영상에서는 특정 제품명을 열거하기보다, “그런 목적의 DB가 있다”는 범주 소개로 지나간다.)[^53][^54]

3.10 검색용(인덱스) 데이터베이스/엔진: 엘라스틱서치·클라우드서치, ‘일반 DB’가 아니라 인덱스 보관용[^55][^56][^57][^58][^59]

화자는 또 다른 범주로 “검색용 인덱스를 보관하기 위한” 시스템을 소개한다.[^55]
예시로 다음을 든다.[^55]

• 엘라스틱서치(Elasticsearch)
• 아마존의 클라우드서치(Amazon CloudSearch)

화자는 이들이 “일반적인 데이터베이스로 사용도 가능하긴” 하지만 “실제로 그렇지”는 않다고 말하며,[^56]
실제 주 용도는 “인덱스 보관용”이라고 선을 긋는다.[^56]

3.10.1 인덱스란: 검색을 빠르게 하는 “색인/목차”[^57]

인덱스가 무엇인지에 대해, “데이터 검색을 되게 빠르게 할 수 있게 도와주기 위한” 것이며 “색인 목차 같은” 것이라고 설명한다.[^57]

3.10.2 동작 방식: 기존 DB에서 데이터 뽑아 입력 → 인덱스 생성/보관 → 검색 요청 시 인덱스로 빠른 검색[^58][^59][^60]

화자는 일반적인 흐름을 다음처럼 묘사한다.

• “기존 DB에서 데이터를 뽑아” 검색 시스템에 “입력”한다.[^58]
• 그러면 그 시스템이 “인덱스를 생성하고 보관”하는 역할을 한다.[^58]
• “검색 요청이 들어오면” 인덱스를 이용해 자료를 “되게 쉽게 검색”하도록 도와준다.[^59]

3.10.3 부가 기능: 실시간 검색어/추천 검색어/오타 교정 같은 기능을 쉽게 구현[^60]

화자는 검색 인덱스 시스템을 쓰면, 단순 검색뿐 아니라 다음 같은 “부가적인 서비스”도 “되게 쉽게” 만들 수 있다고 말한다.[^60]

• 실시간 검색어
• 추천 검색어
• 검색어 오타 교정

그래서 “검색이 중요한 사이트”를 만들 때 이런 것을 쓰는 경우가 많다고 결론낸다.[^61]

3.11 최종 선택 가이드: 대부분은 RDB vs Document DB, 기준은 ‘정확도’와 ‘대량 입출력’[^62][^63][^64]

화자는 “너무 많아서 요약해 달라”고 하는 흐름으로 최종 정리 파트를 제시한다.[^62]
여기서 영상의 선택 기준이 명시적으로 정리된다.

• “일반적으로는” 관계형 DB 또는 도큐먼트 DB 중 “하나 골라서 쓰면” 된다고 말한다.[^62]
• “정확도는 필요 없고, 데이터를 많이 입출력해야 되는 경우”에는 도큐먼트 DB를 쓰면 된다고 제시한다.[^63]
• “데이터의 정확도가 중요”하면 “일반적으로 관계형 DB”를 쓰는 경우가 많다고 다시 확인한다.[^64]

[!TIP] 콘텐츠가 제시하는 1차 의사결정 규칙

1. 기본 후보는 관계형 vs 도큐먼트로 단순화하고[^62]
2. 정확도/트랜잭션이 우선이면 관계형,[^64]
3. 대량 입출력/분산 친화가 우선이면 도큐먼트 쪽을 우선 고려한다.[^63][^41]

4. 핵심 통찰[^1]

1. [h DB 선택은 “종류 암기”가 아니라 “요구사항(정확도 vs 처리량/분산 vs 관계 질의 vs 검색)”에 맞추는 문제로 제시된다.] DB를 무조건 하나로 통일하기보다, 목적에 따라 메인 DB + 특수 DB를 조합하는 시각이 깔려 있다.[^39][^15][^61]

   • 실행: “우리 서비스에서 가장 중요한 것”을 먼저 고르기(정확도/트랜잭션인지, 대량 조회인지, 관계 탐색인지, 검색 품질인지).[^^27][^41][^34][^61]

2. [h 레디스는 ‘키-밸류’의 단순함을 유지하면서도 ‘RAM’이라는 저장 매체 선택으로 실전 활용성을 확보한다.] 그래서 메인 DB를 대체하기보다 캐시/서브DB로 붙는 패턴이 강조된다.[^8][^12][^15]

3. [h 관계형 DB의 강점은 “표 형식” 그 자체보다도 “정확도(트랜잭션)”와 “범용성(널리 쓰임)”으로 설명된다.] 반면 정규화는 중복 제거의 대가로 쿼리 복잡도를 증가시킬 수 있다.[^21][^26][^25]

   • 실행: “돈 거래 등 중요한 기능”이 핵심이면 관계형 DB를 우선 검토.[^26][^27]

4. [m ‘관계형’이라는 명칭이 실제 세계의 ‘관계 데이터’에 최적이라는 뜻은 아니라는 문제제기가 나온다.] 관계 자체를 중심으로 저장/질의하려면 그래프 DB가 더 자연스럽다는 흐름으로 연결된다.[^28][^30][^32]

5. [h 도큐먼트/컬럼패밀리 계열은 ‘유연한 스키마 + 비정규화 + 분산 용이’로 인해 “입출력 많은 서비스” 쪽의 해법으로 제시된다.] 다만 분산의 대가로 정확도/일관성이 떨어질 수 있음을 경고한다.[^41][^43]

6. [m 엘라스틱서치 같은 검색 계열은 ‘일반 DB’가 아니라 “인덱스 저장/검색 기능”에 최적화된 보조 시스템으로 설명된다.] 검색 품질 기능(추천/오타교정 등)을 쉽게 만드는 도구로 자리매김한다.[^56][^60][^61]

5. 헷갈리는 용어 정리[^3]

키-밸류 데이터베이스: 데이터를 key:value 형태로 저장하는 매우 단순한 형태의 DB로, 일반적으로 서브 용도 성격이 강하다고 설명된다.[^3][^5]
레디스(Redis): 키-밸류 형태를 지원하지만 데이터를 1차적으로 RAM에 저장해 매우 빠르며, 메인 DB의 자주 쓰는 데이터를 복사해 두는 캐싱/서브 DB(또는 pub/sub 구현) 용도로 많이 쓰인다고 설명된다.[^8][^12][^15]
관계형 데이터베이스(RDB): 테이블(표) 형태로 데이터를 저장하며 SQL로 입출력하고, 정규화(중복 제거/테이블 분리)를 중시하며, 트랜잭션으로 정확도를 확보하는 DB로 설명된다.[^18][^22][^23][^26]
SQL: 관계형 DB에서 데이터를 저장/조회하기 위한 문법(언어)로, 화자는 매우 쉽다고 표현한다.[^22]
정규화: 데이터 중복을 싫어해 중복이 생기면 테이블을 쪼개는 설계 행위를 말하며, 쿼리가 길고 복잡해질 수 있는 단점으로 연결된다.[^23][^25]
트랜잭션: 돈 거래 같은 중요한 기능을 안전하게 구현하는 데 필요한 기능으로, 관계형 DB에 기본적으로 들어 있다고 설명된다.[^26]
그래프 데이터베이스: 노드에 데이터를 저장하고 노드 간 관계를 함께 기록하는 DB로, 관계/방향 중심 데이터를 다룰 때 유용하다고 설명된다.[^32][^34]
도큐먼트 데이터베이스: 컬렉션 안에 도큐먼트(파일)를 두고 JSON 형태로 저장하며, 스키마를 미리 강제하지 않고 정규화도 하지 않는(중복 허용) 유연한 DB로 설명된다.[^36][^38][^39]
컬럼 패밀리 데이터베이스: 테이블 형태를 유지하면서 행에 대해 칼럼을 더 자유롭게 구성할 수 있고, 정규화 없이 분산 처리에 강한 계열로 설명된다.[^45][^46][^50]
인덱스: 데이터 검색을 빠르게 하기 위한 “색인/목차” 같은 것으로, 검색용 시스템이 생성/보관해 검색 요청을 빠르게 처리한다고 설명된다.[^57][^59]

---

참고(콘텐츠 정보)[^1]

• 제목: 개발시 데이터베이스 선택 가이드 (총정리)[^1]
• 채널: 코딩애플[^1]
• 길이: 6분 58초[^1]
• 링크: https://www.youtube.com/watch?v=ZVuHZ2Fjkl4[^1]

[^1]: @[00:00] "여러분들이 새로운 서비스를 만들거나 ... 데이터베이스를 하나 골라야 되는 경우들이 있습니다" 및 사용자가 제공한 메타데이터(제목/채널/길이/링크). [^2]: @[00:07] "근데 너무 많아서 뭘 걸을지 모르겠다 그러면 이번 기회에 다 정리해 보도록 합시다" [^3]: @[00:15] "키밸류 데이터베이스라는게 있는데 데이터를 키 밸류 형태로 저장" [^4]: @[00:24] "근데 너무 간단해 보여서 실용성은 딱히 없을 것 같죠" [^5]: @[00:28] "실은 맞고요 ... 서브 용도로 사용하거나 그게 다 예요" [^6]: @[00:31] "특수한 기능을 가진 키밸류 ... 레디스" [^7]: @[00:35] "얘는 되게 많이 씁니다" [^8]: @[00:38] "데이터를 하드디스크에 저장하지 않고요" [^9]: @[00:41] "일차적으로 램에 저장을 해 줍니다" [^10]: @[00:44] "램이 하드보다 몇십 몇 백 배는 빠르니까요" [^11]: @[00:47] "메인 DB 같은 걸 하나 두고요" [^12]: @[00:50] "사람들이 자주 쓰는 데이터들 ... 레디스도 추가로 복사" [^13]: @[00:58] "데이터가 필요하면 ... 레디스 꺼내 보여주는 경우" [^14]: @[01:01] "그러면 되게 빠른 서비스를 만들 수" [^15]: @[01:04] "캐싱 용 또는 퍼섭 구현 ... 서브 dvm" [^16]: @[01:07] "레디스 하나로 모든 걸 ... 아무도 안 쓰는 거 같고요" [^17]: @[01:13] "데이터도 표 형태로 저장하고 싶으면 ... 관계형 데이터베이스" [^18]: @[01:24] "테이블을 하나 만들고 ... 어떤 데이터를 저장할지 ... 이름" [^19]: @[01:30] "하나의 행마다 이렇게 데이터를 보관" [^20]: @[01:36] "엑셀도 관계형 ... 대량의 데이터를 저장하려면 오라클 mysql 포스트그레스" [^21]: @[01:42] "점유율 같은 거 보면 상위권들 다 관계형 디비" [^22]: @[01:54] "SQL이라는 문법 ... 쉬워 가지고 세 살짜리 애들도" [^23]: @[02:02] "관계형 디비를 사용할 때 ... 정규화" [^24]: @[02:10] "데이터 중복 ... 다른 테이블로 다 쪼개" [^25]: @[02:14] "정규화 ... 문법 같은게 좀 길고 복잡" [^26]: @[02:25] "기본적으로 트랜잭션 기능 ... 돈 거래 ... 안전" [^27]: @[02:31] "입출력 속도보다 데이터 정확도가 매우 중요 ... 관계형" [^28]: @[02:37] "관계형 ... 관계를 잘 표현 ... 릴레이션 ... 행렬" [^29]: @[02:50] "관계 표현은 가능한데 ... 저장하기엔 좀 귀찮은 점" [^30]: @[02:53] "관계를 주로 ... 그래프 데이터베이스" [^31]: @[02:56] "가장 유명한게 네어 4(Neo4j)" [^32]: @[03:06] "노드 ... 노드 안에 데이터 ... 관계인지도 기록" [^33]: @[03:13] "그래프 쿼리 랭귀지 ... 방향 같은 것도 표현" [^34]: @[03:30] "비행기 노선 ... SNS 친구 관계 ... 코로나 전염 ... 추천 서비스" [^35]: @[03:43] "조금 더 자유로운 도큐먼트 데이터베이스 ... 몽거DV 카우치DV 파이어스토어" [^36]: @[03:59] "컬렉션 ... 도큐먼트 ... 제이슨 형태" [^37]: @[04:06] "제이슨 ... 그냥 키 밸류 형태랑 똑같" [^38]: @[04:10] "미리 정의 ... 갑자기 연락처 ... 에러 안" [^39]: @[04:20] "가장 큰 특징 ... 중복 제거를 하지 않습니다 ... 정규화 같은 걸 안" [^40]: @[04:30] "데이터 입출력 문법 ... 훨씬 간단" [^41]: @[04:34] "대부분 분산을 염두 ... 분산시켜 놓는게 ... 쉬워요 ... 입출력이 ... 많은 서비스" [^42]: @[04:43] "분산에 놓으면 당연히 단점" [^43]: @[04:53] "디비간에 정확도 같은게 떨어질 수" [^44]: @[04:57] "중요하지 않으면 ... 전혀 상관없고요" [^45]: @[05:00] "표 형식 ... 조금 유연 ... 컬럼 패밀리 ... 카산드라 ... 빅 테이블" [^46]: @[05:06] "테이블 ... 로 ... 자유롭게 칼럼을 만들어서" [^47]: @[05:10] "표랑 똑같아요" [^48]: @[05:21] "입출력하려면 SQL이 아니라 ... 만든 언어" [^49]: @[05:23] "카산드라 ... cql" [^50]: @[05:32] "정규화 ... 안 해요 ... 중복 제거 ... 안" [^51]: @[05:38] "분산 처리 ... 매우 잘 ... 많은 입출력" [^52]: @[05:42] "분산 처리해 놓으면 단점 ... 참고" [^53]: @[05:47] "시간 기록 ... 쉽게 해 주는 기능" [^54]: @[05:52] "시계열 데이터 저장하고 분석" [^55]: @[05:59] "검색용 인덱스를 보관 ... 일라스틱 서치 ... 클라우드 서치" [^56]: @[06:03] "일반적인 데이터베이스로 ... 가능 ... 실제로 그렇지 ... 인덱스 보관용" [^57]: @[06:12] "인덱스가 뭐냐면 ... 색인 목차" [^58]: @[06:17] "기존 ... 데이터를 뽑아 ... 입력 ... 인덱스를 생성하고 보관" [^59]: @[06:23] "검색 요청 ... 인덱스를 이용해서 ... 쉽게 검색" [^60]: @[06:26] "실시간 검색어 추천 ... 오타 교정 ... 쉽게" [^61]: @[06:29] "검색이 중요한 사이트 ... 쓰는 경우들이 많고요" [^62]: @[06:33] "일반적으로는 관계형 DV 또는 도큐먼트 DV ... 하나 골라" [^63]: @[06:39] "정확도는 필요 없고요 ... 데이터를 많이 입 출력 ... 도큐먼트" [^64]: @[06:54] "데이터의 정확도가 중요 ... 관계형"