[ DB & SQL(RDBMS, NoSQL) ] 데이터 베이스 기초 이해 07 : 데이터베이스 구조와 용어 정리. (RDBMS vs NoSQL vs Vector DB)

Data-Forge : 데이터로 세상 이해해보기.·2025년 7월 29일
dbsql개발공부데이터데이터사이언스
0

DB : SQL(RDBMS,NoSQL,VectorDB) 이론 공부.

목록 보기
18/19
post-thumbnail

[ DB & SQL(RDBMS, NoSQL) ] 데이터 베이스 기초 이해 07 : 데이터베이스 구조와 용어 정리. (RDBMS vs NoSQL vs Vector DB)

▽ [ DB & SQL(RDBMS, NoSQL) ] 데이터 베이스 기초 이해 07 : 데이터베이스 구조와 용어 정리. (RDBMS vs NoSQL vs Vector DB).


📙 데이터베이스 구조와 용어 정리. (RDBMS vs NoSQL vs Vector DB)

목  차

1. 📒 스키마, 테이블, 뷰, 인덱스, 시퀀스 등 핵심 객체의 개념적 정의
2. 📒 키의 종류(Primary, Foreign, Unique, Composite, Surrogate)와 데이터 무결성
3. 📒 데이터 타입 및 제약조건의 이론적 역할
4. 📒 ERD의 개념적 구조와 모델링 도구의 원리

1. 📒 스키마, 테이블, 뷰, 인덱스, 시퀀스 등 핵심 객체의 개념적 정의

객체RDBMSNoSQLVector DB
스키마 (Schema)데이터베이스의 논리적 구조. 테이블, 뷰, 인덱스 등을 그룹화.
고정된 강타입 구조		스키마리스(동적). 문서마다 다른 필드 가능.
단, Schema Validation 기능 지원 (MongoDB)		컬렉션에 대해 차원 수, 인덱스 유형 등만 정의. 데이터 구조 자체는 유연
테이블 / 컬렉션테이블(Table). 행(Row) + 열(Column).컬렉션(Collection). JSON/BSON 문서 집합.컬렉션(Collection). Embedding 벡터 + 메타데이터 집합.
행 / 문서Row (튜플). 데이터 레코드.Document. 가변 구조. 중첩 가능.Vector Entry. 벡터(고차원 배열) + 원본 텍스트/이미지/메타데이터.
뷰 (View)SELECT 기반 가상 테이블. 보안/추상화 목적.없음. 대신 Aggregation Pipeline 등 사용.없음. 대신 “쿼리 결과(top_k)” 자체가 가상 뷰처럼 활용.
인덱스 (Index)B-Tree, Hash, Bitmap 등 → WHERE 조건 최적화.복합 인덱스, GeoSpatial, Text Index.Vector Index (IVF, HNSW, PQ). 근사 최근접 탐색(ANN).
시퀀스 (Sequence)SERIAL, AUTO_INCREMENT, NEXTVAL.ObjectID(UUID), Snowflake ID 등.UUID 또는 시스템이 자동 발급하는 Vector ID.

📌 RDBMS (관계형 DB)

1. 스키마(Schema)

  • 정의
    : 데이터베이스 안에서 객체(테이블, 뷰, 인덱스 등)의 구조를 정의한 논리적 집합.

  • 역할
    : 데이터 구조를 강하게 제한시켜서 '무결성'과 '일관성'을 보장.

  • EX

CREATE SCHEMA sales;
CREATE TABLE sales.customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL
);
  • 실무 팁
    : 서비스 운영 중 컬럼 타입 변경 같은 스키마 변경은 매우 위험하므로,
    Liquibase/Flyway 같은 DB 마이그레이션 도구 필수 사용.

2. 테이블(Table)

  • 구조 : 행(Row, 튜플) 과 열(Column, 속성) 로 구성.

  • 특징 : 모든 행은 동일한 컬럼 구조와 데이터 타입을 가짐.

  • 중요성 : 정규화 과정을 통해 데이터 중복 최소화.

3. 뷰(View)

  • 개념 : 실제 데이터는 없고, SELECT 쿼리 결과를 저장하는 가상 테이블.

  • 목적 : 보안(특정 컬럼만 노출), 쿼리 단순화

  • 실무 : 대규모 시스템에서는 Materialized View 사용 -> 성능 개선.

4. 인덱스(Index)

  • 개념 : 데이터를 빠르게 찾기 위한 보조 구조.

  • 대표 구조 :

    • B+Tree(범위 검색)
    • Hash Index(정확한 일치 검색)
    • Bitmap Index(OLAP에서 다중 조건)

  • 실무 고려 : SELECT는 빨라지지만, INSERT / UPDATE 성능 저하 가능.

5. 시퀀스(Sequence)

  • 개념 : 고유한 일련번호를 생성하는 객체.

  • 사용 예시 : 주문번호, 회원번호

  • MySQL : AUTO_INCREMENT.

  • 실무 문제 : 분산 환경에서는 충돌 위험 -> UUID, Snowflake ID로 대체

📌 NoSQL

1. 스키마.

  • 특징 : 스키마리스(Schema-less)

  • 장점 : 애플리케이션 변경에 다라 필드를 자유롭게 추가 가능.

  • 단점 : 데이터 일관성 관리 어려움 -> MongoDB에서는 $jsonSchema 옵션 활용.

2. 컬렉션(Collection) & 문서(Document)

  • 구조 : JSON/BSON 기반, 중첩 필드 허용.

  • 예시.

{
  "_id": "cust001",
  "name": "홍길동",
  "orders": [
    {"order_id": "o123", "amount": 20000}
  ]
}
  • 특징 : 정규화보단 "데이터 접근 패턴 최적화"에 집중.

3. 뷰/인덱스/시퀀스.

  • 뷰 : Aggregation Pipeline으로 대체.

  • 인덱스 : 단일/복합, GeoSpatial, Text Index 지원.

  • 시퀀스 : _id 자동 생성(ObjectID, UUID)

📌 Vector DB

1. 스키마.

  • 정의
    : 일반적으로 벡처 차원 수(dimension), 인덱스 유형(HNSW, IVF 등), 메타데이터 구조 정의.

  • 특징 : 정형화된 스키마보다 "검색 정확도와 성능" 중심.

2. 컬렉션(Collection)

  • 벡터(Embedding) + 메타데이터(MetaData)

  • ex(Pinecone/ Weaviate) :

index.upsert([
  ("doc123", [0.12, -0.43, 0.91, ...], {"category": "news"})
])

3. 인덱스

  • ANN(근사 최근접 탐색) 알고리즘 사용.

  • 대표적 구조.

    • HNSW ( Hierarchical Navigable Small World) -> 그래프 탐색 기반
    • IVF ( Inverted File) -> 클러스터링 기반
    • PQ (Product Quantization) -> 벡터 압축.

4. 시퀀스/ID

  • 보통 UUID 기반
  • 벡터 자체가 고유성의 핵심 역할을 수행.

2. 📒 키의 종류(Primary, Foreign, Unique, Composite, Surrogate)와 데이터 무결성

키 유형RDBMSNoSQLVector DB
Primary Key각 행 고유 식별. NULL/중복 불가._id 필드 자동 생성. (예: MongoDB ObjectID)Vector ID. 보통 UUID 기반.
Foreign Key다른 테이블 PK 참조. 참조 무결성 보장.대부분 지원 안 함. → 데이터 중복/내장으로 해결.관계 개념 없음. Join 필요 없음.
Unique Key중복 불가. NULL 허용 가능.Unique 인덱스 가능 ({email:1}, unique:true).일반적으로 지원 X (중복 ID 방지 수준만).
Composite Key(col1, col2) 같이 조합.복합 인덱스 ({field1:1, field2:1}).불필요. (보통 Embedding 자체가 고유성 역할).
Surrogate KeyAUTO_INCREMENT 같은 인공 PK.ObjectID, UUID.UUID, 해시 기반 Vector ID.
무결성 (Integrity)엔티티 무결성, 참조 무결성, 도메인 무결성.무결성 보장 약함. → 앱 로직에서 관리.무결성 개념 대신 벡터 정확도 및 검색 일관성이 핵심.

1️⃣ Primary Key (기본 키).

📌 정의.

  • 테이블 내에서 '각 행을 "유일"하게 식별' 하는 컬럼( 혹은 컬럼 집합 ).

  • NULL 불가, 중복 불가

  • 한 테이블에는 단 하나만 존재.

📌 예시 (RDBMS)

CREATE TABLE Customer (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL
);

📌 내부 원리.

  • RDBMS는 PK에 대해 자동 인덱스 생성.

  • 데이터 검색 시 테이블 전체 탐색(Full Scan) 대신 PK 인덱스를 사용
    → 빠른 조회 가능.

📌 실무 고려.

  • 분산 환경에서는 단순 AUTO_INCREMENT가 충돌 위험
    → UUID, Snowflake ID 활용.

  • PK를 잘못 설계하면 인덱스 크기 폭발 → 성능 저하.

2️⃣ Foreign Key (외래 키)

📌 정의

  • 한 테이블의 컬럼이 '다른 테이블의 "PK"를 참조' 하는 제약조건.

  • ' 참조 무결성 '을 보장. (삭제/수정 시 제약 검증 )

📌 예시 (RDBMS).

CREATE TABLE Orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    FOREIGN KEY (customer_id) REFERENCES Customer(customer_id)
);

📌 내부 원리.

  • INSERT/UPDATE 시 FK 대상 값이 부모 테이블에 존재하는지 체크.

  • DELETE 시 ON DELETE CASCADE 옵션 가능.

📌 실무 고려.

  • 대규모 시스템에서는 FK 검증이 DB 락 경합 유발
    → 애플리케이션 레벨에서 무결성 보장하기도 함.

  • 예: 대형 커머스 시스템에서 성능 문제 때문에 FK 제약을 제거하고,
    서비스 코드에서 검증 로직 수행.

3️⃣ Unique Key (고유 키)

📌 정의.

  • 컬럼 값의 ' "중복"을 허용하지 않음.'

  • 여러 개 설정 가능, NULL은 허용 ( 일부 DB )

📌 예시 (RDBMS).

CREATE TABLE User (
    user_id INT PRIMARY KEY,
    email VARCHAR(255) UNIQUE
);

📌 내부 원리.

  • PK와 달리 NULL 허용 가능 ( DBMS마다 차이 있음 )

  • Unique Index 자동 생성.

📌 실무 고려.

  • 이메일/주민번호 같은 비즈니스적으로 유일해야 하는 속성에 적용.

  • 단, 분산 환경에서는 동시성 충돌 문제
    → DB의 Unique 제약에 의존하거나, Redis 분산 락으로 해결.

4️⃣ Composite Key (복합 키)

📌 정의.

  • 두 개 이상의 컬럼을 조합해, 하나의 PK 역할을 수행.

  • 단일 컬럼으로 유일하지 않을 때 사용.

📌 예시.

CREATE TABLE Enrollment (
    student_id INT,
    course_id INT,
    PRIMARY KEY (student_id, course_id)
);

📌 내부 원리.

  • 인덱스는 코드 순으로 진행( 위 코드를 보면, student_id -> course_id 순서로 구성)

  • 쿼리 시 '왼쪽 컬럼 우선 탐색 원리(Left-most prefix rule)' 적용.

📌 실무 고려.

  • 조합 키가 길어질수록 인덱스 크기 커짐.

  • Surrogate Key를 추가로 두고, 복합 키는 Unique Index로 관리하는 경우가 많음.

5️⃣ Surrogate Key (대리 키)

📌 정의.

  • 실제 데이터와 상관없는 " 인공적으로 생성된 키 "

  • 보통 AUTO_INCREMENT, UUID.

  • 비즈니스적인 의미 없음.

📌 예시.

CREATE TABLE Products (
    product_id BIGINT AUTO_INCREMENT PRIMARY KEY,
    sku VARCHAR(50) UNIQUE
);

📌 실무 고려.

  • 자연 키(Natural Key, 예: 주민번호) 대신 선호되는 방식.

  • 이유: 자연 키는 변경 가능성 존재 → PK 변경은 참조 무결성 파괴 위험.

  • Surrogate Key는 안정적이고 확장에 유리.

6️⃣ 데이터 무결성 (Data Integrity)

📌 유형.

1. 엔티티 무결성 (Entity Integrity)
  • 모든 테이블은 PK를 가져야 하고, PK는 NULL/중복 불가.
2. 참조 무결성 (Referential Integrity)

  • FK 값은 반드시 참조 대상 PK 값과 일치.

  • 옵션: ON DELETE CASCADE, ON UPDATE CASCADE.

3. 도메인 무결성 (Domain Integrity)

  • 각 컬럼은 정의된 데이터 타입 / 제약 조건을 따라야 함.

  • 예: age INT CHECK (age >= 0).

4. 사용자 정의 무결성 (User-defined Integrity)
  • 비즈니스 규칙 기반
    • (예: 한 사용자는 동시에 한 개의 활성 주문만 가질 수 있다).

7️⃣ RDBMS vs NoSQL vs Vector DB 비교

📌 RDBMS.

  • 키와 무결성 개념이 "가장 엄격하게 적용".

  • 데이터 정합성과 무결성을 DB 자체가 보장.

  • 실무에서는 성능과 무결성 사이의 균형( EX : FK 제거 )이 중요.

📌 NoSQL.

  • Primary Key(_id)는 필수.

  • FK 개념 없음 → Join 대신 Document Embed.

  • '무결성 보장'은 애플리케이션 책임.

  • 성능/확장성을 위해 무결성보다 유연성을 택하는 경우 많음.

📌 Vector DB.

  • 키는 단순히 Vector ID 역할.

  • '무결성' 보다 벡터 차원 수 일관성과 검색 정확성이 핵심.

  • 참조 무결성이나 복합 키 같은 개념은 없음.

  • 무결성 = Embedding consistency.

3. 📒 데이터 타입 및 제약조건의 이론적 역할

항목RDBMSNoSQLVector DB
데이터 타입숫자(INT, DECIMAL), 문자열(VARCHAR), 날짜/시간, Boolean, BLOB 등 엄격하게 정의JSON 기반 (문자열, 숫자, 배열, 객체 등 자유). 문서마다 가변 가능.Vector (float32 배열, 보통 128~4096 차원). + Metadata(숫자, 문자열, 태그 등)
제약조건NOT NULL, CHECK, DEFAULT, UNIQUE, PRIMARY/FOREIGN KEY기본적으로 없음. 단, Schema Validation 가능.거의 없음. 다만 차원 수 고정 & 유사도 측정 방식 필수 지정 (cosine, dot-product 등).
예시sql<br>balance DECIMAL(10,2) CHECK (balance>=0)js<br>{ balance: { bsonType: "double", minimum: 0 } }python<br>("id1", [0.12, -0.43, ...], {"category": "news"})

1️⃣ 데이터 타입 (Data Types).

기초 개념.

데이터 타입이란??

  • '데이터'가 '어떤 종류와 형태로 저장' 될지를 정의하는 규칙.

  • 올바른 데이터 저장, 무결성 보장, 효율적인 저장/검색을 위해 필수. !

RDBMS의 주요 데이터 타입.

  • 숫자형: INT, BIGINT, DECIMAL

  • 문자열형: CHAR(고정 길이), VARCHAR(가변 길이), TEXT

  • 날짜/시간형: DATE, TIMESTAMP, DATETIME

  • 논리형: BOOLEAN

  • 이진형: BLOB (이미지, 파일 저장)

ex)

CREATE TABLE Users (
    user_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    birth_date DATE,
    is_active BOOLEAN DEFAULT TRUE
);

원리와 동작.

저장 효율성.

  • CHAR(10) → 항상 10바이트 고정

  • VARCHAR(10) → 실제 길이에 맞게 저장 (추가 길이 바이트 필요)

인덱스 효율성.

  • 짧은 고정 길이 타입(예: INT)은 인덱싱 성능이 좋음.

  • TEXT/BLOB 같은 대형 타입은 인덱싱 비효율적 → 보통 별도 테이블로 분리.

날짜/시간.
  • UNIX timestamp(INT)와 DATETIME 비교
    → 사람이 읽기 쉽고 타임존 처리에 유리한 DATETIME 선호.

성능 & 확장성 고려.

정밀도 관리.
  • 금액/통화 데이터는 'FLOAT' 대신 'DECIMAL(정확한 소수 계산)' 사용.
대규모 시스템.
  • 문자열 비교가 많은 컬럼은 ENUM 대신 정수 코드 매핑
    -> 인덱스 효율성 향상.
분산 환경.

  • DB 종류에 따라 BOOLEAN 저장 방식 차이 ( MySQL : TINYINT )

  • 데이터 타입 차이로 인한 마이그레이션 시 문제 발생 가능.

📌 NoSQL의 데이터 타입.

MongoDB.
  • 숫자(NumberInt, NumberLong, Double), 문자열(String)
  • 날짜(Date), Boolean, 배열(Array), 객체(Document).
Redis.
  • 문자열, 리스트, 해시, 집합(Set), 정렬된 집합(Sorted Set)
특징.
  • 스키마 유연성으로 같은 컬렉션에 다른 타입의 필드도 저장 가능.
실무 문제

  • 동일 필드의 타입 불일치 -> 쿼리 실패 / 예상치 못한 동작.

  • 해결법 : $jsonSchema Validator 사용.

📌 Vector DB의 데이터 타입.

핵심 타입 : 벡터(float32 배열)
메타데이터 : 문자열, 숫자, Boolean -> 필터링 조건으로 사용
제약 조건
  • 모든 벡터는 동일한 차원 수 유지
  • 차원 수 불일치 시 삽입 불가.

2️⃣ 제약조건 (Constraints)

기초 개념.

제약조건이란?
  • 잘못된 데이터 입력을 막아서 "데이터 무결성"을 유지하는 규칙.
주요 제약조건.

  • NOT NULL: 반드시 값이 있어야 함.

  • DEFAULT: 값 입력 없을 시 기본값 설정.

  • CHECK: 조건을 만족해야 함.

  • PRIMARY KEY: 유일 & NULL 불가.

  • FOREIGN KEY: 참조 무결성 보장.

  • UNIQUE: 중복 허용 안 함.

ex)

CREATE TABLE Accounts (
    account_id INT PRIMARY KEY,
    balance DECIMAL(10,2) CHECK (balance >= 0),
    status VARCHAR(10) DEFAULT 'ACTIVE'
);

동작 원리.

  • NOT NULL + UNIQUE 조합 → 사실상 Candidate Key.

  • CHECK 제약조건: 데이터 입력 시 DB 엔진이 조건 검사 수행.

  • DEFAULT: 트리거 없이도 기본값 보장.

  • 제약조건 위반 시: DB는 트랜잭션 롤백.

성능 & 아키텍쳐 고려.

RDBMS.

  • 과도한 제약조건 → INSERT/UPDATE 성능 저하.

  • 대규모 트래픽 시스템에서는 최소 제약조건만 유지, 나머지는 애플리케이션 레벨에서 검증.

  • 예: 배달앱 DB는 FK 제거, 대신 서비스 코드에서 고객/주문 관계 검증.

NoSQL.

  • 기본적으로 제약조건 없음 → 유연성↑, 정합성↓.

  • MongoDB에서 $jsonSchema로 유효성 검사 가능하지만 성능 비용 큼.

  • 실무: 대부분 Validation을 애플리케이션 단에서 처리.

Vector DB.

  • CHECK/NOT NULL 같은 제약은 없음.

  • 핵심 제약조건 = 벡터 차원 일관성.

  • 성능 고려
    : HNSW/IVF 같은 인덱스 구조 선택이 제약조건과 유사한 역할(검색 정확도 & 속도 균형).

3️⃣ 이론적 역할 총정리.

1. 데이터 정합성 유지

  • RDBMS: 제약조건으로 DB 자체에서 강제.

  • NoSQL: 애플리케이션에서 강제.

  • Vector DB: 차원 수 & 메타데이터 형식 강제.

2. 데이터 품질 보장

  • 잘못된 값, NULL 값 방지.

  • 비즈니스 로직 충족 여부(DB 또는 애플리케이션에서 검증).

3. 성능과 확장성의 트레이드오프

  • 제약조건 강화 → 무결성↑, 성능↓

  • 제약조건 완화 → 성능↑, 무결성↓ (대신 코드 레벨 관리 필요)

4. 📒 ERD의 개념적 구조와 모델링 도구의 원리

모델링 항목RDBMSNoSQLVector DB
모델링 도구ERD (Entity-Relationship Diagram). 정규화로 중복 최소화.Document Schema 설계. 쿼리 패턴 기반 비정규화.Vector Schema 설계 (차원 수, 인덱스 알고리즘, 필터링 메타데이터).
관계 표현1:1, 1\:N, M\:N 관계. Join 사용.내장(Embed) → 1\:N, 참조(Reference) → M\:N.관계 없음. 유사도 검색으로 연관성 파악.
설계 원칙데이터 무결성과 정규화(NF) 강조.데이터 접근 패턴 중심. Join 회피를 위해 중복 허용.검색 정확도와 벡터 인덱싱 효율 중심.
주요 사용 사례ERP, 금융, 인사, 재고 관리.IoT, SNS, 로그 관리, 전자상거래.검색엔진, 추천시스템, 챗봇, 멀티모달 AI.

1️⃣ ERD란 무엇인가? (기초 개념).

ERD(Entity Relationship Diagram)

  • 데이터베이스에 담길 엔티티(개체), 속성(필드), 관계(연결선)를 시각적으로 표현한 모델링 도구.

  • 목적 :

      1. 현실 세계의 데이터를 추상화
      1. 데이터 간 관계 정의
      1. 정규화를 통한 중복 최소화.

기본 구성 요소.

  • 엔티티(Entity) : 테이블에 해당. (ex: 학생, 강좌 )

  • 속성(Attribute) : 엔티티의 특성. (ex: 학번, 이름, 과목명 )

  • 관계(Relationship) : 엔티티 간 연결. (ex: 학생이 강좌를 수강한다)

2️⃣ RDBMS에서의 ERD 설계.

📌 기본 원리.

  • 1:1 관계
    : 하나의 행이 하나의 행과만 매핑.

  • 1:N 관계
    : 하나의 행이 여러 행과 연결. → FK 사용.

  • M:N 관계
    : 다대다 → 조인 테이블(Bridge Table) 필요.

ex) 학생(Student) – 수강(Course) 관계

CREATE TABLE Student (
    student_id INT PRIMARY KEY,
    name VARCHAR(50)
);

CREATE TABLE Course (
    course_id INT PRIMARY KEY,
    title VARCHAR(100)
);

CREATE TABLE Enrollment (
    student_id INT,
    course_id INT,
    PRIMARY KEY (student_id, course_id),
    FOREIGN KEY (student_id) REFERENCES Student(student_id),
    FOREIGN KEY (course_id) REFERENCES Course(course_id)
);

📌 정규화와 비정규화.

  • 정규화(NF)

    • 1NF: 원자값

    • 2NF: 부분 종속 제거

    • 3NF: 이행 종속 제거

  • 장점 : 데이터 중복 최소하, 무결성 강화.

  • 단점 : Join이 많아져서 성능 저하 유발.

📌 아키텍쳐 고려.

  • 조회 성능을 위해 부분 비정규화 적용 (예: 고객 테이블에 고객등급 캐싱).

  • ERD 설계 시 ERWin, MySQL Workbench, DBeaver 같은 모델링 도구 활용.

  • 대규모 시스템은 ERD를 모듈 단위로 분리 (User, Order, Product 등 도메인별).

3️⃣ NoSQL에서의 모델링 접근.

📌 기본 원리.

  • ERD 개념은 약화 → 대신 Document Schema 설계 사용.

  • MongoDB에서는 컬렉션(Collection)이 테이블, 문서(Document)가 행에 해당.

📌 Embed vs Reference 전략.

  • Embed(내장)

    • 하위 데이터가 상위 데이터와 함께 자주 조회됨.
    • 장점 : Join 불필요, 읽기 속도 빠름
    • 단점 : 데이터 중복 발생.

  • Reference(참조)

    • 데이터 중복 방지, 하지만 Join 유사 $lookup 필요.
    • 단점 : 성능 비용 큼.

EX (주문 내역 설계):

// Embed 방식
{
  "_id": "order123",
  "customer": {"id": "cust1", "name": "홍길동"},
  "items": [
    {"product_id": "p1", "qty": 2},
    {"product_id": "p2", "qty": 1}
  ]
}

// Reference 방식
{
  "_id": "order123",
  "customer_id": "cust1",
  "item_ids": ["p1", "p2"]
}

📌 확장 개념.

  • 쿼리 패턴 기반 모델링: 어떤 쿼리가 가장 많이 수행되는지 분석 후
    Embed/Reference 결정.

  • 스키마 검증 도구 사용 ($jsonSchema, Mongoose Schema 등).

  • 관계형 ERD → 문서 모델링 변환 경험 필수 (RDB → NoSQL 마이그레이션 시).

4️⃣ Vector DB에서의 모델링 접근.

📌 기본 원리.

  • Vector DB는 관계형 모델링 개념이 거의 없음.

  • 기본 단위 = 벡터(Embedding) + 메타데이터.

  • 목적 = 유사도 기반 검색.

ex) (Pinecone / Milvus)

index.upsert([
  ("doc123", [0.12, -0.43, 0.91, ...], {"category": "news", "lang": "ko"})
])

📌 중급 수준.

  • Schema 요소 :
    • 벡터 차원 수
    • 인덱스 알고리즘(HNSW, IVF, PQ)
    • 메타데이터 필터링 필드

📌 확장 개념.

  • Vector DB에서는 ERD 대신 검색 정확도/성능 튜닝 설계가 핵심.

  • 고려해야 할 것:

    • 차원 수와 임베딩 모델 선택

    • ANN 인덱스 파라미터 (HNSW: M, efSearch)

    • 필터링 조건과 메타데이터 인덱스 전략

  • RAG(Retrieval-Augmented Generation) 같은 AI 활용 시 필수 설계 요소.

5️⃣ 종합 비교

구분RDBMSNoSQLVector DB
모델링 도구ERD (정규화 중심)Document SchemaVector Schema
관계 표현1:1, 1\:N, M\:NEmbed/Reference관계 없음, 유사도 기반
설계 원칙무결성과 정규화쿼리 패턴 최적화, Join 회피차원/인덱스 최적화
실무 고려무결성과 성능 균형데이터 중복 허용, Validation 필요검색 정확도 & 속도 균형
주요 사례ERP, 금융, 재고SNS, IoT, 로그, 커머스추천, 검색, 챗봇, 멀티모달 AI

profile
Data-Forge : 데이터로 세상 이해해보기.
Roll with the punches
이전 포스트

[ DB & SQL(RDBMS, NoSQL) ] DB 모델링 개발의 순서.

다음 포스트

새로운 DB를 연습할 시간인가.

0개의 댓글