[DBMS/분산파일처리] NoSQL

RDBMS 한계 극복, No SQL 개요

구분	내용
개념	RDBMS의 한계를 극복하고, 비정형 데이터를 효율적으로 처리할 수 있는 구조를 가진 분산 DBMS
특징	- 여러 유형의 DB 사용 - 대용량 데이터 처리 - 비 관계형 모델

 

NoSQL 품질속성 이론

가. CAP 이론

구분	내용
배경	- CAP 이론에서는 분산 데이터베이스 시스템은 네트워크 파티션이 발생했을 때 세 가지 중 두 가지만 만족할 수 있음 (장애가 생겨서 서버끼리 통신이 끊기면, 일관성(C)과 가용성(A)을 동시에 완벽하게 지키기 어렵다) * C(Consistency, 일관성), A(Availability, 가용성), P(Partition Tolerance, 분할 허용성) - CAP 이론에서는 네트워크 파티션 상황을 가정하므로 CA는 있을 수 없고 CP와 AP만 만족할 수 있는데 완벽한 CP 시스템이나 AP 시스템은 사실상 쓸모가 없음 * 장애 시 일관성을 더 지킬까? → CP 쪽, 장애 시 응답을 더 유지할까? → AP
시스템	* 완벽한 CP 시스템: - 완벽한 일관성을 갖는 분산 데이터베이스 시스템에서는 하나의 트랜잭션이 다른 모든 노드에 복제된 후 완료 가능 - 하나의 노드라도 문제가 발생하면 장애를 처리하지 않은 채 트랜잭션은 실패하고, 노드가 늘어날수록 지연시간은 길어짐 (정확한 잔액이 응답보다 더욱 중요한 은행시스템 등) * 완벽한 AP 시스템: - 완벽한 가용성을 갖는 분산 데이터베이스 시스템은 모든 노드가 어떤 상황에서도 응답할 수 있어야 함 - 하나의 노드가 문제가 발생한 경우 해당 노드가 가지고 있던 데이터는 응답이 지연되지만 응답한다면 완벽한 가용성을 가지게 됨. 하지만 이로 인해 연결된 사용자는 문제를 인지 못해 계속 요청을 보내게 됨 (끊김 없는 서비스 지속형 시스템 등)
한계	- 일관성과 가용성은 상충 관계이지만 둘 중 하나만 선택해야 하는 것은 아님 - 완벽한 CP 시스템과 완벽한 AP 시스템 사이에 있어 요구사항에 따라 "다소 강한 일관성-다소 약한 가용성", "다소 약한 일관성-다소 강한 가용성" 등 다양한 수준을 선택할 수 있음
보충	- CAP 이론은 파티션이 없는 상황을 설명하지 못함 - 파티션이 없는 상황에서도 분산 시스템은 성능 특성이 있고, 장애 상황만큼 정상 상황에서 시스템이 어떻게 동작하는지도 중요함

나. PECELC 이론

구분	상황	설명
개념	-	CAP 이론의 단점을 보완하기 위해 네트워크 장애 상황과 정상 상황으로 나누어서 설명하는 이론
세부 설명	파티션 (네트워크장애) 상황	A와 C는 상충하며 둘 중 하나를 선택해야 함 (네트워크 단절이 일어나 몇 개의 노드에 접근할 수 없을 때 C를 위해 데이터 반영이 아예 실패하든지, 다른 접근 가능한 노드들에게만 데이터를 반영하든지 둘 중 하나만 선택해야 함)
	정상상황	L과 C는 상충하며 둘 중 하나를 선택해야 함 *L(지연시간, 응답속도)과 C(일관성) (모든 노드들에 새로운 데이터를 반영하는 것은 상대적으로 긴 응답시간이 필요하기 때문임)

[PECELC 이론에 따른 NoSQL 분류]

분류	설명	NoSQL
PC/EC	- 장애 상황(P)일 때 일관성(C)을 위해 가용성(A)를 희생 - 정상 상황(E)일 때 일관성(C)를 위해 응답속도(L)을 희생	HBase, VoltDB, Megastore
PA/EL	- 장애 상황(P)일 때 가용성(A) 우선 (가능한 노드에 우선 응답을 유지) - 정상 상황(E)일 때 L(응답속도) 우선 (응답속도를 위해 모든 노드에 즉시 반영하지 않을 수 있음)	Cassandra, Dynamo
PA/EC	- 장애 상황일 때는 일관성(C)보다 가용성(A) 우선 (접근 가능한 만큼만 데이터를 반영) - 정상 상황일 때는 강한 일관성(C) 반영 (장애 상황이 복구되면 전달하지 못한 데이터를 반영)	MongoDB
PC/EL	- 장애 상황일 때는 일관성(C)을 위해 가용성(A)를 희생 - 정상 상황일 때는 응답속도(L)를 위해 일관성(C)을 일부 희생 (평소만큼의 C를 보장하기 위해 A를 희생하고, 장애상황일 때도 정상상황 때와 같은 Consistency Level을 보장하기 위해 요청 자체를 실패시킬 수 있음)	PNUTS

 

NoSQL 유형

유형	설명
Key-value 기반	(키 하나, 값 하나로 저장하는 방식. 빠르고 단순하고 대용량 처리에 좋지만 복잡한 관계표현엔 약함) - 데이터를 Key와 Value를 짝으로 저장하는 NoSQL DB의 가장 기본적인 데이터베이스 유형 - 많은 양의 Data를 분산 처리할 수 있도록 설계 - 저장소에는 각 Key가 고유한 Hash table - Value에는 Json, BLOB(Binary large objects), String 값이 될 수 있음
Column 기반	(행전체보다 컬럼단위(열 중심)로 데이터관리를 중요하게 보는 방식. 대량 분석/조회에 강하고 조인에 약함) - Google의 BigTable paper를 기반으로 한 Column에서 작동하는 데이터베이스 - 컬럼명을 Columns 속성에 데이터를 저장하고, Value 속성에는 해당 컬럼의 값 저장 - 유연성 극대화 - 단점은 테이블과 조인이 안 됨, 조인이 필요한 데이터는 하나의 테이블에 중복으로 관리하여 처리 속도 향상
Document 기반	(JSON문서 한장으로 필요정보 묶어서 저장하는 방식. 구조유연/개발자편하지만 복잡한 관계표현엔 약함) - 데이터를 key/value pair로 저장하지만, value 부분에 문서(json, xml 포맷 등)가 저장되는 데이터베이스 - 관계형 데이터베이스의 경우 보유한 열과 기반을 알아야 하지만, 문서 기반 데이터베이스는 저장소에 JSON object가 있어 별도로 찾지 않아도 됨
Graph 기반	(데이터 자체보다 관계를 중요하게 보는 방식. 관계탐색 빠르나 단순데이터저장엔 과함) - Entities와 Entities 간의 관계(relations)를 저장하는 데이터베이스 유형 - 테이블이 느슨하게 연결된 RDBMS와 비교할 때, Graph 기반 DB는 본질적으로 관계 탐색에 유리함 - 모든 Node(Vertex)와 Edge에 고유 식별자가 부여

 

NoSQL의 설계 패턴

모델	패턴설명	특징
Denormalization (비정규화)	- 같은 데이터를 중복해서 저장하는 방식 - 중복해서 정보를 저장하여 Join을 없애고 한번의 I/O로 조회를 할 수 있는 패턴 (NoSQL은 조인이 약한경우가 많아서 조회할때 한번에 읽히게 만드는게 중요하므로, 나눠저장하지말고 자주보는건 한번에 일부러 넣어 중복저장)	- 데이터 중복 저장 - RDBMS의 역정규화와 비슷
Aggregation	- Row의 Key만 똑같다면 각각의 Row들이 꼭 같은 컬럼을 가질 필요도 없고, 데이터 타입도 모두 다르게 구성하는 패턴 (관련데이터를 한덩어리로 묶어 저장하는 패턴. 데이터를 정규화해서 잘게 나누기보다 조회에 필요한 속성들을 하나의 묶음으로 관리, 그 과정에서 Row마다 컬럼 구성이 달라도 허용)	유연한 스키마(Schema-less)
Application Side Join (응용프로그램결합조인)	- Join기능이 필요할 경우 Client Application단에서 Join로직을 처리해주는 패턴 (DB가 못 하는 조인을 프로그램이 대신해서 직접 데이터를 합치는 방식)	Client 단 Join 처리
Atomic Aggregate (일관성 보장 모델)	- 일관성을 보장하기 위하여 테이블을 하나로 통합하는 방법 (일관성이 중요한 데이터는 가능하면 한 번에 같이 저장/수정되게 한 덩어리로 두는 방식)	한 테이블로 통합
Index Table (단일 인덱스 모델)	- NoSQL에서는 인덱스가 지원되지 않으므로 별도로 인덱스 테이블을 만드는 방법 (검색 성능이 부족하면 찾기 쉽게 별도 인덱스용 테이블을 만드는 방식)	인덱스 생성
Composite Key Table (복합 키 인덱스 모델)	- 단일 인덱스 모델에서 복합 인덱스가 필요할 경우 복합 키 인덱스 모델로 구성하는 방법 (검색 조건이 여러 개면 복합 조건 검색용으로 복합 키를 만들어 저장. 즉, 두세 가지 조건을 한 번에 찾기 쉽게 키를 합쳐두는 것)	복합 인덱스 생성

 

NoSQL  절차

절차	설명
1. 도메인 모델 파악	- 먼저 저장하고자 하는 도메인을 파악 - 어떤 데이터 개체가 있는지 개체간의 관계는 어떻게 되는지 등을 분석하고 ERD를 그려서 도식화 ** 데이터 관계를 먼저 정확히 나누고 중복없이 처리하는게 우선인 RDBMS와 달리 조인이 약하거나 없으므로 한번에 어떻게 읽을지 조회 방식에 맞게 데이터를 묶어서 저장하는 것이 더 중요
2. 쿼리결과디자인	- “도메인 모델” 기반으로 애플리케이션에 의해서 쿼리의 결과를 정하며 데이터 출력 내용을 디자인 (화면에서 뭘 보여줄지, API가 어떤결과를 줄지 등 어떻게 볼건지 먼저 설계)
3. 패턴을 이용한 데이터 모델링	RDBMS 기능을 제공하지 않기 때문에 이를 배제하고 Put/Get으로만 데이터를 가지고 올 수 있는 형태로 데이터 모델, NoSQL내의 테이블로 재정의 (RDBMS처럼 조인 기능에 기대기 어렵기 때문에 한 번에 읽기 좋은 구조로 데이터 모양을 바꾸는 단계. 즉, 조인 대신 저장 구조를 바꾸는 것)
4. 기능 최적화	RDBMS의 Index와 같은 개념을 NoSQL에서 ‘Secondary Index’를 이용하여 기능의 최적화 (조회 속도를 높이기 위해 튜닝하는 단계)
5. 후보 NoSQL 선정 및 테스트	NoSQL에 대한 구조 및 특성을 분석한 후에 실제로 부하테스트, 안전성, 확장성 테스트를 거친 후에 가장 적절한 솔루션 선택 (NoSQL도 종류가 많음. 업무에 맞는 DB를 검증하는 단계)
6. 선정된 NoSQL의 데이터 모델 최적화 및 하드웨어 디자인	선정된 NoSQL을 기반으로 그에 적합한 데이터 모델 최적화 후 이에 맞는 애플리케이션 인터페이스 설계와 구동시킬 하드웨어 디자인 실시 (실제 운영환경에 맞게 데이터구조를 다듬고, 인터페이스 설계하고 서버구조 정하는 실전 배치 단계)