NoSQL Data Store 최원기.

Presentation on theme: "NoSQL Data Store 최원기."— Presentation transcript:

1 NoSQL Data Store 최원기

2 NoSQL? Not Only SQL Not Relational
NoSQL 이란, 주로 Not Only SQL, Not Relational DB 의 뜻으로 사용됩니다. 기존에 자주 사용 되던 RDBMS의 정해진 포맷과는 다르게, 여러 데이터 모델을 제공하며, transaction 을 제공하여 데이터의 일관성을 Hard하게 관리하던 RDBMS에서, Consistency를 완화 하여 availability 및 speed를 올리기 위한 플랫폼입니다.

3 RDBMS Schema, Join, Relation, Table
기존 RDBMS의 경우 잘 아시는 대로 Table, Relation 구조의 Schema를 가지고 있고 각 Relation 마다 연결되어 있는 데이터 모델을 가지고 있습니다. 이 연결은 Join 시 사용됩니다. 이러한 구조의 data 모델의 경우, Big data를 처리하기 위하여 여러 컴퓨터를 연결하는 등의 확장성을 지원하기엔 큰 오버헤드가 필요합니다. 데이터 구조들이 연결 되어 있기 때문에 플랫폼 확장 시 전체 구조를 대상으로 변경(어느 테이블을 어디에 넣을 지에 대한)이 필요하기 때문입니다. Data 연산 시에도 조인을 통한 여러 컴퓨터 노드에 대한 처리가 필요하므로 큰 오버헤드가 필요합니다. Schema, Join, Relation, Table

4 NoSQL Solution for Massive data Big Data Characteristic
from eCommerce, Web services, Social media, etc. Big Data Characteristic Volume Velocity Variety Data model is Good for Map-Reduce Relation DB need to move another memory space, it takes overheads NoSQL은 정확한 등장 시기는 모르지만, 최근, 전자 상거래, 웹서비스 ,소셜 미디어, 위치 기반의 데이터 등 다량의 데이터 처리가 필요하게 되면서 이에 대한 해법으로 각광 받게 됩니다. NoSQL이 어떠한 방법으로 이러한 큰 데이터 처리에 효율적인지 알아보겠습니다. NoSQL은 빅데이터의 특성인 큰 용량, 빠른 속도, 비정형화된 데이터에 대한 처리를 지원합니다. 또한 몇몇 데이터 모델 및 시스템이 맵 리듀스와 호환이 잘되게 설계 되었습니다.

5 NoSQL (cont’d) Volume Horizontal Scalability( vs Vertically Scalability) Computer Computer CPU + CPU CPU + M M M Computer Computer Computer 차례대로 NoSQL이 이러한 특성들을 어떻게 만족하는지에 대해 발표하겠습니다. 처음으로 큰 용량에 대해서 말씀드리면, NoSQL에 관한 경우 Horizontal Scalability 를 지향하고 있는데 이것은 Vertically Scalability 와 반대 되는 개념입니다. Scalability는 확장성이며, 데이터 량이 증가하였을 때 충분히 대응할 수 있는가라고 보시면 됩니다.그림을 보시면, 컴퓨터의 한 노드 내에 CPU, Memory 및 디스크를 증가 시켜, 처리할 수 있는 데이터의 양을 늘리는 방법을 Vertically Scalability 라고 하고, Horizontal Scalability 의 경우 다량의 컴퓨터를 이용하여 하나의 플랫폼으로 통합시켜 다량의 데이터를 처리하는 방법을 말합니다. Vertically Scalability 의 경우 컴퓨터 하나가 지원할 수 있는 자원의 양은 결국 한정되어 있기 때문에, NoSQL의 경우 컴퓨터가 추가 될 때마다 linear한 performance 를 보이는 scalability를 지원합니다. 이러한 방식으로 NoSQL은 큰 용량에 데이터에 대응합니다. …+… + Vertically Scalability Horizontal Scalability

6 NoSQL (cont’d) Velocity
Eventual Consistency (vs ACID : Atomicity, Consistent, Isolation, Durability ) update are eventually propagated to all node No Transaction, Lock, Two phase commit Some NoSQL Not Allow update and delete 두 번째로 빠른 처리에 대한 NoSQL입니다. 기존 RDBMS 같은 경우, Transaction을 제공하며 data의 일관성 정합성을 제공하기 위해 ACID 특성을 제공하였습니다. Atomicity, Consistency, Isolation, Durability. 하지만 이러한 과정을 만족하기 위해서는 data sync를 맞춰주기 위해 lock protocol이 필요하며, data 일관성을 위한transaction의 serializable를 위한 Two phase commit 등의 추가 오버헤드가 듭니다. 반면에 NoSQL은 consistent에 대한 제한을 완화 하여 eventual Consistent를 지원하여 속도와 availability를 더욱더 활용하는 방안을 사용합니다. RDBMS의 경우, Update를 모든 노드에게 동시에 sync를 맞춰주었을 것이나, NoSQL의 경우 필요한 노드만 update를 적용하고 점차 나중에 맞추어나가는 형식을 사용 하게 됩니다. 대부분 Transaction의 지원이나 lock 과정이 SQL에 비해 미비하며, 특정 NoSQL은 data 일관성에 영향을 주는 update 및 delete연산을 지원하지 않고 빠른 insert, read 연산만을 지원하기도 합니다.

7 NoSQL (cont’d) Variety Flexible Data Model (vs tuple)
Key-Value Store Project Voldmort, Riak, Redis, Tokyo Cabinet, etc. Document Store SimpleDB, CouchDB, MongoDB, etc. Extensible record Hybird = tuple + Document Cassandra, Hbase NoSQL allow variation of Schema RDBMS has fixed schema 다음은 NoSQL의 Variety 부분 입니다. RDBMS의 경우 테이블 튜플 단위의 고정된 데이터 모델이었다면, NoSQL의 경우 플랫폼마다 다양한 데이터 모델을 제시하며, 이 모델들은 기존 RDMBS 보다 Schema에 대한 수정이 간편 합니다. 데이터 모델의 종류로는 Key-value store, 단순하게 key 와 value 값으로 이루어진 데이터 모델이며, Voldmort, Riak, Redis 등이 지원 플랫폼입니다. Document store 같은 경우 일반 데이터 모델과 다르게, 메타 정보를 가진 하나의 엔티티 자체를 JSON등의 구조를 통해 저장하는 방식입니다. 지원 플랫폼은 SimpleDB, CouchDB, MongoDB 등이 있습니다. 그리고 Extensible record를 지원하는 Hbase, Cassandra 등이 있습니다. 이 구조는 튜플과 document의 혼합형이고 뒤에서 다시 설명 드리겠습니다. 추가적으로 범위에 벗어 난다고 생각하여 적지 않았으나 그래프 기반 데이터 모델 또한 NoSQL 플랫폼에 포함됩니다. document

8 NoSQL concepts Shared-Nothing Architecture Consistent Hashing
Sharding Consistent Hashing BASE properties 다음으로 NoSQL에서 자주 등장하는 개념들에 대해서 간략히 설명 드리겠습니다. 총 세 개로 추려보았습니다. Shared Nothing Architecture, 즉 sharding 구조와 Consistent Hashing, BASE property 입니다.

9 NoSQL concepts (cont’d)
Shared-Nothing Architecture Sharding Sharding 구조는 간단하게 설명하도록 하겠습니다. 그림을 보면 아시겠지만, 데이터를 key의 범위를 기준으로 수평적으로 나누어 저장하는 것을 말합니다. 이는 두개의 엔티티로 존재하게 되는 vertically partitioning과 다르게 데이터 처리를 할 때 join등의 추가 연산이 필요하지 않게 되고, 데이터가 유실함에 대해서도, 그 특정 부분 제외 하고는 다른 데이터는 지속적으로 사용 가능 할 수 있도록 지원합니다. Sharding Vertically partitioning

10 NoSQL concepts (cont’d)
Consistent Hashing (vs Original Hash) Original Hashing : When add node, all object have to be re- hashed Consistent Hashing 두 번째로 Consistent Hashing 입니다. Hashing 이란 일단 데이터를 어디 컴퓨터에 저장할 지 판별하고 분산하는 처리과정을 의미합니다. Consistent Hashing 은 high scalability 를 지원하기 위해서 NoSQL용으로 고안된 알고리즘입니다. 기존의 Hashing 의 경우 컴퓨터 한대가 추가 되거나 제거 되게 되면, 남아 있던 컴퓨터 안의 모든 데이터를 새로운 해시 함수를 적용 하여 다시 재분배 해야 하는 큰 worst case 가 등장 할 수 있습니다. 따라서 그림과 같은 consistent Hashing 을 사용합니다. 설명, 두 번째 그림은 C node가 사라지고 D node가 추가된 경우입니다. Skewing is possible, Solution is replicas

11 NoSQL concepts (cont’d)
BASE properties ( Consistency ↓↓) Basically availability Guarantee availability, when node is added or removed Soft State The state of system may change over time, even without input. This is because of the eventual consistency model Eventual Consistency The system will become consistent over time, given that the system doesn’t receive input before that time 마지막으로 BASE concept 가 있습니다. Basically availability, soft state, eventual consistency 의 줄임말 입니다. 각각 Consistency를 줄여 availability, fault tolerance를 지원한다는 목적을 가지고 있습니다. 각각 모든 요청이 항상 성공 및 실패 결과를 반환하며 , 시스템 일부가 망가져도 시스템이 동작할 수 있도록 함을 뜻합니다.

12 Hbase

13 HBase NoSQL based on Hadoop Memory + disk system implemented Java
Data model NoSQL의 대표적인 예인 Hbase에 대해서 간략하게 조사해보았습니다. Hbase로 선정한 이유는 Hadoop 구조를 기반으로 하고 있고, In-memory 기반이기 보다는 disk system과 혼합된 형태인데다가 Java로 구현 되어 있기 때문입니다. Extensible record를 다루는 NoSQL 중에서는 popularity 기준으로 상위권 랭킹에 있기 때문에 조사를 해보았습니다. Hbase의 Data model은 아래 그림 과 같습니다.

14 Hbase data model Row Column Family Column Qualifier Cell, Value
Version

15 HBase (cont’d) 다음은 Hbase의 전체적인 system architecture 입니다. Hbase는 총 세개의 모듈, Master와 Zookeeper, RegionServer로 구성 되어 있습니다. Master와 Zookeeper의 경우 해당 노드가 살아있고 작동하고 있는지 체킹을 하며, I/O 처리에 대한 load balancing을 담당하고, Region Server에 저장 된 data가 일정 용량을 초과하면 Region을 나누는 역할을 합니다. Hmaster , Zookeeper : checking alive, active node, work balancing, Region Split HRegionServer : Store data Hadoop System

16 HBase (cont’d) Region server treat partitioned data model by Row key
BlockCache : Read Cache MemStore : Write Cache per one column family Hstore : store one column family Hfile : Data file HLog : If data is not flushed into persistent storage, we should store Log

17 HBase (cont’d) HBase Write

18 Hbase Hfile Structure

19 Hbase Hfile Structure

20 Hfile Physical Structure
Key a, value Leaf index Bloom filter B-tree Key c, value Leaf index Bloom filter Key z, value Root Index Bloom filter Meta data

21 HBase (cont’d) HBase Read

22 HBase (cont’d) Compaction HFile 1 1 - val 2 – kiki (new) 4 - hello 6 -
*(del) compaction HFile 2 2 - hdfs (old) 5 - hard 6 - test New HFile 1 - val 2 - kiki 4 - hello 5 - hard Merges and rewrites all the Hfiles in a region to one Hfile per column family In this process, drops deleted or expired cells. Lots of disk I/O and network traffic

23 HBase(cont’d) Tiered Storage For HBase small data hot data HDFS
cold data hdd hdd hdd ssd ssd ssd DN1 DN2 DN3

24 HBase(cont’d) Compaction management in distributed key-value datastore, VLDB 2015.

25 HBase(cont’d) Analysis of HDFS Under HBase: A Facebook Messages Case Study, FAST 2014.

26 Thank you