데이터 저장소 모델 이해

  • 아티클

최신 비즈니스 시스템은 점점 더 많은 양의 다른 유형의 데이터를 관리합니다. 그러므로 단일 데이터 저장소가 일반적으로 모든 경우에 최선의 방법이 될 수는 없습니다. 대신 서로 다른 유형의 데이터를 서로 다른 데이터 저장소에 저장하는 것이 좋습니다. 각 데이터 저장소는 특정 워크로드 또는 사용 패턴에 중점을 둡니다. polyglot 지속성이라는 용어는 데이터 저장소 기술을 혼합하여 사용하는 솔루션을 설명하는 데 사용됩니다. 따라서 기본 스토리지 모델과 해당 장단점을 이해하는 것이 중요합니다.

요구 사항에 적합한 데이터 저장소를 선택하는 것이 디자인 결정의 핵심입니다. SQL과 NoSQL 데이터베이스 중에서 선택할 수 있는 구현에는 문자 그대로 수백 가지가 있습니다. 데이터 저장소는 데이터 구조화 방법과 지원하는 작업 유형에 따라 분류됩니다. 이 문서에서는 가장 일반적인 여러 스토리지 모델에 대해 설명합니다. 특정 데이터 스토리지 기술에서 여러 스토리지 모델을 지원할 수 있습니다. 예를 들어 RDBMS(관계형 데이터베이스 관리 시스템)는 키/값 또는 그래프 스토리지을 지원할 수 있습니다. 사실, 단일 데이터베이스 시스템이 여러 모델을 지원하는 소위 다중 모델 지원이 일반적인 추세입니다. 그러나 다양한 모델을 개략적으로 이해하는 것은 여전히 유용합니다.

특정 범주의 모든 데이터 저장소가 동일한 기능을 제공하는 것은 아닙니다. 대부분의 데이터 저장소는 데이터를 쿼리하고 처리하기 위한 서버 쪽 기능을 제공합니다. 경우에 따라 이 기능은 데이터 스토리지 엔진에 기본 제공되어 있습니다. 또는 데이터 스토리지 및 처리 기능이 분리되어 처리 및 분석을 위한 몇 가지 옵션이 있을 수도 있습니다. 또한 데이터 저장소는 다양한 프로그래밍 및 관리 인터페이스를 지원합니다.

일반적으로 요구 사항에 가장 적합한 스토리지 모델을 고려하여 시작해야 합니다. 그런 다음 기능 집합, 비용 및 관리 용이성과 같은 요소를 기반으로 해당 범주 내의 특정 데이터 저장소를 고려합니다.

참고

Azure용 Microsoft Cloud 채택 프레임워크에서 클라우드 채택을 위한 데이터 서비스 요구 사항을 식별하고 검토하는 방법에 대해 자세히 알아봅니다. 마찬가지로 스토리지 도구 및 서비스 선택에 대해서도 알아볼 수 있습니다.

관계형 데이터베이스 관리 시스템

관계형 데이터베이스는 행과 열이 있는 일련의 2차원 테이블로 데이터를 구성합니다. 대부분의 공급업체는 데이터 검색 및 관리를 위해 SQL(구조적 쿼리 언어) 언어를 제공합니다. RDBMS는 일반적으로 정보 업데이트를 위해 ACID(원자성, 일관성, 격리, 영속성) 모델을 준수하는 트랜잭션 방식으로 일관된 메커니즘을 구현합니다.

RDBMS는 일반적으로 데이터 구조가 미리 정의되고 모든 읽기 또는 쓰기 작업이 스키마를 사용해야 하는 스키마 온 라이트(schema-on-write) 모델을 지원합니다.

이 모델은 강력한 일관성 보장이 중요한 경우 매우 유용합니다. 모든 변경 사항은 원자성이며 트랜잭션은 항상 데이터를 일관된 상태로 유지합니다. 그러나 RDBMS는 일반적으로 어떤 식으로든 데이터를 분할하지 않고 수평으로 스케일 아웃할 수 없습니다. 또한 RDBMS의 데이터는 정규화되어야 하므로 모든 데이터 세트에 적합하지 않습니다.

Azure 서비스

작업

  • 레코드는 자주 만들어지고 업데이트됩니다.
  • 하나의 트랜잭션에서 여러 개의 작업이 완료되어야 합니다.
  • 관계는 데이터베이스 제약 조건을 사용하여 적용됩니다.
  • 쿼리 성능을 최적화하는 데 인덱스가 사용됩니다.

데이터 형식

  • 데이터가 고도로 정규화되어 있습니다.
  • 데이터 스키마가 필요하며, 적용되어 있습니다.
  • 데이터베이스에 저장된 데이터 엔터티 사이에 다대다 관계가 존재합니다.
  • 스키마에서 제약 조건이 정의되고, 데이터베이스에 저장된 모든 데이터에 적용됩니다.
  • 데이터에 높은 무결성이 요구됩니다. 인덱스 및 관계가 정확하게 유지되어야 합니다.
  • 데이터에 강력한 일관성이 요구됩니다. 모든 사용자와 프로세스에 대해 모든 데이터가 100% 일관성을 갖도록 트랜잭션이 이루어집니다.
  • 개별 데이터 엔터티의 크기가 작거나 중간 규모입니다.

예제

  • 재고 관리
  • 주문 관리
  • 보고 데이터베이스
  • 회계

키/값 저장소

키/값 저장소는 각 데이터 값을 고유 키와 연결합니다. 대부분의 키/값 저장소는 간단한 쿼리, 삽입 및 삭제 작업만 지원합니다. 값을 수정(부분적으로 또는 완전히)하려면 애플리케이션이 전체 값에 대해 기존 데이터를 덮어써야 합니다. 대부분의 구현에서 단일 값 읽기 또는 쓰기는 원자성 작업입니다.

애플리케이션은 임의의 데이터를 값 세트로 저장할 수 있습니다. 모든 스키마 정보는 애플리케이션에서 제공해야 합니다. 키/값 저장소는 키로 값을 검색하거나 저장합니다.

Diagram of a key-value store

키/값 저장소는 간단한 조회를 수행하는 애플리케이션에 대해 매우 최적화되어 있지만 다른 키/값 저장소에서 데이터를 쿼리해야 하는 경우 적합하지 않습니다. 키/값 저장소는 값별 쿼리에도 최적화되지 않습니다.

단일 키/값 저장소는 별도의 컴퓨터에 있는 여러 노드에 데이터를 쉽게 배포할 수 있으므로 확장성이 매우 뛰어납니다.

Azure 서비스

작업

  • 데이터가 마치 사전처럼 단일 키를 사용하여 액세스됩니다.
  • 조인, 잠금 또는 공용 구조체가 필요하지 않습니다.
  • 집계 메커니즘이 사용되지 않습니다.
  • 일반적으로 보조 인덱스가 사용되지 않습니다.

데이터 형식

  • 각 키는 단일 값과 연결됩니다.
  • 스키마 적용이 없습니다.
  • 엔터티 사이에 관계가 존재하지 않습니다.

예제

  • 데이터 캐싱
  • 세션 관리
  • 사용자 기본 설정 및 프로필 관리
  • 상품 권장 사항 및 광고 게재

문서 데이터베이스

문서 데이터베이스는 각 문서가 명명된 필드와 데이터로 구성된 문서 컬렉션을 저장합니다. 데이터는 단순 값이거나 목록 및 자식 컬렉션과 같은 복잡한 요소일 수 있습니다. 문서는 고유 키로 검색됩니다.

일반적으로 문서에는 고객 또는 주문과 같은 단일 엔터티에 대한 데이터가 포함됩니다. RDBMS의 여러 관계형 테이블에 분산된 정보가 문서에 포함될 수도 있습니다. 문서는 구조가 같을 필요가 없습니다. 애플리케이션은 비즈니스 요구 사항이 변경됨에 따라 문서에 다른 데이터를 저장할 수 있습니다.

Diagram of a document store

Azure 서비스

작업

  • 삽입 및 업데이트 작업이 빈번하게 이루어집니다.
  • 개체 관계형 불일치가 없습니다. 문서가 애플리케이션 코드에서 사용되는 개체 구조와 더욱 잘 매칭됩니다.
  • 개별 문서가 단일 블록으로 검색되고 쓰기됩니다.
  • 데이터의 여러 필드에서 인덱스가 필요합니다.

데이터 형식

  • 데이터를 정규화되지 않은 방식으로 관리할 수 있습니다.
  • 개별 문서 데이터의 크기가 상대적으로 작습니다.
  • 각 문서 유형이 자체 스키마를 사용할 수 있습니다.
  • 문서에 선택적 필드가 포함될 수 있습니다.
  • 문서 데이터가 반정형입니다. 즉, 각 필드의 데이터 형식이 엄격하게 정의되어 있지 않습니다.

예제

  • 상품 카탈로그
  • 콘텐츠 관리
  • 재고 관리

그래프 데이터베이스

그래프 데이터베이스는 노드와 에지, 두 가지 유형의 정보를 저장합니다. 에지는 노드 간의 관계를 지정합니다. 노드와 에지는 테이블의 열과 마찬가지로 해당 노드 또는 에지에 대한 정보를 제공하는 속성을 가질 수 있습니다. 에지는 또한 관계의 특성을 나타내는 방향을 가질 수 있습니다.

그래프 데이터베이스는 노드 및 에지 네트워크에서 쿼리를 효율적으로 수행하고 엔터티 간의 관계를 분석할 수 있습니다. 다음 다이어그램은 그래프로 구성된 조직의 인사 데이터베이스를 보여 줍니다. 엔터티는 직원 및 부서이며, 에지는 보고 관계 및 직원이 근무하는 부서를 나타냅니다.

Diagram of a document database

이 구조를 통해 "Sarah에게 직간접적으로 보고하는 모든 직원 찾기" 또는 "John과 같은 부서에서 일하는 사람은 누구인가요?"와 같은 쿼리를 간단하게 수행할 수 있습니다. 엔터티와 관계가 많은 대형 그래프의 경우 매우 복잡한 분석을 매우 신속하게 수행할 수 있습니다. 많은 그래프 데이터베이스는 관계 네트워크를 효율적으로 트래버스하는 데 사용할 수 있는 쿼리 언어를 제공합니다.

Azure 서비스

작업

  • 데이터 항목 간의 복잡한 관계는 관련 데이터 항목 간의 많은 홉을 포함합니다.
  • 데이터 항목 사이의 관계가 동적이고 시간에 따라 변화합니다.
  • 개체 사이의 관계가 최고의 리소스입니다. 즉, 탐색을 위해 외부 키와 조인이 필요하지 않습니다.

데이터 형식

  • 노드 및 관계
  • 노드는 테이블 행이나 JSON 문서와 비슷합니다.
  • 관계는 노드만큼 중요하며, 쿼리 언어에서 직접적으로 노출됩니다.
  • 여러 개의 전화번호를 갖는 사람과 같은 복합 개체는 크기가 작은 별도의 노드로 분할되어 탐색 가능한 관계와 결합됩니다.

예제

  • 조직도
  • 소셜 그래프
  • 부정 행위 감지
  • 추천 엔진

데이터 분석

데이터 분석 저장소는 데이터 수집, 저장 및 분석을 위한 대규모 병렬 솔루션을 제공합니다. 데이터는 확장성을 극대화하기 위해 여러 서버에 분산됩니다. CSV(구분 기호 파일), parquet 및 ORC와 같은 대용량 데이터 파일 형식은 데이터 분석에 널리 사용됩니다. 기록 데이터는 일반적으로 Blob Storage 또는 Azure Data Lake Storage Gen2와 같은 데이터 저장소에 저장되며, 그런 다음, Azure Synapse, Databricks 또는 HDInsight에서 외부 테이블로 액세스합니다. 성능을 위해 parquet 파일로 저장된 데이터를 사용하는 일반적인 시나리오는 Synapse SQL에서 외부 테이블 사용 문서에 설명되어 있습니다.

Azure 서비스

작업

  • 데이터 분석
  • 엔터프라이즈 BI

데이터 형식

  • 여러 원본으로부터 수집된 기록 데이터입니다.
  • 일반적으로 팩트와 차원 테이블로 구성된 "스타" 또는 "눈송이" 스키마에서 비정규화되어 있습니다.
  • 일반적으로 스케줄링에 따라 새로운 데이터가 로드됩니다.
  • 일반적으로 차원 테이블에는 느린 변경 차원이라 불리는 엔터티의 복수의 기록 버전이 포함됩니다.

예제

  • Enterprise Data Warehouse

열 패밀리 데이터베이스

열 패밀리 데이터베이스는 데이터를 행과 열로 구성합니다. 가장 간단한 형태인 열 패밀리 데이터베이스는 적어도 개념적으로 관계형 데이터베이스와 매우 유사하게 보일 수 있습니다. 열 패밀리 데이터베이스의 이점은 스파스 데이터를 구조화하기 위한 비정규화된 접근법에 있습니다.

열 패밀리 데이터베이스는 행과 열이 있는 표 형식 데이터로 생각할 수 있지만 열은 열 패밀리라는 그룹으로 나뉩니다. 각 열 패밀리는 논리적으로 관련되어 있고 일반적으로 하나의 단위로 검색되거나 조작되는 열 집합을 보유합니다. 개별적으로 액세스되는 다른 데이터는 별도의 열 패밀리에 저장할 수 있습니다. 열 패밀리 내에서 새 열을 동적으로 추가할 수 있고 행은 스파스될 수 있습니다. 즉, 행은 모든 열에 대해 값을 가질 필요가 없습니다.

다음 다이어그램은 Identity 및 Contact Info의 두 열 패밀리가 있는 예를 보여 줍니다. 단일 엔터티의 데이터에는 각 열 패밀리에서 동일한 행 키가 있습니다. 열 패밀리의 특정 개체에 대한 행이 동적으로 달라질 수 있는 이 구조는 열 패밀리 접근 방식의 중요한 이점이므로 이 데이터 저장소 형식은 구조화된 휘발성 데이터를 저장하는 데 매우 적합합니다.

Diagram of a column-family database

키/값 저장소 또는 문서 데이터베이스와 달리 대부분의 열 패밀리 데이터베이스는 해시를 계산하지 않고 키 순서로 데이터를 저장합니다. 많은 구현을 통해 열 패밀리의 특정 열에 대한 인덱스를 만들 수 있습니다. 인덱스를 사용하면 행 키가 아닌 열 값으로 데이터를 검색할 수 있습니다.

행에 대한 읽기 및 쓰기 작업은 일반적으로 단일 열 패밀리에 대해 원자성이지만 일부 구현은 여러 열 패밀리에 걸쳐 전체 행에 원자성을 제공합니다.

Azure 서비스

작업

  • 대부분의 열 패밀리 데이터베이스는 쓰기 작업을 매우 빠르게 수행합니다.
  • 업데이트 및 삭제 작업은 드물게 이루어집니다.
  • 높은 처리량과 낮은 대기 시간을 갖는 액세스를 제공하도록 설계되었습니다.
  • 대규모 레코드에 속한 특정 필드 집합에 대한 간편한 쿼리 액세스를 지원합니다.
  • 대규모로 확장 가능합니다.

데이터 형식

  • 데이터가 하나의 키 열과 하나 이상의 열 패밀리로 이루어진 테이블에 저장됩니다.
  • 구체적인 열은 개별 행에 따라 달라질 수 있습니다.
  • 개별 셀에는 get 및 put 명령을 사용하여 액세스할 수 있습니다.
  • scan 명령을 사용하면 여러 개의 행이 반환됩니다.

예제

  • 권장 사항
  • Personalization
  • 센서 데이터
  • 원격 분석
  • 메시징
  • 소셜 미디어 분석
  • 웹 분석
  • 활동 모니터링
  • 날씨 및 기타 시계열 데이터

검색 엔진 데이터베이스

검색 엔진 데이터베이스를 통해 애플리케이션은 외부 데이터 저장소에 저장된 정보를 검색할 수 있습니다. 검색 엔진 데이터베이스는 대용량 데이터를 인덱싱하고 이러한 인덱스에 거의 실시간으로 액세스할 수 있습니다.

인덱스는 다차원적일 수 있으며 많은 양의 텍스트 데이터에서 자유 텍스트 검색을 지원할 수 있습니다. 인덱싱은 검색 엔진 데이터베이스에 의해 트리거되는 끌어오기 모델을 사용하거나 외부 애플리케이션 코드에 의해 시작되는 밀어넣기 모델을 사용하여 수행할 수 있습니다.

검색은 정확한 항목 또는 유사 항목을 찾을 수 있습니다. 유사 항목 검색은 용어 집합과 일치하는 문서를 찾고 일치하는 정도를 계산합니다. 일부 검색 엔진은 동의어, 장르 확장(예: dogs 및 pets 일치) 및 형태소 분석(동일한 어근일 경우 일치하는 단어로 판단)을 기반으로 일치 항목을 반환할 수 있는 언어 분석도 지원합니다.

Azure 서비스

작업

  • 여러 원본 및 서비스의 데이터 인덱스입니다.
  • 쿼리가 임시이며 복잡한 경우가 많습니다.
  • 전체 텍스트 검색이 필요합니다.
  • 임시 셀프 서비스 쿼리가 필요합니다.

데이터 형식

  • 반정형 또는 비정형 텍스트
  • 정형 데이터에 대한 참조가 있는 텍스트

예제

  • 상품 카탈로그
  • 사이트 검색
  • 로깅

시계열 데이터베이스

시계열 데이터는 시간별로 구성된 값 집합입니다. 시계열 데이터베이스는 일반적으로 많은 수의 원본에서 대량의 데이터를 실시간으로 수집합니다. 업데이트는 거의 발생하지 않으며 삭제는 종종 대량 작업으로 수행됩니다. 시계열 데이터베이스에 기록된 레코드는 일반적으로 작지만 레코드 수가 많아 전체 데이터 크기가 빠르게 커지는 경우가 종종 있습니다.

Azure 서비스

작업

  • 레코드는 일반적으로 시간순으로 순차적으로 추가됩니다.
  • 작업의 대다수(95~99%)가 쓰기 작업입니다.
  • 업데이트는 드물게 이루어집니다.
  • 삭제는 연속 블록 또는 레코드에 대해 대량으로 이루어집니다.
  • 오름차순 또는 내림차순 시간순으로 순차적으로, 종종 병렬로 데이터 읽기가 수행됩니다.

데이터 형식

  • 타임스탬프는 기본 키 및 정렬 메커니즘으로 사용됩니다.
  • 태그는 유형, 원본 및 항목에 대한 그 밖의 정보 등 추가 정보를 정의할 수 있습니다.

예제

  • 모니터링 및 이벤트 원격 분석.
  • 센서 또는 기타 IoT 데이터.

개체 스토리지

개체 스토리지는 대형 이진 개체(이미지, 파일, 비디오 및 오디오 스트림, 대형 애플리케이션 데이터 개체 및 문서, 가상 머신 디스크 이미지)를 저장하고 검색하는 데 최적화되어 있습니다. 또한 이 모델에서는 CSV(구분 기호 파일), parquet 및 ORC와 같은 대용량 데이터 파일도 널리 사용됩니다. 개체 저장소는 매우 많은 양의 비정형 데이터를 관리할 수 있습니다.

Azure 서비스

작업

  • 키로 식별됩니다.
  • 콘텐츠는 일반적으로 구분 기호, 이미지 또는 비디오 파일과 같은 자산입니다.
  • 콘텐츠는 내구성이 높은 상태이고 모든 애플리케이션 계층의 외부에 존재해야 합니다.

데이터 형식

  • 데이터 크기가 큽니다.
  • 값은 불투명합니다.

예제

  • 이미지, 비디오, 사무 문서, PDF
  • 정적 HTML, JSON, CSS
  • 로그 및 감사 파일
  • 데이터베이스 백업

공유 파일

때로는 간단한 플랫 파일을 사용하는 것이 정보를 저장하고 검색하는 가장 효과적인 방법이 될 수 있습니다. 파일 공유를 사용하면 네트워크를 통해 파일에 액세스할 수 있습니다. 적절한 보안 및 동시 액세스 제어 메커니즘이 제공되면 이러한 방식으로 데이터를 공유하여, 분산 서비스를 통해 단순 읽기 및 쓰기 요청과 같은 기본, 저수준 작업을 수행하기 위한 확장성이 뛰어난 데이터 액세스를 제공할 수 있습니다.

Azure 서비스

작업

  • 파일 시스템과 상호 작용하는 기존 앱에서의 마이그레이션입니다.
  • SMB 인터페이스가 필요합니다.

데이터 형식

  • 계층 구조 폴더 집합에 포함된 파일입니다.
  • 표준 I/O 라이브러리를 사용하여 액세스할 수 있습니다.

예제

  • 레거시 파일
  • 여러 VM 또는 앱 인스턴스로부터 액세스할 수 있는 공유 콘텐츠

다양한 데이터 스토리지 모델을 이해하는 데 도움이 되는 다음 단계는 워크로드 및 애플리케이션을 평가하고 특정 요구 사항을 충족할 데이터 저장소를 결정하는 것입니다. 데이터 스토리지 의사 결정 트리를 사용하여 이 프로세스를 지원합니다.

다음 단계