NoSQL 등장 배경
기존 컴퓨팅 시스템 특징
- 기업 업무를 자동화하고 효율화하는 목적
- 기업의 복잡한 데이터를 저장하고 그 데이터 간의 관계를 정의하고 분석하는데 최적화
- 기업의 업무 시스템은 해당 기업의 생산과 판매를 지원하기 위한 것
- 생성되는 데이터양은 한계를 가지고 있음
- 2000년대에 들어서면서 인터넷의 발전과 함께 SNS 서비스가 활성화
- SNS 서비스 시스템은 전 세계 사용자 대상의 서비스로 발전
- 기존의 기업 시스템에서 볼 수 없었던 대규모 데이터를 생산
- 이러한 데이터들은 기존 기업 데이터에 비해 매우 단순한 형태를 가진다.
- 데이터의 패러디임이 한정된 규모의 복잡성 높은 데이터에서 단순한 대량 데이터로 넘어감
- 기존의 데이터 저장 시스템으로는 커버할 수 없는 여러 가지 한계를 야기했고,
결국에는 새로운 형태의 데이터 저장 기술을 요구하게 되었다.
- 대표적인 인터넷 기업이며 대용량 단순 데이터를 가장 많이 보유했기에,
단순 대용량 데이터 처리에 대한 요구가 가장 많은 구글과 아마존에 의해 빅 테이블과 Dynamo라는 논문이 발표됨
- 이 두 논문은 새로운 데이터 저장 기술을 만들어내는 시발점이 되었고,
기존의 오라클 등으로 대변되는 RDBMS 중심의 데이터 저장 기술 시장에
새로운 데이터 저장 기술인 NoSQL이 등장
- NoSQL은 Not Only SQL의 약자로 기존 RDBMS 형태의 관계형 데이터베이스가 아닌 다른 형태의 데이터 저장 기술을 의미
NoSQL의 특징
- RDBMS 제품군 등과 같이 공통된 형태의 데이터 저장 방식(테이블)과 접근 방식(SQL)을 갖는 제품군이 아닌
RDBMS와 다른 형태의 데이터 저장 구조를 총칭하며,
제품에 따라 각기 그 특성이 매우 달라서 NoSQL을 하나의 제품군으로 정의할 수 없다.
- RDBMS가 데이터의 관계를 FK 등으로 정의하고 이를 이용해 join 등의 관계형 연산을 하지만
NoSql은 데이터 간의 관계를 정의하지 않음
- RDBMS의 복잡도와 용량 한계를 극복하기 위한 목적으로 등장한 만큼, 페타바이트급 대용량 데이터 저장 가능
- 기존의 RDBMS처럼 하나의 고성능 머신에 데이터를 저장하는 것 아닌,
일반적인 서버 수십대를 연결해 데이터를 저장 및 처리하는 구조를 가진다.
- 분산형 구조를 통해 데이터를 여러 대의 서버에 저장하고
분산 시에 데이터를 상호 복제해 특정 서버에 장애가 발생하여도 데이터의 유실이나 서비스 중지가 없다.
- 테이블의 스키마가 유동적이다. / 스키마 변경 시 리스크가 크지 않다.
- ID로 사용하는 키 부분에만 타입이 동일하고,
mandatory(생략되지 않는) 필드로 지정하면 값에 해당하는 칼럼은 어떤 타입이든,
어떤 이름이 오든 허용됨
- 분산 시스템의 특징을 그대로 반영하며 CAP 이론을 따른다.
NOSQL 종류
Key/Value Store
- 대부분의 NoSQL은 Key/Value 개념을 지원
- Unique Key에 하나의 Value를 가지고 있는 형태
- put(key, value), value := get(key) 형태 API 사용
- ex ) Redis
Ordered Key/Value Store
- 데이터가 내부적으로 Key를 순서로 Sorting 되어 저장됨
- Key 안에 (column:value) 조합으로 된 여러 개의 필드를 가지는 구조
- 대표 제품 : Hbase, Cassandra
Document Key/Value Store
- Key/Value Store의 확장 형태
- 저장되는 Value의 데이터 타입으로 "Document"라는 구조화된 데이터 타입
JSON, XML, YAML 등 을 사용
- 복잡한 계층구조 표현 가능
- 제품에 따라 추가 기능 (Sorting, Join, Grouping) 지원
NoSQL System List
- Key-Value Stores
- Oracle Coherence
- Redis
- Kyoto Cabinet
- BigTable-style Databases
- Apache Hbase
- Apache Cassandra
- Docuement Databases
- Full Text Search Engines
- Apache Lucene
- Apache Solr
- Graph Database
NoSQL 장단점
Relational modeling
- 전형적으로 가용한 데이터 구조에 기반
- 내가 가지고 있는 답이 무엇인가? / What answer do i have?
- 데이터 모델 정의 후, 애플리케이션에 맞는 쿼리 개발
- RDBMS 모델링 기법
- 저장하고자 하는 도메인 모델 분석
- 개체 간의 관계 (Relationship) 식별
- 테이블 추출
- 테이블을 이용한 쿼리 구현
NoSQL data modeling
- 애플리케이션 특징적인 데이터 접근 패턴에 따라 모델링
- 내가 가지고 있는 질문은 무엇인가? What questions do i have?
- 애플리케이션의 필요한 쿼리와 성능을 정의한 이후, 요구 사항에 부합하도록 데이터 모델을 구성
- NoSQL 데이터 모델링 기법
- 도메인 모델 분석
- 쿼리 결과 도출
- 테이블(데이터 저장 모델) 설계
NoSQL 모델링 특징
- 관계형 데이터베이스 모델링보다 더 깊은 데이터 구조 및 접근 알고리즘에 대한 이해 필요
- NoSQL 쿼리가 실제 몇 개의 물리 노드에 거쳐 수행되는지에 대한 이해가 있어야 제대로 된 쿼리 디자인 가능
- NoSQL 디자인은 DB와 애플리케이션뿐만 아니라 인프라 (네트워크, 디스크)에 대한 디자인을 함께 해야 함
- 대부분의 NoSQL DB는 인증이나 인가 체계가 없어 보안에 매우 취약하기 때문에 별도의 보안 체계를 마련해야 함
방화벽이나 Reverse Proxy 등
RDBMS 장점
- 범용적이며 고성능
- 대부분의 경우 관계형 데이터베이스를 사용하는 것이 안정적
- 데이터의 일관성 보증 ( 트랜잭션 )
- 한 번에 이뤄져야 하는 작업의 경우 데이터 불일치 상황 방지
- 정규화를 전제로 하고 있기 때문에 업데이트 시 비용이 적다 ( 동일 칼럼은 동일 장소에 존재 )
- 데이터베이스 설계 시 이미 불필요한 중복이 삭제됨
- 복잡한 형태의 쿼리 가능 ( join )
- 이미 성숙한 기술
RDBMS 단점
- 대량의 데이터 입력 처리
- 테이블 인덱스 생성 및 스키마 변경
- 개발,운영 시 칼럼을 확정 짓기 어려운 경우
NoSQL 장점
- 특정용도로 특정화되어 있다.
- 각 NoSQL의 솔루션의 특징을 알 필요가 있다.
- 데이터 분산에 용이
- 기본적으로 join 연산은 대부분 불가능하다.
- 데이터 모델 자체가 독립적으로 설계되어 있어 데이터를 여러 서버에 분산시키는 것이 용이
- 데이터에 대한 캐시가 필요한 경우
- 배열 형식의 데이터를 고속으로 처리할 필요가 있는 경우
- 모든 데이터를 저장하고 싶은 경우
NoSQL 단점
- 각 솔루션의 특징을 이해할 필요가 있음
- 아직 새로운 기술로 운영 노하우가 적음
- 버그가 상대적으로 많이 있는 상태
- 업체마다 고유의 특색을 살린 NoSQL을 개발해 공개하는 경우가 많아 새로운 솔루션이 계속 출시되는 상태