데이터 저장소 모델 이해Understand data store models

최신 비즈니스 시스템은 점점 더 많은 유형의 다른 데이터를 관리 합니다.Modern business systems manage increasingly large volumes of heterogeneous data. 그러므로 단일 데이터 저장소가 일반적으로 모든 경우에 최선의 방법이 될 수는 없습니다.This heterogeneity means that a single data store is usually not the best approach. 대신 다른 데이터 저장소에 다양 한 유형의 데이터를 저장 하는 것이 일반적으로 특정 작업 또는 사용 패턴에 중점을 두었습니다.Instead, it's often better to store different types of data in different data stores, each focused toward a specific workload or usage pattern. polyglot 지속성 이라는 용어는 데이터 저장소 기술을 혼합하여 사용하는 솔루션을 설명하는 데 사용됩니다.The term polyglot persistence is used to describe solutions that use a mix of data store technologies. 따라서 주 저장소 모델과 해당 장단점을 이해 하는 것이 중요 합니다.Therefore, it's important to understand the main storage models and their tradeoffs.

요구 사항에 적합한 데이터 저장소를 선택하는 것이 디자인 결정의 핵심입니다.Selecting the right data store for your requirements is a key design decision. SQL과 NoSQL 데이터베이스 중에서 선택할 수 있는 구현에는 문자 그대로 수백 가지가 있습니다.There are literally hundreds of implementations to choose from among SQL and NoSQL databases. 데이터 저장소는 데이터 구조화 방법과 지원하는 작업 유형에 따라 분류됩니다.Data stores are often categorized by how they structure data and the types of operations they support. 이 문서에서는 가장 일반적인 여러 스토리지 모델에 대해 설명합니다.This article describes several of the most common storage models. 특정 데이터 스토리지 기술에서 여러 스토리지 모델을 지원할 수 있습니다.Note that a particular data store technology may support multiple storage models. 예를 들어 RDBMS(관계형 데이터베이스 관리 시스템)는 키/값 또는 그래프 스토리지을 지원할 수 있습니다.For example, a relational database management systems (RDBMS) may also support key/value or graph storage. 실제로 단일 데이터베이스 시스템에서 여러 모델을 지 원하는 다중 모델 지원에 대 한 일반적인 추세가 있습니다.In fact, there is a general trend for so-called multi-model support, where a single database system supports several models. 그러나 다양한 모델을 개략적으로 이해하는 것은 여전히 유용합니다.But it's still useful to understand the different models at a high level.

특정 범주의 모든 데이터 저장소가 동일한 기능을 제공하는 것은 아닙니다.Not all data stores in a given category provide the same feature-set. 대부분의 데이터 저장소는 데이터를 쿼리하고 처리하기 위한 서버 쪽 기능을 제공합니다.Most data stores provide server-side functionality to query and process data. 경우에 따라 이 기능은 데이터 스토리지 엔진에 기본 제공되어 있습니다.Sometimes this functionality is built into the data storage engine. 또는 데이터 스토리지 및 처리 기능이 분리되어 처리 및 분석을 위한 몇 가지 옵션이 있을 수도 있습니다.In other cases, the data storage and processing capabilities are separated, and there may be several options for processing and analysis. 또한 데이터 저장소는 다양한 프로그래밍 및 관리 인터페이스를 지원합니다.Data stores also support different programmatic and management interfaces.

일반적으로 요구 사항에 가장 적합한 스토리지 모델을 고려하여 시작해야 합니다.Generally, you should start by considering which storage model is best suited for your requirements. 그런 다음 기능 집합, 비용 및 관리 용이성과 같은 요소를 기반으로 해당 범주 내의 특정 데이터 저장소를 고려합니다.Then consider a particular data store within that category, based on factors such as feature set, cost, and ease of management.

관계형 데이터베이스 관리 시스템Relational database management systems

관계형 데이터베이스는 행과 열이 있는 일련의 2차원 테이블로 데이터를 구성합니다.Relational databases organize data as a series of two-dimensional tables with rows and columns. 대부분의 공급 업체는 데이터 검색 및 관리를 위한 구조적 쿼리 언어 (SQL) 언어를 제공 합니다.Most vendors provide a dialect of the Structured Query Language (SQL) for retrieving and managing data. RDBMS는 일반적으로 정보 업데이트를 위해 ACID(원자성, 일관성, 격리, 영속성) 모델을 준수하는 트랜잭션 방식으로 일관된 메커니즘을 구현합니다.An RDBMS typically implements a transactionally consistent mechanism that conforms to the ACID (Atomic, Consistent, Isolated, Durable) model for updating information.

RDBMS는 일반적으로 데이터 구조가 미리 정의되고 모든 읽기 또는 쓰기 작업이 스키마를 사용해야 하는 스키마 온 라이트(schema-on-write) 모델을 지원합니다.An RDBMS typically supports a schema-on-write model, where the data structure is defined ahead of time, and all read or write operations must use the schema.

이 모델은 — 모든 변경 내용이 원자성을 유지 하 고 트랜잭션이 항상 일관 된 상태로 데이터를 유지 하는 강력한 일관성 보장이 중요할 때 매우 유용 합니다.This model is very useful when strong consistency guarantees are important — where all changes are atomic, and transactions always leave the data in a consistent state. 그러나 RDBMS는 일반적으로 데이터를 분할 하지 않고 수평으로 확장할 수 없습니다.However, an RDBMS generally can't scale out horizontally without sharding the data in some way. 또한 RDBMS의 데이터는 정규화 되어야 하며,이는 모든 데이터 집합에 적합 하지 않습니다.Also, the data in an RDBMS must normalized, which isn't appropriate for every data set.

Azure 서비스Azure services

작업Workload

  • 레코드는 자주 만들어지고 업데이트 됩니다.Records are frequently created and updated.
  • 하나의 트랜잭션에서 여러 개의 작업이 완료되어야 합니다.Multiple operations have to be completed in a single transaction.
  • 관계는 데이터베이스 제약 조건을 사용하여 적용됩니다.Relationships are enforced using database constraints.
  • 쿼리 성능을 최적화하는 데 인덱스가 사용됩니다.Indexes are used to optimize query performance.

데이터 형식Data type

  • 데이터가 고도로 정규화되어 있습니다.Data is highly normalized.
  • 데이터 스키마가 필요하며, 적용되어 있습니다.Database schemas are required and enforced.
  • 데이터베이스에 저장된 데이터 엔터티 사이에 다대다 관계가 존재합니다.Many-to-many relationships between data entities in the database.
  • 스키마에서 제약 조건이 정의되고, 데이터베이스에 저장된 모든 데이터에 적용됩니다.Constraints are defined in the schema and imposed on any data in the database.
  • 데이터에 높은 무결성이 요구됩니다.Data requires high integrity. 인덱스 및 관계가 정확하게 유지되어야 합니다.Indexes and relationships need to be maintained accurately.
  • 데이터에 강력한 일관성이 요구됩니다.Data requires strong consistency. 모든 사용자와 프로세스에 대해 모든 데이터가 100% 일관성을 갖도록 트랜잭션이 이루어집니다.Transactions operate in a way that ensures all data are 100% consistent for all users and processes.
  • 개별 데이터 항목의 크기는 중간 크기에서 작습니다.Size of individual data entries is small to medium-sized.

예제Examples

  • 재고 관리Inventory management
  • 주문 관리Order management
  • 보고 데이터베이스Reporting database
  • 회계Accounting

키/값 저장소Key/value stores

키/값 저장소는 각 데이터 값을 고유 키와 연결 합니다.A key/value store associates each data value with a unique key. 대부분의 키/값 저장소는 간단한 쿼리, 삽입 및 삭제 작업만 지원합니다.Most key/value stores only support simple query, insert, and delete operations. 값을 수정(부분적으로 또는 완전히)하려면 애플리케이션이 전체 값에 대해 기존 데이터를 덮어써야 합니다.To modify a value (either partially or completely), an application must overwrite the existing data for the entire value. 대부분의 구현에서 단일 값 읽기 또는 쓰기는 원자성 작업입니다.In most implementations, reading or writing a single value is an atomic operation.

응용 프로그램은 임의의 데이터를 값 집합으로 저장할 수 있습니다.An application can store arbitrary data as a set of values. 응용 프로그램에서 스키마 정보를 제공 해야 합니다.Any schema information must be provided by the application. 키/값 저장소는 키로 값을 검색 하거나 저장 합니다.The key/value store simply retrieves or stores the value by key.

키-값 저장소의 다이어그램

키/값 저장소는 간단한 조회를 수행 하는 응용 프로그램에 대해 매우 최적화 되어 있지만 여러 키/값 저장소에서 데이터를 쿼리해야 하는 경우에는 적합 하지 않습니다.Key/value stores are highly optimized for applications performing simple lookups, but are less suitable if you need to query data across different key/value stores. 키/값 저장소는 값으로 쿼리 하는 경우에도 최적화 되지 않습니다.Key/value stores are also not optimized for querying by value.

단일 키/값 저장소는 별도의 컴퓨터에 있는 여러 노드에 데이터를 쉽게 배포할 수 있으므로 확장성이 매우 뛰어납니다.A single key/value store can be extremely scalable, as the data store can easily distribute data across multiple nodes on separate machines.

Azure 서비스Azure services

작업Workload

  • 데이터는 사전 처럼 단일 키를 사용 하 여 액세스 됩니다.Data is accessed using a single key, like a dictionary.
  • 조인, 잠금 또는 공용 구조체가 필요하지 않습니다.No joins, lock, or unions are required.
  • 집계 메커니즘이 사용되지 않습니다.No aggregation mechanisms are used.
  • 일반적으로 보조 인덱스가 사용되지 않습니다.Secondary indexes are generally not used.

데이터 형식Data type

  • 각 키에는 단일 값이 연결 됩니다.Each key is associated with a single value.
  • 스키마 적용이 없습니다.There is no schema enforcement.
  • 엔터티 사이에 관계가 존재하지 않습니다.No relationships between entities.

예제Examples

  • 데이터 캐싱Data caching
  • 세션 관리Session management
  • 사용자 기본 설정 및 프로필 관리User preference and profile management
  • 상품 권장 사항 및 광고 게재Product recommendation and ad serving

문서 데이터베이스Document databases

문서 데이터베이스 는 문서 컬렉션 을 저장 합니다. 여기서 각 문서는 명명 된 필드 및 데이터로 구성 됩니다.A document database stores a collection of documents, where each document consists of named fields and data. 데이터는 단순 값 이나 목록 및 자식 컬렉션과 같은 복합 요소가 될 수 있습니다.The data can be simple values or complex elements such as lists and child collections. 문서는 고유 키로 검색 됩니다.Documents are retrieved by unique keys.

일반적으로 문서에는 고객 또는 주문과 같은 단일 엔터티에 대 한 데이터가 포함 됩니다.Typically, a document contains the data for single entity, such as a customer or an order. 문서에는 RDBMS의 여러 관계형 테이블에 분산 되는 정보가 포함 될 수 있습니다.A document may contain information that would be spread across several relational tables in an RDBMS. 문서는 동일한 구조를 가질 필요가 없습니다.Documents don't need to have the same structure. 애플리케이션은 비즈니스 요구 사항이 변경됨에 따라 문서에 다른 데이터를 저장할 수 있습니다.Applications can store different data in documents as business requirements change.

문서 저장소의 다이어그램

Azure 서비스Azure service

작업Workload

  • 삽입 및 업데이트 작업이 빈번하게 이루어집니다.Insert and update operations are common.
  • 개체 관계형 불일치가 없습니다.No object-relational impedance mismatch. 문서가 애플리케이션 코드에서 사용되는 개체 구조와 더욱 잘 매칭됩니다.Documents can better match the object structures used in application code.
  • 개별 문서가 단일 블록으로 검색되고 쓰기됩니다.Individual documents are retrieved and written as a single block.
  • 데이터의 여러 필드에서 인덱스가 필요합니다.Data requires index on multiple fields.

데이터 형식Data type

  • 데이터를 정규화되지 않은 방식으로 관리할 수 있습니다.Data can be managed in de-normalized way.
  • 개별 문서 데이터의 크기가 상대적으로 작습니다.Size of individual document data is relatively small.
  • 각 문서 유형이 자체 스키마를 사용할 수 있습니다.Each document type can use its own schema.
  • 문서에 선택적 필드가 포함될 수 있습니다.Documents can include optional fields.
  • 문서 데이터가 반정형입니다. 즉, 각 필드의 데이터 형식이 엄격하게 정의되어 있지 않습니다.Document data is semi-structured, meaning that data types of each field are not strictly defined.

예제Examples

  • 상품 카탈로그Product catalog
  • 콘텐츠 관리Content management
  • 재고 관리Inventory management

그래프 데이터베이스Graph databases

그래프 데이터베이스는 노드와 에지, 두 가지 유형의 정보를 저장합니다.A graph database stores two types of information, nodes and edges. 가장자리 노드 간의 관계를 지정 합니다.Edges specify relationships between nodes. 노드와 가장자리에는 테이블의 열과 마찬가지로 해당 노드 또는에 지에 대 한 정보를 제공 하는 속성이 있을 수 있습니다.Nodes and edges can have properties that provide information about that node or edge, similar to columns in a table. 에지는 또한 관계의 특성을 나타내는 방향을 가질 수 있습니다.Edges can also have a direction indicating the nature of the relationship.

그래프 데이터베이스는 노드와 가장자리 네트워크에서 쿼리를 효율적으로 수행 하 고 엔터티 간의 관계를 분석할 수 있습니다.Graph databases can efficiently perform queries across the network of nodes and edges and analyze the relationships between entities. 다음 다이어그램은 그래프로 구성된 조직의 인사 데이터베이스를 보여 줍니다.The following diagram shows an organization's personnel database structured as a graph. 엔터티는 직원 및 부서 이며,에 지는 보고 관계 및 직원이 근무 하는 부서를 표시 합니다.The entities are employees and departments, and the edges indicate reporting relationships and the departments in which employees work.

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

이 구조를 통해 "Sarah에게 직접 또는 간접적으로 보고하는 모든 직원 찾기" 또는 "John과 같은 부서에서 근무하는 직원"과 같은 쿼리를 간단하게 수행할 수 있습니다.This structure makes it straightforward to perform queries such as "Find all employees who report directly or indirectly to Sarah" or "Who works in the same department as John?" 엔터티와 관계가 많은 대형 그래프의 경우 매우 복잡한 분석을 매우 신속하게 수행할 수 있습니다.For large graphs with lots of entities and relationships, you can perform very complex analyses very quickly. 많은 그래프 데이터베이스는 관계 네트워크를 효율적으로 트래버스하는 데 사용할 수 있는 쿼리 언어를 제공합니다.Many graph databases provide a query language that you can use to traverse a network of relationships efficiently.

Azure 서비스Azure services

작업Workload

  • 관련 데이터 항목 사이에 많은 홉을 포함 하는 데이터 항목 간의 복잡 한 관계.Complex relationships between data items involving many hops between related data items.
  • 데이터 항목 사이의 관계가 동적이고 시간에 따라 변화합니다.The relationship between data items are dynamic and change over time.
  • 개체 사이의 관계가 최고의 리소스입니다. 즉, 탐색을 위해 외부 키와 조인이 필요하지 않습니다.Relationships between objects are first-class citizens, without requiring foreign-keys and joins to traverse.

데이터 형식Data type

  • 노드 및 관계.Nodes and relationships.
  • 노드는 테이블 행이나 JSON 문서와 비슷합니다.Nodes are similar to table rows or JSON documents.
  • 관계는 노드만큼 중요하며, 쿼리 언어에서 직접적으로 노출됩니다.Relationships are just as important as nodes, and are exposed directly in the query language.
  • 여러 개의 전화번호를 갖는 사람과 같은 복합 개체는 크기가 작은 별도의 노드로 분할되어 탐색 가능한 관계와 결합됩니다.Composite objects, such as a person with multiple phone numbers, tend to be broken into separate, smaller nodes, combined with traversable relationships

예제Examples

  • 조직도Organization charts
  • 소셜 그래프Social graphs
  • 부정 행위 감지Fraud detection
  • 추천 엔진Recommendation engines

데이터 분석Data analytics

데이터 분석 저장소는 데이터 수집, 저장 및 분석을 위한 대규모 병렬 솔루션을 제공합니다.Data analytics stores provide massively parallel solutions for ingesting, storing, and analyzing data. 데이터는 확장성을 최대화 하기 위해 여러 서버에 분산 됩니다.The data is distributed across multiple servers to maximize scalability. 구분 기호 파일 (CSV), parquetORC 와 같은 큰 데이터 파일 형식은 데이터 분석에서 널리 사용 됩니다.Large data file formats such as delimiter files (CSV), parquet, and ORC are widely used in data analytics. 기록 데이터는 일반적으로 blob 저장소 또는 Azure Data Lake Storage Gen2와 같은 데이터 저장소에 저장 되며,이는 Azure Synapse, Databricks 또는 HDInsight에서 외부 테이블로 액세스 됩니다.Historical data is typically stored in data stores such as blob storage or Azure Data Lake Storage Gen2, which are then accessed by Azure Synapse, Databricks, or HDInsight as external tables. 성능을 위해 parquet 파일로 저장 된 데이터를 사용 하는 일반적인 시나리오는 SYNAPSE SQL에서 외부 테이블 사용문서에 설명 되어 있습니다.A typical scenario using data stored as parquet files for performance, is described in the article Use external tables with Synapse SQL.

Azure 서비스Azure services

작업Workload

  • 데이터 분석Data analytics
  • 엔터프라이즈 BIEnterprise BI

데이터 형식Data type

  • 여러 원본으로부터 수집된 기록 데이터입니다.Historical data from multiple sources.
  • 일반적으로 팩트와 차원 테이블로 구성된 "스타" 또는 "눈송이" 스키마에서 비정규화되어 있습니다.Usually denormalized in a "star" or "snowflake" schema, consisting of fact and dimension tables.
  • 일반적으로 스케줄링에 따라 새로운 데이터가 로드됩니다.Usually loaded with new data on a scheduled basis.
  • 일반적으로 차원 테이블에는 느린 변경 차원이라 불리는 엔터티의 복수의 기록 버전이 포함됩니다.Dimension tables often include multiple historic versions of an entity, referred to as a slowly changing dimension.

예제Examples

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

열 패밀리 데이터베이스Column-family databases

열 패밀리 데이터베이스는 데이터를 행과 열로 구성합니다.A column-family database organizes data into rows and columns. 가장 간단한 형태인 열 패밀리 데이터베이스는 적어도 개념적으로 관계형 데이터베이스와 매우 유사하게 보일 수 있습니다.In its simplest form, a column-family database can appear very similar to a relational database, at least conceptually. 열 패밀리 데이터베이스의 이점은 스파스 데이터를 구조화하기 위한 비정규화된 접근법에 있습니다.The real power of a column-family database lies in its denormalized approach to structuring sparse data.

열 패밀리 데이터베이스는 행과 열이 있는 표 형식 데이터로 생각할 수 있지만 열은 열 패밀리 라는 그룹으로 나뉩니다.You can think of a column-family database as holding tabular data with rows and columns, but the columns are divided into groups known as column families. 각 열 패밀리는 논리적으로 관련되어 있고 일반적으로 하나의 단위로 검색되거나 조작되는 열 집합을 보유합니다.Each column family holds a set of columns that are logically related together and are typically retrieved or manipulated as a unit. 개별적으로 액세스되는 다른 데이터는 별도의 열 패밀리에 저장할 수 있습니다.Other data that is accessed separately can be stored in separate column families. 열 패밀리 내에서 새 열을 동적으로 추가할 수 있고 행은 스파스될 수 있습니다. 즉, 행은 모든 열에 대해 값을 가질 필요가 없습니다.Within a column family, new columns can be added dynamically, and rows can be sparse (that is, a row doesn't need to have a value for every column).

다음 다이어그램은 IdentityContact Info의 두 열 패밀리가 있는 예를 보여 줍니다.The following diagram shows an example with two column families, Identity and Contact Info. 단일 엔터티의 데이터에는 각 열 패밀리에서 동일한 행 키가 있습니다.The data for a single entity has the same row key in each column-family. 열 패밀리의 특정 개체에 대한 행이 동적으로 달라질 수 있는 이 구조는 열 패밀리 접근 방식의 중요한 이점이므로 이 데이터 저장소 형식은 구조화된 휘발성 데이터를 저장하는 데 매우 적합합니다.This structure, where the rows for any given object in a column family can vary dynamically, is an important benefit of the column-family approach, making this form of data store highly suited for storing structured, volatile data.

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

키/값 저장소 또는 문서 데이터베이스와 달리 대부분의 열 패밀리 데이터베이스는 해시를 계산하지 않고 키 순서로 데이터를 저장합니다.Unlike a key/value store or a document database, most column-family databases store data in key order, rather than by computing a hash. 많은 구현을 통해 열 패밀리의 특정 열에 대한 인덱스를 만들 수 있습니다.Many implementations allow you to create indexes over specific columns in a column-family. 인덱스를 사용하면 행 키가 아닌 열 값으로 데이터를 검색할 수 있습니다.Indexes let you retrieve data by columns value, rather than row key.

행에 대한 읽기 및 쓰기 작업은 일반적으로 단일 열 패밀리에 대해 원자성이지만 일부 구현은 여러 열 패밀리에 걸쳐 전체 행에 원자성을 제공합니다.Read and write operations for a row are usually atomic with a single column-family, although some implementations provide atomicity across the entire row, spanning multiple column-families.

Azure 서비스Azure services

작업Workload

  • 대부분의 열 패밀리 데이터베이스는 쓰기 작업을 매우 빠르게 수행합니다.Most column-family databases perform write operations extremely quickly.
  • 업데이트 및 삭제 작업은 드물게 이루어집니다.Update and delete operations are rare.
  • 높은 처리량과 낮은 대기 시간을 갖는 액세스를 제공하도록 설계되었습니다.Designed to provide high throughput and low-latency access.
  • 대규모 레코드에 속한 특정 필드 집합에 대한 간편한 쿼리 액세스를 지원합니다.Supports easy query access to a particular set of fields within a much larger record.
  • 대규모로 확장 가능합니다.Massively scalable.

데이터 형식Data type

  • 데이터가 하나의 키 열과 하나 이상의 열 패밀리로 이루어진 테이블에 저장됩니다.Data is stored in tables consisting of a key column and one or more column families.
  • 구체적인 열은 개별 행에 따라 달라질 수 있습니다.Specific columns can vary by individual rows.
  • 개별 셀에는 get 및 put 명령을 사용하여 액세스할 수 있습니다.Individual cells are accessed via get and put commands
  • scan 명령을 사용하면 여러 개의 행이 반환됩니다.Multiple rows are returned using a scan command.

예제Examples

  • 권장 사항Recommendations
  • 개인 설정Personalization
  • 센서 데이터Sensor data
  • 원격 분석Telemetry
  • 메시징Messaging
  • 소셜 미디어 분석Social media analytics
  • 웹 분석Web analytics
  • 활동 모니터링Activity monitoring
  • 날씨 및 기타 시계열 데이터Weather and other time-series data

검색 엔진 데이터베이스Search Engine Databases

검색 엔진 데이터베이스를 사용 하면 응용 프로그램에서 외부 데이터 저장소에 저장 된 정보를 검색할 수 있습니다.A search engine database allows applications to search for information held in external data stores. 검색 엔진 데이터베이스는 대량의 데이터를 인덱싱하고 이러한 인덱스에 거의 실시간으로 액세스할 수 있습니다.A search engine database can index massive volumes of data and provide near real-time access to these indexes.

인덱스는 다차원적일 수 있으며 많은 양의 텍스트 데이터에서 자유 텍스트 검색을 지원할 수 있습니다.Indexes can be multi-dimensional and may support free-text searches across large volumes of text data. 인덱싱은 검색 엔진 데이터베이스에 의해 트리거되는 끌어오기 모델을 사용하거나 외부 애플리케이션 코드에 의해 시작되는 밀어넣기 모델을 사용하여 수행할 수 있습니다.Indexing can be performed using a pull model, triggered by the search engine database, or using a push model, initiated by external application code.

검색은 정확한 항목 또는 유사 항목을 찾을 수 있습니다.Searching can be exact or fuzzy. 유사 항목 검색은 용어 집합과 일치하는 문서를 찾고 일치하는 정도를 계산합니다.A fuzzy search finds documents that match a set of terms and calculates how closely they match. 일부 검색 엔진은 동의어, 장르 확장(예: dogspets 일치) 및 형태소 분석(동일한 어근일 경우 일치하는 단어로 판단)을 기반으로 일치 항목을 반환할 수 있는 언어 분석도 지원합니다.Some search engines also support linguistic analysis that can return matches based on synonyms, genre expansions (for example, matching dogs to pets), and stemming (matching words with the same root).

Azure 서비스Azure service

작업Workload

  • 여러 원본 및 서비스의 데이터 인덱스Data indexes from multiple sources and services.
  • 쿼리가 임시이며 복잡한 경우가 많습니다.Queries are ad-hoc and can be complex.
  • 전체 텍스트 검색이 필요합니다.Full text search is required.
  • 임시 셀프 서비스 쿼리가 필요합니다.Ad hoc self-service query is required.

데이터 형식Data type

  • 반 구조화 되거나 구조화 되지 않은 텍스트Semi-structured or unstructured text
  • 정형 데이터에 대한 참조가 있는 텍스트Text with reference to structured data

예제Examples

  • 상품 카탈로그Product catalogs
  • 사이트 검색Site search
  • 로깅Logging

시계열 데이터베이스Time series databases

시계열 데이터는 시간별로 구성된 값 집합입니다.Time series data is a set of values organized by time. 시계열 데이터베이스는 일반적으로 많은 수의 원본에서 많은 양의 데이터를 실시간으로 수집 합니다.Time series databases typically collect large amounts of data in real time from a large number of sources. 업데이트는 거의 발생하지 않으며 삭제는 종종 대량 작업으로 수행됩니다.Updates are rare, and deletes are often done as bulk operations. 시계열 데이터베이스에 기록된 레코드는 일반적으로 작지만 레코드 수가 많아 전체 데이터 크기가 빠르게 커지는 경우가 종종 있습니다.Although the records written to a time-series database are generally small, there are often a large number of records, and total data size can grow rapidly.

Azure 서비스Azure service

작업Workload

  • 레코드는 일반적으로 시간순으로 순차적으로 추가됩니다.Records are generally appended sequentially in time order.
  • 작업의 대다수(95~99%)가 쓰기 작업입니다.An overwhelming proportion of operations (95-99%) are writes.
  • 업데이트는 드물게 이루어집니다.Updates are rare.
  • 삭제는 연속 블록 또는 레코드에 대해 대량으로 이루어집니다.Deletes occur in bulk, and are made to contiguous blocks or records.
  • 데이터는 오름차순 또는 내림차순으로 순차적으로 읽습니다.Data is read sequentially in either ascending or descending time order, often in parallel.

데이터 형식Data type

  • 타임 스탬프는 기본 키 및 정렬 메커니즘으로 사용 됩니다.A timestamp is used as the primary key and sorting mechanism.
  • 태그는 형식, 원본 및 항목에 대 한 기타 정보에 대 한 추가 정보를 정의할 수 있습니다.Tags may define additional information about the type, origin, and other information about the entry.

예제Examples

  • 모니터링 및 이벤트 원격 분석.Monitoring and event telemetry.
  • 센서 또는 기타 IoT 데이터.Sensor or other IoT data.

개체 스토리지Object storage

개체 스토리지는 대형 이진 개체(이미지, 파일, 비디오 및 오디오 스트림, 대형 애플리케이션 데이터 개체 및 문서, 가상 머신 디스크 이미지)를 저장하고 검색하는 데 최적화되어 있습니다.Object storage is optimized for storing and retrieving large binary objects (images, files, video and audio streams, large application data objects and documents, virtual machine disk images). 구분 기호 파일 (CSV), parquetORC와 같은 많은 데이터 파일도이 모델에 많이 사용 됩니다.Large data files are also popularly used in this model, for example, delimiter file (CSV), parquet, and ORC. 개체 저장소는 매우 많은 양의 구조화 되지 않은 데이터를 관리할 수 있습니다.Object stores can manage extremely large amounts of unstructured data.

Azure 서비스Azure service

작업Workload

  • 키로 식별됩니다.Identified by key.
  • 콘텐츠는 일반적으로 구분 기호, 이미지 또는 비디오 파일과 같은 자산입니다.Content is typically an asset such as a delimiter, image, or video file.
  • 콘텐츠는 응용 프로그램 계층의 외부에 있어야 합니다.Content must be durable and external to any application tier.

데이터 형식Data type

  • 데이터 크기가 큽니다.Data size is large.
  • 값은 불투명합니다.Value is opaque.

예제Examples

  • 이미지, 비디오, 사무 문서, PDFImages, videos, office documents, PDFs
  • 정적 HTML, JSON, CSSStatic HTML, JSON, CSS
  • 로그 및 감사 파일Log and audit files
  • 데이터베이스 백업Database backups

공유 파일Shared files

때로는 간단한 플랫 파일을 사용하는 것이 정보를 저장하고 검색하는 가장 효과적인 방법이 될 수 있습니다.Sometimes, using simple flat files can be the most effective means of storing and retrieving information. 파일 공유를 사용하면 네트워크를 통해 파일에 액세스할 수 있습니다.Using file shares enables files to be accessed across a network. 적절한 보안 및 동시 액세스 제어 메커니즘이 제공되면 이러한 방식으로 데이터를 공유하여, 분산 서비스를 통해 단순 읽기 및 쓰기 요청과 같은 기본, 저수준 작업을 수행하기 위한 확장성이 뛰어난 데이터 액세스를 제공할 수 있습니다.Given appropriate security and concurrent access control mechanisms, sharing data in this way can enable distributed services to provide highly scalable data access for performing basic, low-level operations such as simple read and write requests.

Azure 서비스Azure service

작업Workload

  • 파일 시스템과 상호 작용하는 기존 앱에서의 마이그레이션입니다.Migration from existing apps that interact with the file system.
  • SMB 인터페이스가 필요합니다.Requires SMB interface.

데이터 형식Data type

  • 계층 구조 폴더 집합에 포함된 파일입니다.Files in a hierarchical set of folders.
  • 표준 I/O 라이브러리를 사용하여 액세스할 수 있습니다.Accessible with standard I/O libraries.

예제Examples

  • 레거시 파일Legacy files
  • 여러 VM 또는 앱 인스턴스로부터 액세스할 수 있는 공유 콘텐츠Shared content accessible among a number of VMs or app instances

다양 한 데이터 저장소 모델을 이해 하는 데에는 다음 단계를 통해 워크 로드 및 응용 프로그램을 평가 하 고 특정 요구 사항을 충족 하는 데이터 저장소를 결정 합니다.Aided with this understanding of different data storage models, the next step is to evaluate your workload and application, and decide which data store will meet your specific needs. 데이터 저장소 의사 결정 트리 를 사용 하 여이 프로세스를 지원할 수 있습니다.Use the data storage decision tree to help with this process.