NoSQL 데이터베이스 활용에서 반복적으로 나타나는 설계 패턴들이 있다. 올바른 패턴 선택은 쿼리 성능, 확장성, 데이터 일관성 사이의 트레이드오프를 결정한다.
NoSQL 유형별 특징
| 유형 | 대표 DB | 데이터 모델 | 강점 |
|---|
| 도큐먼트 | MongoDB, CouchDB | JSON 문서 | 유연한 스키마, 중첩 구조 |
| 키-값 | Redis, DynamoDB | key → value | 단순, 초고속 |
| 와이드 컬럼 | Cassandra, HBase | 동적 컬럼 | 시계열, 쓰기 최적화 |
| 그래프 | Neo4j, Neptune | 노드-엣지 | 관계 탐색 |
| 시계열 | InfluxDB, TimescaleDB | 타임스탬프 | 모니터링, IoT |
쿼리 중심 설계 (Cassandra/DynamoDB)
원칙: "쿼리를 먼저 설계하고, 그에 맞게 테이블을 설계한다"
필요한 쿼리들:
Q1: 사용자의 최근 게시물 가져오기
Q2: 특정 태그의 게시물 가져오기
Q3: 특정 게시물의 댓글 가져오기
각 쿼리마다 별도 테이블:
articles_by_user (PK: user_id, SK: created DESC)
articles_by_tag (PK: tag, SK: created DESC)
comments_by_article (PK: article_id, SK: created ASC)
버킷 패턴 (Bucket Pattern)
javascript
// 문제: IoT 센서가 1초마다 데이터를 저장 → 수십억 건
// 나쁜 예: 매 이벤트 문서
{sensorId:"S01", ts: ISODate("2024-01-01T00:00:01"), val: 22.5}
{sensorId:"S01", ts: ISODate("2024-01-01T00:00:02"), val: 22.6}
// ... 수십억 개 문서
// 좋은 예: 1시간 단위 버킷
{
sensorId: "S01",
hour: "2024-01-01T00",
count: 3600,
sum: 81180.5,
min: 22.0, max: 23.5,
readings: [22.5, 22.6, ...] // 1시간치 배열
}
// 효과: 문서 수 3600배 감소, 집계 쿼리 빠름
속성 패턴 (Attribute Pattern)
javascript
// 문제: 제품마다 다른 속성 (카탈로그 DB)
// 나쁜 예: 희소 컬럼
{product:"TV", size_inch:55, resolution:"4K", weight_kg:18, pages:null, isbn:null}
{product:"Book", size_inch:null, resolution:null, weight_kg:0.5, pages:300, isbn:"..."}
// 좋은 예: 속성 배열 패턴
{
product: "TV",
specs: [
{key:"size_inch", value:"55", unit:"inch"},
{key:"resolution", value:"4K"},
{key:"weight_kg", value:"18", unit:"kg"}
]
}
// 장점: 인덱스 하나로 모든 속성 검색 가능
// db.products.createIndex({"specs.key":1, "specs.value":1})
관련 문서
