3. NoSQL

Key 와 Value의 형태로 자료를 저장하고, 빠르게 조회할 수 있는 자료 구조를 제공하는 저장소
Join 연산 기능은 지원하지 않지만 대용량 데이터와 대규모 확장성을 제공

가.구글 빅테이블

빅테이블은 데이터 서비스가 아닌 구글 내부에서 사용하는 데이터 저장소
구글은 AppEngine 이라는 플랫폼 서비스를 2008년 오픈. AppEngine 에서 사용하는 데이터 저장소가 빅테이블이다.

- 데이터 모델
multi-dimension sorted hash map을 파티션하여 분산 저장하는 저장소
테이블 내의 모든 데이터는 row-key의 사전적 순서로 정렬.저장된다.
row는 n개의 column-family를 가질 수 있으며 column-family 내에 저장된 데이터는 column-key의 사전적 순서로 정렬돼 있다. 동일한 column-key에 대해 타임스탬프(timestamp)가 다른 여러 버전의 값이 존재할 수 있다. 따라서 BigTable에 저장되는 하나의 데이터(map)의 키 값 또는 정렬 기준은 "rowkey + columnkey+ timestamp"가 된다.
테이블의 파티션은 row-key를 이요하며, 분리된 파티션은 분산되 노드에서 서비스하도록 한다. 분리된 파티션을 Tablet이라 하며, 한 Tablet의 크기는 보통 100~200MB이다.

-페일오버
특정 노드에 장애가 발생할 경우 빅테이블 마스터(Master)는 장애가 발생한 노드에서 서비스되던 Tablet을 다른 노드로 재할당식킨다. 재할당 받은 노드는 구글 파일 시스템(GFS)에 저장된 변경 로그 파일, 인덱스 파일, 데이터 파일 등을 이용해 데이터 서비스를 위한 초기화 작업을 후행한 후 데이터 서비스를 한다.
빅테이블은 데이터베이스 클러스터 분류로 나누자면 공유 디스트(Shared Disk)방식이다.
공유 저장소로 구글에서 개발된 분산 파일시스템을 이용하고 있어 모든 노드가 데이터, 인덱스 파일을 공유하고 있다.
빅테이블의 SPOF(Single Point Of Failure)는 마스터다. 빅테이블은 분산 락(lock) 서비스를 제공하는 Chubby를 이요해 Master 르르 계속 모니터링하다가 마스터에 장애가 발생하면 가용한 노드에 마스터 역할을 수행하도록 한다. Chubby는 자체적으로 폴트롤러런스 지원 구조이기 때문에 절대로 장애가 발생하지 않는다.

____________________________________________________________________________

빅테이블은 그림에서 보는 것처럼 데이터 저장소를 위해 별도의 클러스터를 구성하기보다는 파일시스템, Map & Reduce 컴퓨팅 클러스터와 동일한 클러스터 위에 구성된다. 실시간 서비스뿐만 아니라 대용량 데이터의 분석 처리에 적합하도록 구성됐다.

- AppEngine 내에서 운영되 애플리케이션의 데이터 저장소를 제공
내부적으로는 빅테이블을 이용
사용자에게 직접 빅테이블의 API를 공개하지 않고 추상 계층을 두고 있는데, API에 대한 추상화뿐만 아니라 데이터 모델에 대해서도 추상화되어 있다.
사용자 테이블을 생성할 경우 빅테이블의 테이블로 생성되는 것이 아니라 빅테이블의 특정 테이블의 한 영역만을 차지하게 된다. 빅테이블에서는 별도의 사용자 정의 인텍스를 제공하지 않는 반면, AppEngine에서는 사용자가 수행하는 쿼리(query)를 분석하여 자동으로 인텍스(index)를 생성해준다. AppEngin에서 생성한 인텍스도 빅테이블의 특정 테이블 또는 테이블 내의 컬럼(column)ㅇ로 저장된다(구글에서는 AppEngine에 대한 자세한 내용을 공개하지 않아서 AppEngine의 API와 빅테이블의 구조 등을 참조해 추론한 내용임).
빅테이블은 Personsalized Search, Google Analytics, Crawl, News recommend 등 2006년 기준으로 60개 이상의 프로젝트에서 사용되고 있다. 이들 시스템의 공통된 특징은 수백 테라바이트(Tera Byte)에서 수 페타바이트(Peta Byte) 규모의 데이터를 다루고 있으며, 실시간으로 데이터를 저장하거나 조회하고, 주기적인 배치 작업을 통해 데이터를 분석하고, 분석된 결과를 다시 실시간으로 서비스하는 패턴을 갖고있다.

나. 아마존 SimpleDB
SimpleDB는 아마존(Amazon)의 데이터 서비스 플랫폼, SimpleDB는 웹 애플리케이션에서 사용하는 데이터의 실시간 처리를 지원한다.

___________________________________________________________

그림에서와 같이 SimpleDB는 주로 아마존의 다른 플랫폼 서비스와 같이 사용된다. EC2, S3 등과 같은 아마존의 내부 서비스 간 네트워크 트래픽은 무료이고, 외부와의 In/Out 트래픽에는 요금을 부과하는 아마존 서비스의 가격 정책 때문이다. 사용자는 EC2에서 수행되는 웹 서버로 접근하고, 웹 서버에서 SimpleDB의 데이터를 조회해 적절하게 가공한 후 사용자에게 제공하는 혀태로 구성된다. 비용을 염두에 두지 않은 경우라면 외부에서 직접 SimpleDB에 접근해 사용하는 것도 가능하다.
SimpleDB는 하나의 데이터에 대해 여러 개의 복제본을 유지하는 방식으로 가용성을 높인다. 이 경우 복제본 간의 consistency는 트랜잭션 종료 후 데이터는 모든 노드에 즉시 반영되지 않고 초 단위로 지연되어 동기화된다.
SimpleDB는 관계형 데이터 모델과 표준 SQL을 지원하지 않으며, 전용 쿼리 언어를 이용하여 데이터를 조회한다. SimpleDB의 데이터 모델은 Domain, Item, Attribute, Value로 구성되며 스키마(schema)가 없는 구조다.

- 도메인
관계형 데이터베이스의 테이블과 동일한 개념으로 하나의 도메인(Domain)에는 최대 10GB의 데이터를 저장할 수 있으며, 사용자는 100개의 도메인을 가질수 있다. 사용자는 최대 1,000GB의 데이터를 SimpleDB에 저장할 수 있다.

-Items
관계형 데이터베이스의 레코드(record)와 동일한 개념인 item은 독립적인 객체를 나타내며, 하나 이상ㅇ의 Attribute를 가진다. 한 item은 최대 256개의 Attribute를 가질 수 있다.

-Attribute
관계형 데이터베이스의 컬럼(column)과 동일한 개념이지만 사용하기 전에 미리 정의할 필요가 없다. Name, Value 쌍으로 데이터를 저장하고, 저장되는 데이터의 Name이 attribute의 이름이 된다. item의 특정 Attribute(Cell)에는 여러 개의 값을 저장할 수 있다.

여러 도메인에 걸치 쿼리는 허용되지 않으며, 한 번에 하나의 도메인에 대해서만 쿼리를 수행해야 한다.
이 경우 1+N(mast-slave)관계의 데이터 모델을 갖는 두 개의 도메인으로부터 데이터를 조회할 경우 쿼리가 여러 번 수행돼야 하는 단점이 있다. 이것은 SimpleDB만의 문제가 아니라 대부분의 데이터 서비스에서 갖는 문제다.

SimpleDB가 어떻게 인덱스를 관리하지에 대한 공식 문서는 없지만, 제공 쿼리를 이용해 추측하면 모든 arrtibute에 대해 bitmap index를 구성하는 것으로 보인다. 이 경우 고르게 분포된 데이터에 대한 "=" 연산에 대해서는 빠른 쿼리를 수행할 수 있지만">", "<" 연산이나 value에 특정 데이터가 많으면 쿼리 성능이 좋지 않다.

클라이언트는 SOAP또는 REST프로토콜을 이용하여 SimpleDB를 이용할 수 있으며, 다음과 같음 API를 제공한다.
-CreateDomain:도메인을 생성한다.
-DeleteDomain:도메인을 삭제한다.
-ListDomains:모든 도메인의 목록을 가져온다.
-PutAttributes: Item을 생성하고 Attribute에 값을 추가한다.
-DeleteAttributes:Attribute 값을 삭제한다.
-GetAttributes: Attribute의 값을 조회한다.
-Query: 쿼리를 이용하여 조건에 맞는 여러 개의 item을 조회한다. 한 번의 쿼리는 최대 5초 이내에 수행되어야(5초가 넘으면 timeout 발생) 하며, 쿼리 결과로 받을 수 있는 최대 item 수는 256개다.

다. 마이크로소프트 SSDS
SSDS(SQL Server Data Service)는 마이크로소프트에서 2008년 4월에  베타 서비스를 실시한 데이터 서비스다. 다른 데이터 서비스와 동일하게 SSDS 역시 고가용성을 보장한다.
SSDS의 데이터 모델은 컨테이너, 엔티티로 구성돼 있다. 컨테이너는 테이블과 유사한 개념이지만 하나의 컨테이너에 여러 종류의 엔티티를 저장할 수 있다. 예를 들어 Order entitiy와 OrderDetail entitiy를 하나의 컨테이너에 여러 종류의 엔티티를 저장할 수 있다. 예를 들어 Order entity와 OrderDetail entitiy를 하나의 컨테이너에 저장할 수 있다. 엔티티는 레코드와 유사한 개념으로, 하나의 엔티티는 여러 개의 property를 가질 수 있으며, property는 name-value 쌍으로 저장된다.
SSDS를 이용하여 애플리케이션을 개발하면 관련된 정보를 하나의 컨테이너에 저장한다. 관계형 데이터베이스에서는 엔티티를 구분하고 엔티티별로 테이블을 생성하는 것이 일반적이다. 예를 들어 CustomerA의 주문 정보(Order)와 주문 상세 정보(OrderDetail)를 저장하기 위해 Order 테이블과 OrderDetail 테이블을 생성한다. 하지만 SSDS에서는 CustomerA라는 Container를 만들고 Order와 OrderDetail entitiy를 생성한 컨테이너에 모두 저장한다. 즉, CustomerId가 파티셔닝 키가 되고 파티셔닝 대상은 컨테이너가 된다.
이런 방식으로 컨테이너를 구성하면, 많은 컨테이너가 생성되는 데 이들 컨테이너는 여러 노드에 분산.관리된다. 쿼리는 하나의 컨테이너만을 대상으로 한다.
컨테이너의 생성/삭제, 엔티티의 생성/삭제.조회, 쿼리 등의 API를 제공하고 SOAP/REST기반의 프로토콜을 지원한다.