이전 포스트에서는 3차례에 걸쳐서 ScyllaDB vs. Cassandra Benchmark를 테스트해봤다. 3번에 걸친 테스트에서 ScyllaDB에서 주장하는 10배의 성능 향상을 직접 확인하지는 못했다. 그렇다고 ScyllaDB가 홈페이지에서 정확하지도 않은 내용을 주장하는 것은 아니다.

테스트 환경이 제한적이다보니 10배의 성능 향상을 확인 못한 것이지 ScyllaDB에서 테스트한 것과 동일한 사양으로 테스트를 진행한다면 충분히 가능할 것이라 생각한다.

중간 규모의 서비스에서는 Cassandra를 운영한다 하더라도 시스템 사양을 24Core/128Gb로 맞추기는 힘들다. 그나마 적절한 수준이 8~16Core/32Gb일 것이고 현실적으로는 8Core/16Gb정도의 사양으로 운영하게 될 수 있다.

사내 개발장비를 통해서 진행한 테스트(ScyllaDB vs. Cassandra benchmark 따라하기 2 : 사내 개발장비 테스트)가 현실과 가장 유사할 수 있다.

사내 개발장비 테스트에서 보여준 ScyllaDB의 성능은 "그럭저럭한 Request 부하에서는 Cassandra에 가까운 성능을 보여준다"고 할 수 있다. 하지만 AWS를 통한 테스트(ScyllaDB vs. Cassandra benchmark 따라하기 3 : AWS 테스트)에서 확인할 수 있었던 것 처럼 "Request가 증가할수록 ScyllaDB는 Cassandra보다 더 좋은 성능을 보여준다"는 것을 확인할 수 있었다.

지금까지 확인된 사실을 바탕으로 ScyllaDB와 Cassandra의 성능을 짐작해보면 다음과 같이 표현할 수 있다.

<그림 1. Cassandra와 ScyllaDB의 초당 Request 증가에 따른 TPS 변화 예상>

적절한 시스템 사양만 갖춘다면 "Redis의 속도를 가진 Cassandra"를 갖는 것이 불가능하지만은 않다고 보인다.

<그림 2. Redis의 속도를 가진 Cassandra>

만약 현재 Cassandra를 운영하고 있는 경우라면 2016년 1월에 ScyllaDB GA버전이 나온 후 ScyllaDB로 교체하는 것을 고려해볼만한 가치가 있는 것 같다. 

그리고 rowkey, column name 등이 정렬된다는 특징을 이용하면 Message Queue, Time Series DB, CEP 등을 구현하는데 매우 유용할 수 있을 것 같다.

ScyllaDB의 Benchmark 따라하기

지난 포스팅에서는 VirtualBox, 사내 개발장비에서 각각 ScyllaDB와 Cassandra의 성능을 테스트해보았다. 역시나 ScyllaDB 홈페이지에 나와있는 성능 10배 향상은 확인할 수 없었다. 게다가 사내 개발장비에서 테스트한 결과에서는 Cassandra가 약간이나마 더 좋은 성능을 보여줬다.

하지만 앞에서 진행한 2번의 테스트는 아직은 정확한 성능을 측정했다고는 할 수 없다. 부하를 주는 클라이언트가 1대뿐인 환경에서 진행되었고 시스템 사양도 실제 서비스에서 사용하기에는 무리가 있을만하기 때문이다.

이번에는 AWS에서 ScyllaDB와 Cassandra를 테스트해보도록 하겠다. 각 DB의 구성은 Single Node로 구성해서 테스트했다.

테스트에 사용할 EC2 Instance는 다음과 같다.

DB서버(ScyllaDB/Cassandra)

• m3.xlarge : vCPU=4, 메모리=15G
• Volume : m3.xlarge에서 기본 제공되는 SSD 사용

• t2.micro : vCPU=1, ECU=변수, 메모리=1G

ScyllaDB는 앞서 진행했던 사내 개발장비에서보다 낮은 성능을 보여주고 있다. AWS의 Instance Disk I/O 성능이 사내 개발장비보다 낮기 때문에 당연한 결과일 수 있다.

2) 읽기 테스트

VirtualBox 테스트와 마찬가지로 데이터를 먼저 채워넣은 후 읽기 테스트를 진행했다.

읽기 테스트는 다음의 명령은 다음과 같다.

결과는 다음과 같다.

3) 읽기/쓰기 테스트

테스트에 사용한 명령은 다음과 같다.

결과는 다음과 같다.

결과를 종합해서 살펴보면 다음과 같다.

<표 1. AWS에서의 benchmark결과>

m3.xlarge가 vCPU가 4개뿐이어서 큰 기대를 하지는 않았다. 그런데 결과는 기대 이하로 Cassandra가 더 빠르게 나왔다.

이정도까지 했으면 "ScyllaDB가 결과를 너무 과대포장했네~"라고 생각할 수 있을만 하다. 그런데 테스트 중 측정된 Load Average를 보면 좀 더 테스트가 필요하다는 필요성을 느낄 수 있다.

ScyllaDB와 Cassandra 테스트 중 측정된 Load Average는 다음과 같다.

<표 2. 테스트 중 측정된 Load Average>

만약 이렇다면 부하 테스트 클라이언트의 수를 늘렸을 때 ScyllaDB는 더 많은 일을 할 수 있을 것 같다. 물론 ScyllaDB는 Architecture상 Load Average가 크게 올라가지 않을 수 있다.

:: m3.xlarge DB Server, 부하테스트 클라이언트 10대로 테스트 ::

2) 읽기 테스트

결과는 다음과 같다.

3) 읽기/쓰기 테스트

결과는 다음과 같다.

결과를 종합해서 살펴보면 다음과 같다.

<표 2. AWS에서 Client가 10개인 경우의 benchmark결과>

부하테스트 클라이언트를 1대로만 했을때는 Cassandra의 약 80%의 성능 정도만 보이던 ScyllaDB였다. 그런데 클라이언트를 10대로 하니 Cassandra의 2배 이상의 성능을 보여주고 있다.

특이한 점은 Cassandra의 경우 부하를 1대에서 주는 경우와 10대에서 주는 경우 읽기 성능이 크게 달라지지 않았다. 반면에 ScyllaDB는 쓰기 성능과 비슷한 비율로 증가한 것을 알 수 있다.

ScyllaDB의 Benchmark 따라하기 2

지난 포스팅에서는 VirtualBox를 통해서 ScyllaDB와 Cassandra의 성능을 테스트해보았다. 결과에서 ScyllaDB 홈페이지에서 주장하던 10배의 성능 향상을 볼 수는 없었다. 몇가지 조건은 오히려 ScyllaDB쪽에 불리한 것도 있었기 때문에 이번에는 사내에 있는 개발장비에서 성능테스트를 진행해봤다. 사내에서 테스트에 활용할 수 있는 개발장비는 다행히 3대가 있었다.

사내에는 남는 개발장비가 3대 있다. 시스템 사양은 각각 다음과 같다.

DB서버(ScyllaDB/Cassandra)

• CPU : 4 Core
• 메모리 : 16G
• HDD : 128G SSD

• CPU : 2 Core
• 메모리 : 16G
• HDD : 250G SSD

오히려 Cassandra가 더 좋은 성능을 보여주고 있다.

2) 읽기 테스트

VirtualBox 테스트와 마찬가지로 데이터를 먼저 채워넣은 후 읽기 테스트를 진행했다.

읽기 테스트는 다음의 명령은 다음과 같다.

결과는 다음과 같다.

읽기에서도 오히려 Cassandra가 더 좋은 성능을 보여주고 있다.

3) 읽기/쓰기 테스트

테스트에 사용한 명령은 다음과 같다.

결과는 다음과 같다.

결과를 종합해서 살펴보면 다음과 같다.

<표 1. 사내 개발장비에서의 benchmark결과>

테스트 결과 ScyllaDB가 말하는 "Cassandra보다 10배 빠르다"는 확인할 수 없었다. 오히려 Cassandra보다 떨어지는 성능을 보여주고 있었다.

그런데 이번 테스트에서는 ScyllaDB 홈페이지에서 진행한 것 처럼 여러대의 Client에서 부하를 준 것이 아니라 한대의 시스템에서만 부하를 준 것이다. 이번 결과로 확인할 수 있었던 것은 그럭저럭한 사양의 시스템에서 그리 많지 않은 수준의 Request가 들어오는 경우에는 Cassandra가 더 빠를 수 있다는 것이다.

사내 개발장비에서는 여러대의 클라이언트에서 부하를 주는 등의 테스트 진행이 불가능하기 때문에 다음번 포스트에서는 아마존 AWS에서 테스트를 진행해보도록 할 계획인다.

ScyllaDB의 Benchmark 따라하기 1

ScyllaDB가 주장하는 10배 빠르다는 사실을 확인하기 위해서 ScyllaDB 홈페이지의 Scylla vs. Cassandra benchmark에 나와있는 내용을 직접 확인해보도록 하자.

홈페이지에 나와있는대로 하려면 DB서버는 24Core CPU, 128G 메모리가 있어야 한다. NIC도 DB서버에는 10Gbps를 사용했다.

우선 그런건 다 무시하고 PC에서 VirtualBox를 통해서 ScyllaDB와 Cassandra를 테스트해봤다. 테스트 환경은 다음과 같다.

DB 서버 (ScyllaDB/Cassandra)

• CPU : 1 Core
• 메모리 : 2G
• HDD : 20G 고정크기 저장소

부하 테스트 서버

• 없음. DB서버하고 같이 사용함.

ScyllaDB 홈페이지에서도 사용한 명령을 적어주긴 했는데 대충 적은듯한 티가 많이 난다. duration=15min으로 되어있는 부분은 duration=15m이 되어야 한다.

VirtualBox에서 테스트한 결과는 다음과 같다.

2) 읽기 테스트

읽기 테스트를 진행하기 전에 다음의 명령으로 채워넣어놨다.

읽기 테스트는 다음의 명령을 사용했다.

ScyllaDB에 테스트를 할 때 데이터가 늦게 나온다 싶더니 나오라는 결과는 안나오고 다음의 메시지만 나오고 있었다.

메시지가 말해주는건 다음과 같다.

"LOCAL_ONE Consistency level을 가지고 read를 수행하려 했는데 timeout이 발생했다! LOCAL_ONE Consistency level에서는 1개의 응답이 와야 하는데 아무것도 못받았다"

아무래도 thread 700개는 무리였던 것 같다. ScyllaDB 홈페이지에서 테스트에 사용했던 시스템은 24core에 128Gb 메모리를 가진 시스템이었기 때문에 thread를 300개로 낮춰서 다시한번 테스트한 결과는 다음과 같다.

ScyllaDB가 약 65%의 성능 향상이 있는 것으로 결과가 나오긴 했지만 테스트 중 ScyllaDB는 ReadTimeoutException이 한두번 발생하기는 했다. ReadTimeoutException은 Cassandra에서는 발생하지 않았다.

3) 읽기/쓰기 테스트

읽기/쓰기 테스트는 읽기 테스트에 사용했던 명령에 ratio만 read=1,write=1로 수정해서 테스트했다. 그런데 Cassandra에서 ReadTimeoutException이 많이 발생해서 thread 수를 300 -> 100 -> 50 으로 줄여나갔다. 

결과는 다음과 같다.

결과를 종합해서 살펴보면 다음과 같다.

<표 1. VirtualBox에서의 benchmark결과>

ScyllaDB가 아주 약간의 성능 향상이 보여지기는 했다. 그리고 특히 읽기/쓰기 테스트에서는 Cassandra에서만 ReadTimeoutException이 발생해서 Thread 수를 줄여나가야 했다.

아무래도 테스트 환경이 VirtualBox이고 매우 낮은 사양의 VM이라서 이런 결과가 나온 것일 수 있다. 특히 VM마다 CPU Core를 하나만 할당했기 때문에 Request당 하나의 CPU를 할당하는 ScyllaDB는 좀 더 불리한 상황에서 테스트를 진행한 것이다.

아무튼 ScyllaDB가 Cassandra보다 약간 빠른 성능을 보여주는 것은 확인되었다. 다음번에는 사내 개발장비에서 테스트를 진행해보도록 할 계획이다.

Cassandra는 대표적인 Column Family Oriented NoSQL 중 하나이다. Cassandra의 Use Cases 페이지(http://www.planetcassandra.org/apache-cassandra-use-cases/)만 들어가봐도 얼마나 많이 사용되고 있는지 알 수 있다. 

Cassandra가 Java로 만들어져있다는 것은 대부분 알고있는 사실이다. Java 오픈소스 중 C/C++로 구현하는 것은 어렵지 않게 찾아볼 수 있다. Lucene과 CLucene, HBase와 HyperTable 이 대표적인 예이다. Cassandra도 이와 같이 C++로 구현한 오픈소스가 있다. ScyllaDB라는 NoSQL은 Cassandra와 호환되는 Column Family Oriented NoSQL이다.

ScyllaDB의 홈페이지(http://www.scylladb.com/)에서는 다음과 같이 믿기 힘든 내용을 볼 수 있다.

<그림 1> ScyllaDB 홈페이지에 있는 소개 문구

Cassandra와 완전히 호환되면서 10배나 빠르다는 내용을 볼 수 있다. 2배정도 빠르다고 하면 순진한 척 하고 믿어줄 수는 있다. 하지만 10배나 빠르다는 것은 진짜 그런지 확인하지 않고 믿기에는 무리가 있다. 

다음번 포스팅에서는 ScyllaDB 홈페이지에서 진행한 "ScyllaDB vs Cassandra Benchmark"를 직접 확인해보도록 하겠다.

먼저 ScyllaDB에 대해서 알아보면 다음과 같다.

ScyllaDB 소개

ScyllaDB는 C++로 구현한 Cassandra이다. 일반적인 경우 구현 언어가 Java에서 C++로 바뀐다 해서 성능이 10배 향상되는 경우는 거의 찾아보기 힘들다. 그럼에도 테스트를 진행해서 실제 10배 성능향상이 있는지 확인하고자 하는 이유는 ScyllaDB를 만든 사람들 때문이다.

ScyllaDB는 KVM을 만든 사람들이 만들었다. KVM은 Google Compute Engine, OpenStack에서 사용하는 가상화를 위한 Hypervisor이다. 아무래도 시스템에 대해서 매우 잘 알고있는 사람들이 만들었기 때문에 시스템 자원을 최대한 효율적으로 활용해서 10배의 성능 향상을 얻을 수 있었던 것으로 예상한다.

ScyllaDB는 요즘 사용되는 하드웨어에 최적화된 Architecture를 사용하고 있다. 일반적인 JVM 아키텍쳐와 비교해보면 다음과 같다.

<그림 2. 일반적인 JVM 아키텍쳐)와 ScyllaDB 아키텍쳐>

ScyllaDB 홈페이지에서는 좌측의 일반적인 JVM 아키텍쳐는 낮은 CPU 활용, 상대적으로 비용이 많이 드는 Locking, 갑작스런 Latency 불안정 문제를 가지고 있다고 한다. 그러면서 우측 ScyllaDB 아키텍쳐는 shared-nothing 방식을 기반으로 하기 때문에 한대의 시스템에서 1백만 CQL까지도 처리할 수 있다고 한다.

Shared-nothing 방식은 리퀘스트가 처리할 CPU를 할당받아서 거기에서 다 처리하는 방식이라고 ScyllaDB 홈페이지에서 설명하고 있다. 이와 같은 방식으로 만든 Seastar라는 Framework이 있는데 ScyllaDB는 Seastar Framework를 사용하고 있다.

아무튼 ScyllaDB는 shared-nothing 방식의 Seastar Framework를 사용하여 구현하였기 때문에 context switching이 적고 시스템 자원을 최대한으로 활용할 수 있다.

시스템 자원을 최대한 활용하는 방식으로 만들었다고는 하지만 몇가지 문제점(?)들이 예상되기는 한다. 특히 이벤트 처리하는 부분에서 이벤트 처리를 OS에게 맡기는게 아니라 직접 polling하기 때문에 아무 일도 하지 않는 상태에서 모든 CPU를 사용하게 된다.

예를들어 4Core짜리 시스템이 있다면 ScyllaDB를 실행시켜놓은 것만으로 Load Average가 4.0 이 될 것이다. 물론 실행시 옵션을 줘서 사용할 Core 수를 조절할 수는 있다. 서비스를 위해서는 적어도 Core 2개는 일하지 않는 상태로 두는 것이 좋을 것 같다.

현재 ScyllaDB는 Cassandra 2.1.8에서 Thrift와 SSL을 제외하고는 완벽히 호환된다고 한다. 하지만 성능 향상을 위해서 Gossip과 Internal Streaming은 ScyllaDB가 따로 구현했기 때문에 Cassandra 노드와 ScyllaDB 노드를 하나의 클러스터로 구성하는 것은 불가능하다.

NoSQL이 Scalability와 성능을 강조하는 경우가 많기 때문에 Cassandra보다 10배 빠르다고 하는 ScyllaDB는 곧 있으면 주목받을 수 있을꺼라 생각한다. ScyllaDB GA버전이 나오면(2016년 1월에 나온다고 한다.) 어떤 반응이 있을지 기대된다.

HBase의 특징

개인적으로 어떤것이든 도입 필요성에 대해서 경영진을 설득할 때 그것에 대한 특징이 잘 설명된다고 생각한다. 그렇다면 다음에 진행할 프로젝트에서 HBase를 사용해야 한다고 경영진을 설득하는 방법에 대해서 알아보도록 하자.

다음 프로젝트에서 HBase를 사용하고 싶다면 다음과 같이 경영진을 설득할 수 있다.

Hadoop과 강한 연관성을 가지고 있다!

HBase에서 분산 환경을 구축하기 위해서는 HDFS위에서 실행되어야 한다. 어찌보면 제한사항으로 느껴질 수도 있지만 이미 Hadoop을 사용하고 있는 환경에서는 오히려 그것이 큰 장점이 될 수 있다. 설득의 포인트는 "기존의 Hadoop 시스템을 활용해서 NoSQL Database까지 운영할 수 있다"로 하면 된다.

기존 시스템을 활용할 수 있다는 것은 매우 강한 설득력을 가질 수 있다. 구체적인 목적을 가지고 Hadoop 시스템을 필요한 규모만큼만 운영하는 경우라면 "꼭 Hadoop을 활용할 필요가 있느냐?"는 질문을 받을 수 있다. 하지만 다행히 Hadoop 시스템을 구체적인 목적을 가지고 운영하는 경우는 많지 않다.

만약 Hadoop 시스템을 운영하고 있지 않은 경우라도 공략은 어렵지 않다. Hadoop 시스템을 도입하자고 경영진을 설득하는 것은 HBase에 비하면 너무나 쉽기 때문이다.

* 공략 키워드 : Big Data, Hadoop

Big Data 처리가 가능하고 MapReduce도 가능하다!

HBase는 Hadoop의 ecosystem으로 분류된다. 요즘같이 Big Data = Hadoop이라는 관계에 대해서 의문을 갖는 사람들이 많지 않다는 것을 이용하면 된다. 사실 Big Data + 대용량 데이터 처리는 HBase뿐만 아니라 다른 NoSQL Database들도 가능하다. 물론 기존에 많이 사용하던 RDBMS도 Sharding 등을 통해서 충분히 대용량 처리를 할 수 있다.

HBase는 대용량 데이터의 읽기, 쓰기 뿐만 아니라 MapReduce를 통한 처리도 가능하다. 이것을 교묘히 이용하면 성공할 수 있는 확률이 높아지게 된다. 공략의 방식은 다음과 같다.

1. Big Data = Hadoop라는 관계를 강조한다.
2. Hadoop의 MapReduce를 통해서 Big Data 처리를 한다는 것을 슬쩍이라도 얘기해야 한다. 이때 Hadoop이란 것을 강조해야 한다.
3. HBase는 Hadoop의 ecosystem이라고 한다.
4. 간단한 몇가지 정보를 흘려둔 후 경영진이 Big Data = Hadoop = HBase라는 공식을 머리속에 그려낼 수 있도록 시간을 준다.

데이터에 대한 MapReduce를 지원하는 Database가 HBase뿐만은 아니다. HBase와 비교되는 Cassandra도 MapReduce가 가능하다. 하지만 Hadoop의 ecosystem으로 분류되는 HBase에서 Hadoop의 MapReduce를 처리한다고 하면 다른 NoSQL Database보다 더 잘 할 수 있을 것 같은 기분이 든다.

* 공략 키워드 : HBase는 Hadoop의 ecosystem!

CAP이론에서 CP 모델을 가진다.

HBase는 데이터의 Consistency를 보장한다. 다시 말하면 HBase에 쓰기를 한 후 바로 다른 노드에서 읽기를 한 경우 가장 최근에 쓰여진 데이터를 읽는다는 것이 보장된다.

CAP이론을 들먹이면서 자주 비교되는 것이 Cassandra이다. HBase를 경영진에게 설득해야 하는 입장에서 Cassandra는 눈에 가시같은 존재이다. 만약 경영진이 Cassandra에 대해서 언급한다면 좀 치사한 방법이기는 하지만 Cassandra를 깎아내려서 HBase의 존재를 부각시키는 방법이 가장 좋다.

Cassandra는 CAP 이론에서 AP의 모델을 가진다. 극단적으로 말하면 Cassandra는 데이터의 Consistency를 보장하지 못한다. 그렇기 때문에 데이터의 Consistency가 필요한 경우라면 HBase를 사용하는 것이 더 유리하다고 주장한다.

데이터를 다루는 대부분의 경우에는 Consistency는 매우 중요한 속성 중 하나이다. 만약 Cassandra가 Consistency가 약하다는 말을 들으면 경영진도 쉽게 포기하게 될 것이다. 그렇기 때문에 HBase를 사용해야 한다고 경영진을 설득할 때에는 무조건 Consistency를 강조해야 한다. 

만약 경영진이 Cassandra에 대해서 좀 더 자세하게 물어보는 경우 대충 얼버무리면 된다. 만약 Cassandra가 읽기, 쓰기에 대해서 각각 Consistency Level을 설정하는 것이 가능하고 Consistency Level중 ALL은 클러스터 내의 모든 노드에 row를 저장한다는 것까지 경영진이 알게되면 문제가 복잡해지게 되니 조심해야 한다. 만약 경영진이 미리 Cassandra에 대해서 조사한 후 Consistency Level = ALL에 대해서 얘기하면 그럴 경우 하나의 노드가 반응하지 않을 경우 읽기/쓰기가 실패하게 되는 단점이 있다고 얘기해주면 된다.

그리고 Google의 BigTable도 CP 모델을 가진다고 얘기하면 HBase가 더 좋아보일 수도 있다.

HBase에 대해서 간단히 알아보자!

HBase?

HBase에 대해서는 무엇보다도 HBase 홈페이지(http://hbase.apache.org)가 가장 정확하게 설명하고 있을 것 같다.

HBase 홈페이지에는 다음과 같은 좀 더 상세한 설명도 있다.

그렇다면 HBase를 이해하기 위해서는 구글의 BigTable에서 시작해야 할 것 같다.

구글의 Bigtable에 대해서 설명한 논문(http://research.google.com/archive/bigtable.html)에서 Data Model에 대한 설명을 보면 다음과 같다.

Bigtable Data Model의 특징은 sparse, distributed, persistent multidimensional sorted map 이라고 할 수 있다. 

그렇다면 각 특징에 대해서 간단히 알아보면 다음과 같다.

sparse

sparse라는 영어 단어는 "밀도가 희박한"이라는 뜻을 가지고 있다. 뜻도 어려울 뿐만 아니라 발음할때도 r 발음에 주의해야 한다! 스파~ㄹ스라고 해야 하지만 영국식 발음은 스파스 해도 무난하다고 한다. (거꾸로 읽어도 스파스가 된다!)
아무튼.. 밀도가 희박하다는 특징이라고 하면 잘 떠오르지 않는다. 만약 "밀도가 희박하다"는 단어만으로 설명하려 하면 다음과 같은 사태가 발생할 수 있다.

마지막 대사의 괄호 안을 채워넣으려 노력하지 말고 sparse하다는 말에 좀 더 집중해보도록 하자. sparse라는 단어와 관련된 것을 생각해보면 "sparse matrix(희소행렬)"라는 단어가 떠오를 것이다!

sparse matrix(희소 행렬)의 모습은 아래와 같다.

이와 같이 대부분의 항목이 비어있거나 0의 값을 가지는 행렬을 sparse matrix(희소 행렬)이라 한다. Bigtable의 sparse하다는 특징은 정형화된 테이블에 대부분의 값이 들어가있는 모습이 아닌 sparse matrix의 데이터 구성과 유사하다는 것을 의미한다.

distributed

distributed라는 영어 단어는 "분산된"이라는 뜻을 가지고 있다. 흔히 사용되는 단어이고 말 그대로 데이터가 분산되어 관리된다는 것을 의미한다.

persistent multidimensional sorted map

각 단어의 의미를 알아보면 다음과 같다.

persistent라는 단어는 "지속적인"으로 해석되어 메모리 같은 휘발성 저장소가 아닌 하드 디스크와 같은 비휘발성 저장소에 저장된다고도 해석될 수 있다. 하지만 여기서 말하는 persistent라는 속성은 persistent data structure를 나타내는 것이다. persistent data structure는 데이터의 version이 관리되는 데이터 구조를 의미한다.

multidimensional은 말 그대로 다차원을 의미한다. Bigtable의 데이터 모델의 다차원은 row key, column key, timestamp를 의미한다.

sorted 또한 말 그대로 정렬되었다는 것을 의미한다. 

데이터에 대해서 얘기하면서 map을 "지도"라고 해석하는 사람은 없을 것으로 생각한다. 자료구조에서 말하는 map 형태의 데이터를 의미한다.

각 단어에 대한 이해를 했다면 이제 각 단어를 조합하는 응용을 해보면 다음과 같다. 

그렇다면 이제 HBase의 데이터 모델에 대해서 알아보자. 그냥 알아보면 재미없으니 Perl을 사용해서 표현해보면 다음과 같다.

요약하자면.. Bigtable에 대한 설명에서 "Bigtable"이라는 단어를 "HBase"로 변경하면 된다.

이제 HBase에 대해서 정의해보자.

참고자료

• Apache HBase
  http://hbase.apache.org
• Google, Inc. , "Bigtable: A Distributed Storage System for Structured Data"
  http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/ko//archive/bigtable-osdi06.pdf

CAP이론?

NoSQL 소개에는 빠지지 않고 등장하는 그림이다. 이 그림을 약 3~5초정도 보면 다음과 같은 의문이 생기게 된다.

"그럼 ACID는?"

ACID(원자성, 일관성, 고립성, 지속성)는 데이터베이스 트랜젝션이 안전하게 수행된다는 것을 보장하기 위한 성질을 가리키는 약어이다.

- 위키백과, (http://ko.wikipedia.org/wiki/ACID)

ACID는 RDBMS에서 매우 중요하게 생각하는 성질이라 할 수 있다. 그런데 NoSQL에서는 찾아보기 힘든 단어이다.

2000년 Eric Brewer가 "Towards Robust Distributed Systems"라는 제목으로 CAP 이론을 소개할 때 BASE에 대해서도 소개했었다.

성능과 가용성 등을 위해서 ACID의 C와 I의 속성을 포기하고 분산 시스템에 더 적합하다고 생각되는 성질을 정리한 것이 BASE이다.

BASE가 나타내는 성질은 다음과 같다.

Basically Available : 기본적으로 Available하고
Soft-state : 사용자가 관리(refresh, modify)하지 않으면 Data가 expire 될 수도 있으며
Eventually consistency : 지금 당장은 아니지만 언젠가는 Data가 일관성을 가진다

전달하고자 하는 의미는 알겠는데 찝찝한 부분이 있다!

1. Basically Available은 Basically라는 부사를 사용하지 않고 Availablility라고만 표현해도 되고
2. Eventually consistency도 마찬가지로 Eventually라는 부사를 사용하고 있다
3. 게다가 ACID처럼 명사들 만의 약자가 아닌 Basically Available = 부사 + 형용사, Soft-state = 명사, Eventually consistency = 형용사 + 명사 로 구성되어있다.

이렇게 억지로 짜맞춘 단어처럼 보이는 BASE는 ACID와의 관계를 고려하면 좀 더 간결하고 명확한 의미 전달을 할 수 있는 명사들의 약자를 쓰지 않은 이유를 알 수 있다.

Acid와 Base의 비교 #1

ACID와 BASE의 비교 #2

분산 시스템에서 관리되는 데이터의 특징을 나타내는 BASE라는 단어는 의미의 전달보다는 중학교때 배운 산(Acid)과 염기(Base)와 같아보이려는 노력에 의해서 탄생했다는 것을 알 수 있다;;

CAP이론!

BASE의 탄생에 대해서는 그냥 그러려니~ 하고 넘어가고 CAP이론에 대해서 알아보자. 제일 처음에 있던 CAP 세모는 영어로 써져있고 글자도 많으니 좀 더 간단한 그림을 그려보면 다음과 같다.

CAP이론은
"분산 시스템에서는 위 그림의 3개 속성을 모두 가지는 것이 불가능하다!"
이다.

CAP이론에서 보여주는 3개의 속성에 대해서 각각 알아보면 다음과 같다.

Consistency

• 우선.. CAP이론에서 말하는 Consistency는 ACID의 'C'가 아니다! ACID의 'C'는 "데이터는 항상 일관성 있는 상태를 유지해야 하고 데이터의 조작 후에도 무결성을 해치지 말아야 한다"는 속성이다.
• CAP의 'C'는 "Single request/response operation sequence"의 속성을 나타낸다. 그 말은 쓰기 동작이 완료된 후 발생하는 읽기 동작은 마지막으로 쓰여진 데이터를 리턴해야 한다는 것을 의미한다.
• 모든 노드가 같은 시간에 같은 데이터를 보여줘야 한다. (저장된 데이터까지 모두 같을 필요는 없음)
• 정리해보면 Consistency라는 단어보다는 Atomic이라는 단어가 더 정확하게 특징을 나타낸다고 할 수 있다. (Atomic Data Object, Atomic Consistency)
• 그럼 "CAP가 아니라 AAP가 되어야 할텐데.." 라는 생각이 들 수도 있다. 어차피 ACID와 비교하기 위해서 BASE라는 단어도 억지로 만들어내는데 AAP보다는 CAP가 더 이뻐보이니 그렇게 했다고 생각하고 넘어가면 된다.

Availability

• 가용성
• 흔히 보는 단어이고 의미도 크게 혼동될 이유가 없어보인다. "특정 노드가 장애가 나도 서비스가 가능해야 한다"라는 의미를 가진다.
• 데이터 저장소에 대한 모든 동작(read, write 등)은 항상 성공적으로 리턴되어야 한다.
• 명확해 보이는 단어이기는 하지만 분산 시스템에서의 특징을 말하는 것이기 때문에 "서비스가 가능하다"와 "성공적으로 리턴"이라는 표현이 애매하다. 얼마동안 기다리는 것 까지를 성공적이라고 할 수 있느냐에 대한 문제가 남아있다. "20시간정도 기다렸더니 리턴이 왔어! Availability가 있는 시스템이야!"라고 할 수 없기 때문이다.
• 다시한번 "성공적으로 리턴"에 대해서 보면 모든 동작에 대해서 시스템이 "Fail!!"이라는 리턴을 성공적으로 보내준다면 그것을 Availability가 있다고 해야 하느냐에 대해서도 애매하다. CAP를 설명하는 문서들 중 "Fail!!"이라고 리턴을 하는 경우도 "성공적인 리턴"이라고 설명하는 것을 보았다.

Tolerance to network Partitions

• 원래는 Tolerance to network Partitions인데 보통은 Partition-tolerance라고도 한다.
• 노드간에 통신 문제가 생겨서 메시지를 주고받지 못하는 상황이라도 동작해야 한다.
• Availablity와의 차이점은 Availability는 특정 노드가 "장애"가 발생한 상황에 대한 것이고 Tolerance to network Partitions는 노드의 상태는 정상이지만 네트워크 등의 문제로 서로간의 연결이 끊어진 상황에 대한 것이다.

CAP 이론의 이해

CAP이론은 2002년 MIT의 Seth Gilbert와 Nancy Lynch에 의해서 증명되었다. CAP이론을 증명하는 논문에는 그림이 하나도 없어서 너무너무 재미 없다. 재미없는 논문 보다는 간단한 그림으로 CAP이론을 이해해볼 수 있다.

CAP이론을 이해해보기에 앞서.. 다음과 같은 상황을 가정해본다.

- 네트워크가 N1, N2로 구분된 분산환경이다.
- 각 DB 노드는 V=V0이라는 값을 가지고 있다.
- 각 네트워크에는 A, B라는 클라이언트가 존재한다.
- A는 V=V1이라고 쓰고 B가 그것을 읽는다.

이런 환경에서 메시지 전달 과정(M)에서 문제가 생겼을 때..

1. "C"가 꼭 필요한 상황인 경우
- A가 V1이라고 썼기 때문에 B는 V1이라고 읽을 수 있어야만 한다.
- A의 쓰기 동작은 M이 복구되기 전까지는 성공할 수 없다.
- M이 복구되기 전까지는 A의 Write는 block되거나 실패해야 한다. = Availability가 없음 = CP
- M이 문제가 생길 수 없도록 구성 = Partition-Tolerance가 필요 없음 = CA

2. "A"가 꼭 필요한 상황인 경우
- 어떤 경우에도 서비스가 Unavailable하면 안된다.
- A와 B가 꼭 동일한 데이터를 읽을 필요는 없음 = AP
- M이 문제가 생길 수 없도록 구성 = Partition-Tolerance가 필요 없음 = CA

3. "P"가 꼭 필요한 상황인 경우
- 메시지 전달 과정(M)에서 문제가 생기더라도 시스템에 영향이 가서는 안된다.
- A와 B가 꼭 동일한 데이터를 읽을 필요는 없음 = AP
- A의 쓰기 동작은 M이 복구되기를 기다린다. = 그동안 쓰기 서비스 불가능 = Availability가 없음 = CP

NoSQL??

NoSQL이라는 단어에 대해서 "적극적으로" 인터넷을 뒤져보았더니 다음과 같이 설명하고 있었다.

1. No SQL : SQL이 없다는 의미이다.
2. Not Only SQL : SQL뿐이 아니다.. SQL말고도 더 있다
3. NOn-relational operation database SQL : 비관계형 DB SQL

종합해보면 NoSQL은 "SQL이 없으면서도 SQL뿐만 아니라 다른거도 있는 비관계형 DB이다"라고 할 수 있다. 이건 누가 들어도 "대단해!"라고 말할만 하다.

하지만 이미 "BASE"라는 단어에서 느낀것이 있기 때문에 "NoSQL"이라는 단어에서 "N은 이런 의미이고 O는 이런 의미이고.."와 같이 단어 자체에 의미를 부여하려는 쓸데없는 시도는 무시하고 다시 NoSQL에 대해서 정의를 내리면 NoSQL은 "관계형 데이터 모델을 사용하지 않는 모든 Database 또는 Data Store"라고 할 수 있다.

NoSQL의 종류

NoSQL에는 어떤 것들이 있는지 웹서핑을 해봤다. 결과는 다음과 같다.

NoSQL의 종류에 대해서는 기본부터 알아보도록 하자.

• NoSQL의 데이터 모델은 기본적으로 Key-Value Store 모델을 사용한다.

기본 데이터 모델을 기준으로 각각의 Key-Value 관리 방법을 알아보면 다음과 같다.

1. Key-Value Oriented
   - Value가 String, Integer, List, Hash 등의 기본 자료형인 경우이다
2. - 이런 형식의 데이터 모델을 사용하는 경우를 Key-Value Oriented Database라고 한다.
   - 키에 대한 접근은 빠르지만 범위 검색에 대해서는 취약하다.
   - 이런 데이터 모델을 사용하는 DB로는 Redis, Memcached, Tokyo Cabinet  등이 있다.
3. Ordered Key-Value Oriented
   - Key-Value Oriented 모델의 경우 범위 검색에 대해서 취약하다는 단점이 있다.
   - 만약 Key, Value를 정렬해놓는다면 범위 검색에 대한 단점을 어느정도 극복할 수 있다.
4. Column Family Oriented
   - 하나의 Key에 하나의 Value만을 저장하는 단점을 극복했다.
   - 하나의 Key에 여러개의 Column을 저장한다.
   - Column-Value의 묶음을 Column Family라고 한다.
5. - 흔히 Column Oriented Database라고 하지만 Column Family Oriented Database라고 해야 한다. Column Oriented는 RDBMS에서 사용하는 데이터 모델 중 하나이다.
   - 보통은 Ordered Key-Value Oriented 모델을 사용한다. 다시 말하면 Key는 정렬되어 저장되고 Column도 Column Name별로 정렬되어 저장하는 모델을 사용한다.
   - 이런 데이터 모델을 사용하는 DB로는 HBase, Cassandra 등이 있다.
6. Document Oriented
   - Value에 저장되는 값이 Document(JSON, XML 등)이다.
   
   - 이런 데이터 모델을 사용하는 DB로는 MongoDB, CouchDB 등이 있다.

NoSQL 데이터 모델링

RDBMS의 데이터 모델링과 NoSQL의 데이터 모델링을 비교하면 다음과 같다.

다음과 같은 기능을 구현한다고 가정한다.

NoSQL로 구현할 때의 모델링 절차를 살펴보면 다음과 같다.

1. 데이터 분석
   - RDBMS도 모델링을 시작하기 위해서 데이터 분석을 해야 한다. 동일한 절차이지만 RDBMS와 NoSQL은 데이터에 대해서 서로 다른 시각으로 접근을 해야 한다.
   - RDBMS에서의 데이터 분석은 다음과 같다.
   
   - 반면에 NoSQL의 데이터 분석은 다음과 같다.
   
   
   1) 게시판 내에서 게시글은 시간순으로 정렬되어야 함
   2) 게시글:내용 = 1:1
   3) 게시글:댓글 = 1:N
   4) 댓글은 게시글 내에서 시간순으로 정렬되어야 함
   5) "정렬"에 별표
   - RDBMS는 데이터의 관계에 집중해서 데이터 분석을 진행하는 반면에 NoSQL은 표현되는 데이터와 정렬되는 특징에 집중해서 분석을 진행한다.
2. 쿼리 디자인
   - 데이터 분석을 마치면 NoSQL은 데이터의 특징을 고려해서 어떤 종류의 쿼리가 필요한지에 대해서 디자인한다.
   
3. 테이블 디자인
   - 쿼리 디자인에서 2가지 방법을 디자인했다. 각각의 쿼리에 맞는 테이블을 디자인하면 다음과 같다.
   - 쿼리 1
   
   - 쿼리 2
   
   - 각 쿼리에 맞는 테이블을 디자인했을 때 적합한 NoSQL 모델은 Document Oriented, Column Family Oriented 라고 할 수 있다.

NoSQL 언제 사용하면 좋을까?

NoSQL에 대해서 조사해봤더니 다음과 같은 정보를 얻을 수 있었다.

역시나 다들 "빅데이터 처리는 NoSQL이야!"라고 하는 것 같다. 그러면 다른 유명한 업체의 사용 경험을 들어보도록 하자!

1. Twitter 

2. Tumblr 

3. EVERNOTE

4. 결론

기대하는 결과가 나오지 않을 경우 질문을 바꿔보는 것도 좋은 방법이라 생각한다.

언제 NoSQL을 사용하면 안되나?

(바쁜 사람들을 위한 친절한)요약

1. RDBMS가 ACID라면 NoSQL는 BASE이다
2. 분산 시스템에서는 Consistency, Availability, Partition Tolerance의 특징을 모두 가지는 것이 불가능하다
3. NoSQL은 관계형 데이터 모델을 사용하지 않는 모든 Database 또는 Data Store를 말한다.
4. NoSQL의 기본 데이터 모델은 Key-Value이다. Value의 형식에 따라서 Key-Value, Column Family Oriented, Document Oriented로 구분되기도 한다.
5. 데이터 모델링에서 RDBMS는 테이블 디자인이 중요하지만 NoSQL은 쿼리 디자인이 중요하다.
6. RDBMS는 테이블 디자인에 정규화를 하지만 NoSQL은 데이터 비정규화를 한다.
7. 빅데이터 처리에 NoSQL이 꼭 필요한 것은 아니다.
8. 유행을 무조건 따르지 말고 SQL, NoSQL이 무엇인지 알아보고 내가 다루려는 Data에 대해서 파악을 한 후에 사용해야 한다!

참고자료

• Eric Brewer, "Toward Robust Distributed Systems"
  http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
• Nancy Lynch and Seth Gilbert, "Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services"
  http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf
• Coda Hale, "You Can't Sacrifice Partition Tolerance"
  http://codahale.com/you-cant-sacrifice-partition-tolerance/
• Jeff Darcy, "Availability and Partition Tolerance"
  http://pl.atyp.us/wordpress/index.php/2009/11/availability-and-partition-tolerance/
• Nati Shalom, "NoCAP - Part II Availability and Partition Tolerance"
  http://natishalom.typepad.com/nati_shaloms_blog/2010/11/nocap-part-ii-availability-and-partition-tolerance.html
• 조대협, 월간 마이크로소프트 2013년 3월호 Cover Story 1 "NoSQL이란 무엇인가?"
  http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=42440
• 조대협, "NoSQL 데이터 모델링 #1 - 데이터 모델과 모델링 절차"
  http://bcho.tistory.com/665
• 조대협, "NoSQL 데이터 모델링 #2 - 데이터 모델링 패턴"
  http://bcho.tistory.com/666
• Highly Scalable Blog, "NoSQL Data Modeling Techniques"
  http://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/
• Twitter, "Cassandra at Twitter Today"
  https://blog.twitter.com/2010/cassandra-twitter-today
• High Scalability, "Thumblr Architecture"
  http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html
• EVERNOTE Tech Blog, "WhySQL?"
  http://blog.evernote.com/tech/2012/02/23/whysql/