o NoSQL은 Not-Only SQL의 약자로써
o 비관계형 데이터저장소로
o보통 기존 전통적인 방식의 관계형 데이터베이스와(RDBMS)는 다르게 설계된 데이터베이스
o 이러한 데이터스토어들은 테이블 스키마(Table Schema)가 고정되지 않고
o 테이블 간 조인(Join) 연산을 지원하지 않으며
o 대체로 수평적 확장(Horizontal Scalability)이 용이하다는 특징을 갖는다.
2. 등장 배경
o SNS의 등장 및 웹 환경의 변화로 동시에 대량의 데이터를 Write/Read 필요
o 지속적으로 증가하는 사용자에 대응 하기 위하여 수평적 확장성이 필요
o 빠르게 변화하는 비즈니스에 대한 신속한 대응의 필요
o RDBMS와는 다르게 데이터 저장구조가 비정형적이다.
o 위의 요건을 만족하기 위해서는 기존 RDBMS로는 어려움이 있음
o 그러므로 새로운 형태의 저장 방식과 분산 방식이 필요해짐
3. 관계형 데이터베이스의 한계
4. Scale-out 분산
4.1 Why?
4.2 RDBMS의 Scale-out?
4.2.1. ACID(Atomicity, Consistency, Isolation, Durability)의 유지의 어려움
o Atomicity를 만족하기 위해서는 2PC 프로토콜과 같은 분산 트랜잭션 프로토콜이 트랜잭션에 관련되어 있는 시스템간에 이뤄져야 함
o Isolation level을 맞추기 위해서는 일반적으로 데이터를 locking해야 하며. Locking의 단위는 레코드, 테이블, 인덱스 등이 될 수 있음
o 결과적으로 분산된 환경에서 Atomic과 Isolated 속성을 만족하기 위해서는 분산 트랜잭션 프로토콜이 진행되는 동안에 관련된 모든 lock이 각 시스템에 걸려 있어야 하며,
o 이러한 방식은 시스템의 서비스 부하가 높아 질수록 많은 lock 경합이 이루어지는 것을 의미함. 이러한 경합 때문에 scale-out 하기 어려움
4.2.2. 확장의 어려움
o Replication - 복제에 의한 분산
- Master-Slave 구조에서는 결과를 슬레이브의 개수 만큼 복제해야 하는데 N개의 슬레이브에서 읽을 수 있기 때문에 Read는 빠르지만
- Write에서는 병목현상이 발생하기 때문에 확장성에 대한 제한을 가지게 됨
- 다중 마스터구조에서는 마스터를 추가함으로써 쓰기의 성능을 향상시킬 수 있는데 대신에 충돌이 발생할 가능성이 생기게 됨
o Partitioning(Sharding) - 분할에 의한 분산
- Read만큼 Write도 확장할 수 있지만 애플리케이션레이어에서 파티션된 것을 인지하고 있어야 함
- RDBMS의 가치는 관계에 있다고 할 수 있는데 파티션을 하면 이 관계가 깨져버리고 각 파티션된 조각간에 조인을 할 수 없기 때문에 관계에 대한 부분은 애플리케이션 레이어에서 책임져야 함
- 일반적으로 RDBMS에서 수동 Sharding 은 쉽지 않음
4.2.3. How NoSQL Scale-out
o. 데이터 모델의 단순화
- 쿼리 연산의 데이터 closure가 분산의 기본단위가 되고, 이 단위를 모아서 적당한 수준의 shard를 만들 수 있도록 데이터 모델이 단순하게 구성함
- 기본적으로 쿼리는 분산 단위의 읽기 쓰기를 지원하지만, 여러 분산 단위에 대한 집계 연산 등을 하기 위해서 map-reduce와 같은 별도의 쿼리 방식을 지원하기도 함
o 쿼리의 ACID 속성을 완화
- 쿼리 연산의 일관성을 RDBMS의 ACID 속성보다 완화한 형태를 사용함
- 복제(Replacation)까지 포함해서 생각해 보면 이와 같은 쿼리 속성 완화 현상은 두드러짐.
- CouchDB처럼 ACID 속성을 유지해주는 시스템도 있지만, 많은 경우 고 가용성을 위해, Consistence나 Isolated를 완화함
4.3. CAP 이론
o CAP 이론 : 분산 컴퓨팅 시스템에서 보장해야하는 3가지 특징을 정의
o Consistency(일관성) : 모든 노드들은 동시에 같은 데이터를 보아야 한다.
o Availability(유효성) : 모든 노드는 항상 Read와 Write를 할 수 있어야 한다.
o Partition Tolerance(파티션 허용치) : 시스템은 물리적인 네트워크 파티션을 넘어서도 잘 동작해야 한다.
o CAP 이론에 따르면 CAP중 동시에 보장할 수 있는 것은 이중 2가지이므로, 데이터를 관리할 때 CAP중 어느 2가지에 중점을 둘 것인지를 결정해야 함.
o 기존 RDBMS는 CA에 치중 하고 있음
o AP를 추구하는 NoSQL은 Consistency를 포기하게 되고 CP를 추구하는 NoSQL은 Availability를 포기해야 함.
4.1 Why?
4.2 RDBMS의 Scale-out?
4.2.1. ACID(Atomicity, Consistency, Isolation, Durability)의 유지의 어려움
o Atomicity를 만족하기 위해서는 2PC 프로토콜과 같은 분산 트랜잭션 프로토콜이 트랜잭션에 관련되어 있는 시스템간에 이뤄져야 함
o Isolation level을 맞추기 위해서는 일반적으로 데이터를 locking해야 하며. Locking의 단위는 레코드, 테이블, 인덱스 등이 될 수 있음
o 결과적으로 분산된 환경에서 Atomic과 Isolated 속성을 만족하기 위해서는 분산 트랜잭션 프로토콜이 진행되는 동안에 관련된 모든 lock이 각 시스템에 걸려 있어야 하며,
o 이러한 방식은 시스템의 서비스 부하가 높아 질수록 많은 lock 경합이 이루어지는 것을 의미함. 이러한 경합 때문에 scale-out 하기 어려움
4.2.2. 확장의 어려움
o Replication - 복제에 의한 분산
- Master-Slave 구조에서는 결과를 슬레이브의 개수 만큼 복제해야 하는데 N개의 슬레이브에서 읽을 수 있기 때문에 Read는 빠르지만
- Write에서는 병목현상이 발생하기 때문에 확장성에 대한 제한을 가지게 됨
- 다중 마스터구조에서는 마스터를 추가함으로써 쓰기의 성능을 향상시킬 수 있는데 대신에 충돌이 발생할 가능성이 생기게 됨
o Partitioning(Sharding) - 분할에 의한 분산
- Read만큼 Write도 확장할 수 있지만 애플리케이션레이어에서 파티션된 것을 인지하고 있어야 함
- RDBMS의 가치는 관계에 있다고 할 수 있는데 파티션을 하면 이 관계가 깨져버리고 각 파티션된 조각간에 조인을 할 수 없기 때문에 관계에 대한 부분은 애플리케이션 레이어에서 책임져야 함
- 일반적으로 RDBMS에서 수동 Sharding 은 쉽지 않음
4.2.3. How NoSQL Scale-out
o. 데이터 모델의 단순화
- 쿼리 연산의 데이터 closure가 분산의 기본단위가 되고, 이 단위를 모아서 적당한 수준의 shard를 만들 수 있도록 데이터 모델이 단순하게 구성함
- 기본적으로 쿼리는 분산 단위의 읽기 쓰기를 지원하지만, 여러 분산 단위에 대한 집계 연산 등을 하기 위해서 map-reduce와 같은 별도의 쿼리 방식을 지원하기도 함
o 쿼리의 ACID 속성을 완화
- 쿼리 연산의 일관성을 RDBMS의 ACID 속성보다 완화한 형태를 사용함
- 복제(Replacation)까지 포함해서 생각해 보면 이와 같은 쿼리 속성 완화 현상은 두드러짐.
- CouchDB처럼 ACID 속성을 유지해주는 시스템도 있지만, 많은 경우 고 가용성을 위해, Consistence나 Isolated를 완화함
4.3. CAP 이론
o CAP 이론 : 분산 컴퓨팅 시스템에서 보장해야하는 3가지 특징을 정의
o Consistency(일관성) : 모든 노드들은 동시에 같은 데이터를 보아야 한다.
o Availability(유효성) : 모든 노드는 항상 Read와 Write를 할 수 있어야 한다.
o Partition Tolerance(파티션 허용치) : 시스템은 물리적인 네트워크 파티션을 넘어서도 잘 동작해야 한다.
o CAP 이론에 따르면 CAP중 동시에 보장할 수 있는 것은 이중 2가지이므로, 데이터를 관리할 때 CAP중 어느 2가지에 중점을 둘 것인지를 결정해야 함.
o 기존 RDBMS는 CA에 치중 하고 있음
o AP를 추구하는 NoSQL은 Consistency를 포기하게 되고 CP를 추구하는 NoSQL은 Availability를 포기해야 함.
(요즈음에는 다양한 방식을 통해 AP와 CP를 절충하거나 보완하는 방식도 사용됨)
5. NoSQL의 구조
5.1 공통 특징
o Key value store
o Run on large number of commodity machines
o Data are partitioned and replicated among these machines
o Relax the data consistency requirement
o API Model
- get(key)
- put(key, value)
- delete(key)
- execute(key, operation, parameters)
- (※)mapreduce(keyList, mapFunc, reduceFunc)
5.2 데이터 저장 구조
5.2.1. Key-Value(blob)
o 단순한 모델인 만큼 속도가 빠른 것이 주 장점
o Key 단위의 원자적 쓰기/읽기 만을 지원하는 경우가 많으며, 이 경우 여러 key의 value에 동시 처리를 하면서 serialize 할 수 있는 방법은 없음
o 메모리를 저장소로 사용하는 경우 아주 빠른 get/put을 지원하는 것을 목적으로 함
o Key에 대한 단위 연산이 빠른 것이지, 여러 key에 대한 연산은 고정적으로 네트워크 전송 지연이 포함되기 때문에 느릴 수 있음
(RDBMS테이블에 10만 row의 데이터를 select 하는 것과 Key-value 단위로 10만 번 읽는 것은 비교할 수 없을 정도로 Key-Value DB가 느림)
5.2.2. Key-Value(Structure)
o List, Set 과 같은 ADT(Abstract Data Structure)를 제공하는 모델이고, 장점은 한 key에 대해 여러 값을 저장할 수 있음
o Key-BLOB모델에서는 단일 값만 Value로 사용할 수 있으나, 이 구조는 여러 Key를 사용해 저장 해야 하는 데이터를 하나의 key 만 사용하여 저장할 수 있음
o 단순히 get/put하는 모델보다는 처리 시간이 오래 걸림(그리 많은 차이가 나지는 않음/설계에 따라 극복 가능함)
5.2.3. Document oriented
o schema 없이, 임의의 property 를 추가할 수 있는 데이터 모델
o JSon이나 XML 같은 문서 데이터를 저장하기 적합한 구조
o Document id나 특정 property 값 기준으로 order-preserving 하는 경우가 많음
(이 경우 해당 key 값의 range에 대한 효율적인 연산이 가능해 지므로 이에 대한 쿼리를 제공)
o 쿼리 처리에 있어서 데이터를 parsing 해서 memory 연산을 해야 하므로 처리 overhead가 key-value나 key-structure 모델보다 큼(큰 크기의 document를 다룰 때 성능 저하 발생)
5.2.4. Multi-dimensional map
o Bigtable의 경우 row-column-timestamp에 의해서 데이터를 mapping 하고, 데이터 자체는 binary 값
o Cassandra의 경우 row-column, families-column 형태로 데이터를 mapping 하고 데이터 자체는 binary 값
o 두 모델 모두 데이터(column)에 대한 grouping 과 access 방식을 구조화 하는 방식으로 데이터를 모델링 할 수 있음
댓글 없음:
댓글 쓰기