Oracle NoSQL Database Overview

오라클은 올해 9월에 NoSQL 제품을 내놓았습니다. 데이터 베이스 분야에서 오랜 기간 동안 제왕의 자리에 있던 오라클이 NoSQL을 만드는 건 그리 어렵지 안을 거라 생각 됩니다. 그래서 몇 가지 주요 특징들을 살펴 보고자 합니다.

우선 태생은 이렇습니다.


Oracle Berkeley DB ->Oracle Berkeley DB Java Edition -> Oracle Berkeley DB Java Edition High Availability(BDB JE/HA) -> Oracle NoSQL Database (BDB JE/HA와 Oracle NoSQL Database에 대한 비교자료가 있으니 참고 하시기 바랍니다. 어떤 블로그 에서는 BDB JE/HA 는 엔진이며 NoSQL은 자동차에 비유를 하기도 했습니다. 관계야 보는 시각에 따라 달라 질 수 있으니…)

간략하게 특징을 요약하면


  • BerkleyDB Java Edition 기반으로 key-value 기반구조 이다(Simple Data Model)
  • single-master 와 multireplicas로 구성 되 있다(High Availability )
  • fail-over 를 지원 하기 위해 PAXOS 기반으로 자동 master선택을 지원한다.(High Availability )
  • 조정 가능한 일관성 정책들을(consistency policies) 지원한다(Predictable behavior)
  • auto-sharding(Scalability)
  • 웹콘솔 기능지원(Administration)

 Oracle에서 언급한 주요 특징은


  • Simple Data Model
  •  Key-value 기반의 구조로 되어있다
  •  Java API 기반의 CRUD를 지원한다
  • Scalability
  • 자동으로 해쉬 기반의 분산 파티셔닝을 지원한다
  • 지능형 NoSQL 데이터베이스 드라이버를 통한 최적의 데이터 액세스를 제공
  • Predictable behavior
  • 조절 가능한 ACID 트랜젝션 에 대해 전체 또는 수행 단위별 지원
  • 지연시간 경계를 통한 B-tree 케싱 과 효과적인 쿼리 디스페칭 기능
  • High Availability 
  • No single point of failure
  • 내장된, 컨피그 가능한 복제기능
  • 단일 또는 다중노드 장애에 대해 탄력적
  • 데이터 센터 복제를 통한 재해 복구
  • Easy Administration
  • 웹콘솔과 커멘드 라인 인터페이스 제공
  • 시스템 및 노드 매니지 먼트 기능 제공
  • 시스템의 토플로지, 상태, 실시간 부하,흐름 및 평균 지연, 이벤트 및 경고 상태 viewing 기능 제공

주목할만한 부분은


Scalability, Predictable behavior, High Availability 이며, 추가적으로 어드민 기능도 보실 수 있습니다.

그럼 그림을 보며 세부 내용을 좀더 살펴 보기로 하겠습니다.

 
그림1) Oracle NoSQL Database Architecture: September 2011

Scalability

전반적인 Architecture를 살펴 보면 해쉬 알고리즘 기반으로 데이터를 분할에 파티션 단위로 쪼겐 후 가용성을 확보하기 위해 Replication 구조를 도입한 케이스라고 볼 수 있습니다.(어디서 많이 보던 구조이네요. 용어들도 비슷하고). Scalability 요소를 들여다 보면 Hash function과 Partition Numbers가 보이며 그 중 가장 핵심적인 부분은 Partition(sharding) 이라고 보여 집니다. 여기서 Partition 개념은 MongoDB에서 보았던 샤딩(sharding)개념과 동일 하며 자동으로 미리 설정된 범위에 따라 추가가 될 수 있는 기능입니다. 설정된 범위에 따라 자동으로 확장 가능 하니 클라우드 환경(scale-out)에서는 필수 기능이 아닌가 싶습니다. 이렇게 분리된 데이터에 대한 접근 관리를 위해 필요로 하는 기능들을 오라클에서 제공하는 클라이언트 드라이버가 어떻게 처리하는 과정을 살펴보도록 하겠습니다.

그림2): Oracle NoSQL Database Processing : September 2011

  1. 어플리케이션에서 클라이언트 드라이버로 데이터를 넘겨준다.
  2. 클라이언트 드라이버에서 “Katana”라는 키를 기반으로 데이터를 분할하여 파티션 넘버를 할당한다.
  3. 클라이언트 드라이버는 Replication 그룹에 파티션에 할당하기 위해 컨설트 한다.
  4. Replication 그룹이 할당되고, 클라이언트 드라이버는 Replication 그룹 상태 테이블(RGST)을 컨설트 한다.
  5. RGST는 각 Replication 노드를 구성하는 Replication 그룹에 대한 정보를 포함한다.
  6. RGST를 기반으로 클라이언트 드라이버는 요청을 보내기위한 적당한 노드를 선택 한다.(요청은 반드시 마스터 노드에게만 전달 해야한다)
  7. 리플리케이션 노드는 명령을 수행한다. putIfAbsent()일 경우 키가 존재하면 단순히 에러만 리턴 하고 , 존재하지 안을 경우는 키를 추가 한 다음(master) 다른 노드들(replica)에게 새로운 key/value값을 전달한다.

처리 과정을 살펴보면 클라이언트 드라이버의 역할은 아주 다양하다는 것을 아실 수 있습니다. 클라이언트 드라이버는 2-6의 과정에 관여를 하고 있으며 “클라이언트 드라이버가 최적화된 기능을 제공하지 않는다면 시스템 전반적으로 영향이 크게 미치지 않을까?” 라고 짐작 하실 수 있을 것 입니다.  

Predictable behavior

이 부분은  consistency policies 위주로 정리해 보았습니다. 대다수의 NoSQL database들은 eventual consistency를 제공 하며, Oracle NoSQL역시 이 기능을 제공합니다. 추가적으로 consistency 정책에 대해 선택옵션 기능을 추가 하였습니다.

그림3): Oracle NoSQL Database Consistency : September 2011

오른쪽으로 가까워 질수록 데이터에 대한 일관성은 보장되며 속도는 떨어질 것으로 예상되며,반면 왼쪽은 일관성이 덜 보장되나 속도는 올라갈 것으로 예상 됩니다 .이러한 기능이 주는 장점은 플랫폼 변경 없이 사용가능, 즉, 신규 개발 시 마다 새로운 플랫폼에 대해 적응할 필요성이 줄어든 다는 점입니다. 그러나 간과해선 안 되는 부분은 어떠한 정책을 선택 하던지 사전에 데이터에 대한 분석이 철저히 이루어져야 할 필요가 있다는 것입니다.

그림4): Oracle NoSQL Database : September 2011

이러한 유동적인 데이터 접근 정책을 DBMS설치 단계가 아닌 코딩 단계에 적용 가능하게 한다는 것 또한 타 NoSQL에 비해 눈 여겨 볼 부분이라고 보여집니다. 이것이 주는 의미는 각 오퍼레이션 별 서로 다른 정책 설정 가능하며, 플랫폼 대한 적용 성 검토 이후 서비스 방향이 변경 됨에 따라 새로 재검토 할 경우 유동적으로 대처 가능하리라 예상됩니다. 이런 4가지 형태의 지원은 CAP 모델에 있어서 C/P 또는 A/P 를 지원 가능 하게 한다고 생각 되며, 데이터에 대한 유연한 형태의 데이터 접근을 보장 하고, 다른 NoSQL이 같지 못한 특징 중에 하나로, 서비스 성격에 맞추어 변경할 필요성이 없어짐으로 인해 개발자의 신규 플랫폼 적응에 대해 부담감을 덜어주는 측면이 존재 한다고 생각 됩니다.

High Availability

고 가용성 측면에서 눈 여겨 볼 부분은 1Master/ 2Replica 부분으로 Master/slave 구조와 유사한 방식이 있습니다. 각각의 기능은 Master는 read/write 가 가능 하며 Replica는 read-only 입니다. Master/Replica를 합하여 Replication group 이라고 부르며 위 그림1)에서는 하나의 Replication 그룹이 데이터 센터 1과 2로 분할되어 있는 구조로 구성 되 있습니다(Replica는 확장가능). 이러한 구성이 주는 장점은 데이터 센터 1이 장애가 날 경우를 대비 해서 구성될 때 효과를 볼 수 있으며, 단점은 공간적으로 분리돼 있을 때 Replication 구조를 유지하기 위한 오버헤드가 발생한다고 볼 수 있겠습니다. 이러한 방식에서 우리는 두 가지 정도에 대해 의문을 가질 수 있습니다. “마스터에 장애가 발생다면? Replica 는 왜 read only일까?” 마스터에 장애가 발생할 경우(“No single point of failure”)에는 Replica set 중에서 마스터를 빠르게 재 선출(Paxos protocol 사용) 함으로서 마스터의 공백으로 인한 write 불가 현상을 커버하고, 다수의 Replica의 read-only 기능은, NoSQL이 같고 있는 장점 중에 하나인, 빠른 데이터 처리를 지원하기 위해서 필수라고 판단 되며(멀티 write는 transection 비용증가) 멀티 액세스를(master/replica set 사용) 가능하게 함으로서 많은 요청에 대비 할 수 있는 이점을 제공 합니다.

또한 Replication 기능에 대해 한가지 알아두어야 할 점은 Read기능은 Replication group(master/replica)을 모두 사용 가능해서 성능 향상에 도움이 되지만 Write기능은 Master에서 각replica에게 복제 되는 과정을 거쳐야 하기 때문에 쓰기 성능에 영향을 줄 수 있습니다.

아래 두 개의 그래프는 Oracle에서 제공한 자료로 Oracle NoSQL Database에 대한 Benchmark 자료를 살펴 보도록 하겠습니다.

차트1) Oracle NoSQL Database : September 2011)

그래프가 표현하는 내용은 데이터 증가에 따라 처리율과 평균 지연시간이 같이 상승 함을 나타내며, 파란색 라인은 왼쪽(초당 처리량)을 보시면 되고 빨간색은 오른쪽(지연시간)을 보시면 됩니다.

차트2) Oracle NoSQL Database : September 2011)

두 번째 그래프에서는 Read와 Update에 대한 지연 율은 데이터가 증가하면서 오히려 더 감소한 후 수평에 가까운 형태를 보입니다. 두 개의 차트를 비교해볼 때 파란색 선은 동일한 패턴을 보이나, 갈색 선은 패턴이 달라진걸 알 수 있습니다. 원인은 Replication에 있다고 판단되며, 쓰기는 Master에서만 가능하나, 읽기는 replica셋에서 가능하기 때문입니다.   시사점


수많은 NoSQL Database가 존재하며 각각 특성도 다양합니다. 그들의 대부분은 누군가의 필요로 인해 만들어 졌으며, 우리는 그러한 제품들이 왜 만들어 지고, 사용 되고 있는지 정확히 알 필요성이 있습니다. 그래야만 우리가 만들어가는 서비스에 효율적인 형태로 사용 할 수 있기 때문입니다. 이렇게 효율적으로 사용 되기 위해서는 –       NoSql 적용 기준 정리 (사전 테스트 환경 제공. 아키텍쳐 검토. ) –       데이터 중요도에 따른 적용 정책 가이드 등에 대한 제도가 정착이 되면 좀더 성공적으로 NoSQL을 도입 할 수 있을 거라 예상 됩니다.

Reference

http://www.oracle.com/technetwork/database/nosqldb/overview/index.html http://www.oracle.com/technetwork/database/berkeleydb/berkeleydb-je-ha-whitepaper-132079.pdf http://www.oracle.com/technetwork/database/nosqldb/learnmore/nosql-database-498041.pdf

Advertisements