NoSQL Technical

NoSql 입문

시작하며

NoSQL의 의미를 해석하는 의견은 다양하지만 가장 가까운 의미로는 Not Only SQL이라고 한다. 꼭 SQL만 사용하지 않는다는 의미로 기존 관계형 DBMS가 갖고 있는 특성에 다른 특성들을 부가적으로 지원한다.

근래에 많은 기업에서 RDBMS에서 NoSql로 변화를 꾀하고 있다고 한다. 그중 큰 이유중 하나가 빅데이터가 아닐까 싶다. 빅데이터를 다룸에 있어서 RDBMS만으로는 트래픽을 감당함에 있어 어려움을 겪고 있는데 이러한 문제점을 해결할 방안으로 NoSql이 대세로 떠오르는 것 같다. 그렇다면 왜 NoSql이 RDBMS의 제약 사항을 해결해 주는지 그 특징과 구조에 대해 알아볼 필요가 있겠다. 한번 알아보도록 하자.

RDBMS

RDBMS 초기

지금으로 아주 오래된 역사이지만, 빠르게 집고 넘어가면서 우리가 지금쓰는 RDBMS가 되기까지 어떠한 과정을 통해 도달 했는지를 간략히 짚어보자

  • 플랫형
    • 자기테이프에 기록하던 방식으로 특정 위치 블럭마다 공유의 공간을 기록하며 접근하는 방식.
    • 단일 레코드에 단일 엔티티가 결합되는 형태로, 데이터 중복과 비효율적 검색 구조를 가짐.
  • 계층형
    • 부모-자식 관계를 허용하여, 부모에 대한 중복 데이터를 방지.
    • 단, 자식 1건에 N건의 부모 형태의 역관계를 표현하기 어렵고, 이를 해결하기 위한 구조적 비용 부담이 큼.
  • 네트워크
    • 계층형의 문제를 해결하기 위해, 부모, 자식 단위를 노드라 하고, 관계정보를 엣지, 노드와 엣지의 묶음을 그래프라고 함.
    • 노드 연결 구조에 따른 설계와 관리 난이도 및 유지보수 비용 증가

RDBMS 혁명

RDBMS에서는 Application 외에 자체적인 프로그램 언어인 SQL을 두고, 데이터를 읽기, 쓰기, 변경, 삭제할 수 있는 방식으로 구성되는 방식으로 발전되어, 지금까지 문제된 과거까지의 내용을 모두 발전된 최종형의 모습으로 등장한다.

SQL이라는 “질의언어” 외에도 데이터 기록관리를 위한 구조로 DBMS와 분리하여 관리 할 수 있는 방식의 “스토리지 관리 프로그램”, IO 성능을 위해 항상 효율적이고 효과적으로 운용하기 위한 “메모리 관리 프로그램”, 데이터 구조 정보를 추적하기 위한 “데이터 사전” 등 RDBMS를 구현하기 위한 최소 요구 사항들이 존재한다.

NoSQL의 출현 배경과 유형

출현 배경

RDBMS 가 최종형의 모습으로 막강하게 자리를 지킨 것은 사실이지만, Enterprise 기업 규모에서 처리하는 형태보다 전세계 웹에서 제공하는 서비스 유형에서의 발생 데이터 규모는 차원이 다를 정도라는 사실을 발견했다.

복잡한 비즈니스 보다는 많은 양의 읽기와 쓰기 작업, 빠른 응답 시간, 높은 가용성 등이 새롭게 필요한 요구사항으로 논의되었다.

RDBMS에서 초기에는 이런 요구사항에 대응하기 위해, CPU, MEMORY 등 Resource 증설하는 Scale Up으로 대응하였으나, 그로인한 관리 비용은 증가되고, RDBMS를 복수로 구성하는 클러스터 방식인 Scale Out으로까지 확장하여 고려하였다. 그러나, 이런식은 트랜잭션 관리비용 증가라는 또 다른 문제를 발생하게 되었다.

결국, NoSQL이 등장하게 되는 이유에는 “확장성”, “비용”, “유연성”, “가용성” 적인 요구사항을 충족하기 위한 여러 종류의 목적별로 등장하게 된다. 따라서, NoSQL만이 아닌, RDBMS와 서로 보완이 필요한 형태로써 요구되어졌고, 그 목적성에 따라 발전하게 되었다.

유형

NoSql은 거대한 Map으로서 key-value 형식을 지원한다고 한다. 이러한 형식 때문에 비정형데이터를 보다 쉽게 저장 및 처리할 수 있는 구조이다.

Key-Value, Documents, Column Family, Graph, Time Series 방식이 있으며, 유형별 목적성을 가지고 있다.

Key-Value DBMS

소개

가장 기본적인 패턴으로 대부분의 NoSQL은 다른 데이터 모델을 지원하더라도, 기본적으로 Key/Value의 개념을 지원한다. Key/Value란 Unique한 Key에 하나의 Value를 가지고 있는 형태를 말한다. Put(Key, Value)으로 데이터를 저장하고 Get(Key)으로 데이터를 읽어오는 API를 지니고 있다.

내부 구조

Redis

대표 제품으로 Redis가 있다. Redis는 Remote Dictionary Server의 약자로서, Key-Value 구조의 비정형 데이터를 저장하고 관리하기 위한 비관계형 DBMS이다. 모든 데이터를 메모리로 불러와 처리하는 메모리 기반이다.

Column Family DBMS

소개

Value는 String이나 Integer와 같은 Primitive 타입이 될 수 도 있지만, 이 정도로는 우리가 일반적으로 사용하는 테이블에서 더 확장된 개념을 사용하는데, 그것이 바로 Column Family라는 개념이다. Key 안에 (Column, Value) 조합으로 된 여러 개의 필드를 갖는데 이를 Column Family라고 한다. 대표 제품으로 Hbase, Cassandra가 있다.

내부 구조

Hbase

Hadoop 플랫폼을 위한 데이터 비관계형 분산 데이터 베이스이다. Hadoop의 분산 파일 시스템인 HDFS에서 동작하기 때문에 가용성 및 확장성을 그대로 이용할 수 있다. 대용량의 Data를 안정적으로 다루는데 효과적이며 데이터 분석 처리 지원에 적합하다.

Cassandra

분산형 NoSQL DBMS으로, 고성능을 제공하면서 수많은 서버 간의 대용량의 데이터를 관리하기 위해 설계되었다. Cassandra는 여러 클러스터를 지원하며, 마스터리스 비동기 레플리케이션을 통해 모든 클라이언트에 대한 낮은 지연 운영을 허용한다.

Documents DBMS

소개

Key/Value Store의 확장된 형태로, Key에 해당하는 Value필드에 데이터를 저장하는 구조는 같으나, 저장되는 Value의 데이터 타입이 Document라는 타입을 사용한다. Document 타입은 XML, JSON, YAML과 같이 구조화된 데이터 타입으로, 복잡한 계층 구조를 표현할 수 있다. 대표 제품으로 MongoDB, CouchDB가 있다.

내부 구조

MongoDB와 CouchDB

MongoDB와 CouchDB 모두 Document Data처리를 위해 사용되는 DB이다. 하지만 용도에 따라 맞게 선택하여 사용하면 된다. MongoDB의 경우 자주 변경되는 Data와 큰 DB에서 좋은 성능이 필요한 경우, CouchDB는 다소 변경이 빈번하지 않고 버전 관리가 중요한 경우에 적합하다. 결론적으로 MongoDB는 보다 빠르며, CouchDB는 보다 안전하다.

Graph DBMS

소개

Graph DB는 의미그대로 Data를 Graph 형태로 저장하고 관리하는 DB를 의미한다. 여기서 Graph는 Data와 Data 사이를 연결하는 Data Relationship으로 구성된다. 사용자는 Schema의 정이없이 자유롭게 Data와 Data Relation을 Graph DB에 저장할 수 있다. Transaction은 지원하지 않는다. 대표 제품으로 Neo4j가 있다.

내부 구조

Neo4j

Graph Data를 저장하고 관리하기 위한 DB이다. 특징으로 자바 기반으로 임베딩 방식과 Rest 방식을 지원하며, 인덱스 및 노드 탐색 지원, 이중화를 통한 고가용성을 지원(Zookeeper 사용) 등이 있다.

Time Series DBMS

소개

시시각각 수집된 데이터를 시간 순서에 따라 저장하고 조회하는 기능을 제공하는 시계열 데이터베이스이다. 대표 제품으로 InfluxDB가 있다.

내부 구조

Fig. 4 Data Structure of the Time-Series DB

InfluxDB

시계열 데이터베이스(TSDB)이다. Go 언어로 개발 되었으며 사물인터넷 센서 데이터, 실시간 분석 등의 분야에서 시계열 데이터의 저장 및 검색에 최적화되어 있다.

마무리

NoSQL의 단점으로 새로운 기술로 운영 노하우가 적으며, 버그가 RDBMS보다 상대적으로 많이 있는 상태이다. 이러한 단점을 보완하여 적용할 수 있는 능력을 쌓을 수 있도록 노력하여야 하며, 업무에 대한 높은 이해를 바탕으로 알맞게 적용하여 사용해야 한다.

다음 회차엔 NoSQL 유형별 대표시스템을 직접사용해 보고 느낀점 및 어떤 시스템에 적합할지 고민해보고자 한다.

참조사이트

https://www.samsungsds.com/global/ko/support/insights/1195843_2284.html

https://www.kdata.or.kr

https://ssup2.github.io/theory_analysis/NoSQL_Graph_DB/

댓글 남기기

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.

%d 블로거가 이것을 좋아합니다: