제 블로그의 모든 글은 IMHO로 쓴 것입니다. 서로에 대한 존중을 담은 덧글을 남겨 소통을 하신다면 더 좋은 글로 발전이 될 수 있을 것 같습니다. 존중이 담기지 않은 덧글은 언제든 삭제될 수 있습니다. 감사합니다:)
—
NoSQL이란?
- nosql은 기본적으로
Not-only SQL의 약자이다. - 즉 RDMS형태가 아닌 디비는 전부 NoSQL이다.
용어가 처음으로 등장한 것은 1998년 카를로 스트로찌(Carlo Strozzi)라는 엔지니어가 공개한 표준 SQL인터페이스를 채용하지 않은 자신의 경량 Open Source 관계형 데이터베이스를 NoSQL이라고 명명한 데서 유래했다고 합니다.
이후 2009년에는 요한 오스칼손(Johan Oskarsson)이라는 엔지니어가 Open Source기반의 분산데이터베이스 관련 행사를 준비하며 NoSQL이라는 용어를 사용했다고 합니다.
이때부터 기존의 관계형 데이터베이스 시스템의 주요 특성을 보장하는 ACID(Atomic, Consistency, Integrity, Duarabity)특성을 제공하지 않는, 그렇지만 뛰어난 확장성이나 성능 등의 특성을 갖는 수많은 비관계형, 분산 데이터 베이스들이 등장했고, 이때부터 NoSQL이라는 용어가 보편적으로 사용되었습니다.
NoSQL이 등장한 이후에도 시장에서는 관계형 데이터베이스가 데이터를 처리하는 데 가장 최적의 시스템으로 받아들이고 있었습니다. 특히 기업의 ERP나, MIS시스템 등 데이터의 정확한 처리가 필수적인 시스템에서는 현재도 관계형 데이터베이스(RDB)를 사용하고 있습니다
NoSQL의 특징
그럼에도 불구하고 NoSQL은 기존 RDBMS에 비해 몇 가지 공통된 특징을 가지고 있다. 이를 정리하면 다음과 같다.
-
NoSQL은 RDBMS와는 달리 데이터 간의 관계를 정의하지 않는다
가장 큰 특징 중의 하나는 관계형 데이터베이스인 RDBMS가 데이터의 관계를 Foreign Key 등으로 정의하고 이를 이용해 Join 등의 관계형 연산을 한다고 하면, NoSQL은 데이터 간의 관계를 정의하지 않는다. 데이터 테이블은 그냥 하나의 테이블이며 각 테이블 간의 관계를 정의하지도 않고 일반적으로 테이블 간의 Join도 불가능하다. -
RDBMS에 비해 훨씬 더 대용량의 데이터를 저장할 수 있다
RDBMS의 복잡도와 용량 한계를 극복하기 위한 목적으로 등장한 만큼, 페타바이트급의 대용량 데이터를 저장할 수 있다. -
분산형 구조
NoSQL은 기존의 RDBMS와는 다르게 하나의 고성능 머신에 데이터를 저장하는 것이 아니라, 일반적인 서버(인텔 계열의 CPU를 사용하는 Commodity Server) 수십 대를 연결해 데이터를 저장 및 처리하는 구조를 갖는다. 즉 분산형 구조를 통해 데이터를 여러 대의 서버에 분산해 저장하고, 분산 시에 데이터를 상호 복제해 특정 서버에 장애가 발생했을 때에도 데이터 유실이나 서비스 중지가 없는 형태의 구조다. -
고정되지 않은 테이블 스키마
RDBMS와는 다르게 테이블의 스키마가 유동적이다. 예를 들어 RDBMS의 경우 테이블이 <표 1>과 같은 형태로 되어 있을 때 해당 테이블은 반드시 숫자, 이름 문자열, 주소 문자열만 들어갈 수 있다.
그런데 NoSQL은 대부분 이런 개념이 없다. ID로 사용하는 키 부분에만 타입이 동일하고, mandatory(생략되지 않는) 필드로 지정하면 값에 해당하는 컬럼은 어떤 타입이든, 어떤 이름이 오든 허용된다. 즉 <표 2>와 같이 ID 필드는 공통이지만, 데이터를 저장하는 컬럼은 각기 다른 이름과 다른 데이터 타입을 갖는 것이 허용된다.
CAP이론과 왜 두가지는 만족 하지 못할까?
P는 네트워크 장애가 있을 수 있다는 것을 인정하느냐의 문제이고 이는 인정 할 수밖에 없는 문제이므로 처음부터 선택되어있는 것이다.
결국, CAP Theorem이 내포하고 있는 의미는 분산시스템에서 네트 워크 장애상황일 때 일관성과 가용성 중 많아도 하나만 선택할 수 있다 는 것이다.
하지만 이런 식의 해석은 정상 상황일 때의 분산시스템 동작을 서술해 주지 못한다. 이에 대해 Daniel Abadi가 PACELC라는 아주 우아한 표기법을 제시하였다.
PACELC
- Partition 상황일 경우 A/C 둘 중 하나를 선택한다. 네트워크 단절이 일어나 몇 개의 노드에 접근 할 수 없을 때 C를 위해 데이터 반영이 아예 실패하던지 C를 포기하고 일단 접근 가능한 노드들이게 만 데이터를 반영하던지 둘 중의 하나만 골라야 한다
- 정상상황일 때에는 L과 C는 상충하며 둘 중 하나를 선택해야 한다. 모든 노드들에 새로운 데이터 를 반영하는 것은 상대적으로 긴 응답시간이 필요하기 때문이다.
PACELC에 따른 DB
- HBase는 PC/EC이다. 장애 상황일때 C를 위해 A를 희생한다. 그렇지 않은 경우에도 C를 위해 L을 희생한다.
- Cassandra는 PA/EL이 가능하도록 디자인 되었다. 설정에 따라 Eventual Consistency의 특성을 가지게 되는데, 이 경우 PA/EL이 된다. 장애 상황인 경우 에는 가능한 노드에만 데이터를 반영하고 정상으로 복구되면 필요한 노드에 데이터 를 모두 반영한다. 정상상황일때도 Latency를 위해 모든 노드에 데이터를 반영하 지 않는다.
- Brewer가 제시한 가상의 분산시스템은 PA/EC이다. 정상적인 경우에는 모든 노 드에서 같은 메세지를 볼 수 있도록 쓰기 연산이 일어나는데 P 상황인 경우, 이를 판단하여 일단 접근 가능한 만큼만 데이터를 반영한다 결과적으로 시스템은 디운되 지 않지만 절단된 노드들 끼리는 데이터를 주고 받지 못하게 된다. 장애상황이 복구 되면 이를 감지하여 전달하지 못한 데이터를 반영한다. 장애상황일때에만 C를 포 기하고 보통의 상황에서는 강력한 C를 가져가는 것이다.
참조 PACELC: http://eincs.com/2013/07/misleading-and-truth-of-cap-theorem/ CAP theorem 관련 강의 https://www.youtube.com/watch?v=hUd_9FENShA Hbase vs Cassandra https://brocess.tistory.com/115