NoSQL 알기
NoSQL 정의
NoSQL은 Not Only SQL, 또는 No SQL로 많이 알려져 있습니다. 그러나 공식적으로 정의된 적이 없으며, NoSQL이란 단어는 영국 소프트웨어 개발자 Johan Oskarsson이 오픈소스 분산 데이터베이스의 토론을 위해 주관한 모임의 이름에서 유래 됐다고 합니다.
마틴파울러는 NoSQL이 아래의 조건을 만족하는 데이터 저장소라고 기술 하였습니다.
1. 대용량 웹 서비스를 위하여 만들어진 데이터 저장소
2. 관계형 데이터 모델을 지양하며 대량의 분산된 데이터를 저장하고 조회하는데 특화된 저장소
3. 스키마 없이 사용 가능하거나 느슨한 스키마를 제공하는 저장소
즉, NoSQL이란 빅데이터를 처리하기 위한 분산 데이터 저장소의 통칭 정도로 이해하면 쉽습니다.
CAP
CAP란 컴퓨터 과학 분야에서 분산 컴퓨터 시스템을 설명하는데 사용되는 이론입니다. 이론의 뜻은 “Consistency(일관성), Availability(가용성), Partition Tolerance(분할 허용성) 모두를 동시에 지원하는 분산 컴퓨터 시스템은 없다” 라고 정의 되어 있습니다.
Consistency(일관성) : 동시성, 동일성이라고도 하며, 다중 클라이언트에서 같은 시간에 조회하는 데이터는 항상 동일한 데이터임을 보증하는 것을 의미합니다. 즉, 어떤 값이 바뀌면 바뀌기 전의 데이터가 노출되면 안된다는 의미 입니다. 일관성은 RDBMS에서 지원하는 가장 기본적인 기능입니다. 그러나 NoSQL에서는 빠른 분산 처리를 위해 일관성을 희생하기도 합니다.
Availability(가용성) : 모든 클라이언트의 읽기와 쓰기 요청에 대하여 항상 응답이 가능해야 함을 보증하는 것을 의미 합니다. NoSQL은 클러스터 내에서 몇 개의 노드가 망가지더라도 다른 노드가 값을 가지고 있어 클라이언트 요청에 대한 응답을 반드시 할 수가 있습니다.
Partition Tolerance(분할 허용성) : 지역적으로 분할된 네트워크 환경에서 동작하는 시스템있습니다.. 두지역 간의 네트워크가 단절되거나 네트워크 데이터의 유실이 일어나더라도, 각 지역 내의 시스템은 정상적으로 동작해야 함을 의미 합니다.
분산컴퓨터 시스템에서 CAP중 두가지만 지원하는게 아니라 두가지를 지원하기 위해 한가지를 희생하는 것입니다. 이 이론은 2000년 전산학자 에릭 브루어가 가설을 제시하고, 2002년 세스 길버트와 낸시 린치가 증명하였습니다.
사진출처 : http://blog.nahurst.com/visual-guide-to-nosql-systems
CA : RDBMSs, 애스터 데이터, 그린플럼, 버티카
CP : 빅테이블, 하이퍼테이블, HBASE, MongoDB, 테라스토어, 스칼라리스, 버클리DB, 맴캐시DB, 레디스
AP : 다이나모DB, 카산드라, 볼드모트, 도쿄캐비닛, KAI, 심플DB, CouchDB, 리악
CAP 이론으로 나눈 NoSQL.
NoSQL의 저장방식
1. 키-값 모델 형식 : 레디스, 리악, 다이나모, 볼드모트 등이 키-값 구조로 데이터를 저장합니다. 키-값 모델은 단일키 처리만을 지원하기 때문에 복잡한 다중연산이 필요한 서비스나 값 기준 검색이 지원이 필요한 서비스에는 어울리지 않습니다.
2. 문서 모델 형식 : MongoDB, CoushBase, 테라스토어, 레이븐DB 등이 문서모델로 저장이 됩니다. 문서 모델 NoSQL의 키는 문서에 대한 ID로 표현이 됩니다. 또한 저장된 문서를 컬렉션으로 관리하며, 문서 저장과 동시에 문서 ID에 대한 인덱스를 생성합니다. 이 인덱스를 통해 O(1)의 시간안에 문서를 조회할 수 있습니다. 문서 모델은 관계형 데이터베이스와 유사한 검색 조건을 포함한 쿼리를 처리할 수 있있습니다. 그리고 B트리의 특성으로 인하여 한번 작성되면 자주 변하지 않는 정보를 저장하고 조회하는데 적합합니다. 예를들어 로그 저장, 타임라인 저장, 통계정보 저장등이 해당됩니다.
3. 컬럼 모델 형식 : HBASE, 카산드라, 하이퍼테이블이 이에 해당됩니다. 1은 map(또는 Dictionary)와 비슷하고, 2는 json, bson등의 구조를 상상하시면 편하지만 컬럼 모델 형식은 조금은 생소한 방법입니다. 컬럼은 컬럼 이름, 컬럼 값, 타임스탬프로 구성이 되어져 있으며, 컬럼의 집합은 row이고 row key는 각 row를 식별하는 값이 됩니다. row의 집합은 테이블 또는 키 스페이스가 됩니다. 몇가지 컬럼들을 묶어 컬럼 패밀리를 구성할 수도 있습니다. 컬럼 패밀리는 디스크 저장방법에 영향을 줍니다. 타임 스탬프란 값에 대한 버전이라고 이해하면 됩니다. user1 이란 row key에 score라는 컬럼이 있습니다. score를 50, 60, 70을 입력하면 score라는 이름의 컬럼이 3개가 되며, 각각 입력된 타임스탬프를 갖고 있습니다. 이때 값을 요청하게 되면 최근 타임스탬프의 값을 돌려주며, DB설정에는 컬럼의 유지 개수를 설정할 수도 있으며, 과거의 데이터도 조회할 수 있습니다. 컴럼 모델 형식은 느슨한 스키마를 제공합니다. 데이터를 저장하려면 테이블과 컬럼 패밀리를 미리 생성해주어야 합니다. 키-값 모델과, 문서 모델은 스키마 없이 사용이 가능합니다. 타임스탬프라는 역할로 데이터 업데이트가 없으며, 항상 INSERT만 있습니다. 컬럼 모델형식은 쓰기에 가장 특화가 되어 있습니다. 채팅내용이나 메일 저장소, 알림내용 저장, 실시간 분석을 위한 데이터 저장소 등의 서비스 구현에 적합합니다. 카산드라는 페이스북에서 메일과 쪽지 알림을 처리하기 위해 개발 하였습니다.
4. 그래프 모델 : 그래프 모델은 알려진 DB로는 Neo4J, OrientDB, HypergraphDB, Infinite Graph등이 있습니다. 그래프 모델은 노드와 관계로 이루어 지는데, 관계는 조회조건으로 사용되며, 방향성이 있습니다. 관계로 조회를 하다보면 결국 어마어마한 순회가 될 수도 있어 순회의 깊이를 제한하기도 합니다. 그래프 모델은 연관검색이나 친구추천, 내 친구가 좋아하는 영화 추천받기등에 활용할 수가 있습니다. Neo4J의 경우 Shard를 지원하지 않으며, 모든 데이터가 단일 서버에 존재해야 한다는 점이 있어 빅데이터와 어울리지 않는다는 의견도 있습니다.
당신의 선택은?
요즘 같은 시대에 기획자들의 컨텐츠를 따라가려면 한가지 DB를 사용하기에는 커다란 무리가 있습니다. 적어도 2, 3개의 DB를 가져가야 되죠. 게임을 개발하는데에 한 종류의 DB로 모든 것이 구현 가능해도 서비스에 문제가 발생할 것입니다. 기본 데이터는 RDBMS에 저장하고, 빠른 캐시성 대이터 읽고쓰기/정렬을 위해서는 Redis를 쓰고, 로그는 스키마에서 자유로운 MongoDB를 쓰는 등 적절한 곳에 DB등을 사용하여야 몸도, 마음도 편해질 것 같습니다.
결론
열심히 공부하자.
도움 책 : 이것이 레디스다 - 정경석 지음
