본문으로 건너뛰기
J
피드

Stonebraker의 CAP 정리 비판 — NoSQL 진영이 결과적 일관성을 남용하고 있다 (2010)

backend 약 3분
tags
#cap-theorem#nosql#distributed-systems#consistency#databases
vote
0
댓글
북마크

Mike Stonebraker가 NoSQL 진영의 CAP 정리 남용을 비판한 글에 대한 James Hamilton의 코멘터리. 애플리케이션 버그와 관리 실수에는 결과적 일관성이 무용하며, 완전 일관성을 너무 일찍 포기하지 말라는 주장.

  • 1

    CAP 정리가 적용되지 않는 데이터 손실 케이스(앱 버그, 관리 실수, DB 구현 버그)를 결과적 일관성이 보호하지 못함

  • 2

    지연 삭제(Deferred Delete) 기법으로 데이터 손실 방어 가능

  • 3

    네트워크 파티션은 이론적으로 드물지만 현실에서는 여전히 포스트모템 단골 주제

  • 4

    완전 일관성은 대규모에서도 실용적으로 구현 가능하며 앱 구현 오류를 줄여줌

  • 2010년 글인데 지금 읽어도 유효한 내용임. Mike Stonebraker가 CACM 블로그에서 NoSQL 진영이 CAP 정리(CAP Theorem)를 남용하고 있다고 정면으로 비판한 글에 대한 코멘터리

  • NoSQL 쪽에서 흔히 하는 주장이 "CAP 정리 때문에 결과적 일관성(Eventual Consistency)을 선택할 수밖에 없다"인데, Stonebraker는 이게 논점을 잘못 짚은 거라고 반박함. 애플리케이션 버그, 관리자 실수, DB 구현체 버그로 데이터가 날아가면 결과적 일관성이든 뭐든 아무 소용없다는 거임

  • 글쓴이(James Hamilton, AWS VP 출신)가 소개하는 꿀팁: 지연 삭제(Deferred Delete). 삭제 요청이 들어와도 즉시 지우지 않고 며칠~몇 주 뒤에 가비지 컬렉션하는 방식. 완벽한 보호는 아니지만 실제로 여러 번 살려줬다고 함

  • 네트워크 파티션이 드물다는 Stonebraker 주장에는 살짝 이견을 보임. 이론적으로는 드물어야 하는데, 현실에서는 네트워크 장비 설정 오류, 블랙홀, 패킷 드롭, 브라운아웃이 포스트모템 단골 주제라는 거임. 네트워크 장비가 아직도 메인프레임 비즈니스 모델(비싸고, 수직 통합, 2중화)에서 못 벗어났다는 지적이 인상적

❗중요

> Stonebraker의 핵심 주장: 완전 일관성(Full Consistency)을 너무 일찍 포기하지 마라. 많은 애플리케이션에서 완전 일관성은 충분히 감당 가능하고, 오히려 애플리케이션 구현 오류를 줄여준다.

  • Amazon SimpleDB가 완전 일관성 지원을 추가한 게 이 글 시점이었음. 결과적 일관성이 필요한 곳에는 쓰고, 완전 일관성이 필요한 곳에는 그걸 쓰면 된다는 것. 양자택일이 아니라는 얘기

  • 16년이 지난 지금 돌이켜보면, Spanner, CockroachDB, TiDB 같은 분산 DB들이 실제로 완전 일관성 + 고가용성을 대규모로 구현해냈으니 Stonebraker의 주장이 맞았던 셈

16년이 지난 지금 Spanner, CockroachDB 등이 완전 일관성 + 고가용성을 대규모로 증명했으니, Stonebraker의 주장이 선견지명이었던 셈.

prev

이전 기사 (P)

next

다음 기사 (N)

댓글

댓글

댓글을 불러오는 중...

관련 기사

backend

클릭하우스가 PgBouncer 처리량을 4배로 끌어올린 방법

ClickHouse Managed Postgres 팀은 단일 스레드인 PgBouncer를 여러 프로세스로 띄우고 `so_reuseport`와 피어링(peering)을 조합해 16 vCPU 머신을 제대로 쓰게 만들었다. 동일한 AWS 환경에서 단일 프로세스는 약 8.7만 TPS 근처에서 막혔지만, 16개 프로세스 구성은 약 33.6만 TPS까지 올라갔다.

backend

SQLite 쓸 거면 STRICT 테이블을 기본값으로 보자는 주장

SQLite의 STRICT 테이블은 INTEGER 컬럼에 문자열이 들어가는 식의 타입 실수를 막아주는 기능이다. 글쓴이는 SQLite 특유의 유연한 타입 시스템보다, 실수는 빨리 터뜨리는 쪽이 실무에서 낫다고 주장한다. 다만 기존 테이블을 바로 STRICT로 바꾸기 어렵고, SQLite 3.37.0 이상에서만 쓸 수 있다는 제약도 있다.

backend

왜 아직도 Lisp를 배워볼 만한가

Lisp는 괄호가 많은 이상한 언어처럼 보이지만, 핵심은 문법이 아니라 언어 자체를 확장할 수 있다는 점에 있음. 매크로, 코드-데이터 동일성, REPL 중심 개발이 합쳐지면 프로그램을 '작성'한다기보다 살아 있는 시스템을 계속 진화시키는 방식으로 개발하게 됨.

backend

EDB 포스트그레스 AI, 포레스터 멀티모델 데이터 플랫폼 리더 선정

EDB의 AI 데이터 플랫폼 EDB 포스트그레스 AI가 2026년 2분기 포레스터 웨이브 멀티모델 데이터 플랫폼 보고서에서 리더로 선정됐음. 트랜잭션, 분석, AI 워크로드를 하나의 플랫폼에서 다루는 흐름이 강해지는 가운데, EDB는 전략과 현재 제공 기능 모두에서 높은 평가를 받았다고 밝힘.

backend

Bun, Zig에서 Rust로 갈아탔다: 11일짜리 초대형 런타임 포팅 실험

Bun 팀이 53만 줄이 넘는 Zig 코드베이스를 Rust로 기계적으로 포팅했고, Bun v1.4.0부터 Rust 기반으로 전환될 예정임. 핵심 이유는 성능보다 안정성이었고, use-after-free, double-free, 메모리 누수 같은 문제를 컴파일러와 타입 시스템으로 더 빨리 잡기 위해서였음. Claude Code 워크플로 64개를 병렬로 돌려 11일 만에 전 플랫폼 테스트 통과까지 밀어붙인 사례라, LLM 기반 대규모 코드 마이그레이션의 꽤 강한 신호탄임.