non-relational-workload 비관계형 데이터베이스

비관계형 데이터는 테이블 집합으로 구조화되지 않은 모든 것을 의미하는 모든 것을 포괄하는 용어입니다. 

비정형 데이터에는 다양한 유형이 있고 정보가 다양한 목적으로 

사용되므로 각각 특정 시나리오를 대상으로 하는 다양한 유형의 비관계형 데이터베이스 관리 시스템이 있습니다. 

이제 가장 일반적인 유형의 비관계형 데이터베이스에 대해 알아봅니다. 

비관계형 데이터베이스에 대해 읽다 보면 NoSQL이라는 용어를 보게 될 것입니다. 

NoSQL은 단순히 비관계형을 의미하는 다소 느슨한 용어입니다. 

이 용어가 SQL이 아니라는 것을 암시하려는 것인지 아니면 SQL만이 아니라는 것을 의미하는지에 대해서는 논쟁의 여지가 있습니다. 

일부 비관계형 데이터베이스는 테이블이 아닌 문서에 적합한 SQL 버전을 지원합니다. 예를 들어 Azure Cosmos DB 등이 있습니다.

 

NoSQL 비관계형 데이터베이스는 일반적으로 키-값 저장소, 문서 데이터베이스, 열 패밀리 데이터베이스, 그래프 데이터베이스의 네 가지 범주로 분류됩니다. 다음으로 몇 가지 일반적인 유형의 NoSQL 데이터베이스를 살펴보겠습니다.

 

키-값 저장소는 데이터를 삽입하고 쿼리하기 위한 NoSQL 데이터베이스 중 가장 간단하면서도 가장 빠른 유형입니다. 

키-값 저장소의 각 데이터 항목에는 키와 값이라는 두 개의 요소가 있습니다. 키는 항목을 

고유하게 식별하고 값에는 항목의 데이터가 들어 있습니다. 

값은 데이터베이스 관리 시스템에 불투명하며  항목은 키 순서대로 저장됩니다.

 

한 가지 중요한 점은 불투명이라는 용어는 데이터베이스 관리 

시스템이 값을 구조화되지 않은 블록으로만 인식한다는 

의미이며, 값의 데이터가 어떻게 구조화되고 어떤 필드가 포함되는지는 애플리케이션만 이해한다는 의미입니다.

불투명의 반대는 투명입니다. 데이터가 투명하면 데이터베이스 

관리 시스템은 데이터의 필드 구성 방식을 이해합니다. 

관계형 테이블은 투명한 구조의 한 예입니다. 

쿼리는 검색할 항목을 식별하는 키를 지정합니다. 

값으로는 검색할 수 없습니다. 

키-값 저장소에서 데이터를 검색하는 애플리케이션은 반환된 

값의 내용을 파싱합니다. 

쓰기 작업은 삽입 및 삭제로만 제한됩니다.항목을 

업데이트해야 하는 경우 항목을 가져와서 

응용 프로그램의 메모리에서 수정한 다음 데이터베이스에 다시 써서 

원본을 덮어써야 합니다. 사실상 삭제와 삽입을 반복해야 합니다.

 

키-값 저장소의 초점은 

데이터를 매우 빠르게 읽고 쓰는 기능이지만 검색 기능은 부차적입니다. 

키-값 저장소는 

대량의 데이터가 연속 스트림으로 도착하여 즉시 저장해야 하는 경우 데이터 수집에 매우 적합합니다.

Azure 테이블 스토리지는 키-값 저장소의 예이며, 

Cosmos DB는 테이블 API를 사용하여 키-값 저장소도 구현합니다.

문서 데이터베이스는 키-값 저장소와 NoSQL 스펙트럼의 반대쪽 끝을 나타냅니다. 

문서 데이터베이스에서 각 문서는 고유한 ID를 갖지만 문서의 필드는 

데이터베이스 관리 시스템에 투명합니다. 

문서 데이터베이스는 일반적으로 

이전 강의에서 설명한 대로 JSON 형식으로 데이터를 저장하거나 XML, 

YAML, BSON과 같은 일반적인 형식으로 데이터를 저장할 수 있으며 문서를 일반 텍스트로 저장할 수도 있습니다.

필드와 문서는 스토리지 관리 시스템에 표시되므로 

애플리케이션에서 이러한 필드의 값을 사용하여 데이터를 쿼리하고 필터링할 수 있습니다.

일반적으로 문서에는 엔티티의 전체 데이터가 포함됩니다. 

엔티티를 구성하는 항목은 애플리케이션별로 다릅니다. 

예를 들어 엔티티에는 고객, 주문 

또는 이 둘의 조합에 대한 세부 정보가 포함될 수 있습니다.관계형

데이터베이스 관리 시스템에서는 일반적으로 여러 관계형 테이블에 분산되는 정보가 단일 문서에 포함될 수 있습니다. 

문서 저장소에서는 모든 문서의 구조가 동일할 필요는 없습니다. 

이 자유 형식 접근 방식을 사용하면 유연성이 뛰어납니다. 

비즈니스 요구 사항이 변경됨에 따라 응용 프로그램이 문서에 다른 데이터를 저장할 수 있습니다.

애플리케이션은 문서 키를 사용하여 문서를 검색할 수 있으며, 키는 문서의 고유 식별자입니다. 

문서 키를 자동으로 만드는 문서 데이터베이스도 

있고 키로 사용할 문서 속성을 지정할 수 있는 문서 데이터베이스도 있습니다.

또한 응용 프로그램은 하나 이상의 필드 값을 기반으로 문서를 쿼리할 수 있습니다.

일부 문서 데이터베이스는 인덱싱된 

하나 이상의 필드를 기반으로 문서를 빠르게 조회할 수 있도록 인덱싱을 지원합니다.

일부 문서 데이터베이스 관리 시스템은 내부 업데이트를 

지원하므로 응용 프로그램이 전체 문서를 

다시 작성하지 않고도 문서의 특정 필드 값을 수정할 수 있습니다.

 

Cosmos DB와 같은 다른 문서 데이터베이스 관리 시스템은 전체 문서를 읽고 쓸 수만 있습니다. 이러한 경우 업데이트로 인해 

전체 문서가 새 버전으로 바뀝니다. 이 접근 방식은 데이터베이스의 조각화를 줄여 성능을 향상시킬 수 있습니다. 

대부분의 문서 데이터베이스는 관계형 데이터베이스보다 더 빠르게 대량의 데이터를 수집하지만 이러한 유형의 처리를 위한 키-값 저장소만큼 최적은 아닙니다. 

문서 데이터베이스의 초점은 쿼리 기능이며, Azure Cosmos DB는 핵심 SQL API에서 문서 데이터베이스 접근 방식을 구현합니다. 

열 패밀리 데이터베이스는 데이터를 행과 열로 구성합니다. 

이러한 구조의 예로는 앞에서 설명한 ORC 및 Parquet 파일이 있습니다. 

가장 단순한 형태의 열 패밀리 데이터베이스는 적어도 개념적으로는 관계형 데이터베이스와 매우 유사하게 보일 수 있습니다.

컬럼 패밀리 데이터베이스의 진정한 힘은 희소 데이터를 구조화하는 비정규화된 접근 방식에 있습니다. 

예를 들어 이전 섹션에서 설명한 것처럼 과거 데이터를 유지 관리할 필요성을 무시하고 고객 및 고객 주소에 대한 정보를 관계형 데이터베이스에 저장해야 하는 경우 화면의 예제 다이어그램과 유사한 스키마를 설계할 수 있습니다. 

고객 및 주소 스키마와 해당 테이블은 몇 가지 샘플 데이터로 채워져 있습니다. 

고객 1과 고객 2가 동일한 주소를 공유하며 스키마는 이 주소 정보가 중복되지 않도록 합니다. 

이는 일대다 관계를 구현하는 표준 방법입니다. 

관계형 모델은 이러한 유형의 관계를 구현하는 매우 일반적인 접근 방식을 지원하지만, 특정 고객의 주소를 찾으려면 애플리케이션이 두 테이블을 조인하는 쿼리를 실행해야 합니다. 

이 쿼리가 응용 프로그램에서 가장 자주 수행되는 쿼리인 경우 요청 수가 많고 테이블 자체가 크면 이 조인 작업 수행과 관련된 오버헤드가 빠르게 커질 수 있습니다. 

열 패밀리 데이터베이스의 목적은 이와 같은 상황을 효율적으로 처리하는 것입니다. 

열 패밀리 데이터베이스는 행과 열로 구성된 테이블 형식 데이터를 보관하는 것으로 생각할 수 있지만 열을 열 그룹이라는 그룹으로 나눌 수 있습니다. 

각 열 집합에는 논리적으로 서로 관련된 열 집합이 포함되어 있습니다.

고객 사례는 이전 고객의 예와 동일한 정보를 구조화하는 한 가지 방법을 보여줍니다. 

열 패밀리 데이터베이스를 사용하면 데이터가 고객 정보와 주소 정보가 들어 있는 두 개의 열 그룹으로 그룹화됩니다. 

열을 구성하는 다른 방법도 가능하지만애플리케이션에서 수행하는 가장 일반적인 쿼리를 최적화하려면 열 패밀리를 구현해야 합니다.

이 경우 고객의 주소를 검색하는 쿼리는 해당 관계형 데이터베이스에서 필요한 것보다 적은 수의 읽기로 데이터를 가져올 수 있으며, 

이러한 쿼리는 주소 정보 열 패밀리에서 직접 데이터를 가져올 수 있습니다. 

열 패밀리 데이터베이스의 각 행에는 키가 들어 있으며 이 키를 사용하여 행의 데이터를 가져올 수 있습니다.

 

이 예제는 물리적인 것이 아니라 개념적인 것으로, 데이터가 물리적으로 구성되는 방식이 아니라 데이터의 논리적 구조를 보여주기 위한 것임을 주목할 필요가 있습니다. 

대부분의 열 패밀리 데이터베이스에서 열 패밀리는 별도로 저장됩니다. 

이전 예제에서 고객 정보 열 패밀리는 물리적 스토리지의 한 영역에, 주소 정보 열 패밀리는 단순한 수직 분할 형태로 다른 영역에 배치될 수 있습니다. 

실제로 구조는 행이 아닌 열 그룹 측면에서 생각해야 합니다. 여러 열 집합에 걸친 단일 엔티티의 데이터는 

각 열 집합에서 동일한 행 키를 갖습니다. 

앞서 설명한 개념적 레이아웃 대신 데이터를 다음과 같은 물리적 구조 쌍으로 시각화할 수 있습니다. 

고객 정보와 주소 정보라는 두 가지 구조가 있는 경우 각 열 구조를 행 키로 결합할 수 있습니다. 

가장 널리 사용되는 열 패밀리 데이터베이스 관리 시스템은 

Apache Cassandra이며, 

Azure Cosmos DB는 Cassandra API를 통해 열 패밀리 접근 방식을 지원합니다. 

 

 

그래프 데이터베이스를 사용하면 항목을 저장할 수 있지만 주요 초점은 이러한 엔터티가 서로 가지는 관계에 있습니다. 

그래프 데이터베이스는 두 가지 유형의 정보를 저장합니다. 하나는 엔티티의 인스턴스로 생각할 수 있는 노드이고 다른 하나는 노드 간 관계를 지정하는 엣지입니다. 

노드와 엣지는 모두 테이블의 열과 같이 해당 노드나 엣지에 대한 정보를 제공하는 속성을 가질 수 있으며, 엣지에는 관계의 특성을 나타내는 방향이 있을 수 있습니다.

 

 

그래프 데이터베이스의 목적은 응용 프로그램이 

노드와 에지 네트워크를 통과하는 쿼리를 효율적으로 수행하고 

개체 간의 관계를 분석할 수 있도록 하는 것입니다. 

조직의 인사 데이터베이스는 그래프로 구성할 수 있습니다. 

엔티티는 조직 내 직원 및 부서이며, 

가장자리는 보고 라인과 직원이 근무하는 부서를 나타냅니다. 

그래프에서 가장자리의 화살표는 관계의 방향을 나타냅니다. 

엔티티와 관계가 많은 대형 그래프의 경우 매우 

복잡한 분석을 매우 빠르게 수행할 수 있으며, 대부분의 그래프 데이터베이스는 

관계 네트워크를 효율적으로 탐색하는 데 사용할 수 있는 쿼리 언어를 제공합니다. 

종종 같은 정보를 관계형 데이터베이스에 저장할 수 있지만 

이 정보를 쿼리하는 데 필요한 SQL에는 비용이 많이 드는 

재귀 조인 작업과 중첩된 하위 쿼리가 많이 필요할 수 있습니다. 

 

Azure Cosmos DB는 Gremlin API를 사용하여 그래프 데이터베이스를 지원합니다.

Gremlin API는 그래프 생성 및 쿼리를 위한 표준 언어입니다.