"NoSQL"에 대해 들어보셨나요? 최근 몇 년 동안 이 용어는 많은 관심을 받고 있습니다. "NoSQL"이라는 단어를 보면 "아니오!"의 약자로 착각할 수도 있습니다. 하지만 실제로는 "SQL 이상"의 약어입니다. 해당되는 경우 관계형 데이터베이스를 사용하되, 그렇지 않은 경우에는 반드시 관계형 데이터베이스를 사용해야 한다는 뜻입니다. 더 적절한 데이터 저장소를 사용하는 것을 고려하세요.
관계형 데이터베이스의 단점을 보완하기 위해 다양한 NoSQL 데이터베이스가 등장했습니다.
이 책에서 소개하는 NoSQL 데이터베이스를 더 잘 이해하기 위해서는 관계형 데이터베이스에 대한 이해가 필요합니다. 그럼 관계형 데이터베이스의 역사, 분류, 특징에 대해 살펴보겠습니다.
관계형 데이터베이스의 간략한 역사
1969년, 에드거 프랭크 코드(Edgar?6?1 Frank?6)는 관계형 데이터 모델의 개념을 처음 소개한 획기적인 논문을 발표했습니다. 안타깝게도 이 논문을 발표한 IBM은 IBM 내부 간행물에 불과했기 때문에 이 논문은 미지근한 반응을 보였고, 1970년 다시 ACM의 커뮤니케이션 잡지에 "대규모 공유 데이터 뱅크를 위한 데이터의 관계형 모델링"이라는 제목의 논문을 발표하여 마침내 주목을 받게 됩니다.
Cod의 관계형 데이터 모델 개념은 오늘날 관계형 데이터베이스의 기초가 되었습니다. 당시 관계형 데이터베이스는 열악한 하드웨어 성능과 느린 처리 속도로 인해 실제로 사용되지 않았습니다. 그러나 하드웨어 성능이 향상되고 사용 편의성과 우수한 성능이라는 장점이 부각되면서 관계형 데이터베이스가 널리 사용되고 있습니다.
다양성과 성능
이 책은 NoSQL 데이터베이스를 다루고 있지만 오해해서는 안 되는 중요한 전제가 있습니다. 이 전제는 "관계형 데이터베이스는 결코 성능이 낮은 것이 아니며, 매우 뛰어난 다용도성과 높은 성능을 가지고 있다"는 것입니다. 의심할 여지 없이 대부분의 애플리케이션에 가장 효율적인 솔루션입니다.
뛰어난 장점
널리 사용되는 범용 데이터베이스인 관계형 데이터베이스는 다음과 같은 뛰어난 장점이 있습니다.
데이터 일관성 유지(트랜잭션)
표준화를 전제로 하기 때문에 데이터 업데이트 시 오버헤드가 거의 없습니다(기본적으로 동일한 필드만 존재)
조인과 같은 복잡한 쿼리를 수행할 수 있습니다.
실용적인 결과와 전문적인 기술 정보(성숙한 기술)가 많이 있습니다.
관계형 데이터베이스의 가장 큰 장점 중 하나는 데이터 일관성을 유지한다는 것입니다. 데이터 일관성과 처리 무결성을 엄격하게 보장해야 할 때 관계형 데이터베이스를 사용하는 것이 잘못된 것은 아닙니다. 그러나 어떤 경우에는 조인할 필요가 없고 위에서 언급한 관계형 데이터베이스의 장점이 특별히 필요하지 않습니다. 이 시점에서 굳이 관계형 데이터베이스를 고집할 필요는 없어 보입니다.
관계형 데이터베이스의 단점
처리가 느리다
앞에서도 언급했듯이 관계형 데이터베이스는 성능이 매우 높습니다. 하지만 결국 모든 용도에 완벽하게 적용할 수 없는 획일적인 데이터베이스입니다. 특히 다음과 같은 처리에는 적합하지 않습니다.
대용량 데이터의 쓰기 처리
데이터 업데이트에 따른 테이블의 인덱싱 또는 테이블 아키텍처 변경.
필드가 고정되지 않은 경우 적용.
결과를 빠르게 반환해야 하는 간단한 쿼리 처리
。。。。。。
NoSQL 데이터베이스
관계형 데이터베이스의 단점을 보완하기 위해(특히 최근 몇 년 동안) NoSQL 데이터베이스가 등장했습니다. 관계형 데이터베이스는 널리 사용되며 복잡한 트랜잭션과 연결을 처리할 수 있습니다. 반면, NoSQL 데이터베이스는 특정 도메인에서만 사용되며, 복잡한 처리가 거의 필요 없고, 앞서 나열한 관계형 데이터베이스의 단점을 보완하는 데 그칩니다.
데이터가 분산되는 경향이 있습니다.
앞에서도 언급했듯이 관계형 데이터베이스는 대량의 데이터를 작성하는 데 적합하지 않습니다. 원래 관계형 데이터베이스는 JOIN에 기반을 두고 있었기 때문에 데이터 간의 연관성이 관계형 데이터베이스의 이름을 얻게 된 주된 이유입니다. 조인을 위해 관계형 데이터베이스는 데이터를 동일한 서버에 저장해야 했기 때문에 데이터 분산에 도움이 되지 않았습니다. 이에 반해 NoSQL 데이터베이스는 본질적으로 조인 처리를 지원하지 않으며 각 데이터가 독립적으로 설계되어 있어 여러 서버에 데이터를 쉽게 분산할 수 있습니다. 데이터가 여러 서버에 분산되어 있기 때문에 각 서버의 데이터 양이 줄어들고, 대량의 데이터를 써야 하는 경우에도 처리하기가 더 쉽습니다. 마찬가지로 데이터 읽기 작업도 당연히 쉬워집니다.
성능 및 확장성 개선
저희가 서버가 더 많은 데이터를 쉽게 처리하기를 원한다면, 두 가지 선택지가 있습니다: 하나는 성능을 개선하는 것이고, 다른 하나는 확장성을 높이는 것입니다. 차이점을 정리해 보겠습니다.
첫째, 성능 향상은 기존 서버 자체의 성능을 개선하여 처리 능력을 높이는 것을 의미합니다. 프로그래밍을 변경할 필요가 없는 매우 간단한 방법이지만 비용이 발생합니다. 성능을 두 배로 향상시키는 서버를 구입하려면 보통 2배 이상, 많게는 5~10배의 비용을 지출해야 합니다. 이 방법은 간단하지만 비용이 많이 듭니다.
반면, 규모를 늘리려면 저렴한 서버를 여러 대 사용하여 처리 능력을 높이는 방법이 있습니다. 절차의 변경이 필요하지만 저렴한 서버를 사용하기 때문에 비용을 통제할 수 있습니다. 게다가 앞으로는 저렴한 서버를 더 늘리기만 하면 됩니다.
데이터를 많이 처리하지 않는다면 굳이 사용할 필요가 없나요?
NoSQL 데이터베이스는 기본적으로 "대량의 데이터를 더 쉽게 쓰고 서버 수를 더 쉽게 늘릴 수 있도록" 설계되었습니다. 하지만 대량의 데이터에서 작동하지 않는다면 NoSQL 데이터베이스를 사용하는 것이 무의미하지 않을까요?
정답은 '아니요'이며, 실제로 대용량 데이터를 처리하는 데 유리합니다. 하지만 NoSQL 데이터베이스에는 적절히 활용할 수 있다면 도움이 될 다양한 기능이 있습니다. 2장과 3장에서 구체적인 예제를 소개할 것이며, 이러한 사용 사례를 통해 NoSQL 사용의 이점을 느낄 수 있을 것입니다.
데이터 캐싱이 잘 되었으면 좋겠어요.
배열형 데이터를 고속으로 처리하고 싶습니다.
모든 데이터를 저장하고 싶습니다.
다양한 NoSQL 데이터베이스
키-값 저장소, 문서 데이터베이스, 열 저장소 데이터베이스 등 다양한 유형의 NoSQL 데이터베이스가 있으며 각 데이터베이스에는 고유한 특성이 있습니다. 다음 섹션에서는 NoSQL 데이터베이스의 유형과 특징에 대해 살펴보겠습니다.
NoSQL 데이터베이스란 무엇인가요?
NoSQL은 말하기는 쉽지만 몇 가지 유형이 있을까요? 제가 글을 쓰기 시작했을 때 공식 NoSQL 웹 사이트에서 이미 122가지 유형이 있다는 것을 확인했습니다. 또한 공식 웹사이트에서는 이 책에서 다루지 않은 그래프 데이터베이스, 객체 데이터베이스 등 다양한 카테고리에 대해 설명하고 있습니다. 우리가 깨닫지 못하는 사이에 이미 수많은 NoSQL 데이터베이스가 존재합니다.
이 섹션에서는 대표적인 NoSQL 데이터베이스를 소개합니다.
키-값 저장소
데이터가 키와 값으로 저장되는 가장 일반적인 NoSQL 데이터베이스입니다. 처리 속도가 빠르지만 키의 정확히 일치하는 쿼리를 통해서만 데이터를 가져올 수 있습니다. 데이터가 저장되는 방식에 따라 임시, 영구, 또는 두 가지 모두로 분류할 수 있습니다.
임시
Memcached가 이 범주에 속합니다. 임시는 "데이터가 손실될 수 있다"는 의미로, 멤캐시는 모든 데이터를 메모리에 저장하므로 저장 및 읽기 속도가 매우 빠르지만 멤캐시가 중지되면 데이터가 사라집니다. 데이터가 메모리에 저장되기 때문에 메모리 용량을 초과하는 데이터는 연산할 수 없습니다(이전 데이터는 손실됨).
메모리에 데이터 저장
매우 빠른 저장 및 읽기 처리가 가능합니다.
데이터가 손실될 수 있습니다.
영구
도쿄 타이런트, 플레어, ROMA 등이 이 범주에 속합니다. 등이 이 범주에 속합니다. 임시와 달리 영구는 "데이터가 손실되지 않는다"는 의미입니다. 여기서 키-값 저장소는 멤캐시드처럼 메모리에 데이터를 저장하지 않고 하드 드라이브에 데이터를 유지합니다. 데이터를 메모리에서 처리하는 멤캐시와 비교하면 하드 드라이브에서의 IO 작업이 불가피하기 때문에 성능 차이가 있습니다. 하지만 가장 큰 장점은 데이터가 손실되지 않는다는 것입니다.
하드 드라이브에 데이터를 저장
매우 빠르게 저장하고 읽을 수 있지만 멤캐시와 비교할 수 없음
데이터가 손실되지 않음
두 가지 장점 모두
Redis가 이 범주에 속하며, 임시 키-값 저장소와 영구 키-값 저장소의 장점을 결합한 애드혹(ad hoc), 임시 및 영구 키-값 저장소입니다. Redis는 먼저 데이터를 메모리에 저장하고 특정 조건(기본값은 15분마다 1회 이상, 5분에 10개 이상의 키, 10,000개 이상의 키)이 충족될 때 하드 드라이브에 씁니다. 이렇게 하면 메모리에 있는 데이터의 처리 속도와 하드 디스크에 쓰는 데이터의 영속성을 모두 보장할 수 있습니다. 이 유형의 데이터베이스는 특히 배열형 데이터를 처리하는 데 적합합니다.
메모리와 하드 디스크에 동시에 데이터 저장
매우 빠른 저장 및 읽기 처리를 수행할 수 있습니다.
하드 디스크에 저장된 데이터는 사라지지 않습니다(복구 가능).
배열형 데이터 처리에 적합
문서 지향 데이터베이스
MongoDB와 CouchDB가 이 범주에 속합니다. 이들은 NoSQL 데이터베이스이지만 키-값 저장소와는 다릅니다.
테이블 구조가 정의되지 않음
문서 지향 데이터베이스는 다음과 같은 특징이 있습니다: 테이블 구조가 정의되어 있지 않더라도 마치 정의된 것처럼 사용할 수 있습니다. 관계형 데이터베이스의 테이블 구조를 변경하는 것은 번거롭고 일관성을 위해 프로그램을 수정해야 합니다. 그러나 NoSQL 데이터베이스는 이러한 문제를 제거할 수 있으며(일반적으로 절차가 정확합니다) 매우 편리하고 빠릅니다.
복잡한 쿼리 조건을 사용할 수 있습니다.
키-값 저장소와 달리 문서 지향 데이터베이스는 복잡한 쿼리 조건을 통해 데이터를 가져올 수 있습니다. 트랜잭션 처리 및 JOIN과 같은 관계형 데이터베이스의 처리 기능은 없지만 기본적으로 다른 처리는 가능합니다. 사용하기 매우 쉬운 NoSQL 데이터베이스입니다.
테이블 구조를 정의할 필요가 없습니다.
복잡한 쿼리 조건을 사용할 수 있습니다.
컬럼 지향 데이터베이스
Cassandra, Hbase, HyperTable이 모두 이 범주에 속합니다. 이러한 유형의 NoSQL 데이터베이스는 최근 몇 년 동안 데이터 볼륨이 폭발적으로 증가함에 따라 특히 각광받고 있습니다.
행 지향 및 열 지향 데이터베이스
일반 관계형 데이터베이스는 데이터를 동작 방식으로 저장하며 특정 조건에 대한 데이터 가져오기와 같은 동작 방식으로 데이터를 읽는 데 탁월합니다. 이러한 이유로 관계형 데이터베이스를 행 지향 데이터베이스라고도 합니다. 이와 대조적으로 열 지향 데이터베이스는 데이터를 열에 저장하며 열에서 데이터를 읽는 데 능숙합니다.
높은 확장성
열 지향 데이터베이스는 확장성이 뛰어나며 데이터가 증가해도 그에 상응하는 처리 속도(특히 쓰기 속도)가 저하되지 않아 대량의 데이터를 처리해야 하는 상황에서 주로 사용됩니다. 또한 일괄 처리 프로그램의 메모리로 컬럼 지향 데이터베이스를 활용하여 대량의 데이터를 업데이트하는 경우에도 유용합니다. 그러나 컬럼 지향 데이터베이스에 대한 사고 방식이 기존의 데이터베이스 저장소에 대한 사고 방식과 매우 다르기 때문에 컬럼 지향 데이터베이스를 적용하기는 매우 어렵습니다.
높은 확장성(특히 쓰기 처리)
적용이 어렵습니다.
최근 트위터나 페이스북과 같이 대량의 데이터를 업데이트하고 쿼리해야 하는 웹 서비스가 점점 더 많아지고 있습니다. 열 지향 데이터베이스의 이점은 이러한 서비스 중 일부에 매우 유용할 수 있지만 이 책에서 다루는 내용과는 거의 관련이 없으므로 자세히 설명하지 않겠습니다.
요약:
NoSQL은 SQL이 없는 것은 아니지만, SQL 그 이상입니다.
NoSQL은 방대한 양의 데이터와 매우 동시적인 요청을 처리할 때 트랜잭션과 같은 메커니즘으로 인한 SQL 데이터베이스의 성능 부족을 보완하기 위해 등장했습니다.
NoSQL은 SQL을 대체할 수 있는 솔루션이 아니라 하나의 대안일 뿐입니다.
대부분의 NoSQL 제품은 대용량 메모리와 고성능 랜덤 읽기 및 쓰기(예: 고성능 SSD 어레이)를 기반으로 하므로 일반 소규모 기업은 NoSQL을 선택할 때 신중해야 합니다! 비용 낭비와 프로젝트 일정 지연을 초래할 수 있는 단순히 NoSQL을 위한 NoSQL은 하지 마세요.
NoSQL이 전부는 아니지만 대규모 프로젝트에서는 종종 필요합니다!