NOSQL의 특징과 최근 공개된 데이터 저장소의 데이터 분산이나 확장방법과, 정합성(Consistency) 혹은 가용성(Availability)을 어떻게 보장하는지 확인 및 클라우드 데이터 서비스에서는 이런 속성등이 어떻게 서비스 되는지 살펴봄
관계형 데이터 관리시스템은 ACID 속성에 집중해 데이터를 안전하게 저장하고 정합성을 보장하는데 주목적이 있음
최근 인터넷과 하드웨어 발전으로 인해 검색서비스, 소셜 네트워크 서비스, 데이터웨어하우징 같은 다양한 서비스가 출현
이런서비스들은 데이터에 대해 강한 수준의 정합성이나 견고성보다는 손쉬운 확장성, 시스템 확장과정이나 장애상황에서도 서비스를 유지할수 있는 고가용성, 낮은 비용 등을 요구함
이런 속성을 BASE로 표현하며 BASE에 맞는 새로운 데이터 관리시스템이 출현하게 됨
결국 확장성, 고가용성 제공해야 하지만 표준 SQL이나 엔터티 간의 관계을 지원하지 않는 데이터 관리 시스템이 등장하게 됐으며, 이런 데이터 관리시스템을 NoSQL이라고함
2000년대 접어들면서, 데이터는 급속도로 증가했으며, 글로벌하게 웹서비스를 제공하는 구글, 야후, 페이스북 등과 같은 업체에서 관계형 데이터베이스만으로는 서비스를 효율적으로 제공할수 없다는 것을 인식하고 서비스의 요구사항에 부합되는 데이터 저장소를 별개로 개발해 사용하기 시작함
관계형 데이터베이스는 그 자체적으로 대규모의 데이터를 저장하기 위해 스케일아웃 (Scale-out) 방식으로 확장하기 어려움
구글, 야후, 페이스북 같은 인터넷 서비스 업체들은 이들 서비스가 저장중인 대용량의 데이터는 고가의 솔루션에 저장할 수준의 고가용성을 요구하지 않은 경우가 많으며, 저가의 스토리지나 분산파일 시스템등을 이용함
수억~수십억건 이상의 데이터에 대해 조인(join)같은 연산이 불필요하며, 강한 데이터 정합성보다는 필요에 다라 데이터를 복제해서 안정적으로 보관하고, 장애상황에도 즉시 데이터를 조회할수 있는 저장소가 필요함
수십억건 이상의 데이터를 저장하고 있는 테이블에 대해 인덱스를 재구성, 칼럼의 추가등과 같은 작업은 시스템이 운영중인 상황에서는 현실적으로 불가능함
h3.CAP이론
분산환경에서 데이터 관리 시스템을 구성할 경우 CAP이라는 이론이 있음
* 정합성(Consistenecy) : 모든 클라이언트는 항상 동일한 데이터를 보장받는 속성
* 가용성(Availability) : 분산 시스템에서 가용성은 네트워크 단절 상황에서도 장애가 발생하지 않는 노드는 모든 요청에 대해 정해진 시간내에 응답을 해야 한다는 속성
* 단절내성(Partition Tolerance) : 네트워크가 단절된 상태에서도 시스템의 속성(정합성 이나 가용성)을 유지해야 한다는 속성
시스템이 단절내성을 갖으려면 노드 사이에 전송되는 메시지가 전달되지 않는 상황에서도 시스템에 제공하려는 정합성이나 가용성을 지원해야 함
분산환경에서는 네트워크상에 서버들이 분산배치되기 때문에 이 속성이 반드시 포함해야 하는 속성임
CAP이론은 "적절한 응답 시간 내의 세 가지 속성을 모두 만족시키는 분산 시스템을 구성할수 없다" 라고 정의한 이론
MySQL의 복제Replication 기반 마스터슬레이브 구성에 대해 CAP속성을 분석
MySQL의 마스터-슬레이브 구성에서 쓰기 연산은 그림 7.2에서와 같이 마스터 서버에서만 처리하고 읽기연산은 마스터와 슬레이브 모두에서 처리함
이런구성에서 마스터에 장애가 발생하면 쓰기연산에는 가용성을 지원하지 않고 분산구성도 아니기 때문에 일기 연사만 고려해봄
클라이언트에서 Insert , Delete , Update 같은 데이터의 수정연산은 MySQL의 마스터 서버로만 접속하고, 읽기연산은 슬레이브로만 접속한다고 가정함
* 정합성: 그림 7.2에서 네트워크가 정상적인 경우에 클라이언트는 슬레이브 1, 슬레이브 2 어떤서버에 접속하더라도 동일한 데이터를 읽을수있음, 따라서 데이터 정핪성을 만족함
* 가용성: 동일한 데이터가 여러개의 슬레이브 노드에 저장돼 있기 때문에 특정 슬레이브에 장애가 발생하더라도 클라이언트는 읽기 연산을 수행할 수 있다. 따라서 가용성을 만족시킨다.
* 단절내성: 그림 7.2와 같이 네트워크가 단절되면 클라이언트1, 클라이언트2 모두 데이터 조회가 가능함
하지만 네트워크가 단절된 이후 데이터 수정이 발생하면 슬레이브 1 과 슬레이브 2의 데이터가 다른 버전을 갖게 돼
클라이언트1 , 클라이언트2에서 조회하는 데이터가 다를수 있다.
네트워크 상태에서 데이터 정합성을 만족시킬수 없음
따라서 MySQL의 마스터-슬레이브 구성에서
관계형 데이터베이스는 정합성과 가용성에 초점이 맞춰져 있음
h3.NoSQL의 특징과 구분
NoSQL의 범주로 분류 하는 기준
| 데이터모델 | 설명 |
|---|---|
| 키-값 모델 | 가장 단순한 데이터 모델로, 키와 바이너리 타입의 값을 저장하는 구조 |
| 칼럼 모델 | 데이터는 칼럼에 저장되며 테이블, 칼럼등과 같이 스키마가 존재하는 모델 |
| 문서 모델 | 데이터의 저장 단위가 문서가 되면, 하나의 문서내에는 여러 개의 필드와 필드에 대응하는 값이 존재함 |
| 그래프모델 | 그래프에 있는 노드(node) 와 엣지 (Edge)를 저장하고 이를 쉽게 내비게이션할 수 있는 모델 |
NoSQL 솔루션 분류
| 데이터모델 | 솔루션 |
|---|---|
| 키-값 | memcached, Dynamo, Volemort , Tykyo Cabiner, Redis |
| 칼럼 | Google Bigtable , Cloudata, HBase , Hypertable , Cassandra |
| 문서 | MongoDb , CouchDB |
| 그래프 | Neo4j, FlockDB, InfiniteGraph |
h4.NoSQL의 특징, 분류
데이터를 여러 서버에 배치하는 경우 데이터 분산을 어떻게 하느냐에 따라 크게 메타데이터 방식, P2P방식으로 분류
* 메타데이터 방식 : 데이터의 배치정보가 중앙집중적인 데이터 서버나 마스터 서버에 저장돼 있으며, 클라이언트는 데이터연산을 위해
메타데이터나 서버를 경유해 실제데이터를 처리할 서버로 접속하는 방식
- 장점: 데이터 배치에 대한 정보를 중앙에서 관리하기 때문에, 관리하기 편하며 맵리듀스 등가 결합하기 쉬움
- 단점: 데이터를 관리하는 서버나 관리 데이터에 문제가 발생하면 전체 데이터에 접근할수 없다는 점
예) 빅테이블(Bigtable) , 몽고DB(MongoDB) 등이 이런방식 사용
* P2P방식 : 별도의 메타 정보가 없으며, 해시함수를 이용해 특정 키를 서비스하는 서버를 찾는방식
- 장점: 메타 정보나 이를 관리하는 서버가 없기때문에, 장애가 지역적인 키 영역에만 나타남
- 단점: 저장된 데이터를 이용해 분석 작업을 하는 경우 메타데이터 방식보다 어려움
데이터 저장방식에 따른 분류
* 데이터 파일을 분산 파일 시스템에 저장하고 데이터 관리 시스템에서는 논리적인 관리만 담당하는 방식
- 데이터의 복제, 장애발생 시 복제본의 재생성 등은 분산파일 시스템 제공하는 기능을 이용
- 예) 빅테이블(big table) , 클라우데이터(Cloudata) , Hbase
* 데이터 관리시스템 자체적으로 데이터 파일을 저장하는 방식
- 데이터 관리 시스템 자체적으로 복제, 장애 시 복구등에 대한 기능을 모두 처리함
- 예) 빅테이블이나 빅테이블을 모방한 솔루션을 제외한 대부분의 솔루션이 이런 방식으로 구현돼 있음
NoSQL을 사용할때에는 구축하려는 시스템의 적합한 솔루션인지 판단하기 위해 다음 항목을 비교 검토해야함
대부분 분산 시스템으로 구성되기 때문에 데이터 모델뿐만 아니라 데이터 분산, 클러스터 맴버쉽, 장애대응 등 다양한 분산 이슈를 해결해야 하므로 구현 자체가 복잡한 경우가 많음
문서가 부족해 사용하기 어려움
NoSQL을 이해하려면 해당 오픈소스의 이론적 배경을 설명하는 논문등을 충분히 이해하고 접근하는것이 좋음
예) HBase는 빅테이블 논문 , 카산드라(Cassandra)는 다이나모(Dynamo)논문 등..
파티셔닝 범위, 서비스 서버 등과 같은 파티셔닝에 대한 정보는 하나의 루트 테블릿과 다수의 메타 테블릿에 저장
루트 테블릿을 서비스하는 서버의 정보는 zookeeper 와 같은 역할을 하는 chuby (distributed lock service)에 저장되며,
루트 테블릿에서 하나의 열에는 하나의 메타 tablet에 대한 정보 (tablet 이름, 최대 row key, 서버 정보)를 저장
메타 테블릿에서 하나의 열에는 사용자 테이블에 있는 하나의 테블릿에 대한 정보를 저장.
특정 row key를 서비스하는 사용자 테이블의 테블릿과 테블릿 서버를 찾기 위해 chuby -> 루트 테블릿 -> 메타 테블릿 순으로 찾는다.
하나의 빅테이블 클러스터는 하나의 마스터 서버와 다수의 테블릿 서버로 구성된다.
마스터 서버는 마타 정보 같이 클러스터 관리에 필요한 정보를 갖고 있지 않기 때문에 마스터 장애 시에도 데이터 서비스는 영향을 받지 않는다.
마스터 서버는 테블릿을 할당하거나, 테블릿 서버가 클러스터에 추가/제거되는 것을 감지하고, 테블릿 서버의 부하 분산과 구글 파일 시스템에 저장된 파일에 대한 가비지 컬렉션을 수행한다.
테블릿 서버는 테블릿을 관리하고 클라이언트로부터 데이터 읽기/쓰기 요청을 받아 처리하며,하나의 테블릿 서버는 수천 개까지 테블릿을 서비스하고, 하나 테블릿 크기는 100~200MB이다.
빅테이블은 구글파일 시스템, 맵리듀스, 처비 등과 같은 구글 내부의 분산 플랫폼 이용함
구글 파일시스템은
h2.HBase
HBase는 빅테이블과 동일한 기능과 확장성을 갖는 분산 데이터 관리를 목적으로 개발된 아파치 파운데이션의 오픈소스 프로젝트임
HBase도 데이터 파일 저장소로 하둡파일 시스템을 사용하고 클러스터 관리를 위해 주키퍼를 이용함
HBase 시스템 구성도
HBase는 아래의 3개로 구성됨
HBase 환경설정
$ cd $HBASE_HOME
vi conf/hdfs-env.sh
#항목 중 JAVA_HOME
export JAVA_HOME=/usr/java/default
export HBASE_MANAGES_ZK=false
실햄모드
* 단독모드(Standalone Mode): 데이터 저장소로 하둡 로컬파일 시스템을 이용함
즉, 하둡 파일 시스템을 실행할 필요가 없으며, 지금까지 설정된 내용에서 HBASE_MANAGES_ZK=ture로 설정해 실행하는 모드
주키퍼, 마스터 서버, 리전 서버가 하나의 서버에서 실행함
* 가상분산모드(Peseudo Distributed Mode): 단독모드와 유사하지만 데이터 파일을 하둡 파일시스템에 저장함
* 완전분산모드(Fully Distributed Mode): 모든 서버가 분산돼 실행되고, 주키퍼도 별도의 클러스터 구성을 사용함
단독모드와 가상분산모드는 테스트용으로만 사용함, 실제운영환경에서는 사용하지 않음
- 가상분산모드 설정 (conf/hbase-site.xml)
<property>
<name>hbase.rootdir</name>
<value>hdfs://localhost:9000/hbase</value>
<description>..</description>
</property>
<property>
<name>dfs.replication</name>
<value>1</value>
<description>..</description>
</property>
hbase.rootdir 설정값은 : 데이터 파일이 저장되는 하둡파일 시스템의 클러스터 정보와 디렉토리를 지정함
dfs.replication 설정값은: 리플리케이션 개수를 지정함 (완전분산 모드 이값을 3으로 설정)
- 완전분산모드 설정 (conf/hbase-site.xml)
<property>
<name>hbase.cluster.distributed</name>
<value>true</value>
<description>The mode the cluster will be in. Possible values are
false: standalone and pseudo-distributed setups with managed Zookeeper
true: fully-distributed with unmanaged Zookeeper Quorum (see hbase-env.sh)
</description>
</property>
<property>
<name>hbase.zookeeper.property.clientPort</name>
<value>2181</value>
<description>Property from ZooKeeper's config zoo.cfg.
The directory where the snapshot is stored.
</description>
</property>
<property>
<name>hbase.zookeeper.quorum</name>
<value>zk_server01,zk_server02,zk_server03</value>
<description>The directory shared by RegionServers.
</description>
</property>
server02
server03
server04
리젼서버의 목록은 클러스터 시작시 리젼서버에 ssh를 접속해 실행시키는 용도로만 사용하고 운영중인 클러스터에서는 사용하지 않음
환경모두 설정했으면 프로그램을 모든 리젼서버로 배포하고 bin/start-hbase.sh 명령을 실행
HBase는 CLI기반 쉘을 제공하며 실행가능한 명령표
http://wiki.apache.org/hadoop/Hbase/Shell
./bin/hbase shell
HBase Shell; enter 'help<RETURN>' for list of supported commands.
Type "exit<RETURN>" to leave the HBase Shell
Version 0.90.4, r1150278, Sun Jul 24 15:53:29 PDT 2011
이제 cf 컬럼 패밀리를 가진 test 테이블을 만듭니다.
hbase(main):001:0> create 'test', 'cf'
0 row(s) in 0.5790 seconds
이제 자료들을 삽입하겠습니다.
hbase(main):002:0> put 'test', 'row1', 'cf:a', 'value1'
0 row(s) in 0.2530 seconds
hbase(main):003:0> put 'test', 'row2', 'cf:b', 'value2'
0 row(s) in 0.0340 seconds
hbase(main):004:0> put 'test', 'row3', 'cf:c', 'value3'
0 row(s) in 0.0350 seconds
첫번째 삽입은 row에 value1을 값으로 가진 컬럼 cf:a을 삽입하는 것입니다. 컬럼들은 콜론을 기준으로 컬럼 패밀리 전치사 cf와 콜론 뒤의 컬럼 수식자 접미사 a식으로 구성되어 있습니다.
이제 스캔을 해봅시다.
scan 'test'
ROW COLUMN+CELL
row1 column=cf:a, timestamp=1316337980526, value=value1
row2 column=cf:b, timestamp=1316337990551, value=value2
row3 column=cf:c, timestamp=1316338000426, value=value3
3 row(s) in 0.1210 seconds
하나의 값을 가져오는 것은 아래와 같습니다.
get 'test', 'row1'
COLUMN CELL
cf:a timestamp=1316337980526, value=value1
1 row(s) in 0.0380 seconds
지우기 위해서는 disable과 drop을 합니다.
hbase(main):007:0> disable 'test'
0 row(s) in 2.0620 seconds
hbase(main):008:0> drop 'test'
0 row(s) in 1.1100 seconds
종료합시다.
HBase 클라이언트 API는
데이터 저장을 위해서는 Put객체를 이용함
데이터 조회하는 방법은 두가지가 있는데 Get 연산자과 Scan연산자임
HBase는 단순히 실시간 데이터 서비스만이 아니라 저장된 데이터를 맵리듀스와 같은 분산 병렬프레임워크를 활용해 분석할수 있는 기능을 제공
HBase는 리젼을 이용해 맵리듀스 작업에서 분산 처리되는 단위는 리젼임
코드예제) 클라우데이터에서 만든입력 테이블의 로우, 칼럼을 바꿔 다른 테이블에 저장하는 'Inverted Job'을 HBase용으로 구현
맵리듀스 실행을 위한 환경 설정부분은 기존의 맵리듀스 프로그램과 유사 하지만 대신 입/출력을 하둡파일시스템이 아닌 HBase테이블이용함
클라우데이터, HBase 모두 분산 파일 시스템 위에서 운영되는 데이터 저장 솔루션으로, 실시간 처리뿐만 아니라 저장된 데이터를
이용해 분석 작업을 처리하는데에 최적화 됐다고 할 수 있음
두 솔루션 모두 메모리에 임시로 데이터를 보관하고 분산 파일스시템으로 저장하는 개념이기 때문에
다음과 같은 상황에서는 성능이 저하되거나 병목현상이 발생할 가능성이 높으므로 이런상황을 고려해 시스템을 구성하고 튜닝해야함
h2.카산드라(Cassandra)
h3.다이나모(Dynamo)
다이나모의 설계원칙
다이나모는 데이터분산 배치를 위해 P2P(peer-to-peer) 분산기법을 이용함
다이나모는 DHT기법을 이용해 데이터를 파티셔닝함
DHT(Distributed Hash Table)
데이터와 서버를 동일한 주소 공간에 배치함으로써 데이터의 키 값과 분산환경에서의 서버 ID는 동일한 해시함수로 동이란 주소공간에
데이터와 노드를 배치함
DHT방식은 중앙집중적인 관리가 없어도 데이터를 관리하는 서버를 찾는 룩업에 성능이 좋으며
클러스터에 참여하는 서버의 추가와 제거가 자동으로 이뤄질 수 있게 구성할수 있음
하지만 해시함수를 이용한 유일한 키 값에 의존하기 때문에 복잡한 쿼리의 사용이 힘들다
(DHT 알고리즘으로는 Chord, CAN, Pastry, Tapestry 등이 있음 , 설명은 Chord로함)
DHT는 키 공간 분할(keyspace partition)과 오버레이 네트워크(overlay network)로 구성됨
- 키 공간 분할: 분산된 키를 어떻게 배치시킬 것인가를 결정하는 사항
데이터에 hash(key)값을 이용해서 키 영역을 파티셔닝시킴
- 오버레이: 네트워크 물리적인 서버와 연결과 상관없이 논리적인 서버간의 연결관리와 키를 담당하는 노드를 찾아가는 매커니즘을 제공함
특정키를 서비스하는 노드를 찾아가는 라우팅 알고리즘을 제공함
클러스터에 참여하는 서버는 hash(서버ID)결과로 반환되는 값을 이용해 자신이 관리해야 하는 키영역을 결정함
N1 서버는 hash(N1)보다 크거나 같고 hash(N2)보다 작은 값의 영역을 담당함
그림과 같은 서버 구성에서 'key1'을 관리하는 서버는 hash(key1)값에 의해 결정되며, 'key1'은 N1서버가 관리함
다이나모는 데이터 신뢰성을 위해 데이터를 여러 노드에 복제함
데이터의 복제는 클러스터에서 키에 매핑되는 노드와 매핑된 노드 다음에 위치하는 노드에서 '복제본 수 - 1개'의 노드에 저장함
데이터 복제는 낙관적(optimistic) 정책을 사용함
다이나모의 기본 요구 사항은 쓰기 연산에 대한 고가용성이지만 N,R,W라는 세가지 파라미터를 이용해 성능/가용성/내구성(durability)의 수준을 설정함
다이나모 CAP속성
다이나모는 소스는 공개되지않았지만 Scalaris, Project Voldmort , Ringo등과 같은 다이나모 개념을 구현한 오픈소스 프로젝트가 있음
카산드라는 다이나모 같은 P2P 네트워크 환경에서 구조화된 데이터 저장소를 제공하는 시스템을 페이스북에서 개발해 아파치 오픈소스로 공개함
카산드라는 빅테이블의 데이터모델, 메모리기반/디스크 기반의 컴팩션 처리 기법과 다이나모의 일관성 해싱(consistent hashing)기법을 혼합해 구성한 시스템
각 노드는
카산드라는 P2P기반이기 때문에 클라이언트에서 클러스터의 정보를 찾이가 여러운 구조이므로, 별도의 네이밍 서비스를 사용함
카산드라의 시스템 속성은 기본적으로 가용성과 단절내성(partition Tolerance)을 보장함
카산드라는 관계형 데이터 모델은 지원하지 않으며, 기본적인 데이터 모델은 빅테이블의 데이터 모델과 비슷함
차이점은 두가지 타입의 패밀리를 제공함
"Column" 은 name(이름), value(값), timestamp(시간) 을 가지고 있습니다.
"Column Family" (타입이 같은 Column 의 모임, 이하 CF) 은 RDBMS 의 Relation(비공식: Table) 과 비슷한 의미를 가지고 있습니다. 특이하게도 CF 는 바로 Column 을 하위 구조로 가질 수도 있고 Column 의 모임인 Super Column 을 하위 구조로 가질 수 있습니다.
"Keyspace" 는 CF의 모임입니다. 예를 들자면 "사람", "음악" 이 Keyspace 고 사람 또는 음악이 가지는 다양한 특징을 구분지어 놓으면 CF 가 되는 것이지요.
"Cluster" 는 최상위 개념으로 이러한 Keyspace 의 모임입니다.
카산드라 서버는 최초 서버 시작시 storage-conf.xml 설정파일의 Partitioner 와 InitialToken값을 이용해 서버에서 서비살 데이터 범위를 결정함
나머지 내용은 책으로 설명함
URL 추천
HBASE
1. http://lunarium.info/arc/index.php/HBase%E3%81%AE%E6%A7%8B%E9%80%A0
카산드라
1. http://theeye.pe.kr/category/%ED%97%88%EC%A0%91%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%A8%B8/NoSQL?page=2
2. http://dev.paran.com/2011/06/29/what-is-cassandra-dbms/
3. http://bcho.tistory.com/440