다음을 통해 공유

데이터 저장소 모델 이해

  • 아티클

최신 비즈니스 시스템은 점점 더 많은 양의 이질적인 데이터를 관리합니다. 이러한 이질성은 단일 데이터 저장소가 일반적으로 최선의 방법이 아님을 의미합니다. 대신, 각각 특정 워크로드 또는 사용 패턴에 초점을 맞춘 서로 다른 데이터 저장소에 다양한 형식의 데이터를 저장하는 것이 더 좋습니다. 폴리글랏 지속성이라는 용어는 다양한 데이터 저장소 기술을 혼합하여 사용하는 솔루션을 설명하는 데 사용됩니다. 따라서 기본 스토리지 모델과 해당 장단을 이해하는 것이 중요합니다.

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

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

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

메모

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

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

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

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

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

Azure 서비스

업무량

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

데이터 형식

  • 데이터는 고도로 정규화됩니다.
  • 데이터베이스 스키마가 필요하고 적용됩니다.
  • 데이터베이스에서 데이터 엔터티 간의 다대다 관계.
  • 제약 조건은 스키마에 정의되고 데이터베이스의 모든 데이터에 적용됩니다.
  • 데이터에는 높은 무결성이 필요합니다. 인덱스 및 관계를 정확하게 유지 관리해야 합니다.
  • 데이터에는 강력한 일관성이 필요합니다. 트랜잭션은 모든 데이터가 모든 사용자 및 프로세스에 대해 100% 일관되도록 하는 방식으로 작동합니다.
  • 개별 데이터 항목의 크기는 작고 중간 크기입니다.

예제

  • 인벤토리 관리
  • 주문 관리
  • 보고서 데이터베이스
  • 회계

키/값 저장소

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

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

키-값 저장소 다이어그램

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

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

Azure 서비스

업무량

  • 데이터는 사전과 같은 단일 키를 사용하여 액세스됩니다.
  • 조인, 잠금, 유니언이 필요하지 않습니다.
  • 집계 메커니즘은 사용되지 않습니다.
  • 보조 인덱스는 일반적으로 사용되지 않습니다.

데이터 형식

  • 각 키는 단일 값과 연결됩니다.
  • 스키마 적용은 없습니다.
  • 엔터티 간의 관계가 없습니다.

예제

  • 데이터 캐싱
  • 세션 관리
  • 사용자 기본 설정 및 프로필 관리
  • 제품 추천 및 광고 서비스

문서 데이터베이스

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

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

문서 저장소 다이어그램

Azure 서비스

  • NoSQL용 Azure Cosmos DB(Azure Cosmos DB 보안 기준)

업무량

  • 삽입 및 업데이트 작업은 일반적입니다.
  • 객체-관계 임피던스 불일치가 없습니다. 문서는 애플리케이션 코드에 사용되는 개체 구조와 더 잘 일치할 수 있습니다.
  • 개별 문서는 검색되고 단일 블록으로 작성됩니다.
  • 데이터에는 여러 필드에 대한 인덱스가 필요합니다.

데이터 형식

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

예제

  • 제품 카탈로그
  • 콘텐츠 관리
  • 인벤토리 관리

그래프 데이터베이스

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

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

문서 데이터베이스 다이어그램

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

Azure 서비스

업무량

  • 관련된 데이터 항목 사이에 여러 번의 연관 연결을 포함한 복잡한 관계입니다.
  • 데이터 항목 간의 관계는 동적이며 시간이 지남에 따라 변경됩니다.
  • 개체 간의 관계는 외래 키와 조인이 트래버스할 필요 없이 일류 시민입니다.

데이터 형식

  • 노드와 관계
  • 노드는 테이블 행 또는 JSON 문서와 유사합니다.
  • 관계는 노드만큼 중요하며 쿼리 언어로 직접 노출됩니다.
  • 여러 전화 번호를 가진 사람과 같은 복합 개체는 트래버스 가능한 관계와 결합된 별도의 작은 노드로 나뉘는 경향이 있습니다.

예제

  • 조직도
  • 소셜 그래프
  • 사기 감지
  • 추천 엔진

데이터 분석

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

Azure 서비스

업무량

  • 데이터 분석
  • 엔터프라이즈 비즈니스 인텔리전스

데이터 형식

  • 여러 원본의 기록 데이터입니다.
  • 일반적으로 팩트 테이블과 차원 테이블로 구성된 "별" 또는 "눈송이" 스키마에서 비정규화됩니다.
  • 일반적으로 예약된 기준으로 새 데이터로 로드됩니다.
  • 차원 테이블은 이라고도 하는 느린 변경 차원으로 불리는 여러 과거 버전의 엔터티를 포함하고 있습니다.

예제

  • 엔터프라이즈 데이터 웨어하우스

컬럼 패밀리 데이터베이스

열 패밀리 데이터베이스는 데이터를 행과 열로 구성합니다. 가장 간단한 형식에서 열 패밀리 데이터베이스는 적어도 개념적으로 관계형 데이터베이스와 매우 유사하게 나타날 수 있습니다. 열 패밀리 데이터베이스의 진정한 힘은 스파스 데이터를 구조화하는 비정규화된 접근 방식에 있습니다.

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

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

열 패밀리 데이터베이스 다이어그램

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

행에 대한 읽기 및 쓰기 작업은 보통 단일 열 패밀리 내에서 원자성으로 이루어지지만, 일부 구현에서는 여러 열 패밀리에 걸쳐 전체 행의 원자성을 보장하기도 합니다.

Azure 서비스

업무량

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

데이터 형식

  • 데이터는 키 열과 하나 이상의 열 패밀리로 구성된 테이블에 저장됩니다.
  • 특정 열은 개별 행에 따라 달라질 수 있습니다.
  • 개별 셀은 get 및 put 명령을 통해 액세스됩니다.
  • 스캔 명령을 사용하여 여러 행이 반환됩니다.

예제

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

검색 엔진 데이터베이스

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

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

검색 기능은 정확하거나 모호할 수 있습니다. 퍼지 검색은 용어 모음과 일치하는 문서를 찾고 일치 정도를 계산합니다. 일부 검색 엔진은 동의어, 장르 확장 일치(예: dogs을 pets로 일치) 및 어간 추출(같은 어근을 가진 단어 일치)을 기반으로 결과를 반환할 수 있는 언어 분석을 지원합니다.

Azure 서비스

업무량

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

데이터 형식

  • 반구조적 텍스트 또는 구조화되지 않은 텍스트
  • 구조화된 데이터에 대한 참조가 있는 텍스트

예제

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

시계열 데이터베이스

시계열 데이터는 시간별로 구성된 값 집합입니다. 시계열 데이터베이스는 일반적으로 많은 수의 원본에서 대량의 데이터를 실시간으로 수집합니다. 업데이트는 드물며 삭제는 대량 작업으로 수행되는 경우가 많습니다. 시계열 데이터베이스에 기록된 레코드는 일반적으로 작지만 레코드 수가 많고 총 데이터 크기가 빠르게 증가할 수 있습니다.

Azure 서비스

업무량

  • 레코드는 일반적으로 순차적으로 시간 순서로 추가됩니다.
  • 작업의 압도적 비율(95-99%)은 쓰기 작업입니다.
  • 업데이트는 드물다.
  • 삭제는 대량으로 발생하며 연속 블록 또는 레코드로 만들어집니다.
  • 데이터는 종종 병렬로 오름차순 또는 내림차순으로 읽습니다.

데이터 형식

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

예제

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

오브젝트 스토리지

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

Azure 서비스

업무량

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

데이터 형식

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

예제

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

공유 파일

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

Azure 서비스

  • Azure Files(보안 기준)

업무량

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

데이터 형식

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

예제

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

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

다음 단계