467. 컬럼 패밀리 DB (Column-family) - HBase, Cassandra

⚠️ 이 문서는 "1억 명의 유저가 남긴 10억 개의 로그를 저장해야 하는데, 사람마다 남기는 로그의 속성(컬럼)이 1,000개씩 다를 때 어떻게 빈칸(Null) 없이 저장할까?"라는 빅데이터 시대의 난제를 해결하기 위해, **구글(Bigtable)이 발명해 낸 '행(Row)'과 '열(Column)'이 무한히 늘어나는 다차원 맵 저장소인 '컬럼 패밀리 NoSQL'**을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: RDBMS처럼 뼈대(컬럼)가 고정되어 있지 않다. 하나의 행(Row)에 컬럼을 수천 개씩 무한대로 추가할 수 있는 동적 스키마(Dynamic Schema) 구조를 가진다.
  2. 가치: 데이터가 없는 빈칸(Null)은 아예 디스크에 저장조차 하지 않으므로 저장 공간의 낭비가 0%다. 압도적인 쓰기(Write) 성능으로 대규모 로그나 센서 데이터를 긁어모으는 데 최적화되어 있다.
  3. 기술 체계: 관련된 컬럼들을 그룹으로 묶는 '컬럼 패밀리(Column Family)' 개념이 핵심이며, Apache HBase와 Cassandra가 이 분야의 양대 산맥이다.

Ⅰ. 개요: 빈칸으로 가득 찬 엑셀 표 (Context & Necessity)

어느 쇼핑몰에서 고객들의 활동을 기록하려고 한다.

  • 철수는 [신발클릭, 검색어: 나이키]를 남겼다.
  • 영희는 [장바구니 담기, 검색어: 원피스, 찜하기, 쿠폰 다운로드]를 남겼다.

RDBMS(MySQL)로 이 테이블을 만들려면, 고객들이 할 수 있는 1,000가지의 행동을 미리 컬럼으로 다 1,000개 파놔야 한다.

  • 철수의 데이터 줄에는 찜하기, 쿠폰 컬럼이 비어있다(Null).
  • 1억 명의 데이터가 쌓이면, 이 테이블은 데이터보다 빈칸(Null)이 더 많은 거대한 쓰레기장이 된다.

컬럼 패밀리 DB는 빈칸을 만들지 않는다.

  • 철수: [신발클릭: 1, 검색어: 나이키] (컬럼 2개만 생성됨)
  • 영희: [장바구니: 1, 검색어: 원피스, 찜: 1, 쿠폰: 1] (컬럼 4개만 생성됨)

필요할 때마다 그때그때 새로운 컬럼 이름을 만들어서 데이터를 끼워 넣으면 된다. (동적 컬럼 추가)

📢 섹션 요약 비유: RDBMS가 100칸짜리 약통을 미리 사서, 약이 없는 빈칸까지 들고 다녀야 하는 **'고정형 약통'**이라면, 컬럼 패밀리 DB는 약이 생길 때마다 새로운 주머니를 달아서 쓸 수 있는 **'무한 확장 주머니 바지'**와 같습니다. 빈칸이라는 개념 자체가 존재하지 않습니다.

Ⅱ. 컬럼 패밀리 DB의 핵심 구조 ★

데이터를 찾는 주소(Key)가 RDBMS보다 훨씬 복잡하다. 3차원 주소라고 생각하면 된다.

1. Row Key (행 키 = PK)

  • 데이터를 묶는 가장 큰 단위. (예: 철수, 영희)
  • 이 Row Key 단위로 데이터들이 전 세계 수백 대의 서버(파티션)에 분산되어 저장된다.

2. Column Family (컬럼 패밀리)

  • 관련된 컬럼들을 묶어놓은 그룹(주머니)이다. 이 단위로 하드디스크에 파일이 생성된다.
  • 예: 프로필 패밀리, 활동로그 패밀리.
  • 테이블을 만들 때 이 패밀리까지만 미리 뼈대를 정해두면 된다.

3. Column Qualifier (컬럼 식별자)

  • 패밀리 안에 동적으로 무한히 추가할 수 있는 실제 데이터의 이름이다.
  • 예: 프로필:이름, 프로필:나이, 활동로그:검색어, 활동로그:찜하기
  • 핵심: Row마다 이 컬럼들이 달라도 아무 상관이 없다! (철수는 2개, 영희는 100개 가질 수 있음)

Ⅲ. 실무 활용과 저장 엔진 (LSM-Tree)

이런 유연한 구조 덕분에 컬럼 패밀리 DB는 '쓰기(Write)'의 제왕이 되었다.

  • 저장 엔진: 이런 무식한 양의 데이터를 디스크에 빠르게 쓰기 위해, HBase와 Cassandra는 내부적으로 LSM-Tree(377번 문서) 구조를 완벽하게 채택하고 있다. 메모리(MemTable)에 대충 모았다가 디스크로 확 쏟아버리기 때문에 초당 수백만 건의 로그가 들어와도 끄떡없다.
  • 주요 도메인:
    • 구글의 모든 웹페이지 검색 색인 (Bigtable 원조)
    • 페이스북의 메신저 대화 기록 (수백억 건의 카톡)
    • 넷플릭스의 시청 로그 데이터 저장
┌──────────────────────────────────────────────────────────────┐
│           컬럼 패밀리 (Column-family) 데이터 저장 구조 시각화            │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ 🔑 Row Key: User_1001 (김철수) ]                               │
│                                                              │
│  📂 프로필 패밀리 (Profile)                                       │
│   ├── 이름: "김철수"                                           │
│   └── 전화: "010-1234"                                         │
│                                                              │
│  📂 활동로그 패밀리 (Activity)  ◀── (컬럼을 무한대로 확장 가능!)        │
│   ├── 20260410_검색: "나이키"                                   │
│   ├── 20260410_클릭: "신발"                                    │
│   └── 20260411_로그인: "True"                                  │
│                                                              │
│ ★ 특징: User_1002번은 프로필 패밀리에 '나이' 컬럼이 추가로 있어도 에러 안 남!│
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"정형 데이터의 안전함과 비정형 데이터의 무한한 유연성을 섞다." 컬럼 패밀리 DB는 언뜻 보면 Document DB(MongoDB)의 JSON과 비슷해 보이지만, 하드디스크에 데이터를 저장하고 파티셔닝하는 방식(LSM-Tree와 분산 처리)에서 완벽한 빅데이터용으로 진화한 아키텍처다. RDBMS로 1년 치 센서 로그를 감당하려다 테이블 풀 스캔에 서버가 뻗는 경험을 해본 아키텍트라면, 무한히 늘어나는 동적 컬럼을 완벽하게 수용하면서도 특정 시간대의 로그만 0.01초 만에 뽑아올 수 있는 이 거대한 '와이드 컬럼 스토어(Wide-column Store)'의 위대함을 뼈저리게 느끼게 될 것이다.

📌 관련 개념 맵

  • 관련 데이터베이스: Google Bigtable, Apache HBase, Apache Cassandra, AWS Keyspaces
  • 내부 저장 엔진: LSM-Tree (377번 문서), MemTable, SSTable
  • 상위 개념: NoSQL, Big Data Storage
  • 분산 원리: Consistent Hashing (일관된 해싱을 통한 파티셔닝)

👶 어린이를 위한 3줄 비유 설명

  1. RDBMS는 아파트 우편함이에요. 집마다 우편함 크기가 똑같아서 편지가 없으면 빈칸이고, 편지가 너무 많으면 터져버리죠.
  2. 컬럼 패밀리는 마법의 산타클로스 양말이에요. 편지가 없으면 양말이 아예 사라져서(용량 0) 자리를 차지하지 않죠.
  3. 그리고 편지가 1,000장씩 쏟아져 들어오면 양말이 무한대로 길어지면서(동적 컬럼 추가) 모든 편지를 다 담아낼 수 있답니다!