NoSQL이 등장하게된 계기는, 기존 RDBMS는 구조상 분산처리에 적합하지 않았습니다. 데이터베이스를 분산 저장하는 샤딩이라는 기술이 있지만, 어플리케이션 레벨에서 직접 구성해야 했기 때문에 번거로웠고, 다른 방법인 오라클의 공유 디스크 기술의 경우에는 라이선스 문제가 있었습니다. 또한 하드웨어의 성능을 증가시키는 scale-up 확장방식에 적합하였기 때문에 장비수를 늘리는 scale-out 방식을 사용할 수 없어 비용부담이 컸습니다. 두번째로 SNS등의 발전으로 처리할 데이터가 폭발적으로 증가하고, 데이터의 형식은 예측할 수 없어 스키마가 정해져있는 기존 관계형 데이터베이스를 대체할 방법이 필요했습니다. 세번째로, RDBMS 시장은 주로 오라클과 마이크로소프트, IBM같은 상용 DBMS가 대부분 차지하고 있는 상황이여서, Mysql과같은 오픈소스의 선택지가 넓은 NoSQL을 고려하게 되었습니다.
기존의 RDBMS와 NoSQL에 대해 정리한 표 입니다. 가장 큰 차이는 각각 ACID와 BASE특성을 갖고 있다는 점과 schema 구조의 유연성의 차이, 하드웨어 업그레이드 방식의 수직적 확장에 의존하는 RDBMS와는 달리 NoSQL 수평적 확장이 가능하고, noSQL은 데이터를 저장할 때의 형식에 의존하지 않습니다. 또한 NoSQL은 집합 단위로 데이터가 저장됩니다. 그럼 특징을 하나씩 살펴보겠습니다.
우선 기존 RDBMS부터 알아보자면 각각 트랜잭션이 무조건 다 완료되거나 다 실패한다는 ATOMICITY(원자성), 트랜잭션이 데이터의 일관성(공통되는 특징)에 영향을 끼치면 안된다는 CONSISTENCY(일관성) , 트랜잭션이 순차적으로 동시에 한개씩 실행됨을 보장하는 ISOLATION(독립성), 트랜잭션의 결과가 영구히 남아있어야 한다는 DURABILITY(지속성) 4개의 특성 ACID라고 하고, 이 특성을 기반으로 두고 있습니다.
이와 반대로 NoSQL은 기본적으로 시스템이 언제나 사용할 수 있는 상태로 유지될 수 있도록 지원하는 availability, 아래 eventually consistency를 위해 input 없이도 시스템 상태가 바뀔 수 있다는 soft-state, 입력 당시엔 일관성이 유지된 상태가 아니지만, 특정 상황엔 일관성이 유지된 상태가 된다는 Eventually consistency 총 3개의 특성 BASE라 하고, 기반으로 두고 있습니다.
RDBMS와의 가장 큰 차이점은 noSQL같은 경우 무조건적으로 일관성을 보장하지 않습니다.
지금까지의 RDBMS와 다른 특징 데이터에 일관성이 보장되지 않아도 되고, 데이터 타입이 고정되지 않고 유연하며, 확장성이 좋다라는 특징 덕분에 빅데이터 처리에 유리합니다.
NoSQL은 아직 제품군이 제대로 정의되지 않았고, 제품 각각의 특성이 있기에 CAP 이론을 기반으로 제품을 구분합니다. Consistency는 모든 사용자가 서로 같은 시점의 데이터를 볼 수 있어야 한다는 특성, Availability는 시스템이 항상 작동해야 한다는 특성, 세번쨰 Tolerance to Network Partitions는 각각의 분산처리를 위해 나눠진 노드끼리 메시지 손실이 일어날 수 있다는 특성입니다. 1,2번째 특성의 경우 분산 시스템의 특성이지만, 3번째 P의 경우 네트워크 구성에 관련한 특성이고, 장애가 없는 네트워크란 존재하지 않기 때문에 모든 nosql 제품은 P를 택하게 됩니다. 즉, 네트워크 장애 상황(P)가 일어나면 A와 P중 무엇에 가중치를 두느냐의 차이입니다.
아까의 CAP는 P를 포함(즉, 장애가 있다는 상황)을 전제로 계산하기 때문에, 이를 개선하여 장애가 존재할시(partitio일시) Availability와 Consitency를, 일반 상황에선 consistency 와 latency 중 하나에 우선순위를 두어 제품군을 나누도록 권장하고 있습니다.
NoSQL 제품을 큰 범위로 나누자면 집합지향 모델과 그래프 모델로 이루어져 있습니다. 주로 집합지향 모델이 채택되고, 각각 키-밸류 형식, 도큐먼트 형식, 컬럼패밀리 방식으로 나눠집니다. 그래프 모델은 기존 RDBMS와 비슷한 특성을 가지고, 클러스터링에 적합하지 않으며 특수한 상황에만 사용됩니다.
NoSQL은 주로 aggregate이라는 단위를 씁니다. 오른쪽이 기존 관계형 데이터베이스가 값을 저장하는 방식이라면, 왼쪽에는 의미있는 단위로 값을 묶어 한번에 저장합니다. 이 방식으로 인해 여러 큰 클러스터에 값을 저장하는데 유리하고, 질의가 빨라집니다. 또한 하나의 집합이 하나의 노드에 저장됨을 보장합니다.
Agreegate oriented 모델 방식 중 Key-value oriented 방식은 Key값과 value값이 1대1로 매칭되는 가장 간단한 방식입니다. Put,get,delete 정도의 단순한 쿼리만 지원하고, 키로만 값을 찾아올 수 있습니다. value에는 들어가는 값의 형식을 제한하지 않습니다. 이 방식을 사용한 DB로는 aws dynamodb, redis가 있습니다.
Column family stores 방식은 하나의 키에 여러 컬럼을 묶어놓은 column family를 저장하는 방식으로 여러 개의 데이터를 한번에 저장할 수 있습니다. 이 방식을 사용한 db는 Cassandra, apache hbase가 있습니다.
DOCUMENT DATABASE 방식은 키와 – json, xml 등의 구조화된 데이터 형식으로 저장됩니다. 다른 도큐먼트 query languag를 사용시 도큐먼트 안의 데이터도 질의 가능합니다. 이 방식을 사용한 DB로는 mongoDB, CouchDB가 있습니다.
NoSQL은 RDBMS의 데이터 분석 – 테이블 디자인 – 쿼리 디자인 방식과 다르게 데이터 분석 – 쿼리 디자인 – 테이블디자인의 순서로 모델링합니다.
감사합니다.
NoSQL이 등장하게된 계기는, 기존 RDBMS는 구조상 분산처리에 적합하지 않았습니다. 데이터베이스를 분산 저장하는 샤딩이라는 기술이 있지만, 어플리케이션 레벨에서 직접 구성해야 했기 때문에 번거로웠고, 다른 방법인 오라클의 공유 디스크 기술의 경우에는 라이선스 문제가 있었습니다. 또한 하드웨어의 성능을 증가시키는 scale-up 확장방식에 적합하였기 때문에 장비수를 늘리는 scale-out 방식을 사용할 수 없어 비용부담이 컸습니다. 두번째로 SNS등의 발전으로 처리할 데이터가 폭발적으로 증가하고, 데이터의 형식은 예측할 수 없어 스키마가 정해져있는 기존 관계형 데이터베이스를 대체할 방법이 필요했습니다. 세번째로, RDBMS 시장은 주로 오라클과 마이크로소프트, IBM같은 상용 DBMS가 대부분 차지하고 있는 상황이여서, Mysql과같은 오픈소스의 선택지가 넓은 NoSQL을 고려하게 되었습니다.
기존의 RDBMS와 NoSQL에 대해 정리한 표 입니다. 가장 큰 차이는 각각 ACID와 BASE특성을 갖고 있다는 점과 schema 구조의 유연성의 차이, 하드웨어 업그레이드 방식의 수직적 확장에 의존하는 RDBMS와는 달리 NoSQL 수평적 확장이 가능하고, noSQL은 데이터를 저장할 때의 형식에 의존하지 않습니다. 또한 NoSQL은 집합 단위로 데이터가 저장됩니다. 그럼 특징을 하나씩 살펴보겠습니다.
우선 기존 RDBMS부터 알아보자면 각각 트랜잭션이 무조건 다 완료되거나 다 실패한다는 ATOMICITY(원자성), 트랜잭션이 데이터의 일관성(공통되는 특징)에 영향을 끼치면 안된다는 CONSISTENCY(일관성) , 트랜잭션이 순차적으로 동시에 한개씩 실행됨을 보장하는 ISOLATION(독립성), 트랜잭션의 결과가 영구히 남아있어야 한다는 DURABILITY(지속성) 4개의 특성 ACID라고 하고, 이 특성을 기반으로 두고 있습니다.
이와 반대로 NoSQL은 기본적으로 시스템이 언제나 사용할 수 있는 상태로 유지될 수 있도록 지원하는 availability, 아래 eventually consistency를 위해 input 없이도 시스템 상태가 바뀔 수 있다는 soft-state, 입력 당시엔 일관성이 유지된 상태가 아니지만, 특정 상황엔 일관성이 유지된 상태가 된다는 Eventually consistency 총 3개의 특성 BASE라 하고, 기반으로 두고 있습니다.
RDBMS와의 가장 큰 차이점은 noSQL같은 경우 무조건적으로 일관성을 보장하지 않습니다.
지금까지의 RDBMS와 다른 특징 데이터에 일관성이 보장되지 않아도 되고, 데이터 타입이 고정되지 않고 유연하며, 확장성이 좋다라는 특징 덕분에 빅데이터 처리에 유리합니다.
NoSQL은 아직 제품군이 제대로 정의되지 않았고, 제품 각각의 특성이 있기에 CAP 이론을 기반으로 제품을 구분합니다. Consistency는 모든 사용자가 서로 같은 시점의 데이터를 볼 수 있어야 한다는 특성, Availability는 시스템이 항상 작동해야 한다는 특성, 세번쨰 Tolerance to Network Partitions는 각각의 분산처리를 위해 나눠진 노드끼리 메시지 손실이 일어날 수 있다는 특성입니다. 1,2번째 특성의 경우 분산 시스템의 특성이지만, 3번째 P의 경우 네트워크 구성에 관련한 특성이고, 장애가 없는 네트워크란 존재하지 않기 때문에 모든 nosql 제품은 P를 택하게 됩니다. 즉, 네트워크 장애 상황(P)가 일어나면 A와 P중 무엇에 가중치를 두느냐의 차이입니다.
아까의 CAP는 P를 포함(즉, 장애가 있다는 상황)을 전제로 계산하기 때문에, 이를 개선하여 장애가 존재할시(partitio일시) Availability와 Consitency를, 일반 상황에선 consistency 와 latency 중 하나에 우선순위를 두어 제품군을 나누도록 권장하고 있습니다.
NoSQL 제품을 큰 범위로 나누자면 집합지향 모델과 그래프 모델로 이루어져 있습니다. 주로 집합지향 모델이 채택되고, 각각 키-밸류 형식, 도큐먼트 형식, 컬럼패밀리 방식으로 나눠집니다. 그래프 모델은 기존 RDBMS와 비슷한 특성을 가지고, 클러스터링에 적합하지 않으며 특수한 상황에만 사용됩니다.
NoSQL은 주로 aggregate이라는 단위를 씁니다. 오른쪽이 기존 관계형 데이터베이스가 값을 저장하는 방식이라면, 왼쪽에는 의미있는 단위로 값을 묶어 한번에 저장합니다. 이 방식으로 인해 여러 큰 클러스터에 값을 저장하는데 유리하고, 질의가 빨라집니다. 또한 하나의 집합이 하나의 노드에 저장됨을 보장합니다.
Agreegate oriented 모델 방식 중 Key-value oriented 방식은 Key값과 value값이 1대1로 매칭되는 가장 간단한 방식입니다. Put,get,delete 정도의 단순한 쿼리만 지원하고, 키로만 값을 찾아올 수 있습니다. value에는 들어가는 값의 형식을 제한하지 않습니다. 이 방식을 사용한 DB로는 aws dynamodb, redis가 있습니다.
Column family stores 방식은 하나의 키에 여러 컬럼을 묶어놓은 column family를 저장하는 방식으로 여러 개의 데이터를 한번에 저장할 수 있습니다. 이 방식을 사용한 db는 Cassandra, apache hbase가 있습니다.
DOCUMENT DATABASE 방식은 키와 – json, xml 등의 구조화된 데이터 형식으로 저장됩니다. 다른 도큐먼트 query languag를 사용시 도큐먼트 안의 데이터도 질의 가능합니다. 이 방식을 사용한 DB로는 mongoDB, CouchDB가 있습니다.
NoSQL은 RDBMS의 데이터 분석 – 테이블 디자인 – 쿼리 디자인 방식과 다르게 데이터 분석 – 쿼리 디자인 – 테이블디자인의 순서로 모델링합니다.
감사합니다.
사례로 알아보는 MariaDB 마이그레이션
현대적인 IT 환경과 애플리케이션을 만들기 위해 우리는 오늘도 고민을 거듭합니다. 최근 들어 오픈소스 DB가 많은 업무에 적용되고 검증이 되면서, 점차 무거운 상용 데이터베이스를 가벼운 오픈소스 DB로 전환하는 움직임이 대기업의 미션 크리티컬 업무까지로 확산하고 있습니다. 이는 클라우드 환경 및 마이크로 서비스 개념 확산과도 일치하는 움직임입니다.
상용 DB를 MariaDB로 이관한 사례를 통해 마이그레이션의 과정과 효과를 살펴 볼 수 있습니다.
MariaDB로 이관하는 것은 어렵다는 생각을 막연히 가지고 계셨다면 본 자료를 통해 이기종 데이터베이스를 MariaDB로 마이그레이션 하는 작업이 어렵지 않게 수행될 수 있다는 점을 실제 사례를 통해 확인하시길 바랍니다.
웨비나 동영상
https://www.youtube.com/watch?v=xRsETZ5cKz8&t=52s
Cloud DW technology trends and considerations for enterprises to apply snowflakeSANG WON PARK
올해 처음 오프라인으로 진행된 "한국 데이터 엔니지어 모임"에서 발표한 cloud dw와 snowflake라는 주제로 발표한 내용을 정리하여 공유함. (2022.07)
[ 발표 주제 ]
Cloud DW 기술 트렌드와 Snowflake 적용
- Modern Data Stack에서 Cloud DW의 역할
- 기존 Data Lake + DW와 무엇이 다른가?
- Data Engineer 관점에서 어떻게 사용하면 좋을까? (기능/성능/비용 측면의 장점/단점)
[ 주요 내용 ]
- 최근 많은 Data Engineer가 기존 기술 스택(Hadoop, Spark, DW 등)의 기술적/운영적 한계를 극복하기 위한 고민중.
- 특히 Cloud의 장점과 운영 및 성능을 고려한 Cloud DW(AWS Redshift, GCP BigQuery, DataBricks, Snowflake)를 고려
- 이 중 Snowflake를 실제 프로젝트에 적용한 경험과 기술적인 특징/장점/단점을 공유하고자 함.
작년부터 정부의 데이터 정책 변화와 Cloud 기반의 기술 변화 가속화로 기업의 데이터 환경에도 많은 변화가 발생하고 있고, 기업들은 이에 적응하기 위한 다양한 시도를 하고 있다.
그 중심에 cloud dw (또는 Lake house)가 위치하고 있으며, 이를 기반으로 통합 데이터 플랫폼으로의 아키텍처로 변화하고 있다. 하지만, 아직까지 기존 DW 제품과 주요 CSP(AWS, GCP, Azure)의 제품군을 다양하게 시도하고 있으나, 기대와 다르게 생각보나 낮은 성능 또는 비싼 사용료, 운영의 복잡성으로 인한 많은 시행착오를 거치고 있다.
이 상황에서 작년에 처음 검토한 snowflake의 다양한 기능들이 기업들의 고민과 문제를 상당부분 손쉽게 해결할 수 있다는 것을 확인할 수 있었고, 이를 이용하여 실제 많은 기업들에게 적용하기 위한 POC를 수행하거나, 실제 적용하는 프로젝트를 수행하게 되었다.
본 발표 내용은 이러한 경험을 기반으로 기업(그리고 실제 업무를 수행할 Data Engineer) 관점에서 snowflake가 어떻게 문제를 해결할 수 있는지 cloud dw를 도입/활용/확장 하는 단계별로 문제와 해결 방안을 중심으로 설명하였다.
https://blog.naver.com/freepsw?Redirect=Update&logNo=222815591918
네이버클라우드플랫폼에서 제공하는 클라우드 데이터베이스 서비스를 소개하고, 네이버클라우드 플랫폼의 클라우드 데이터베이스 관리 노하우에 대해 소개합니다 | Introduce cloud database services provided by Naver Cloud Platform and know-how of managing cloud databases on Naver Cloud Platform
사례로 알아보는 MariaDB 마이그레이션
현대적인 IT 환경과 애플리케이션을 만들기 위해 우리는 오늘도 고민을 거듭합니다. 최근 들어 오픈소스 DB가 많은 업무에 적용되고 검증이 되면서, 점차 무거운 상용 데이터베이스를 가벼운 오픈소스 DB로 전환하는 움직임이 대기업의 미션 크리티컬 업무까지로 확산하고 있습니다. 이는 클라우드 환경 및 마이크로 서비스 개념 확산과도 일치하는 움직임입니다.
상용 DB를 MariaDB로 이관한 사례를 통해 마이그레이션의 과정과 효과를 살펴 볼 수 있습니다.
MariaDB로 이관하는 것은 어렵다는 생각을 막연히 가지고 계셨다면 본 자료를 통해 이기종 데이터베이스를 MariaDB로 마이그레이션 하는 작업이 어렵지 않게 수행될 수 있다는 점을 실제 사례를 통해 확인하시길 바랍니다.
웨비나 동영상
https://www.youtube.com/watch?v=xRsETZ5cKz8&t=52s
Cloud DW technology trends and considerations for enterprises to apply snowflakeSANG WON PARK
올해 처음 오프라인으로 진행된 "한국 데이터 엔니지어 모임"에서 발표한 cloud dw와 snowflake라는 주제로 발표한 내용을 정리하여 공유함. (2022.07)
[ 발표 주제 ]
Cloud DW 기술 트렌드와 Snowflake 적용
- Modern Data Stack에서 Cloud DW의 역할
- 기존 Data Lake + DW와 무엇이 다른가?
- Data Engineer 관점에서 어떻게 사용하면 좋을까? (기능/성능/비용 측면의 장점/단점)
[ 주요 내용 ]
- 최근 많은 Data Engineer가 기존 기술 스택(Hadoop, Spark, DW 등)의 기술적/운영적 한계를 극복하기 위한 고민중.
- 특히 Cloud의 장점과 운영 및 성능을 고려한 Cloud DW(AWS Redshift, GCP BigQuery, DataBricks, Snowflake)를 고려
- 이 중 Snowflake를 실제 프로젝트에 적용한 경험과 기술적인 특징/장점/단점을 공유하고자 함.
작년부터 정부의 데이터 정책 변화와 Cloud 기반의 기술 변화 가속화로 기업의 데이터 환경에도 많은 변화가 발생하고 있고, 기업들은 이에 적응하기 위한 다양한 시도를 하고 있다.
그 중심에 cloud dw (또는 Lake house)가 위치하고 있으며, 이를 기반으로 통합 데이터 플랫폼으로의 아키텍처로 변화하고 있다. 하지만, 아직까지 기존 DW 제품과 주요 CSP(AWS, GCP, Azure)의 제품군을 다양하게 시도하고 있으나, 기대와 다르게 생각보나 낮은 성능 또는 비싼 사용료, 운영의 복잡성으로 인한 많은 시행착오를 거치고 있다.
이 상황에서 작년에 처음 검토한 snowflake의 다양한 기능들이 기업들의 고민과 문제를 상당부분 손쉽게 해결할 수 있다는 것을 확인할 수 있었고, 이를 이용하여 실제 많은 기업들에게 적용하기 위한 POC를 수행하거나, 실제 적용하는 프로젝트를 수행하게 되었다.
본 발표 내용은 이러한 경험을 기반으로 기업(그리고 실제 업무를 수행할 Data Engineer) 관점에서 snowflake가 어떻게 문제를 해결할 수 있는지 cloud dw를 도입/활용/확장 하는 단계별로 문제와 해결 방안을 중심으로 설명하였다.
https://blog.naver.com/freepsw?Redirect=Update&logNo=222815591918
네이버클라우드플랫폼에서 제공하는 클라우드 데이터베이스 서비스를 소개하고, 네이버클라우드 플랫폼의 클라우드 데이터베이스 관리 노하우에 대해 소개합니다 | Introduce cloud database services provided by Naver Cloud Platform and know-how of managing cloud databases on Naver Cloud Platform
2. 1. NoSQL이란?
NoSQL 데이터베이스는 전통적인 관계형 데이터베이스 보다 덜 제한적인 일관성 모델을 이용
하는 데이터의 저장 및 검색을 위한 매커니즘을 제공한다. 이러한 접근에 대한 동기에는 디자
인의 단순화, 수평적 확장성, 세세한 통제를 포함한다. NoSQL 데이터베이스는 단순 검색 및 추
가 작업을 위한 매우 최적화된 키 값 저장 공간으로, 레이턴시와 스루풋과 관련하여 상당한 성
능 이익을 내는 것이 목적이다. NoSQL 데이터베이스는 빅데이터와 실시간 웹 애플리케이션의
상업적 이용에 널리 쓰인다. 또, NoSQL 시스템은 SQL 계열 쿼리 언어를 사용할 수 있다는 사
실을 강조한다는 면에서 "Not only SQL"로 불리기도 한다.
NoSQL의 특징
● NoSQL은 RDBMS와는 달리 데이터 간의 관계를 정의하지 않는다
가장 큰 특징 중의 하나는 관계형 데이터베이스인 RDBMS가 데이터의 관계를 Foreign Key 등
으로 정의하고 이를 이용해 Join 등의 관계형 연산을 한다고 하면, NoSQL은 데이터 간의 관계
를 정의하지 않는다. 데이터 테이블은 그냥 하나의 테이블이며 각 테이블 간의 관계를 정의하
지도 않고 일반적으로 테이블 간의 Join도 불가능하다.
● RDBMS에 비해 훨씬 더 대용량의 데이터를 저장할 수 있다
RDBMS의 복잡도와 용량 한계를 극복하기 위한 목적으로 등장한 만큼, 페타바이트급의 대용
량 데이터를 저장할 수 있다.
● 분산형 구조
NoSQL은 기존의 RDBMS와는 다르게 하나의 고성능 머신에 데이터를 저장하는 것이 아니라,
일반적인 서버(인텔 계열의 CPU를 사용하는 Commodity Server) 수십 대를 연결해 데이터를 저
장 및 처리하는 구조를 갖는다. 즉 분산형 구조를 통해 데이터를 여러 대의 서버에 분산해 저장
하고, 분산 시에 데이터를 상호 복제해 특정 서버에 장애가 발생했을 때에도 데이터 유실이나
서비스 중지가 없는 형태의 구조다.
●고정되지 않은 테이블 스키마
RDBMS와는 다르게 테이블의 스키마가 유동적이다. 예를 들어 RDBMS의 경우 테이블이 <표
1>과 같은 형태로 되어 있을 때 해당 테이블은 반드시 숫자, 이름 문자열, 주소 문자열만 들어
갈 수 있다.
그런데 NoSQL은 대부분 이런 개념이 없다. ID로 사용하는 키 부분에만 타입이 동일하고,
mandatory(생략되지 않는) 필드로 지정하면 값에 해당하는 컬럼은 어떤 타입이든, 어떤 이름이
오든 허용된다. 즉 <표 2>와 같이 ID 필드는 공통이지만, 데이터를 저장하는 컬럼은 각기 다른
이름과 다른 데이터 타입을 갖는 것이 허용된다.
NOSQL SURVEY !2
3. 2. NoSQL의 주요 핵심 기술
CAP : NoSQL의 이론적 기반
Consistency : each client always has the same view of the data
Availability : all clients can always read and write
Partition tolerance : the system works well across physical network partitions
Consistency (일관성) : 모든 노드들은 동시에 같은 데이터를 보아야 합니다.
Availability (유효성) : 모든 노드는 항상 읽기와 쓰기를 할 수 있어야 합니다.
Partition Tolerance (파티션 허용차) : 시스템은 물리적인 네트워크 파티션을 넘어서도 잘 동작하
여야 합니다
NoSQL에 대해서 이해하려면 먼저 CAP 이론에 대해서 알 필요가 있습니다. CAP이론은
Brewer's CAP Theorem으로 알려져 있는데 분산 컴퓨팅 시스템에서 보장해야 하는 특징으로 위
의 3가지를 정의하고 있습니다.
CAP 이론에 따르면 위 3가지 중에 동시에 2가지만 보장할수 있고 3개를 모두 보장하는 것이 불
가능하다고 나와있습니다. 그래서 데이터를 관리할때 이 3가지 중에 어느 2가지에 중점을 두냐
NOSQL SURVEY !3
4. 는 것은 아주 중요한 부분입니다. 이 부분을 이해하는데 Nathan Hurst이 만든 위의 Visual
Guide to NoSQL Systems는 큰 도움이 됩니다.
Visual Guide to NoSQL Systems
기존에 많이 사용하던 RDBMS는 3가지 중 CA에 집중하고 있습니다. 웹이 발전하면서 다양한
요구사항이 생겨나고 엄청난 양의 데이터를 처리해야 하게 되면서 RDBMS가 갖지 못한 P의
특성이 필요해졌고 그러면서 등장한 것이 NoSQL입니다. 좀더 풀어쓰면 데이터베이스에 대한
수평적 확장(Horizontal Scalability 즉 옆에 서버한대 더 배치해서 데이터베이스를 늘리고 싶다
는 의미입니다.)에 대한 이슈가 발생했고 확장성이슈를 해결하기 위해서 P를 선택하다 보니 기
존에 가지고 있던 C나 A의 특성중 하나를 포기해야 했습니다. 그래서 NoSQL에는 다양한 시도
들이 있지만 가장 중요한 이슈는 확장성을 해결하려는 것으로 생각됩니다.
관계형 데이터베이스는 기본적으로 분산형을 고려해서 디자인 되지 않았습니다. 그래서
ACID(원자성, 일관성, 독립성, 지속성) 트랜잭션 같은 추상화와 고레벨 쿼리모델을 풍부하게
제공할 수 있지만 확장성이 좋지 못하기 때문에 모든 NoSQL 데이터베이스는 다양한 방법으로
확장성 이슈를 해결하기 위해 초점을 맞추고 있습니다. 각 NoSQL에는 여러가지 차이점들이
있지만 CAP의 범주에서만 보면 CP를 선택하거나 AP를 선택하게 됩니다.
왜 비관계형이어야 하는가?
NoSQL이 확장성 이슈를 해결하려고 CP나 AP의 특성을 선택했지만 구체적으로 어떤 특징을
선택하고 왜 그래야 했는지 이해할 필요가 있습니다. NoSQL은 많은 제품군들이 있는데 모두
같은 전략으로 접근하고 있지는 않고 각각에 제품에 따라 다양한 접근을 하고 있는데 아래 적
힌 내용들은 비관계형으로 가기 위한 여러가지 특성들에 대한 이야기이고 제품군에 따라 아래
의 특성들을 선택한 여부는 다른 것으로 보입니다.
관계형 데이터 베이스는 확장하기가 어렵습니다.
Replication - 복제에 의한 확장
Master-Slave 구조에서는 결과를 슬레이브의 갯수만큼 복제해야 하는데 N개의 슬레이브에서
읽을 수 있기 때문에 Read는 빠르지만 Write에서는 병목현상이 발생하게 기 때문에 확장성에
대한 제한을 가지게 됩니다.
다중 마스터구조에서는 마스터를 추가함으로써 쓰기의 성능을 향상시킬 수 있는데 대신에 충
돌이 발생할 가능성이 생기게 됩니다.
Partitioning(Sharding) - 분할에 의한 확장
Read만큼 Write도 확장할 수 있지만 애플리케이션레이어에서 파티션된 것을 인지하고 있어야
합니다. RDBMS의 가치는 관계에 있다고 할 수 있는데 파티션을 하면 이 관계가 깨져버리고
각 파티션된 조각간에 조인을 할 수 없기 때문에 관계에 대한 부분은 애플리케이션 레이어에서
책임져야 합니다. 일반적으로 RDBMS에서 수동 Sharding 은 쉽지 않습니다.
NoSQL에서 필요없는 특성들
NOSQL SURVEY !4
5. UPDATE와 DELETE
Update와 Delete는 전통적으로 정보의 손실이 발생하기 때문에 잘 사용되지 않으며 후에 데이
터 검사 및 재활성화를 위해서 기록해둘 필요가 있습니다. 그리고 사용자가 커뮤니티를 탈퇴한
다고 그들의 글을 지우지 않듯이 도메인 관점에서는 실제로 삭제되지 않습니다. 이런 접근을
하게 되면 Update / Delete를 모두 Insert로 모델할수 있고 과거 데이터는 버전을 붙혀서 기록할
수 있으며 이 데이터들은 비활성데이터들이 됩니다. 이 INSET-only 시스템에서는 2개의 문제
가 있는데 데이터베이스에서 종속(cascade)에 대한 트리거를 이용할 수 없으며 Query가 비활성
데이터를 걸러내야 할 필요가 있습니다.
JOIN
데이터가 많을 때 JOIN은 많은 양의 데이터에 복잡한 연산을 수행해야 하기 때문에 비용이 많
이 들며 파티션을 넘어서는 동작되지 않기 때문에 피해야 합니다. 정규화는 일관된 데이터를
가지기 쉽게 하고 스토리지의 양을 줄이기 위해서 하는건데 반정규화(De-normalization)를 하면
JOIN문제를 피할 수 있습니다. 반정규화로 일관성에 대한 책임을 디비에서 애플리케이션으로
이동시킬수 있는데 이는 INSERT-only라면 어렵지 않습니다.
ACID 트랜젝션
Atomic (원자성) : 여러 레코드를 수정할 때 원자성은 필요없으며 단일키 원자성이면 충분합니
다.
Consistency (일관성) : 대부분의 시스템은 C보다는 P나 A를 필요로 하기 때문에 엄격한 일관성
을 가질 필요는 없고 대신 결과의 일관성(Eventually Consistent)을 가질 수 있습니다.
Isolation (격리성) : 읽기에 최선을 다하는(Read-Committe) 것 이상의 격리성은 필요하지 않으며
단일키 원자성이 더 쉽습니다.
Durability (지속성) : 각 노드가 실패했을때도 이용되기 위해서는 메모리가 데이터를 충분히 보
관할 수 있을정도로 저렴해지는 시점까지는 지속성이 필요합니다.
고정된 스키마
RDBMS에서는 데이터를 사용하기 전에 스키마를 정의해야하고 Index등을 정의해야 하는데
현재의 웹환경에서는 빠르게 새로운 피쳐를 추가하고 이미 존재하는 피쳐를 조정하기 위해서
는 스키마 수정이 필수적으로 요구됩니다. 하지만 컬럼의 추가/수정/삭제는 row에 lock을 걸고
index의 수정은 테이블에 락을 걸기 때문에 스키마 수정이 어렵습니다.
NOSQL SURVEY !5
6. 3. NoSQL 관련 제품
몽고DB, 카산드라DB, Hbase, Redis
Cassandra
카산드라는 구글의 BigTable 컬럼 기반의 데이타 모델과 FaceBook에서 만든 Dynamo의 분산 모
델을 기반으로 하여 제작되어 Facebook에 의해 2008년에 아파치 오픈소스로 공개된 분산 데이
타 베이스 입니다. 기존의 관계형 데이타 베이스와 다르게 SQL을 사용하지 않는 NoSQL의 제
품중의 하나이며, 대용량의 데이타 트렌젝션에 대해서 고성능 처리가 가능한 시스템입니
다.(High-Scale). 노드를 추가함으로써 성능을 낮추지 않고 횡적으로 용량을 확장할 수 있으며
얼마전에 트위터도 MySQL에서 Cassandra로 데이타베이스를 전환하였다고 합니다. 자바로 작
성되었음에도 불구하고, 데이타베이스라는 명칭에 걸맞게 여러 프로그래밍 언어를 지원합니
다. (Ruby,Perl,Python,Scala,Java,PHP,C#)
데이타간의 복잡한 관계 정의(Foreign Key)등이 필요없고, 대용량과 고성능 트렌젝션을 요구하
는 SNS (Social Networking Service)에 많이 사용되고 있으며. 성능이나 확장성과 안정성이 뛰어
납니다.
HBASE
HBase는 Cassandra와 마찬가지로 Bigtable의 영향을받은, 대량 데이터를 효율적으로 다루기 위
한 목적으로 개발된 NoSQL 데이터베이스입니다. 대용량 데이터를 다루는 NoSQL 데이터베이
스중 Cassandra와 함께 가장 많이 사용되고 있습니다만, Cassandra와는 구별되는 뚜렷한특징을
가지고 있습니다. Cassandra는 성능을 우선시 할 경우 데이터 일관성이 보장되지 않을 수있는
데. 대량 데이터를우수한 성능으로 데이터 일관성을 보장하면서 다뤄야 할 때는바로 HBase입
니다.
HBase는 중앙에 전체 분산 시스템을 통제하는 마스터를 두고 복제된 전체 데이터의 일관성을
관리 하기때문에 분산된 복제 데이터 사이의일관성을 보장하며 제약이 있지만 트랜잭셔성 처
리도 지원이 가능합니다.대량 데이터 분석 및 처리를 위해 사용되는 Hadoop의 산하 프로젝트
NOSQL SURVEY !6
7. 로 시작된 데이터베이스로 HDFS 및 MapReduce등과 함께 사용하기에최적화 되어 있습니다.
MapReduce를 지원하는 다른 데이터베이스도 있지만 별도로 개발되었기 때문에 HBase처럼
HDFS를 사용하며 MapReduce의 기능을 적합하게 사용하는 예는 없습니다.대량 데이터를 분
삭하여 의미 있는 값을 만드는 데 있어 널리 사용되고 있는 MapReduce와 함께 효율적으로 이
용할 수 있다는 것이 큰 장점 입니다.
Mongo DB
MongoDB는 10gen 사에서 개발된 높은 성능과 확장성을 가지고 있는 데이터베이스 입니다.
몽고DB는 크로스 플랫폼 도큐먼트 지향 데이터베이스 시스템입니다. NoSQL 데이터베이스로
분류되는 몽고DB는 JSON과 같은 동적 스키마형 문서들을 선호함에 따라 전통적인 테이블 기
반 관계형 데이터베이스 구조의 사용을 하지않습니다. 이로써 특정한 종류의 애플리케이션을
더 쉽고 더 빠르게 데이터 통합을 가능케 합니다. GPL과 아파치 라이선스를 결합하여 공개된
몽고DB는 자유-오픈 소스 소프트웨어입니다.
Redis
Redis는 "REmote DIctionary System"의 약자로 메모리 기반의 Key/Value Store 입니다.
Cassandra나 HBase와 같이 NoSQL DBMS로 분류되기도 하고, memcached와 같은 In memory
솔루션으로 분리되기도 합니다.성능은 memcached에 버금가면서 다양한 데이타 구조체를 지
원함으로써 Message Queue, Shared, memory, Remote Dictionary 용도로도 사용될 수 있으며, 이
런 이유로 인스탄트그램, 네이버 재팬의 LINE 메신져 서비스, StackOverflow,Blizzard,digg 등 여
러 소셜 서비스에 널리 사용되고 있습니다.
< Redis 특징 >
ㅁ처리 속도가 빠르다
ㅁ데이터가 메모리+Disk에 저장된다
ㅁ만료일을 지정하여 만료가 되면 자동으로 데이터가 사라진다.
ㅁ저장소 메모리 재사용 하지 않는다
NOSQL SURVEY !7
8. 4. NoSQL 적용사례
GOOGLE’s BIG TABLE
1.
ITWORLD 기사 : http://www.itworld.co.kr/t/54649/%EB%B9%85/93284
구글, 빅데이터 저장 서비스 ‘클라우드 빅테이블’ 공개
Joab Jackson | IDG News Service
구글이 대용량 데이터를 온라인에
저장할 수 있는 서비스를 출시했다.
기업들이 데이터 분석을 클라우드
서비스로 수행할 수 있을 것으로 기
대된다.
구글 클라우드 빅테이블(Google
Cloud Bigtable)이라는 이름의 이 서
비스는 구글이 몇 년간 내부적으로 이용해왔던 기술을 상용화 한 것이다. 현재 구글 검색, 지메
일, 구글 애널리틱스 등 많은 구글 핵심 서비스에 빅테이블이 사용되고 있다.
금융 업체들은 빅테이블을 트렌드 분석을 위해 페타바이트 용량의 거래 데이터를 저장하는데
사용할 수 있으며, 통신사, 디지털 광고 회사, 에너지, 생명과학 등 데이터 집적도가 높은 업계
에서도 활용할 것으로 기대된다. 사물 인터넷 모니터링 시스템의 센서 데이터 저장용으로도 사
용될 수 있다.
구글 클라우드 빅테이블은 NoSQL 데이터베이스로, 고객들은 오픈소스 아파치 HBase(Apache
HBase)용 API를 사용해서 데이터를 읽고 작성할 수 있다. 따라서, 빅데이터용 인기 오픈소스 데
이터 프로세스 플랫폼인 하둡 소프트웨어로 쉽게 이 서비스를 이용할 수 있다. 또한, 구글 빅쿼
리, 구글 클라우드 데이터플로우 등 다양한 구글 클라우드 서비스와도 통합할 수 있다.
구글은 구글 클라우드 빅테이블이 다른 NoSQL DB보다 빠르다고 주장한다. 내부 벤치마크에
서 빅테이블은 HBase, 카산드라 NoSQL DB보다 읽기/쓰기 속도가 빨랐다.
구글은 클라우드 빅테이블의 데이터 백업을 위한 복제, 보안을 위한 암호화 등을 직접 처리한
다. 사용자들은 매우 빠르게 새로운 빅테이블 클러스터를 만들 수 있다. 데이터 양이 증가하면
구글이 자동으로 추가 스토리지 용량을 제공한다.
여러 서드파티 업체들이 이미 빅테이블을 이용하고 있다. 예를 들어서, 금융 소프트웨어 및 서
비스 업체인 선가드(Sungard)는 클라우드 빅테이블에 금융 감사 추적 시스템을 구축해서 초당
250만 개의 거래 메시지를 처리하고 있다.
NOSQL SURVEY !8
9. 2.
지디넷 코리아 기사
http://www.zdnet.co.kr/news/news_view.asp?artice_id=20150507082703
구글, 내부 핵심 DB기술도 클라우드로 판다
구글이 검색, G메일, 분석 등의 서비스에 사용해온 데이터베이스 ‘빅테이블’을 클라우드 서비
스로 공개했다.
6일(현지시간) 미국 지디넷 등 외신에 따르면, 구글은 NoSQL 데이터베이스 ‘구글 클라우드 빅
테이블(Bigtable)’을 베타서비스로 제공한다고 밝혔다. 구글 빅테이블은 2006년 논문으로 공개
된 구글 내부 서비스용 데이터베이스다. 스키마 없는 NoSQL DB의 원조 중 하나로 통하며, 하
둡 에코시스템에 많은 영향을 끼쳤다.
구글은 ‘클라우드 빅테이블’이 오픈소스 아파치 HBASE API를 통해 접근할 수 있고, 현존하는
빅데이터 및 하둡 에코시스템 다수와 네이티브하게 통합가능하다고 설명했다.
클라우드 빅테이블은 ‘클라우드 Pub/Sub’, ‘데이터플로’, ‘빅쿼리’ 등 구글클라우프플랫폼의 빅
데이터 제품과도 통합가능하다.
코리 오코너 구글 빅테이블 프로덕트매니저는 “외부의 다른 옵션과 비교해 비상할 정도로 짧
은 한자릿수 밀리초 레이턴시를 갖는다”며 “훌륭한 가격 대비 성능, 월당 달러당 데이터 수집,
저장, 쓰기 용량이 대단히 높다”고 강조했다.
구글 클라우드 빅테이블과 HBASE, 카산드라의 성능 비교(자료:구글클라우드플랫폼 블로그)
구글 클라우드 빅테이블과 HBASE, 카산드라의 성능 비교(자료:구글클라우드플랫폼 블로그)
구글은 새로운 서비스가 경쟁 NoSQL 기술과 비교해 달러당 2배의 성능, 절반의 총소유비용
(TCO)을 자랑한다고 주장했다. HBASE, 카산드라 등이 비교대상으로 거론됐다.
클라우드 빅테이블은 기본적을 복제되며, 모든 데이터는 암호화된다. 클라우드 빅테이블 클러
스터를 만들고 재배열하는 작업 모두 단순한 사용자인터페이스(UI)로 이뤄지고, 10초 안에 작
업을 완료할 수 있다고 강조했다. 스토리지 규모는 자동으로 확장되고, 복잡하게 용량 수요를
측정할 필요가 없다고 덧붙였다.
코리 오코너 매니저는 “하둡 에코시스템의 많은 사람들, 전문가조차 HBASE는 어렵다고 말한
다”며 “클라우드 빅테이블은 당신의 HBASE나 카산드라 클러스터보다 더 많은 혜택을 갖는다”
고 말했다.
구글은 클라우드 빅테이블의 또 다른 용도로 사물인터넷(IoT) 인프라를 짚었다. 광고, 에너지,
재무 서비스, 통신 분야도 유용한 사용처로 꼽았다.
NOSQL SURVEY !9