[컴퓨터월드] NoSQL이라는 개념은 20여 년 전 처음 사용된 이래 발전을 거듭해 왔으며, 현재는 마이크로서비스 아키텍처(MSA)를 위한 필수 항목으로 자리 잡게 됐다. 주지된 바와 같이 데이터베이스(DB) 환경은 SQL 즉 관계형 데이터베이스 관리 시스템(RDBMS)의 세계에서 점차 NoSQL 로 바뀌어 가고 있다. 물론 SQL과 NoSQL 외에도 NewSQL, 시계열 DB, 검색엔진 등 다양한 형태의 DB 종류들이 생겨나고 있지만 현재 DB 생태계를 양분하고 있는 건 SQL과 NoSQL이라고 할 수 있다.

NoSQL은 ‘Not Only SQL’ 또는 ‘Non-SQL’의 약자로 통칭 SQL을 사용해 데이터를 처리하는 시스템인 RDBMS와 다른 방식을 가진 DBMS를 말한다. NoSQL은 스키마리스(schemaless), 대용량 데이터 처리, 분산 처리, 고가용성 등의 특징을 갖고 있으며 유연한 데이터 모델 및 높은 확장성과 성능을 가진다는 장점이 있다. 하지만 복잡한 조인(join) 연산 및 데이터 일관성 보장이 쉽지 않다는 단점도 있다. 그러므로 이러한 장단점을 파악해 워크로드의 상황에 맞게 사용하는 것이 매우 중요하다.

이처럼 NoSQL은 많은 산업군에서 사용하는 DB가 됐지만, 여전히 RDBMS에 친숙한 사용자들은 NoSQL을 어떻게 사용해야 하는지 잘 모르고 있는 것이 현실이다. SQL과 NoSQL이 구조적으로 어떻게 다른지, NoSQL을 잘 사용하려면 어떤 형태로 디자인해야 하는지 등에 대해 본 기고를 통해 알아보고자 한다.

SQL vs NoSQL

SQL과 NoSQL 사이에는 구조적인 차이점이 있다. 첫 번째는 데이터 모델이다. SQL은 테이블 기반의 관계형 모델이지만 NoSQL은 다양한 형태의 모델이 존재한다. 예를 들어 키-값(key-value), 컬럼-패밀리(column-family), 도큐먼트(document), 그래프(graph) 등이 있다. 두 번째는 스키마의 유무다. SQL은 고정된 스키마가 존재하지만, NoSQL은 유연한 스키마 또는 스키마가 없는 형태로 구성될 수 있다. 세 번째로, NoSQL은 SQL에 비해 데이터의 관계가 명확하지 않다. 그래서 NoSQL은 외래키와 같은 형태가 존재하지 않는다. 네 번째는 ACID(원자성·일관성·독립성·지속성)의 보장이다. NoSQL은 데이터의 무결성과 일관성을 강하게 보장하지는 않는다. 다섯 번째, SQL은 데이터 정규화를 통한 중복을 허용하지 않는 것이 일반적이지만 NoSQL은 필요에 따라서 중복을 허용하기도 한다. 이처럼 여러 가지 구조적인 차이점들로 인해 NoSQL을 사용할 때 SQL과 같은 방식으로 접근하면 안 된다. 다음은 각각의 NoSQL 별로 디자인 패턴을 어떻게 가져가야 하는지 살펴보도록 하겠다.

키-값 DB 디자인 패턴

키-값 DB(Key-Value DB)는 값과 값을 가져오기 위한 식별자인 키가 한쌍으로 묶여 있는 가장 단순한 구조의 DB다. 그렇기에 높은 읽기 성능을 가질 수 있다. 하지만 단순한 구조로 돼있어 SQL처럼 복잡한 연산이나 다양한 기능을 제공하진 않는다. 그래서 이러한 단점을 보완하고자 다양한 디자인 패턴을 응용해 사용이 가능하다.

먼저 키를 복합적으로 사용해서 구성할 수 있다. 예를 들어 ‘type:id:attribute’처럼 일관된 키 이름을 사용해 관련 데이터를 논리적으로 그룹화할 수 있다. 또한 단일 값에 JSON 형태로 저장해 읽기 성능을 높일 수도 있다. 보조 인덱스를 활용하거나 버전 관리도 가능하다. 데이터 삭제 시에는 TTL을 활용해 반복적인 삭제 작업을 줄일 수도 있다. 이러한 패턴들은 상황에 따라 조합해 사용이 가능하며 애플리케이션의 요구사항 및 데이터 접근 방식 등을 고려해 적절한 패턴을 선택해야 한다.

도큐먼트 DB 디자인 패턴

도큐먼트 DB(Document DB)는 JSON 또는 BSON 형식의 유연한 동적 문서에 데이터를 저장하는 NoSQL DB다. 주로 콘텐츠 관리나 전자상거래 및 소셜 미디어 애플리케이션에서 대규모 비정형 데이터를 빠르게 처리하기 위한 용도로 많이 사용하고 있다. 그래서 도큐먼트 DB의 디자인 패턴은 데이터의 유연성과 쿼리 효율성을 최적화하는 데 중점을 두는 것이 일반적이다.

임베디드 문서 패턴처럼 관련 데이터를 단일 문서 내에 중첩해 읽기 성능을 높이거나 참조 패턴처럼 관련 문서를 참조로 연결할 수도 있다. 참조 패턴을 사용하게 되면 데이터의 중복을 최소화할 수 있으며 유연성을 강화할 수 있다. 이 두 가지 패턴을 적절히 섞은 형태도 가능하다. 또한 서브 문서 패턴, 시계열 데이터 패턴, 트리 구조 패턴 등 성능과 유연성, 동시성, 데이터 중복과 같은 특징들을 고려해 애플리케이션의 요구사항에 따라 적절히 선택해야 한다.

컬럼-패밀리 DB 디자인 패턴

컬럼-패밀리 DB(Column-family DB)는 높은 수준의 확장성, 성능 및 내결함성으로 대량 데이터를 저장하고 관리하도록 설계된 NoSQL DB다. 데이터는 서로 관련된 컬럼 그룹에 저장되며 대규모 데이터의 효율적인 저장과 빠른 읽기/쓰기 성능을 최적화하는 데 중점을 둔다.

관련 데이터를 단일 로우에 저장하는 와이드 로우 패턴, 타임스탬프를 컬럼 이름으로 사용하는 시계열 데이터 패턴, 미리 계산된 집계 결과를 별도 컬럼 패밀리에 저장하는 집계 패턴, 보조 인덱스를 사용하는 인덱싱 패턴 등이 있으며 다차원 모델링을 하거나 요약 데이터를 생성하고 NULL 값을 저장하지 않는 등의 특정 영역에 특화된 패턴들도 있다.

이러한 패턴들은 각 컬럼형 DB의 제공 기능과 함께 사용이 가능하며 모델링 시에 읽기 패턴을 우선적으로 고려하는 것이 중요하다. 대규모 분산 환경에서의 확장성과 가용성도 함께 고려해야 한다.

그래프 DB 디자인 패턴

그래프 DB(Graph DB)는 데이터 간의 복잡한 관계를 관리하도록 설계된 NoSQL DB다. 데이터는 노드와 엣지로 저장되며 노드는 엔티티를 나타내고 엣지는 노드 간의 관계를 나타낸다. 그렇기에 그래프 DB의 디자인 패턴은 관계를 중심으로 데이터를 모델링하고 효율적으로 탐색하는 데 초점을 맞춘다. 특히 노드에 레이블을 사용하거나 관계의 방향을 명확히 정의하는 형태로 구성되며 트리 구조처럼 계층구조를 노드와 관계로 표현하거나 파티셔닝 등 논리적으로 분할하는 패턴을 가질 수도 있다.

자주 사용하는 경로를 미리 저장하거나 속성, 엣지에 인덱싱을 생성하는 패턴도 있다. 또한 관계에 동적으로 변하는 가중치를 부여할 수도 있고 메타데이터를 별도 노드에 저장해 스키마 정보 및 그래프 통계를 관리할 수도 있다. 그래프 DB 설계는 비즈니스 도메인의 관계를 정확히 표현하는 것이 중요하며 쿼리 패턴을 예상해 모델을 최적화하는 것이 필요하다.

NoSQL의 사용 사례

NoSQL의 구조와 유형은 비즈니스에 따라 달라진다. 다음은 다양한 유형의 NoSQL에 대한 구체적인 용도의 예시다.

• 데이터 관계 유형 : 복잡한 데이터 집계와 이러한 지점 간의 관계 관리는 일반적으로 그래프 기반 NoSQL DB로 처리된다. 여기에는 추천 엔진, 지식 그래프, 사기 탐지 애플리케이션 및 소셜 네트워크가 포함되며, 다양한 데이터 유형을 사용하는 사람들 간에 연결이 이뤄진다.

• 로우 레이턴시(Low Latency) 유형 : 게임, 홈 피트니스 애플리케이션, 광고 기술 모두 실시간 데이터 관리를 위해 높은 처리량을 필요로 한다. 이 인프라는 시장 입찰가 업데이트나 가장 관련성 높은 광고 노출 등 소비자에게 최고의 가치를 제공한다. 웹 애플리케이션은 디스크 스토리지에서 발생할 수 있는 지연 없이 빠른 응답 시간을 제공하고 사용량 급증을 관리하기 위해 인메모리 NoSQL DB가 필요하다.

• 확장 및 대용량 데이터 유형 : 이커머스에서는 특가 세일이나 연말 쇼핑 시즌 등 사용량이 급증할 때 이를 관리할 수 있는 기능이 필요하다. 키-값 DB는 단순한 구조로 트래픽이 많을 때 쉽게 확장할 수 있어 이커머스 애플리케이션에서 자주 사용된다. 이러한 민첩성은 게임, 애드테크, 사물인터넷(IoT) 애플리케이션에 유용하다.

키–값 DB 솔루션 종류

• 레디스(Redis) : 레디스랩스가 지원하는 레디스 엔터프라이즈는 오픈소스 키-값 기반의 NoSQL 인메모리 DB다. 이 시스템은 사용하기 쉽고, 강력한 일관성을 제공하며, 유연한 스키마리스 모델을 갖추고 있다. 또한 고가용성과 쉬운 배포가 특징이다. 레디스는 목록, 집합, 비트맵, 해시 등 다양한 키-값 유형을 지원한다. 뿐만 아니라 플러그인 모듈을 통해 추가적인 데이터 구조, 검색 기능, 그래프, JSON, XML 등의 모델도 지원할 수 있다. 레디스 엔터프라이즈는 온프레미스 환경은 물론 클라우드에서 관리형 서비스로도 제공된다. 실시간 인덱싱, 쿼리 기능, 그리고 전문 검색 엔진이 포함돼 있어 다양한 사용 사례에 적용할 수 있다.

• AWS 다이나모DB(AWS DynamoDB) : AWS 다이나모DB는 규모와 관계없이 ms 응답 시간을 제공하는 서버리스, NoSQL, 완전 관리형 DB 서비스다. 가장 큰 장점은 사용한 만큼만 비용을 지불하면서 애플리케이션을 개발 및 실행할 수 있다는 점이다. 또한 사용자는 원하는 양의 데이터를 저장 및 검색하고 모든 수준의 요청 트래픽을 처리할 수 있는 DB 테이블을 만들 수 있다. 사용자는 다운타임이나 성능 저하 없이 테이블의 처리 용량을 늘리거나 줄일 수 있으며, 개발자와 관리자는 AWS 관리 콘솔을 사용해 리소스 사용률과 성능 메트릭을 모니터링할 수 있다. 민감한 데이터를 보호하기 위해 미사용 데이터 암호화(Encryption at Rest) 기능을 제공하며, 온디맨드 백업 기능을 이용해 사용자가 장기 보존 및 규정 준수 요구 사항을 위해 테이블의 전체 백업을 생성할 수 있다.

• 리악(Riak) : 이 시스템은 분산 NoSQL 키-값 DB로, 진보된 지역적, 다중 클러스터 복제 기능을 갖추고 있다. 이 기능 덕분에 하드웨어 장애나 네트워크 단절이 발생하더라도 데이터의 읽기와 쓰기가 원활하게 이뤄진다. 고가용성을 보장하는 마스터 없는 아키텍처를 채택하고 있어, 클러스터 내 데이터 분산을 자동화함으로써 빠른 성능과 안정적인 사업 연속성을 제공한다. 또한 물리적 하드웨어를 선형적으로 확장할 수 있어 운영 부담을 크게 늘리지 않고도 서비스 수용 능력을 쉽게 증가시킬 수 있다.

• 오라클 NoSQL DB(Oracle NoSQL Database) : 오라클 NoSQL DB는 문서, 키값 및 고정 스키마 데이터를 위한 예측 가능한 짧은 대기 시간, 동적 확장성, 고성능 및 안정적인 데이터 스토리지를 제공하는 완전 관리형 DB 클라우드 서비스다. 단 몇 분이면 손쉽게 서비스를 시작할 수 있다. 오라클에서 완벽하게 관리하기 때문에 개발자는 기본 인프라, 소프트웨어, 보안 및 고가용성을 관리하는 번거로움 없이 애플리케이션 개발 및 데이터 저장소 요구 사항에만 집중할 수 있다.

도큐먼트 DB 솔루션 종류

• 몽고DB(MongoDB) : 몽고DB가 관리하고, GNU 라이선스(Gnu Affero General Public License)와 아파치(Apache) 라이선스의 조합하에 퍼블리싱되는 무료 오픈소스 크로스 플랫폼 문서 지향 DB다. 몽고DB는 스키마가 있는 JSON 및 유사 문서를 사용하며, 다양한 규모의 기업에서 수천 건의 배포를 최적화하면서 얻은 운영 베스트 프랙티스를 제공한다. 클라우드 기반 서비스로 DB 관리, 설정 및 환경 구성, 소프트웨어 패치, 모니터링 및 백업을 처리할 수 있으며, 분산 DB 클러스터로 운영된다. 주요 기능으로는 완전 관리형 백업, 특정 시점 복구, 실시간 성능 패널, 사용자 지정 가능 알림 등이 있다.

• 카우치DB(CouchDB) : 데이터를 수집하고 JSON 기반 문서 형식으로 저장하는 오픈소스 NoSQL 문서 DB다. 관계형 DB와 달리, 카우치DB는 다양한 컴퓨팅 디바이스, 모바일 전화 및 웹 브라우저에서 레코드 관리를 간소화하는 스키마 없는 데이터 모델을 사용한다. 카우치DB는 다중 버전 동시성 제어(MVCC)의 형태를 구현하므로 쓰기 중에 DB 파일을 잠그지 않는다. 충돌은 애플리케이션이 해결하도록 내버려둔다. 충돌을 해결하는 것은 일반적으로 데이터를 처음에 도큐먼트 중 하나로 병합해 오래된 것을 삭제하는 것을 수반한다.

• 카우치베이스(Couchbase) : 카우치베이스 서버는 다중 모델 JSON 문서 지원 DB 플랫폼이다. 캐시가 내장된 오픈소스 NoSQL 키-값 및 문서 DB이기도 하다. 성능은 물론, 다중 모델, 확장성 및 자동화를 지원하는 DB가 필요한 기업에 적합하다. 소셜 미디어 및 모바일 애플리케이션, 콘텐츠 및 메타데이터 저장소, 전자상거래 트랜잭션 등의 애플리케이션에 많이 사용하며, 문서, 유연한 데이터 모델, 인덱싱, 전문 검색을 완벽하게 지원하며, 실시간 분석을 위한 맵리듀스 기능을 제공한다.

• 애저 코스모스 DB(Azure Cosmos DB) : 애저 코스모스 DB는 여러 NoSQL 모델과 JSON 및 바이너리 데이터를 포함한 다양한 데이터 형식을 지원하는 마이크로소프트 애저 클라우드의 DB 서비스다. 애저 코스모스 역시 완전 관리형 서비스로 마이크로소프트가 기반 인프라까지 모두 관리해 개발자가 애플리케이션과 데이터에 집중할 수 있다. 클라우드 서비스 기반 서비스로 자동으로 즉각적인 확장성을 제공하며, 데이터 암호화 및 데이터 액세스 제어와 같은 보안 툴도 갖추고 있다. 특히 몽고DB, 카산드라(Cassandra) 및 기타 NoSQL 엔진을 위한 오픈소스 API를 제공한다.

컬럼-패밀리 DB 솔루션 종류

• 에이치베이스(HBASE) : 아파치 에이치베이스는 오픈소스 NoSQL 분산형 빅데이터 스토어다. 이를 통해 페타바이트 규모의 데이터에 엄격하게 일관되고 무작위의 실시간 액세스가 가능하다. 에이치베이스는 크고 산재된 데이터 세트를 처리하는 데 매우 효과적이다. 에이치베이스는 아파치 하둡(Apache Hadoop) 및 하둡 에코시스템과 원활하게 통합되며, 아마존 엘라스틱 맵리듀스(Amazon Elastic MapReduce, EMR) 파일 시스템 또는 EMRFS를 사용해 하둡 분산 파일 시스템(HDFS) 또는 아마존 S3(Amazon S3)에서 실행된다. 에이치베이스는 하둡용 아파치 맵리듀스 프레임워크에 대한 직접적인 입력 및 출력 역할을 하며, 아파치 피닉스(Apache Phoenix)와 연동해 에이치베이스 테이블에 대한 SQL과 유사한 쿼리를 가능하게 한다

• 카산드라(Cassandra) : 카산드라는 피어투피어(Peer to Peer, P2P) 통신을 하는 분산 DB로 확장성이 뛰어난 NoSQL DB다. 데이터센터 및 클라우드에서 대량의 정형, 비정형 데이터를 관리하는 데 적합하다. 최대한의 유연성과 빠른 응답 시간을 위해 설계된 강력한 모델과 함께 단일 장애 지점 없이 많은 사용 서버에서 지속적인 가용성, 선형 확장성 및 운영 단순성을 제공한다.

• 데이터스택스(DataStax) : 데이터스택스 아스트라 DB는 아파치 카산드라 기반의 완전 관리형 클라우드 네이티브 DB 서비스다. 다양한 API와 프로그래밍 언어 옵션을 통해 동적으로 확장하고 애플리케이션 개발을 가속화해 실시간 애플리케이션을 빠르게 구축하고 제한 없이 확장할 수 있다는 것이 데이터스택스의 설명이다. 프라이빗 링크, IP 액세스 제어, 싱글사인온, 애플리케이션 토큰, 데이터 암호화 등 다양한 보안 메커니즘을 내장하고 있으며, 마이크로서비스와 API 우선 원칙을 기반으로 구축된 서버리스 아키텍처이기 때문에 수요에 따라 자동으로 확장된다.

• 구글 빅테이블(Google BigTable) : 구글이 내세우는 빅테이블의 특징은 한자리 ms 수준의 짧은 지연시간과 무한 확장성, 99.999%의 가용성을 제공하는 엔터프라이즈급 NoSQL DB 서비스다. 빅테이블은 멀티테넌트, 혼합 운영 및 실시간 분석 워크로드를 지원한다. 구글은 빅테이블이 키-값 및 칼럼 저장소로, 정형, 반정형, 비정형 데이터에 빠르게 액세스하는 데 이상적이라고 설명한다. 개인화와 같이 지연시간에 민감한 워크로드에도 적합하다. 빅테이블은 서버 트래픽에 맞춰 리소스를 자동으로 확장해 필요에 따라 관련 샤딩, 복제, 쿼리를 처리한다.

그래프 DB 솔루션 종류

• 네오포제이(Neo4j) : 네오포제이는 그래프 DB 중 하나로, 관계 데이터를 중점적으로 저장하고 효과적으로 관리할 수 있는 DB 시스템이다. 그래프 DB는 데이터를 노드와 엣지 형태로 저장해 복잡한 관계를 직관적으로 표현하는 데 특화돼 있다. 사이퍼(Cyphe)는 네오포제이의 그래프 쿼리 언어로, 그래프 데이터에서 정보를 검색하는 데 사용된다. 이 언어는 그래프용 SQL과 유사하며 직관적이기 때문에 지금까지 가장 배우기 쉬운 그래프 쿼리 언어 중 하나로 인정받고 있다. 뿐만 아니라 사이퍼는 그래프 데이터의 효과적인 쿼리, 업데이트 및 관리를 가능하게 한다.

• 블레이즈그래프(BlazeGraph) : 블레이즈그래프는 표준 기반의 확장 가능한 고성능 오픈소스 그래프 DB다. 전체가 자바로 작성된 이 플랫폼은 쿼리, 업데이트, 기본 페더레이션 쿼리, 서비스 설명을 포함한 블루프린트와 RDF/SPARQL 1.1 제품군을 지원한다. 블레이즈그래프는 내구성이 뛰어난 명명된 솔루션 세트를 위한 새로운 확장 기능, 구체화된 명령문 모델의 효율적인 저장 및 쿼리, 확장 가능한 그래프 분석을 지원한다. 이 DB는 멀티 테넌시를 지원하며 임베디드 DB, 독립형 서버, 가용성이 높은 복제 클러스터로 배포할 수 있으며 구글의 빅테이블(bigtable), 아파치 어큐물로(Apache Accumulo) 또는 카산드라와 유사한 수평적으로 분할된 서비스 페더레이션으로 배포할 수 있다.

• 오리엔트DB(OrientDB) : 오리엔트DB는 자바로 작성된 오픈소스 NoSQL DB 관리 시스템이다. 그래프, 문서 및 개체 모델을 지원하는 다중 모델 DB이며 관계는 레코드 간의 직접 연결을 통해 그래프 DB에서와 같이 관리된다. 스키마 없는 모드, 스키마 전체 모드 및 스키마 혼합 모드를 지원하고 사용자 및 역할을 기반으로 하는 강력한 보안 프로파일링 시스템을 갖추고 있으며 그래프 탐색을 위해 확장된 SQL과 함께 그렘린(Gremlin)을 사용한 쿼리를 지원한다. 오리엔트DB는 B-트리 및 확장 가능한 해싱을 기반으로 하는 여러 인덱싱 메커니즘을 사용하는데, 마지막 하나는 ‘해시 인덱스’라고 한다. 각 레코드에는 디스크 상의 레코드 위치를 나타내는 서로게이트 키가 있다. 레코드 간 링크(엣지)는 레퍼러 내부에 직접 저장된 레코드 위치 또는 레코드 위치의 B-트리(소위 레코드 ID 또는 RID)로 저장되며, RID의 컨테이너 역할을 하며, 이를 통해 일대다 관계를 빠르게 순회하고 새 링크를 빠르게 추가/제거할 수 있다.

• 알레그로그래프(AllegroGraph) : 알레그로그래프는 수평으로 분산된 다중 모델(벡터, 문서 및 그래프), 엔티티-이벤트 지식 그래프 플랫폼으로, 기업이 생성형 AI만으로는 해답을 찾을 수 없는 매우 복잡하고 분산된 데이터로부터 정교한 의사 결정 통찰력과 예측 분석을 추출할 수 있는 뉴로-심볼릭(Neuro-Symbolic AI) 애플리케이션을 구축할 수 있다.

NoSQL를 도입할 때 고려사항

NoSQL DB를 도입할 때는 몇 가지 중요한 고려 사항이 있다. 먼저 대규모 데이터를 처리할 때 일정한 응답 시간을 유지할 수 있어야 한다. 또한 자주 변하는 동적 데이터를 잘 다룰 수 있어야 한다. NoSQL은 보통 비정규화된 데이터 모델을 사용하는데, 이는 복잡한 관계형 구조 대신 더 단순하고 유연한 방식으로 데이터를 저장한다. 데이터를 찾고 표현하는 것도 간단해야 한다. 여러 테이블을 복잡하게 연결할 필요 없이 원하는 정보를 쉽게 가져올 수 있어야 한다. 그리고 보통 데이터를 여러 지역에 걸쳐 복사해 저장하는데, 이때 데이터의 일관성, 가용성, 성능을 세밀하게 조절할 수 있어야 한다. 마지막으로 NoSQL을 도입할 때는 클라우드에서 제공하는 관리형 서비스를 이용하는 것이 좋다. 이렇게 하면 시스템 관리에 들어가는 노력을 줄이고, NoSQL이 진정으로 제공하는 이점에만 집중할 수 있기 때문이다.

결론

NoSQL DB의 등장과 활용은 데이터베이스 아키텍처에 혁명적인 변화를 가져왔다. 이러한 변화는 빅데이터, IoT, 실시간 분석 등 현대적인 데이터 중심 애플리케이션의 요구사항을 효과적으로 충족시키고 있다. 그러나 동시에 데이터 일관성, 트랜잭션 관리, 복잡한 쿼리 처리 등에서 새로운 도전과제도 제시하고 있다. 향후 DB 아키텍처는 NoSQL과 전통적인 관계형 데이터베이스의 장점을 결합한 하이브리드 모델로 진화할 것으로 예상된다. 또한 AI와 머신러닝 기술의 발전에 따라, 더욱 지능적이고 자동화된 데이터 관리 시스템이 등장할 것으로 전망된다. 결론적으로, NoSQL의 도입은 단순한 기술적 변화를 넘어 데이터 중심 비즈니스 모델을 가능케 하는 핵심 동력이 됐다. 앞으로도 데이터의 가치와 중요성이 증대됨에 따라, 이러한 혁신적인 DB 아키텍처의 역할은 더욱 중요해질 것이다.

참고문헌

• https://en.wikipedia.org/wiki/Key-value_database
• https://inyl.github.io/programming/2017/05/09/database.html
• https://www.mongodb.com/resources/basics/databases/nosql-explained
• https://learn.microsoft.com/ko-kr/dotnet/architecture/cloud-native/relational-vs-nosql-data
• https://github.com/blazegraph/database/wiki/About_Blazegraph
• https://en.wikipedia.org/wiki/OrientDB
• https://allegrograph.com/products/allegrograph/
• https://aws.amazon.com/ko/pm/dynamodb/
• https://azure.microsoft.com/ko-kr/products/cosmos-db
• https://cloud.google.com/bigtable/
• https://neo4j.com/
• https://www.datastax.com/
• https://cassandra.apache.org/
• https://hbase.apache.org/
• https://www.couchbase.com/
• https://en.wikipedia.org/wiki/Apache_CouchDB
• https://www.oracle.com/kr/database/nosql/
• https://riak.com/
• https://redis.io/