NoSQL DB 중 먼저 알아볼 대상은 키-값 데이터베이스다.
가장 대표적이고 가장 단순한 구조의 데이터베이스다.
[NoSQL] 키-값 데이터베이스 / Key-Value Database or Key-Value store
단순한 구조인 만큼 많은 기능을 제공하지는 않으나, 단순성으로 인해 얻는 이점이 있다.
단순성 simplicity
고유의 키를 통해 값을 가져온다는 단순한 구조의 형태이다.
단순한 구조이므로 구현이 쉽다는 장점이 있으나 기능상 다양한 기능을 기대하기는 어렵다.
값의 일부를 검색한다거나 조인을 통해 복잡한 연산 등은 불가능하다.
값에 대한 타입 제한이 없으므로 원하는 형태의 데이터를 입력할 수 있다.
또한 복잡하지 않으므로 결과적으로 빠른 연산을 기대할 수 있다.
속도 speed
단순성으로 비롯되는 빠른 속도는 key-value 방식의 장점이라고 할 수 있다.
또한 빠른 연산을 위해서 메모리 (캐시메모리, RAM) 에서 데이터를 관리하는 방식을 사용한다.
조회 작업 시 디스크에서 데이터를 가져오지만 같은 key값에 대해 조회했던 이력이 있어서 캐시메모리에 이미 저장된 데이터가 있다면 디스크를 조회하는 것보다 더 빠른 결과를 내보낼 수 있다.
입력 작업의 경우에도 마찬가지로 캐시메모리에 일단 값을 입력하고 결과값을 사용자에게 회신한 뒤에 실제적인 데이터를 데이터베이스에 입력하는 방식으로 처리하면 더 빠른 연산 결과를 내보낼 수 있다.
단, 메모리의 경우는 한정적인 자원이고 세션이 끊기거나 작업이 종료되는 경우 날라가므로 관리가 필요하다.
메모리를 통해 key-value database 방식을 많이 사용하는 형태는 쇼핑몰의 장바구니를 예로 들 수 있겠다.
로그인 하지 않고 장바구니에 담아둔 내역들이 인터넷 브라우저를 켜둔 상태에서 계속적으로 유지가 되는 형태를 본 적이 있을 것이다.
단순한 형태의 구조이므로 키-값 방식을 적용하기에도 적합해보인다.
확장성 scalability
NoSQL에서 말하는 확장성이란 시스템에 걸리는 부하를 적절히 조정하기 위해 필요한 만큼의 서버를 증감하는 것을 말한다.
분산 데이터베이스임을 전제로 하고 서버를 늘려서 더 많은 부하를 감당할 수 있도록 하거나 사용량이 적을 때는 서버를 줄이는 형태의 작업을 확장성이라고 말한다.
읽기와 쓰기 작업을 처리하는데 여러 방식이 있으나 책에서 두 가지 방식을 소개하고 있다.
- 마스터 - 슬레이브 복제 (Master-slave replication)
: 쓰기보다 읽기가 많이 일어나는 구조에 적합한 방식
: 읽기/쓰기를 모두 수행하는 마스터 서버와 이 데이터를 기준으로 읽기 요청에만 응답하는 슬레이브 서버로 구성됨
: 단순함이 최대 장점. 클러스터 내의 모든 서버는 마스터 서버와만 통신하면 됨.
: 마스터가 고장나면 쓰기작업이 불가한 구조 > 마스터가 고장나는 경우 슬레이브 중 하나를 마스터로 세워서 처리함
- 마스터 없는 복제 (Masterless replication)
: 쓰기가 많이 일어나는 구조에 적합한 방식
: 데이터를 모든 서버에서 읽고 쓰는 작업을 처리하므로 각각의 서버에서 처리한 내용을 공유해야 한다.
: 서버끼리 유기적으로 연결되는 링(Ring) 구조가 적합한 구조이다.
키-값 데이터베이스의 구성요소
1) 키
- 값을 가져오기 위한 식별자, 이름공간 내에서 고유해야 한다.
- 이름공간이란 키-값 쌍을 묶어둔 것으로 데이터베이스라고 보면된다. 즉 키-값 데이터베이스 내에서 키는 중복될 수 없다. 다만 키가 다르다면 값은 얼마든지 중복되어도 관계없다.
- 키를 통해 값을 찾아와야 하므로 명명 규칙을 세워서 의미있는 값으로 만드는 것이 좋다 (RDBMS에서는 키값은 의미없는 숫자 등으로 생성)
- 키값을 처리하기 위해서 해시(Hash) 함수를 사용하기도 한다.
2) 값
- 키-값 데이터베이스에서 값의 데이터 타입에는 큰 제약이 없다.
- 정수, 실수, 문자열, BLOB, JSON 객체, 이미지, 오디오, list 등... 다양한 값이 들어갈 수 있다.
단순한 구조로부터 얻을 수 있는 속도와 확장성에 대한 장점을 알아봤고, 기본적인 구조에 대해서 알아봤다.
키-값 데이터베이스는 그럼 어떤 단점과 한계점을 가지고 이를 보완하기 위해 어떤 방식으로 설계해야 하는지 알아보자.
단점과 한계점
1) 값 검색에 대한 한계
- 키를 통해 값을 검색하고 수정 및 삭제를 진행할 수 있으나, 값을 기준으로 한 검색은 어렵다.
=> 방법이 없는 것은 아니나 키를 기준으로 한 검색보다는 효율성이 떨어진다.
- 값에 대해 텍스트 검색을 하는 방법 (Riak)
- 키만 사용해서 검색하는 경우 보조 인덱스 (Secondary Index)를 사용하여 값의 속성을 인덱스로 만들 수 있음
2) 범위 질의를 지원하지 않음
- 시작일 ~ 종료일 사이의 데이터를 검색하거나 특정 범위 내의 데이터를 검색하는 기능 없음
- 이 역시 보조 인덱스를 사용해서 기능을 보완해야 한다.
3) RDBMS (관계형 데이터베이스) 의 SQL처럼 활용성 있는 질의언어가 없음
- 간단한 조회를 위한 구조이므로 질의 언어가 없음
- 일부 데이터베이스의 경우 XML, JSON 등의 데이터 구조를 지원하므로 이를 이용해서 검색할 수 있다.
설계 시 고려해야 하는 것
잘 설계된 키는 코드를 더 읽기 쉽게 하며, 키-값 데이터베이스의 관리 효율성을 높인다.
키를 설계함에 있어서 명명규칙을 따르는 것이 좋으며, 아래의 사항을 고려하는 것이 좋다고 한다.
- 단어 사용 시 애매하지 않은 단어를 이용해서 명확하게 표현하는 것이 좋다.
- 키를 만들기 위해 공통 구분자를 사용한다. 일반적으로 사용되는 것은 : (콜론) 이다.
- 구간 검색을 쉽게 하기 위해 범위를 기반으로 하는 용어를 사용한다. (ex. 날짜나 정수형)
- 키는 가능한 짧게 만든다.
잘 설계된 키는 코드의 가독성을 높일 뿐 아니라 코드의 양 자체를 줄일 수 있다.
또한 범위를 기반으로 하는 용어를 키에 포함시키면 키-값 데이터베이스의 한계로 지적되는 검색을 용이하게 할 수 있다. (물론 보조 인덱스 등으로 검색하는게 효율성은 높다고 한다.)
단, 키에 제약이 있을 수 있으므로 사용하고자 하는 데이터베이스의 제약을 확인해봐야 한다.
키-값 데이터베이스를 적용한 NoSQL로 가장 유명한 Redis (https://redis.io/) 의 경우는 다양한 타입을 지원하여 키 값을 생성하는데 큰 제약이 없는 편이다.
그렇다면 키-값 데이터베이스에서 키만 잘 설계하면 될까?
물론 키를 설계하는 게 제일 중요하겠지만 값의 경우도 고려할 사항이 있다.
- 구조화 된 데이터 유형은 대기 시간을 줄이는 데 도움이 된다.
: 여기서 말하는 대기시간은 데이터를 디스크에서 읽어들이는데 사용되는 시간을 말한다.
: 대기 시간을 줄이기 위해서는 자주 사용되는 값을 메모리에 저장하는 방식이 있으나, 메모리 공간이 부족하다는 제약이 있다.
: 다른 방법으로는 자주 사용되는 속성을 함께 저장하는 방식이다. 자주 사용될 대상을 묶어서 저장해두어 한 번 조회했을 때 값을 가져올 수 있으므로 데이터 탐색 횟수를 줄일 수 있다.
: ★이 경우 중복된 데이터가 값에 여러개 들어갈 수 있으나 키-값 데이터베이스에서는 큰 문제가 되지 않는다.★
의도적인 비정규화로 데이터 탐색 횟수를 줄이기 위한 방안이다.
- 값이 크면 읽기/쓰기 연산이 비효율적일 수 있다.
: 자주 사용될 대상을 묶어서 저장하라는 위의 내용과 약간은 상반되는 부분이 있지만, 정도를 지켜야 한다는 의미이다.
: 예를 들어 주문정보를 담고 있을 때, 대상에 모든 주문 정보를 담게 되면 데이터 읽기 및 주문정보 갱신 시 쓰기에도 많은 시간을 소요하게 된다.
: 값이 아주 큰 경우는 키-값 데이터베이스가 아닌 문서 데이터베이스를 사용하는 것이 좋다.
참고 : 키-값 데이터베이스를 위한 설계 패턴
- TTL (Time to Live) 키
- 테이블 모방
- 집계
- 원자 집계
- 열거형 키
- 인덱스
참고 도서 [NoSQL 철저입문 / 길벗 출판사]
'DataBase' 카테고리의 다른 글
[NoSQL] 기본 개념 정리 (0) | 2018.11.28 |
---|---|
JDBC와 ODBC의 차이점에 대해서 (2) | 2011.03.30 |