2025년 6월 07일·7분
마이클 스톤브레이커와 현대 데이터베이스: 그가 바꾼 것들
Ingres, Postgres, Vertica에 담긴 마이클 스톤브레이커의 핵심 아이디어와 그것들이 SQL 데이터베이스, 분석 엔진, 현대 데이터 스택에 어떤 영향을 미쳤는지 살펴봅니다.
Ingres, Postgres, Vertica에 담긴 마이클 스톤브레이커의 핵심 아이디어와 그것들이 SQL 데이터베이스, 분석 엔진, 현대 데이터 스택에 어떤 영향을 미쳤는지 살펴봅니다.
마이클 스톤브레이커는 데이터베이스 연구에만 영향을 준 연구자가 아니라, 많은 팀이 매일 의존하는 제품과 설계 패턴을 직접적으로 형성한 컴퓨터 과학자입니다. 관계형 데이터베이스, 분석용 웨어하우스, 스트리밍 시스템을 사용해 본 적이 있다면, 그가 증명하거나 구축하거나 보급한 아이디어의 혜택을 본 것입니다.
이 글은 전기나 이론적 데이터베이스 강의가 아닙니다. 대신 스톤브레이커의 주요 시스템(예: Ingres, Postgres, Vertica)이 현대 데이터 스택의 선택에 어떻게 연결되는지 보여줍니다:
현대 데이터베이스는 다음을 신뢰성 있게 수행할 수 있는 시스템입니다:
거래 처리, BI 대시보드, 실시간 파이프라인을 비교하면 각 데이터베이스가 이 목표들을 다르게 최적화한다는 것을 알게 됩니다.
우리는 실용적 영향을 중심으로 다룹니다: 오늘날의 "웨어하우스 + 레이크 + 스트림 + 마이크로서비스" 세계에서 나타나는 아이디어들과 그것들이 무엇을 사고·구매·운영하게 만드는지. 명확한 설명, 트레이드오프, 실무적 함의를 기대하세요—증명이나 구현 세부로 깊게 들어가진 않습니다.
스톤브레이커의 경력은 특정 작업을 위해 설계된 시스템들의 연속으로 보는 것이 가장 이해하기 쉽습니다—그리고 가장 좋은 아이디어들이 주류 데이터베이스 제품으로 전파되는 과정을 지켜보면 됩니다.
Ingres는 관계형 데이터베이스가 단지 이론이 아니라 빠르고 실용적일 수 있음을 증명한 학술 프로젝트로 시작했습니다. SQL 스타일 쿼리와 비용 기반 최적화 개념을 대중화하는 데 기여했고, 이후 상업 엔진에서 표준이 된 사고방식을 확산시켰습니다.
Postgres(연구 시스템으로, 이후 PostgreSQL로 이어짐)는 데이터베이스가 고정 기능이 되어선 안 된다는 다른 배팅을 실험했습니다. 새로운 데이터 타입, 새로운 인덱스 방법, 더 풍부한 동작을 전체 엔진을 다시 쓰지 않고도 추가할 수 있어야 한다는 아이디어입니다.
이 시기에 많은 현대 기능들이 기원을 두고 있습니다—확장형 타입, 사용자 정의 함수, 그리고 워크로드가 바뀔 때 적응할 수 있는 데이터베이스라는 개념 등이 그 예입니다.
분석 수요가 커지면서 행 지향 시스템은 대규모 스캔과 집계에서 어려움을 겪었습니다. 스톤브레이커는 칼럼형 저장과 필요한 칼럼만 읽고 잘 압축하는 실행 기법을 밀어붙였습니다—지금은 분석 데이터베이스와 클라우드 웨어하우스에서 표준이 된 아이디어들입니다.
Vertica는 칼럼 저장 연구 아이디어를 상업적으로 실현 가능한 대규모 병렬 처리(MPP) SQL 엔진으로 가져갔습니다. 프로토타입이 개념을 검증하면, 제품은 신뢰성, 툴링, 실제 고객 제약을 고려해 이를 단단하게 만듭니다—이 패턴은 산업 전반에 반복됩니다.
그의 이후 작업은 스트림 처리와 워크로드 전용 엔진으로 확장되어, 범용 데이터베이스 하나가 모든 곳에서 이기는 경우가 드물다는 주장을 강화했습니다.
프로토타입은 가설을 빠르게 검증하기 위해 만들어지고, 제품은 운영성(업그레이드, 모니터링, 보안, 예측 가능한 성능, 지원)을 우선시해야 합니다. 스톤브레이커의 영향은 많은 프로토타입 아이디어가 상업용 데이터베이스의 기본 기능으로 졸업했기 때문에 두드러집니다.
Ingres(INteractive Graphics REtrieval System의 약칭)은 관계형 모델이 우아한 이론을 넘어서 현실적인 업무에서 쓸 수 있음을 입증한 초기 사례였습니다. 당시 많은 시스템은 맞춤형 접근 방법과 애플리케이션별 데이터 경로 위주로 만들어졌습니다.
Ingres는 다음과 같은 실용적 문제를 풀려 했습니다:
질문이 바뀔 때마다 소프트웨어를 다시 쓰지 않고 사람들이 유연하게 데이터에 질문하도록 어떻게 허용할 것인가?
관계형 데이터베이스는 무엇을 원하는지(예: "연체된 인보이스가 있는 캘리포니아 고객") 기술하면, 그걸 어떻게 가져올지 단계별로 적지 않아도 된다는 약속을 했습니다. 하지만 그 약속을 현실로 만들려면 시스템이 다음을 할 수 있어야 했습니다:
Ingres는 당시 하드웨어에서도 실행 가능하고 반응성이 느껴지는 "실용적" 관계형 컴퓨팅으로 가는 중요한 발걸음이었습니다.
Ingres는 데이터베이스가 쿼리 계획 수립이라는 어려운 일을 해야 한다는 생각을 대중화했습니다. 개발자가 모든 데이터 접근 경로를 수동으로 튜닝하는 대신, 시스템이 어느 테이블을 먼저 읽을지, 어떤 인덱스를 사용할지, 어떻게 조인할지를 선택할 수 있게 했습니다.
이로 인해 SQL 스타일 사고가 확산되었습니다: 선언형 쿼리를 작성할 수 있으면 더 빠르게 반복하고, 더 많은 사람이(분석가, 제품팀, 재무 등) 맞춤 리포트를 기다리지 않고 직접 질문할 수 있게 됩니다.
핵심 실무적 통찰은 비용 기반 최적화입니다: 데이터에 대한 통계에 근거해 예상되는 "비용"(보통 I/O, CPU, 메모리의 혼합)이 가장 낮은 쿼리 계획을 선택하는 것.
그 결과로 흔히 얻는 이점은:
Ingres가 현대 최적화의 모든 조각을 발명한 것은 아니지만, SQL + 옵티마이저라는 패턴을 확립해 관계형 시스템을 "좋은 아이디어"에서 일상적 도구로 확장시키는 데 기여했습니다.
초기 관계형 데이터베이스는 고정된 데이터 타입(숫자, 텍스트, 날짜)과 고정된 연산(필터, 조인, 집계)을 가정하는 경향이 있었습니다. 하지만 팀들이 지리공간, 로그, 시계열, 도메인별 식별자 같은 새로운 정보를 저장하기 시작하면서 이 가정은 한계를 드러냈습니다.
고정된 설계에서는 새로운 요구가 생길 때마다 열악한 선택을 강요당합니다: 데이터를 텍스트 블롭으로 억지로 집어넣거나, 별도 시스템을 덧붙이거나, 벤더가 지원 기능을 추가할 때까지 기다리는 식입니다.
Postgres는 데이터베이스가 확장 가능이어야 한다는 아이디어를 밀었습니다—즉, 안전하고 통제된 방식으로 새로운 기능을 추가할 수 있어야 하며, SQL에서 기대하는 안전성과 정합성을 깨뜨리지 않아야 합니다.
쉽게 말하면, 확장성은 전동 공구에 인증된 부속품을 붙이는 것과 비슷합니다. 모터를 뜯어 고치지 않고도 도구에 "새 기술"을 가르칠 수 있고, 트랜잭션, 권한, 쿼리 최적화는 하나의 일관된 체계로 유지됩니다.
이 사고방식은 오늘날 PostgreSQL 생태계(및 많은 Postgres 영감을 받은 시스템)에서 뚜렷하게 보입니다. 핵심 기능을 기다리는 대신, 검증된 확장을 채택해 SQL과 운영 도구와 매끄럽게 통합할 수 있습니다.
높은 수준의 예시는:
핵심은 Postgres가 "데이터베이스가 무엇을 할 수 있는지 바꾸는 것"을 설계 목표로 삼았다는 점입니다—그리고 이 아이디어는 현대 데이터 플랫폼이 어떻게 진화하는지에 여전히 영향을 미칩니다.
데이터베이스는 단순히 정보를 저장하는 것 이상입니다—많은 일이 동시에 일어나도 정보가 옳게 유지되도록 하는 것이 핵심입니다. 이것이 바로 트랜잭션과 동시성 제어의 역할이며, SQL 시스템이 실제 비즈니스 작업에서 신뢰받는 주요 이유입니다.
트랜잭션은 하나의 단위로 성공하거나 실패해야 하는 변경들의 묶음입니다.
돈을 이체하거나 주문을 넣거나 재고를 업데이트할 때 "반쯤 끝난" 상태는 허용할 수 없습니다. 트랜잭션은 고객에게 비용을 청구했지만 재고를 확보하지 못하는 상황이나 재고가 줄었지만 주문 기록이 없는 상황을 방지합니다.
실무적으로 트랜잭션은:
동시성은 많은 사람(및 애플리케이션)이 동시에 데이터를 읽고 바꾸는 상황을 뜻합니다: 고객의 결제, 고객센터의 계정 편집, 백그라운드 작업의 상태 업데이트, 분석가의 리포트 실행 등.
주의하지 않으면 동시성은 다음 같은 문제를 만듭니다:
한 영향력 있는 접근법은 **MVCC(다중 버전 동시성 제어)**입니다. 개념적으로 MVCC는 행의 여러 버전을 잠시 동안 보관해, 읽는 쪽은 안정된 스냅샷을 유지하면서 쓰기가 진행되도록 합니다.
큰 이점은 읽기가 쓰기를 자주 막지 않는다는 점이며, 쓰기 또한 장시간 실행되는 조회에 의해 자주 지연되지 않습니다. 올바름은 유지하면서 대기 시간이 줄어듭니다.
오늘날 데이터베이스는 종종 혼합 워크로드를 처리합니다: 높은 볼륨의 쓰기와 대시보드 / 고객 뷰 / 운영 분석을 위한 빈번한 읽기. 현대 SQL 시스템은 MVCC, 더 똑똑한 락킹, 격리 수준 같은 기법에 의존해 속도와 정확성을 균형 있게 유지합니다—따라서 활동을 확장해도 데이터에 대한 신뢰를 잃지 않습니다.
행 지향 데이터베이스는 거래 처리용으로 설계되었습니다: 보통 하나의 고객이나 하나의 주문, 하나의 계정을 건드리는 작은 읽기/쓰기가 많습니다. 이런 설계는 전체 레코드를 빠르게 가져오거나 업데이트할 때 탁월합니다.
스프레드시트를 떠올려 보세요. 행 저장소는 각 행을 하나의 폴더로 보관하는 것과 같습니다: 주문 #123에 대한 "모든 것"이 필요하면 한 폴더를 꺼내면 끝입니다. 칼럼 저장소는 열별로 보관하는 것과 같아서, "order_total" 서랍, "order_date" 서랍, "customer_region" 서랍이 따로 있습니다.
분석에서는 전체 폴더가 거의 필요하지 않습니다—보통 "지난 분기 지역별 총수익은 얼마였나?" 같은 질문을 던지죠. 이런 쿼리는 수백만 건의 레코드에서 몇 개의 필드만 건드립니다.
분석 쿼리는 대개:
칼럼형 저장소를 사용하면 엔진은 쿼리에서 참조된 칼럼만 읽을 수 있으므로 나머지는 건너뜁니다. 디스크에서 읽는 데이터가 줄고(메모리로 옮기는 데이터도 줄어들어) 성능이 크게 향상됩니다.
칼럼 데이터는 반복 값(지역, 상태, 카테고리 등)이 많아 압축에 유리합니다—이로 인해 읽는 바이트 수가 줄고 때로는 압축된 상태로 연산을 수행할 수 있어 속도가 더 빨라집니다.
칼럼 저장소는 OLTP 우선 데이터베이스에서 분석 우선 엔진으로의 전환을 표시합니다. 이들은 스캔, 압축, 빠른 집계를 설계 목표로 두며, 이러한 특성은 이후 주요 설계 고려사항이 되었습니다.
Vertica는 스톤브레이커의 분석 데이터베이스 아이디어가 운영 환경에서 실행 가능한 제품으로 바뀐 대표적 예입니다. 칼럼 저장소의 교훈을 받아 분산 설계와 결합해 하나의 문제를 겨냥했습니다: 데이터 볼륨이 단일 서버를 넘어서도 큰 분석 SQL 쿼리를 빠르게 답하는 것.
MPP는 여러 머신이 하나의 SQL 쿼리를 동시에 처리하게 하는 방식입니다.
하나의 데이터베이스 서버가 모든 데이터를 읽고 그룹화·정렬하던 대신, 데이터는 노드들에 나뉘어지고 각 노드는 자신의 파티션을 병렬로 처리한 뒤 부분 결과를 합쳐 최종 답을 냅니다.
잘 분배되고 쿼리가 병렬화될 수 있다면, 한 박스에서 분 단위가 걸릴 작업이 클러스터에서는 초 단위로 줄어들 수 있습니다.
Vertica 스타일의 MPP 분석 시스템은 많은 행을 스캔하고 효율적으로 필터·집계하려는 경우에 탁월합니다. 전형적 사용 사례는:
MPP 분석 엔진은 거래(OLTP) 시스템을 바로 대체할 수 없습니다. 이들은 많은 행을 읽고 요약을 계산하는 데 최적화되어 있으며, 작은 단건 업데이트 처리에는 적합하지 않습니다.
일반적 트레이드오프는:
핵심은 집중입니다: Vertica와 유사 시스템은 저장, 압축, 병렬 실행을 분석에 맞게 조율해 속도를 얻고, 거래형 시스템이 피하려는 제약을 받아들입니다.
데이터베이스가 "저장하고 질의"할 수만 있어도 분석에서 느리게 느껴질 수 있습니다. 차이는 종종 당신이 쓰는 SQL이 아니라 엔진이 그것을 어떻게 실행하는가—페이지를 어떻게 읽고, 데이터를 CPU로 어떻게 옮기며, 메모리를 어떻게 쓰고, 불필요한 작업을 어떻게 줄이는가—에 있습니다.
스톤브레이커의 분석 중심 프로젝트들은 쿼리 성능을 저장 문제만큼 실행 문제로 보아야 한다는 생각을 밀어붙였습니다. 이 사고는 팀들이 단건 조회 최적화에서 수백만(혹은 수십억) 행의 긴 스캔·조인·집계 최적화로 관심을 옮기게 했습니다.
많은 오래된 엔진은 쿼리를 "튜플-아-타임"(행 단위)으로 처리해 함수 호출과 오버헤드가 많습니다. 벡터화 실행은 이 모델을 뒤집어, 엔진이 값의 배치(벡터)를 조밀한 루프에서 처리하게 합니다.
비유하자면, 장보기에서 물건을 한 번에 하나씩 들고 가는 대신 카트를 쓰는 것과 같습니다. 배치는 오버헤드를 줄이고 최신 CPU가 잘하는 예측 가능한 루프와 캐시 활용을 가능하게 합니다.
빠른 분석 엔진은 CPU와 캐시 효율을 극대화하는 데 집착합니다. 실행 혁신은 보통 다음에 집중합니다:
이 아이디어들은 중요합니다. 왜냐하면 분석 쿼리는 종종 원시 디스크 속도가 아니라 메모리 대역폭과 캐시 미스에 의해 제한되기 때문입니다.
현대 데이터 웨어하우스와 SQL 엔진—클라우드 웨어하우스, MPP 시스템, 빠른 인프로세스 분석 도구—은 자주 벡터화 실행, 압축 인식 연산자, 캐시 친화적 파이프라인을 표준 관행으로 사용합니다.
벤더가 "오토스케일링"이나 "스토리지와 컴퓨트 분리" 같은 기능을 마케팅하더라도, 일상적 체감 성능은 여전히 이러한 실행 선택에 크게 좌우됩니다.
플랫폼을 평가할 때는 그들이 무엇을 저장하는지뿐 아니라 조인과 집계를 내부적으로 어떻게 실행하는지, 실행 모델이 트랜잭션이 아닌 분석에 맞게 설계되었는지를 물어보세요.
스트리밍 데이터는 연속적으로 도착하는 사건들의 흐름입니다—신용카드 결제, 센서 측정값, 제품 페이지 클릭, 패키지 스캔, 로그 라인 같은 것들이 실시간으로 연속적으로 들어옵니다.
전통적 데이터베이스와 배치 파이프라인은 기다릴 수 있을 때 훌륭합니다: 어제 데이터를 로드하고 보고서를 돌리고 대시보드를 발행하는 식입니다. 그러나 실시간 요구는 다음 배치 작업을 기다리지 않습니다.
배치로만 처리하면:
스트리밍 시스템은 계산이 이벤트가 도착함에 따라 계속 실행될 수 있다고 가정하고 설계됩니다.
연속 쿼리는 끝나지 않는 SQL 쿼리와 같습니다. 한 번 결과를 반환한 뒤 끝나는 대신 새로운 이벤트가 들어올 때마다 결과를 갱신합니다.
스트림은 유한하지 않으므로 스트리밍 시스템은 계산을 관리 가능하게 만들기 위해 윈도우를 사용합니다. 윈도우는 "마지막 5분", "매 분", "마지막 1,000개 이벤트" 같은 시간 또는 이벤트의 슬라이스입니다. 이를 통해 전체를 다시 처리하지 않고 롤링 카운트, 평균, top-N 같은 것을 계산합니다.
실시간 스트리밍이 즉시 가치 있는 경우:
스톤브레이커는 수십 년 동안 데이터베이스가 모두 범용으로 "모든 걸 하는" 방식으로 만들어져선 안 된다고 주장해 왔습니다. 이유는 단순합니다: 서로 다른 워크로드는 서로 다른 설계 결정을 보상합니다. 하나의 작업(예: 작은 트랜잭션 업데이트)에 강하게 최적화하면 보통 다른 작업(예: 수십억 행 스캔)이 느려집니다.
대부분의 현대 스택은 한 종류 이상의 데이터 시스템을 사용합니다. 그 이유는 비즈니스가 여러 가지 종류의 답을 요구하기 때문입니다:
이는 실무에서 "한 사이즈가 모두에 맞지 않는다"는 것을 보여줍니다: 작업의 형태에 맞는 엔진을 선택해야 합니다.
선택(또는 새 시스템 정당화) 시 빠른 필터링 기준:
여러 엔진은 각자 명확한 워크로드가 있을 때 건강할 수 있습니다. 새 도구는 비용, 지연, 리스크를 줄이는 명확한 근거가 있어야 자리잡을 자격이 있습니다.
운영 주체가 확실한 적은 수의 시스템을 선호하고, 명확한 목적이 없는 컴포넌트는 퇴출시키세요.
스톤브레이커의 연구 주제들—관계형 기반, 확장성, 칼럼 저장, MPP 실행, "작업에 맞는 도구"—은 현대 데이터 플랫폼의 기본 형태에서 볼 수 있습니다.
웨어하우스는 수십 년간의 SQL 최적화, 칼럼형 저장, 병렬 실행 작업의 산물입니다. 거대한 테이블에서 빠른 대시보드를 보면 칼럼 지향 포맷과 벡터화 처리, MPP 스타일의 스케일링이 쓰인 경우가 많습니다.
레이크하우스는 웨어하우스의 아이디어(스키마, 통계, 캐싱, 비용 기반 최적화)를 오픈 파일 포맷과 오브젝트 스토리지 위에 얹은 것입니다. "저장소는 싸고 컴퓨트는 탄력적"이라는 변화는 새롭지만, 그 아래의 쿼리와 트랜잭션 사고는 새롭지 않습니다.
MPP 분석 시스템(셰어드-낫팅 클러스터)은 데이터를 파티셔닝하고 계산을 데이터 쪽으로 이동시키며 조인·집계 시 데이터 이동을 세심히 관리하면 SQL을 확장할 수 있다는 연구의 직접적 후계자입니다.
SQL은 웨어하우스, MPP 엔진, 심지어 레이크 쿼리 레이어 전반에서 공통 인터페이스가 되었습니다. 팀들은 SQL을:
실행이 배치, 대화형, 스트리밍 등 다른 엔진에서 일어나더라도 SQL은 사용자-facing 언어로 남는 경우가 많습니다.
유연한 저장 방식이 구조 필요성을 없애진 않습니다. 명확한 스키마, 문서화된 의미, 통제된 진화는 다운스트림의 붕괴를 줄여줍니다.
좋은 거버넌스는 관료주의가 아니라 데이터를 신뢰 가능하게 만드는 것—일관된 정의, 소유권, 품질 검사, 접근 제어—에 가깝습니다.
플랫폼을 평가할 때 물어볼 것:
벤더가 자신의 제품을 이 기본 항목들에 평이한 언어로 매핑하지 못하면, 그 "혁신"은 포장에 불과할 수 있습니다.
스톤브레이커의 일관된 메시지는 단순합니다: 데이터베이스는 특정 작업을 위해 설계될 때 가장 잘 작동하며, 그 작업이 바뀔 때 진화할 수 있어야 한다는 점입니다.
기능 비교 전에 실제로 무엇을 해야 하는지 적어보세요:
유용한 규칙: 워크로드를 몇 문장으로 설명할 수 없다면, 유행어에 끌려 도구를 사게 될 가능성이 큽니다.
팀들은 요구가 얼마나 자주 바뀌는지 과소평가합니다: 새로운 데이터 타입, 새 지표, 규정 준수 변경, 새로운 소비자들 등.
변화를 일상적이고 위험이 적게 만드는 플랫폼과 데이터 모델을 선호하세요:
빠른 답은 옳은 답일 때만 가치가 있습니다. 옵션을 평가할 때 시스템이 다음을 어떻게 다루는지 물어보세요:
데모만 보지 말고 작은 "자체 데이터로 검증"을 하세요:
많은 데이터베이스 조언은 "올바른 엔진을 선택하라"에서 끝나지만, 팀은 그 엔진 주위에 어드민 패널, 메트릭 대시보드, 수집 서비스, 백오피스 워크플로우 같은 앱과 내부 도구들을 배포해야 합니다.
스키마 설계를 빠르게 반복하거나 작은 내부 "데이터 제품"을 반복 검증하려면, 채팅 기반 워크플로로 React 웹앱, 백엔드 서비스(Go + PostgreSQL), 모바일 클라이언트(Flutter)를 빠르게 생성해 주는 vibe-코딩 플랫폼 같은 도구(예: Koder.ai)가 유용할 수 있습니다. 이는 장기 인프라를 결정하기 전에 워크로드가 실제로 어떻게 작동하는지 검증할 때 특히 도움이 됩니다.
더 깊이 들어가고 싶다면 칼럼형 저장소, MVCC, MPP 실행, 스트림 처리를 찾아보세요. 추가 설명 글들은 /blog에 있습니다.
그는 연구 시스템의 아이디어를 실제 제품 설계에까지 녹여낸 드문 사례입니다. Ingres(SQL + 쿼리 최적화), Postgres(확장성 + MVCC 개념), Vertica(칼럼형 저장소 + MPP 분석)에서 증명된 아이디어가 오늘날 웨어하우스, OLTP 데이터베이스, 스트리밍 플랫폼의 설계와 마케팅에 그대로 반영되어 있습니다.
SQL은 사용자가 무엇을 원하는지 선언하면 데이터베이스가 어떻게 그것을 효율적으로 수행할지 결정하게 해 줍니다. 이 분리는 다음을 가능하게 했습니다:
비용 기반 옵티마이저는 테이블 통계에 기초해 가능한 쿼리 실행 계획을 비교하고 기대 비용(I/O, CPU, 메모리)이 가장 낮은 계획을 선택합니다. 실용적으로는:
그래서 옵티마이저는 운영 비용과 성능에 직접적 영향을 줍니다.
MVCC(다중 버전 동시성 제어)는 짧은 시간 동안 여러 버전의 행을 유지해, 읽는 쪽이 안정적인 스냅샷을 보면서 쓰기 작업이 진행되게 합니다. 실무 관점에서:
확장성은 데이터베이스가 새로운 기능(타입, 함수, 인덱스 등)을 엔진 전체를 갈아치우지 않고 안전하게 추가할 수 있다는 뜻입니다. 오늘날엔:
운영 규칙으로는: 확장은 의존성처럼 다루어야 하며, 버전 관리, 업그레이드 테스트, 누가 설치 가능한지 제한하는 것이 좋습니다.
행 저장소는 전체 레코드를 자주 읽거나 쓰는 OLTP에 적합합니다. 칼럼 저장소는 수백만 건에서 일부 필드만 읽어 집계하는 분석에 뛰어납니다. 간단한 휴리스틱:
MPP(대규모 병렬 처리)는 데이터를 여러 노드에 분할해 많은 머신이 하나의 SQL 쿼리를 동시에 처리하게 하는 방식입니다. 적합한 경우:
복잡성의 대가로는 데이터 분배 결정, 조인 시 셔플 비용, 단건 업데이트에 대한 불편함 등을 고려해야 합니다.
벡터화 실행은 한 번에 행 하나씩 처리하는 대신 일정 크기의 배치(벡터)로 작업을 수행해 오버헤드를 줄이고 CPU 캐시를 잘 활용합니다. 체감되는 결과:
배치 시스템은 주기적으로 실행되므로 데이터가 최신이 아니기 쉽습니다. 스트리밍 시스템은 이벤트를 연속적으로 받아 결과를 점진적으로 갱신합니다. 스트리밍이 특히 유리한 곳:
스트리밍은 계산 범위를 제한하기 위해 시간 창(예: 최근 5분) 같은 윈도우 개념을 사용합니다.
각 시스템이 명확한 워크로드 경계와 측정 가능한 이점을 가져야 여러 시스템을 쓰는 것이 정당화됩니다. 스프로일을 피하려면:
또한, 도구는 비용·지연·신뢰성 측면에서 실제 이득을 증명해야 합니다.