운영 DB와 DW의 차이? 쉽게 설명해 드릴게요

안녕하세요! '하트카운트'팀에서 Analytics Engineering 을 담당하고 있는 Jaden 입니다.  저번 글, ‘데이터 아키텍쳐? 쉽게 배워봅시다’ 의 뜨거운 성원에 힘입어, 이번 글을 작성하게 되었습니다.

운영계, 분석계 : 그 차이가 무엇인가?

Database와 Data Warehouse의 차이를 알려면 먼저 데이터 관리 시스템이 OLTP(운영계)와 OLAP(분석계)로 나뉜다는 것을 알아야 해요.

1. 운영계(Operational Systems)

운영계 시스템은 조직의 일상적인 비즈니스 프로세스와 트랜잭션을 지원합니다.

이러한 시스템은 실시간 데이터 처리에 중점을 두며, 데이터의 생성, 업데이트, 검색 및 삭제와 같은 기본적인 데이터 조작 작업을 신속하게 처리할 수 있어야 합니다.

예를 들어, 온라인 판매 시스템, 고객 관리 시스템, 재고 관리 시스템 등이 운영계 시스템에 해당합니다.

이 시스템들은 OLTP(Online Transaction Processing) 작업에 최적화되어 있으며, 데이터베이스 관리 시스템(DBMS)을 사용하여 운영 데이터를 관리합니다.

2. 분석계(Analytical Systems)

분석계 시스템은 대규모의 데이터를 분석하여 조직의 의사 결정 과정을 지원하는 데 초점을 맞춥니다.

이 시스템들은 데이터 웨어하우스를 포함하여, 역사적 데이터와 다양한 데이터 소스로부터 수집된 정보를 통합, 저장하고 이를 분석하는 데 사용됩니다.

분석계는 OLAP(Online Analytical Processing) 작업에 최적화되어 있으며, 복잡한 쿼리 처리와 대규모 데이터 세트의 집계, 분석을 수행할 수 있는 기능을 제공합니다.

자, 그럼 위에 등장한 OLPT와 OLAP 의 차이에 대해서 더 알아봅시다.

OLTP와 OLAP의 차이

OLTP(Online Transaction Processing)

OLTP는 '온라인 트랜잭션 처리'를 의미하며, 주로 사용자의 트랜잭션을 실시간으로 처리하는 데 최적화된 시스템입니다. 이 시스템은 입력, 수정, 삭제 같은 작업이 빈번한 운영 시스템에서 사용됩니다.

은행 거래, 온라인 주문, 예약 시스템 등이 OLTP의 전형적인 사용 사례입니다.

OLTP 시스템은 주로 행 기반(row-oriented) 데이터베이스 구조를 사용하여, 각각의 데이터 행이 메모리에 연속적으로 저장됩니다.

이 구조는 INSERT, UPDATE, DELETE와 같은 트랜잭션 연산을 빠르게 처리할 수 있게 해주며, 트랜잭션의 신속한 처리와 데이터의 무결성 유지에 중점을 둡니다.

행 기반 데이터베이스는 각 트랜잭션이 개별적인 레코드에 대해 실행될 때 효율적이며, 복잡한 트랜잭션 관리, 동시성 제어, 롤백 및 복구 기능을 제공합니다.

OLAP(Online Analytical Processing)

OLAP는 '온라인 분석 처리'를 의미하며, 대량의 데이터를 분석하여 비즈니스 인텔리전스를 제공하는 데 사용됩니다.

OLAP는 주로 데이터 웨어하우스 환경에서 활용되며, 역사적 데이터를 분석하고, 복잡한 쿼리를 처리하며, 보고서를 생성하고, 예측 분석을 수행하는 데 적합합니다.

OLAP 시스템은 열 기반(column-oriented) 데이터베이스 구조를 주로 사용하여, 데이터를 열 단위로 저장합니다.

이 구조는 분석 쿼리가 특정 열의 데이터를 대량으로 스캔하거나 집계할 때 매우 효율적입니다. OLAP는 대규모 데이터 세트에 대한 빠른 응답 시간, 다차원 분석, 데이터 웨어하우스에서의 사용에 최적화되어 있습니다.

정리하면 OLTP → Database, OLAP → DW

결국 정리하면 아래와 같습니다.

데이터베이스는 주로 실시간 트랜잭션 처리에 적합하며, 데이터 웨어하우스는 대규모 데이터 분석 및 보고서 작성을 위해 설계되었습니다.

데이터베이스란 무엇인가? 그 종류는?

데이터베이스는 구조화된 정보 또는 데이터의 집합입니다. 구조화되어 있기 때문에, 사용자는 데이터를 효과적으로 검색, 갱신, 관리할 수 있죠. 많이들 들어보셨겠지만, 대표적인 데이터베이스의 종류로는 RDB, NoSQL 이 있어요!

1. 관계형 데이터베이스(RDB)

되게 어렵게 말하고 있지만, 그냥 표 형태로 데이터를 관리하는거에요. 스프레트 시트와 똑같은 구조로 데이터를 관리하는 겁니다. 전통의 방법이죠.

우리는 이걸 멋드러지게 RDB(Relational Database)라고 부릅니다.

RDB, 즉 관계형 데이터베이스(Relational Database)가 "관계형"이라고 불리는 이유는, 데이터를 테이블(table) 형태로 저장하고 이 테이블들 사이에 정의된 관계(relationship)를 통해 데이터를 조직화하기 때문입니다.

RDB는 SQL(Structured Query Language)을 사용하여 데이터를 관리합니다.

SQL을 통해 데이터를 삽입(insert), 조회(select), 수정(update), 삭제(delete)하는 등의 작업을 할 수 있어요. SQL의 강력한 쿼리(query) 기능 덕분에, 복잡한 데이터 분석과 관리가 가능한 것입니다. MySQL, PostgreSQL, Oracle Database가 RDB를 관리하는 DBMS 범주에 속해요.

이것도 더 쉽게 설명해보자면,

표 형태 스프레드 시트를 관리하는 툴이

• MS의 Excel
• Google의 Google Sheet
• Apple의 Numbers

이렇게 여러 개의 소프트웨어들과 같다고 보시면 됩니다.

RDBMS 의 대표 주자들로는

• Oracle Database
• MySQL
• PostgreSQL

등을 꼽아볼 수 있습니다.

2. NoSQL 데이터베이스

그럼 NoSQL은 왜 등장하게 된 걸까요? NoSQL의 등장 배경에 대해 알려 드릴게요.

NoSQL 데이터베이스가 필요한 이유와 배경을 이해하기 위해서는 먼저, 기존의 데이터베이스 시스템인 관계형 데이터베이스(RDBMS)의 한계를 살펴보아야 합니다.

관계형 데이터베이스는 엄격한 스키마(데이터 구조)를 따라야 하며, 데이터는 테이블에 저장됩니다.

이 시스템은 일관성, 무결성 및 복잡한 쿼리를 지원하는데 최적화되어 있습니다.

그러나 디지털 데이터의 양이 폭발적으로 증가하고, 웹 및 모바일 애플리케이션의 등장으로 데이터의 형태와 활용 방법이 다양해지면서 기존의 관계형 데이터베이스로는 이러한 요구사항을 충족시키기 어려워졌습니다.

관계형 데이터베이스(RDBMS)의 한계점

1. 데이터 양의 폭발적 증가: 소셜 미디어, IoT(사물인터넷) 디바이스, 온라인 거래 등에서 발생하는 거대한 양의 데이터를 처리하려면 더 유연하고 확장 가능한 데이터 스토리지 솔루션이 필요했습니다.
2. 다양한 데이터 형태: 관계형 데이터베이스는 주로 구조화된 데이터에 적합하지만, 현대의 애플리케이션은 비구조화된 데이터(예: 텍스트, 이미지, 비디오) 또는 반구조화된 데이터(예: JSON, XML)를 다루는 경우가 많습니다. 이러한 데이터를 효과적으로 관리하기 위해 더 유연한 데이터 모델이 필요했습니다.
3. 빠른 개발과 변화에 대한 요구: 애플리케이션의 빠른 개발과 지속적인 업데이트를 위해서는 데이터 스키마의 변화가 쉬워야 합니다. 관계형 데이터베이스에서 스키마를 변경하는 것은 종종 복잡하고 시간이 많이 소요되는 작업입니다.
4. 확장성: 거대한 양의 데이터를 처리하고, 전 세계 사용자에게 빠른 액세스를 제공하기 위해서는 데이터베이스를 여러 서버에 분산시켜 확장할 수 있어야 합니다. 관계형 데이터베이스는 이러한 수평적 확장이 제한적입니다.

이러한 한계점을 해결할 수 있는 NoSQL의 특징에 대해 정리하면 아래와 같습니다.

NoSQL의 주요 특징

• 유연한 스키마: NoSQL 데이터베이스는 유연한 스키마를 제공하여, 다양한 형태의 데이터를 쉽게 저장하고 관리할 수 있어요.
• 확장성: 대부분의 NoSQL 데이터베이스는 수평적 확장성을 지원하여, 데이터 양의 증가에 따라 데이터베이스를 쉽게 확장할 수 있어요.
• 고성능: 특정 유형의 데이터 모델에 최적화되어 있어, 빠른 읽기와 쓰기 작업을 지원합니다.
• 다양한 데이터 모델 지원: 키-값, 문서, 그래프, 컬럼 기반 등 다양한 데이터 모델을 지원하여, 애플리케이션의 요구사항에 맞게 선택할 수 있어요.

NoSQL 데이터베이스는 크게 아래 네 가지 유형으로 분류할 수 있습니다.

1. 문서(Document) , e.g. MongoDB
2. 키-값(Key-Value) , e.g. Redis
3. 컬럼(Column-family) , e.g. Cassandra
4. 그래프(Graph) , e.g. Neo4j

NoSQL 데이터베이스의 유형

• 문서 지향(Document-oriented) 데이터베이스: 데이터를 JSON, BSON 형태의 문서로 저장합니다. 각 문서는 유연한 스키마를 가지며, 복잡한 데이터 구조를 쉽게 표현할 수 있어요. 예: MongoDB, Couchbase
• 키-값(Key-Value) 스토어: 간단한 키와 값을 쌍으로 저장하는 가장 기본적인 형태의 NoSQL 데이터베이스에요. 빠른 데이터 검색에 유용합니다. 예: Redis, DynamoDB
• 컬럼 기반(Column-family) 스토어: 대규모 분산 환경에서 높은 성능과 확장성을 제공하며, 데이터를 컬럼 패밀리 단위로 저장해요. 빅 데이터 분석에 적합합니다. 예: Cassandra, HBase
• 그래프(Graph) 데이터베이스: 엔티티 간의 관계를 그래프 형태로 저장하고, 복잡한 관계를 효과적으로 탐색할 수 있어요. 예: Neo4j, Titan

소셜 네트워크, 실시간 위치 기반 서비스, 빅 데이터 분석 등 다양한 분야에서 NoSQL 데이터베이스가 활용되고 있어요.

예를 들어, 소셜 미디어 애플리케이션에서는 사용자와 그들의 관계를 효과적으로 관리하기 위해 그래프 데이터베이스를 사용할 수 있어요. 또는, 웹 애플리케이션의 세션 정보를 빠르게 처리하기 위해 키-값 스토어를 활용할 수도 있죠.

자, 지금까지 Database 에 대해서 알아봤습니다! 그럼 이제 Data Warehouse 에 대해 알아봅시다.

Data Warehouse 가 무엇인가?

DW도 결국 데이터를 Table 형태로 저장하는 RDB 입니다. 그러나 Oracle, PostgreSQL 과 같은 전통적인 RDBMS 와는 다르죠.

차이는 데이터를 저장하는 방식, 즉 row 기반과 column 기반의 구조적 차이에서 특히 드러납니다. 이어지는 단락에서 Row 기반과 Column 기반의 차이에 대해 자세히 다뤄보겠습니다.

Row 기반 vs Column 기반

OLTP DB의 Row 기반 구조

데이터베이스는 주로 실시간 거래 처리와 업무 지원을 목적으로 합니다. 이를 위해 데이터베이스는 row 기반 구조를 채택하는 경우가 많습니다.

Row 기반 저장 방식은 각 행(row)이 하나의 레코드를 나타내며, 이 레코드는 여러 가지 속성(column)으로 구성됩니다.

이 방식은 실시간으로 데이터를 추가, 수정, 삭제하는 거래 처리에 최적화되어 있습니다. 왜냐하면 특정 거래나 업무와 관련된 모든 데이터 속성을 빠르게 접근하고 수정할 수 있기 때문입니다.

• 데이터 접근의 지역성: Row 기반 구조에서는 관련 데이터가 물리적으로 인접해 있기 때문에, 한 번의 디스크 I/O로 필요한 모든 데이터를 읽을 수 있습니다. 예를 들어, 고객 정보를 업데이트하거나 주문 정보를 조회할 때 해당 레코드의 모든 정보(행)를 쉽게 접근할 수 있습니다.
• 쓰기 작업의 효율성: 새로운 레코드를 추가하거나 기존 레코드를 업데이트할 때, 해당 레코드의 모든 정보를 연속된 공간에 저장합니다. 이는 쓰기 작업을 단순화하고 빠르게 수행할 수 있게 합니다. 또한, 트랜잭션 로그와 함께 작업을 관리하며 데이터 일관성과 복구를 용이하게 합니다.
  

OLAP DW의 Column 기반 구조

반면, 데이터 웨어하우스는 분석과 의사 결정 지원을 주 목적으로 하며, 대량의 역사적 데이터를 저장하고 관리합니다. 이러한 목적에 더 적합하게, 데이터 웨어하우스는 종종 column 기반 구조를 채택합니다.

Column 기반 저장 방식은 각 열(column)이 동일한 유형의 데이터를 포함하며, 이는 대규모 데이터 세트에 대한 질의(query) 수행 시, 필요한 데이터만 선택적으로 스캔하고 처리하는 데 효율적입니다.

이는 특히, 대량의 데이터에서 특정 속성에 대한 분석이나 집계를 수행할 때 성능 이점을 제공합니다.

• 선택적 데이터 접근: Column 기반 구조에서는 쿼리가 필요로 하는 특정 열의 데이터만 읽어 처리할 수 있습니다. 대량의 데이터에서 몇 개의 열만을 대상으로 하는 집계나 분석 작업을 수행할 때, 불필요한 데이터를 읽지 않기 때문에 디스크 I/O가 크게 감소합니다.
• 데이터 압축의 효율성: 같은 열에 있는 데이터는 동일한 유형이기 때문에, 데이터 압축이 효율적으로 이루어집니다. 이는 저장 공간을 절약하고, 디스크 I/O를 줄이는 데 도움이 됩니다. 또한, 압축된 데이터는 메모리 내에서 더 빠르게 처리할 수 있어 쿼리 성능이 향상됩니다.

정규화 vs 비정규화

데이터 웨어하우스(DW)와 온라인 트랜잭션 처리(OLTP) 데이터베이스는 데이터를 관리하고 처리하는 방법이 근본적으로 다릅니다.

OLTP 시스템은 데이터 중복을 최소화하고 데이터 무결성을 유지하기 위해 데이터를 정규화합니다. 이는 데이터를 여러 관련 테이블로 나누고, 이 테이블들 사이의 관계를 정의함으로써 달성됩니다.

반면, 데이터 웨어하우스는 비정규화를 사용함으로써, 데이터 분석과 조회 과정이 단순화됩니다.

사용자는 데이터에 더 빠르게 접근할 수 있고, 복잡한 쿼리나 다수의 테이블 조인 없이도 필요한 정보를 얻을 수 있습니다. 이는 분석가가 보다 쉽게 인사이트를 얻고, 빠른 의사결정을 내릴 수 있도록 돕습니다.

스타 스키마는 중앙의 팩트 테이블과 이를 둘러싼 차원 테이블로 구성되어 데이터 분석과 보고를 단순화합니다.

스노우플레이크 스키마는 스타 스키마를 좀 더 세분화하여 정규화하지만, 여전히 분석을 위해 최적화된 구조를 유지합니다.

"정규화를 하지 않는다"는 말을 더 쉽게 설명하자면, 데이터 웨어하우스는 데이터를 저장할 때 정보를 여러 테이블로 나누지 않고, 가능한 한 테이블에 모아 둔다는 의미입니다.

예를 들어, 당신이 책을 매우 많이 가지고 있는 도서관의 관리자라고 생각해보세요. 도서관 방문자가 특정 책에 대한 정보(저자, 출판년도, 장르 등)를 빠르게 찾길 원한다면, 모든 정보를 한 곳에 모아 두는 것이 도움이 될 것입니다.

• 정규화된 접근 방식 (OLTP 시스템): 책의 제목은 한 책장에, 저자는 다른 책장에, 출판년도는 또 다른 책장에 분류하여 보관합니다. 이렇게 하면 공간을 효율적으로 사용할 수 있고, 중복을 줄일 수 있습니다. 하지만, 한 방문자가 특정 책에 대한 모든 정보를 알고 싶을 때, 여러 책장을 돌아다녀야 합니다.
• 비정규화된 접근 방식 (데이터 웨어하우스): 각 책에 대한 모든 정보를 한 권의 '정보집'에 모아 둡니다. 이 정보집은 책의 제목, 저자, 출판년도 등 모든 것을 포함합니다. 이렇게 하면, 한 방문자가 특정 책에 대한 모든 정보를 한 곳에서 빠르게 찾을 수 있습니다. 물론 같은 정보(예: 같은 저자의 다른 책)가 여러 권의 정보집에 중복될 수 있지만, 정보를 찾는 것이 훨씬 빠르고 쉽습니다.

빅데이터 분석용 DW 에는 어떤 솔루션들이 있는가?

클라우드 기반 데이터 웨어하우스

온-프레미스 데이터 웨어하우스

요약 정리

오늘은 데이터를 다루는 두 가지 중요한 시스템인 데이터베이스(DB)와 데이터 웨어하우스(DW)에 대해 알아보았습니다.

DB는 일상적인 업무 처리와 트랜잭션 관리를 위한 OLTP(Online Transaction Processing) 시스템으로, 데이터의 정확성과 신속한 처리가 핵심입니다.

반면, DW는 데이터 분석과 의사 결정 지원을 목적으로 하는 OLAP(Online Analytical Processing) 시스템으로, 대량의 데이터를 통합하여 복잡한 쿼리와 보고를 가능하게 합니다.

DB와 DW의 차이를 정리한 표

오늘도 여러분께 도움이 되었기를 바라며,

Everyone is an Analyst, 하트카운트 팀의 Jaden 이었습니다 !