OLTP(온라인 트랜잭션 처리)Online transaction processing (OLTP)

컴퓨터 시스템을 사용 하는 트랜잭션 데이터의 관리를 OLTP (온라인 트랜잭션 처리) 라고 합니다.The management of transactional data using computer systems is referred to as online transaction processing (OLTP). OLTP 시스템은 조직의 일상적인 작업에서 발생하는 비즈니스 상호 작용을 기록하고, 이 데이터를 쿼리하여 유추할 수 있도록 지원합니다.OLTP systems record business interactions as they occur in the day-to-day operation of the organization, and support querying of this data to make inferences.

트랜잭션 데이터Transactional data

트랜잭션 데이터는 조직의 활동과 관련된 상호 작용을 추적하는 정보입니다.Transactional data is information that tracks the interactions related to an organization's activities. 이러한 상호 작용은 일반적으로 고객으로부터 수신된 지불, 공급업체로 수행된 지불, 인벤토리를 통해 이동되는 제품, 수행된 주문 또는 배달된 서비스와 같은 비즈니스 트랜잭션입니다.These interactions are typically business transactions, such as payments received from customers, payments made to suppliers, products moving through inventory, orders taken, or services delivered. 트랜잭션 자체를 나타내는 트랜잭션 이벤트는 일반적으로 시간 차원, 일부 숫자 값 및 다른 데이터에 대한 참조를 포함합니다.Transactional events, which represent the transactions themselves, typically contain a time dimension, some numerical values, and references to other data.

트랜잭션은 일반적으로 원자성을 가지고 일관되어야 합니다.Transactions typically need to be atomic and consistent. 원자성은 전체 트랜잭션이 항상 하나의 작업 단위로 성공 또는 실패하고, 절반만 완료된 상태를 유지하지 않는다는 것을 의미합니다.Atomicity means that an entire transaction always succeeds or fails as one unit of work, and is never left in a half-completed state. 트랜잭션을 완료할 수 없는 경우 데이터베이스 시스템은 해당 트랜잭션의 일부로 이미 수행된 모든 단계를 롤백해야 합니다.If a transaction cannot be completed, the database system must roll back any steps that were already done as part of that transaction. 전형적인 RDBMS에서, 이 롤백은 트랜잭션을 완료할 수 없을 때 자동으로 발생합니다.In a traditional RDBMS, this rollback happens automatically if a transaction cannot be completed. 일관성은 트랜잭션이 항상 데이터를 유효한 상태로 유지함을 의미합니다.Consistency means that transactions always leave the data in a valid state. (원자성 및 일관성에 대한 매우 비공식적인 설명입니다.(These are very informal descriptions of atomicity and consistency. 이러한 속성에 대해 ACID와 같은 좀 더 공식적인 설명이 있습니다.)There are more formal definitions of these properties, such as ACID.)

트랜잭션 데이터베이스는 모든 데이터가 모든 사용자 및 프로세스에 대해 엔터프라이즈의 컨텍스트 내에서 강력하게 일관된 상태를 유지하도록 하기 위해 비관적 잠금과 같은 다양한 잠금 전략을 사용하여 트랜잭선의 강력한 일관성을 지원할 수 있습니다.Transactional databases can support strong consistency for transactions using various locking strategies, such as pessimistic locking, to ensure that all data is strongly consistent within the context of the enterprise, for all users and processes.

트랜잭션 데이터를 사용하는 가장 일반적인 배포 아키텍처는 3계층 아키텍처의 데이터 저장소 계층입니다.The most common deployment architecture that uses transactional data is the data store tier in a 3-tier architecture. 3계층 아키텍처는 일반적으로 프레젠테이션 계층, 비즈니스 논리 계층 및 데이터 저장소 계층으로 구성됩니다.A 3-tier architecture typically consists of a presentation tier, business logic tier, and data store tier. 관련된 배포 아키텍처는 여러 중간 계층 처리 비즈니스 논리를 가질 수 있는 N 계층입니다.A related deployment architecture is the N-tier architecture, which may have multiple middle-tiers handling business logic.

트랜잭션 데이터의 일반적인 특성Typical traits of transactional data

트랜잭션 데이터는 다음과 같은 특성을 가질 수 있습니다.Transactional data tends to have the following traits:

요구 사항Requirement DescriptionDescription
표준화Normalization 고도로 정규화됨Highly normalized
스키마Schema 쓰기 시 스키마, 강력하게 적용Schema on write, strongly enforced
일관성Consistency 강력한 일관성 ACID 보장Strong consistency, ACID guarantees
무결성Integrity 높은 무결성High integrity
트랜잭션 사용Uses transactions Yes
잠금 전략Locking strategy 비관적 또는 낙관적Pessimistic or optimistic
업데이트 가능Updateable Yes
추가 가능Appendable Yes
작업Workload 과도 쓰기, 보통 읽기Heavy writes, moderate reads
인덱싱Indexing 기본 및 보조 인덱스Primary and secondary indexes
데이터 크기Datum size 소규모~중간 규모Small to medium sized
ModelModel 관계형Relational
데이터 모양Data shape 테이블 형식Tabular
쿼리 유연성Query flexibility 매우 유연Highly flexible
소수 자릿수Scale 작음(MB) ~ 큼(몇 TB)Small (MBs) to Large (a few TBs)

이 솔루션을 사용해야 하는 경우When to use this solution

비즈니스 트랜잭션을 효율적으로 처리 및 저장하고, 클라이언트 애플리케이션에 일관된 방식에서 사용할 수 있게 하려는 경우 OLTP를 선택합니다.Choose OLTP when you need to efficiently process and store business transactions and immediately make them available to client applications in a consistent way. 또한 분명한 처리 지연이 비즈니스의 일상 작업에 부정적인 영향을 미칠 때 이 아키텍처를 사용합니다.Use this architecture when any tangible delay in processing would have a negative impact on the day-to-day operations of the business.

OLTP 시스템은 트랜잭션을 효율적으로 처리 및 저장할 뿐만 아니라 트랜잭션 데이터를 쿼리하도록 디자인되었습니다.OLTP systems are designed to efficiently process and store transactions, as well as query transactional data. OLTP 시스템에서 개별 트랜잭션을 효율적으로 처리하고 저장한다는 목적은 데이터 정규화, 즉 데이터를 덜 중복되는 좀 더 작은 청크로 분할함으로써 어느 정도 달성됩니다.The goal of efficiently processing and storing individual transactions by an OLTP system is partly accomplished by data normalization — that is, breaking the data up into smaller chunks that are less redundant. 이 경우 OLTP 시스템이 많은 수의 트랜잭션을 독립적으로 처리할 수 있도록 하고, 중복 데이터가 있을 때 데이터 무결성을 유지하기 위해 필요한 추가 처리가 해소되므로 효율성이 유지됩니다.This supports efficiency because it enables the OLTP system to process large numbers of transactions independently, and avoids extra processing needed to maintain data integrity in the presence of redundant data.

과제Challenges

OLTP 시스템을 구현 및 사용할 경우 다음과 같은 몇 가지 해결 과제가 발생할 수 있습니다.Implementing and using an OLTP system can create a few challenges:

  • 잘 계획된 SQL Server 기반 솔루션과 같은 예외도 있지만, OLTP 시스템이 대량의 데이터에 대한 집계를 처리하는 데 항상 적절한 것은 아닙니다.OLTP systems are not always good for handling aggregates over large amounts of data, although there are exceptions, such as a well-planned SQL Server-based solution. 수백만 개의 개별 트랜잭션에 대한 집계 계산에 의존하는 데이터 분석은 OLTP 시스템의 리소스를 과도하게 사용합니다.Analytics against the data, that rely on aggregate calculations over millions of individual transactions, are very resource intensive for an OLTP system. 따라서 실행이 느려질 수 있으며, 데이터베이스의 다른 트랜잭션을 차단하게 되어 속도 저하를 야기할 수 있습니다.They can be slow to execute and can cause a slow-down by blocking other transactions in the database.
  • 고도로 정규화된 데이터에 대해 분석 및 보고 작업을 수행할 경우, 조인을 사용해서 대부분의 쿼리를 비정규화해야 하므로 쿼리가 복잡해질 수 있습니다.When conducting analytics and reporting on data that is highly normalized, the queries tend to be complex, because most queries need to de-normalize the data by using joins. 또한 OLTP 시스템에서 데이터베이스 개체에 대한 명명 규칙은 간결하고 간단한 편입니다.Also, naming conventions for database objects in OLTP systems tend to be terse and succinct. 명명 규칙이 간결하고 정규화가 높아지면서 비즈니스 사용자가 DBA 또는 데이터 개발자의 도움 없이 OLTP 시스템을 쿼리하는 것이 어려워집니다.The increased normalization coupled with terse naming conventions makes OLTP systems difficult for business users to query, without the help of a DBA or data developer.
  • 트랜잭션 기록을 무기한 저장하고, 하나의 테이블에 너무 많은 데이터를 저장하게 되면 저장된 트랜잭션 수에 따라 쿼리 성능이 저하될 수 있습니다.Storing the history of transactions indefinitely and storing too much data in any one table can lead to slow query performance, depending on the number of transactions stored. 일반적인 해결 방법은 OLTP 시스템에서 적절한 기간(예: 현재 회계 연도) 동안 두었다가 기록 데이터를 데이터 마트 또는 데이터 웨어하우스 등의 다른 시스템으로 오프로드하는 것입니다.The common solution is to maintain a relevant window of time (such as the current fiscal year) in the OLTP system and offload historical data to other systems, such as a data mart or data warehouse.

Azure의 OLTPOLTP in Azure

App Service Web Apps에 호스트되는 웹 사이트, App Service에서 실행되는 REST API 등의 애플리케이션이나 모바일 또는 데스크톱 애플리케이션은 일반적으로 REST API를 매개자로 사용해서 OLTP 시스템과 통신합니다.Applications such as websites hosted in App Service Web Apps, REST APIs running in App Service, or mobile or desktop applications communicate with the OLTP system, typically via a REST API intermediary.

실제로 대부분의 워크로드는 순수한 OLTP가 아닙니다.In practice, most workloads are not purely OLTP. 분석 구성 요소의 역할을 하기도 합니다.There tends to be an analytical component as well. 또한, 운영 체제에 대한 보고서 실행 등, 실시간 보고에 대한 요구도 높아지고 있습니다.In addition, there is an increasing demand for real-time reporting, such as running reports against the operational system. 이것을 HTAP(하이브리드 트랜잭션 및 분석 처리)라고도 합니다.This is also referred to as HTAP (Hybrid Transactional and Analytical Processing). 자세한 내용은 OLAP(온라인 분석 처리)를 참조하세요.For more information, see Online Analytical Processing (OLAP).

Azure에서 다음의 모든 데이터 저장소는 OLTP 및 트랜잭션 데이터 관리의 핵심 요구 사항을 충족합니다.In Azure, all of the following data stores will meet the core requirements for OLTP and the management of transaction data:

주요 선택 조건Key selection criteria

선택 옵션의 범위를 좁히려면 먼저 다음 질문에 답변합니다.To narrow the choices, start by answering these questions:

  • 사용자 고유의 서버를 관리하지 않고 관리되는 서비스를 원하시나요?Do you want a managed service rather than managing your own servers?

  • 사용하는 솔루션이 Microsoft SQL Server, MySQL 또는 PostgreSQL 호환성에 대해 특정 종속성을 갖나요?Does your solution have specific dependencies for Microsoft SQL Server, MySQL or PostgreSQL compatibility? 애플리케이션은 데이터 저장소와 통신하기 위해, 선택 가능한 데이터 저장소를 지원되는 드라이버를 기준으로 또는 사용되는 데이터베이스에 대해 가정되는 조건에 따라 제한할 수 있습니다.Your application may limit the data stores you can choose based on the drivers it supports for communicating with the data store, or the assumptions it makes about which database is used.

  • 쓰기 처리량 요구 수준이 특히 높은 편인가요?Are your write throughput requirements particularly high? 그렇다면 메모리 내 테이블을 제공하는 옵션을 선택합니다.If yes, choose an option that provides in-memory tables.

  • 솔루션의 다중 테 넌 트가 있나요?Is your solution multitenant? 그렇다면 데이터베이스마다 고정 리소스가 있는 것이 아니라, 탄력적인 리소스 풀에서 여러 데이터베이스 인스턴스를 가져오는 방식의 용량 풀을 지원하는 옵션을 고려합니다.If so, consider options that support capacity pools, where multiple database instances draw from an elastic pool of resources, instead of fixed resources per database. 이렇게 하면 모든 데이터베이스 인스턴스에서 용량을 보다 잘 분산하고, 좀 더 비용 효율적인 솔루션을 만들 수 있습니다.This can help you better distribute capacity across all database instances, and can make your solution more cost effective.

  • 데이터를 여러 지역에서 짧은 대기 시간으로 읽을 수 있어야 하나요?Does your data need to be readable with low latency in multiple regions? 그렇다면 읽을 수 있는 보조 복제본을 지원하는 옵션을 선택합니다.If yes, choose an option that supports readable secondary replicas.

  • 여러 지리적 지역에서 데이터베이스의 높은 가용성을 유지해야 하나요?Does your database need to be highly available across geo-graphic regions? 그렇다면 지리적 복제를 지원하는 옵션을 선택합니다.If yes, choose an option that supports geographic replication. 또한 주 복제본에서 보조 복제본으로의 자동 장애 조치(Failover)를 지원하는 옵션을 고려합니다.Also consider the options that support automatic failover from the primary replica to a secondary replica.

  • 데이터베이스에 특정 보안 요구가 있나요?Does your database have specific security needs? 그렇다면 행 수준 보안, 데이터 마스킹 및 투명한 데이터 암호화와 같은 기능을 제공하는 옵션을 검토합니다.If yes, examine the options that provide capabilities like row level security, data masking, and transparent data encryption.

기능 매트릭스Capability matrix

다음 표에서는 주요 기능 차이점을 요약해서 보여 줍니다.The following tables summarize the key differences in capabilities.

일반 기능General capabilities

기능Capability Azure SQL DatabaseAzure SQL Database Azure Virtual Machine의 SQL ServerSQL Server in an Azure virtual machine Azure Database for MySQLAzure Database for MySQL Azure Database for PostgreSQLAzure Database for PostgreSQL
관리되는 서비스인지 여부Is Managed Service Yes 아니요No Yes Yes
플랫폼에서 실행Runs on Platform 해당 사항 없음N/A Windows, Linux, DockerWindows, Linux, Docker N/AN/A N/AN/A
프로그래밍 기능 1Programmability 1 T-SQL, .NET, RT-SQL, .NET, R T-SQL, .NET, R, PythonT-SQL, .NET, R, Python SQLSQL SQL, PL/pgSQLSQL, PL/pgSQL

[1] 많은 프로그래밍 언어가 OLTP 데이터 저장소에 연결하고 이 저장소를 사용할 수 있도록 하는 클라이언트 드라이버 지원은 포함되지 않습니다.[1] Not including client driver support, which allows many programming languages to connect to and use the OLTP data store.

확장성 기능Scalability capabilities

기능Capability Azure SQL DatabaseAzure SQL Database Azure Virtual Machine의 SQL ServerSQL Server in an Azure virtual machine Azure Database for MySQLAzure Database for MySQL Azure Database for PostgreSQLAzure Database for PostgreSQL
최대 데이터베이스 인스턴스 크기Maximum database instance size 4TB4 TB 256TB256 TB 16TB16 TB 16TB16 TB
용량 풀 지원 여부Supports capacity pools Yes Yes 아니오No 아니요No
클러스터 스케일 아웃 지원 여부Supports clusters scale out 아니요No Yes 아니오No 아니요No
동적 확장성(강화)Dynamic scalability (scale up) Yes 아니요No Yes Yes

분석 워크로드 기능Analytic workload capabilities

기능Capability Azure SQL DatabaseAzure SQL Database Azure Virtual Machine의 SQL ServerSQL Server in an Azure virtual machine Azure Database for MySQLAzure Database for MySQL Azure Database for PostgreSQLAzure Database for PostgreSQL
임시 테이블Temporal tables Yes Yes 아니오No 아니요No
메모리 내(메모리 최적화) 테이블In-memory (memory-optimized) tables Yes Yes 아니오No 아니요No
Columnstore 지원 여부Columnstore support Yes Yes 아니오No 아니요No
적응 쿼리 처리Adaptive query processing Yes Yes 아니오No 아니요No

가용성 기능Availability capabilities

기능Capability Azure SQL DatabaseAzure SQL Database Azure Virtual Machine의 SQL ServerSQL Server in an Azure virtual machine Azure Database for MySQLAzure Database for MySQL Azure Database for PostgreSQLAzure Database for PostgreSQL
읽기 가능 보조 복제본Readable secondaries Yes Yes Yes Yes
지리적 복제Geographic replication Yes Yes Yes Yes
보조 복제본으로 자동 장애 조치(Failover)Automatic failover to secondary Yes 아니오No 아니요No 아니요No
지정 시간 복원Point-in-time restore Yes Yes Yes Yes

보안 기능Security capabilities

기능Capability Azure SQL DatabaseAzure SQL Database Azure Virtual Machine의 SQL ServerSQL Server in an Azure virtual machine Azure Database for MySQLAzure Database for MySQL Azure Database for PostgreSQLAzure Database for PostgreSQL
행 수준 보안Row level security Yes Yes Yes Yes
데이터 마스킹Data masking Yes Yes 아니오No 아니요No
투명한 데이터 암호화Transparent data encryption Yes Yes Yes Yes
특정 IP 주소로 액세스 제한Restrict access to specific IP addresses Yes Yes Yes Yes
VNet 액세스만 허용 하도록 액세스 제한Restrict access to allow VNet access only Yes Yes Yes Yes
Azure Active Directory 인증Azure Active Directory authentication Yes Yes 아니오No 아니요No
Active Directory 인증Active Directory authentication 아니요No Yes 아니오No 아니요No
다단계 인증Multi-factor authentication Yes Yes 아니오No 아니요No
상시 암호화 지원 여부Supports Always Encrypted Yes Yes 아니오No 아니요No
개인 IPPrivate IP 아니요No Yes 아니오No 아니요No