특수 테이블 형식 사용

  • 12분

SQL Server는 표준 디스크 기반 테이블 이외의 특정 시나리오 및 워크로드를 위해 설계된 특수 테이블 형식을 지원합니다. 메모리 내, 임시, 외부, LEDGER 및 GRAPH를 비롯한 이러한 테이블 형식은 표준 테이블이 효율적으로 해결할 수 없는 특정 성능, 규정 준수 또는 아키텍처 문제를 해결합니다.

이러한 특수 테이블 형식을 사용하는 시기와 방법을 이해하는 것은 애플리케이션의 요구 사항을 충족하는 효과적인 데이터베이스 솔루션을 설계하는 데 매우 중요합니다.

메모리 내 최적화 테이블 사용

기존 디스크 기반 테이블은 캐싱을 사용하더라도 디스크 I/O에서 대기 시간이 발생합니다. 응답 시간이 밀리초인 초당 수천 개의 트랜잭션과 같이 고속이 필요한 시나리오의 경우 디스크 대기 시간이 병목 상태가 됩니다. 메모리 상의 테이블은 데이터를 완전히 RAM에 유지하고, 잠금 없는 낙관적 동시성을 통해 문제를 해결합니다.

메모리 내 테이블을 사용하는 시기 이해

메모리 내 최적화 테이블은 특정 워크로드에 상당한 성능 이점을 제공합니다.

  • 세션 상태 스토리지 - 수백만 개의 동시 세션이 있는 웹 애플리케이션
  • 실시간 분석 - 마이크로초 대기 시간이 필요한 금융 거래 시스템
  • 고주파 OLTP - 10,000개 이상의 트랜잭션/초를 처리하는 주문 처리 시스템
  • 캐싱 계층 - 자주 액세스되는 참조 데이터(제품 카탈로그, 구성)
  • 스테이징 테이블 - 집중적인 삽입/업데이트 작업이 있는 ETL 프로세스

예를 들어 쇼핑 카트 데이터에 메모리 내 테이블을 사용하는 전자 상거래 사이트는 서브밀리초 응답 시간으로 50,000개의 동시 카트를 처리하여 체크 아웃 대기 시간을 80%줄입니다.

고려 사항 분석

메모리 내 테이블은 더 빠르게 액세스할 수 있도록 실제 테이블 데이터를 RAM에 저장하고 기존 테이블은 디스크에 데이터를 저장합니다. 그러나 데이터 크기는 사용 가능한 RAM에 의해 제한되며, 이러한 테이블은 큰 개체 형식(예: VARCHAR(MAX)또는 NVARCHAR(MAX)VARBINARY(MAX))을 지원하지 않습니다.

테이블 데이터가 메모리에 있는 경우에도 SQL Server는 내구성을 보장하기 위해 트랜잭션 로그를 디스크에 씁니다. 즉, 서버가 다시 시작되면 커밋된 트랜잭션이 손실되지 않습니다. 즉, 데이터가 트랜잭션 로그에서 메모리로 다시 복구됩니다.

옵션을 사용하여 MEMORY_OPTIMIZED = ON 메모리 내 최적화 테이블을 만들 수 있습니다. 예제는 다음과 같습니다.

-- Create in-memory optimized table
CREATE TABLE dbo.OrderCache (
    OrderID INT PRIMARY KEY NONCLUSTERED,
    CustomerID INT,
    OrderDate DATETIME2,
    Amount DECIMAL(10,2),
    INDEX IX_CustomerID NONCLUSTERED (CustomerID)
) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);

임시 테이블 사용

임시 테이블 은 데이터 변경의 전체 기록을 자동으로 추적합니다. 행을 업데이트하거나 삭제하면 SQL Server는 해당 버전이 유효한 시기를 표시하는 타임스탬프가 있는 연결된 기록 테이블에 이전 버전을 자동으로 저장합니다. 이 과정은 투명하게 이루어지며, INSERT, UPDATE, DELETE 문을 사용하여 데이터를 정상적으로 수정하면 데이터베이스 엔진에서 버전 관리를 처리합니다.

주요 이점은 언제든지 존재했던 데이터를 쿼리하는 것입니다. 복잡한 감사 테이블을 유지 관리하거나 사용자 지정 버전 관리 논리를 작성하지 않고 "2025년 1월 1일에 이 직원의 급여가 무엇이었습니까?" 또는 "지난 분기에 재고가 있는 모든 제품을 보여주세요"라고 물어볼 수 있습니다.

임시 테이블은 규정 준수, 문제 해결 및 분석 요구 사항을 제공합니다.

  • 규정 준수 및 감사 - 전체 변경 기록이 필요한 재무 레코드
  • 문제 해결 - 이의를 제기한 트랜잭션이 발생한 시점의 계정 잔액 조사
  • 추세 분석 - 분기 동안 제품 가격이 어떻게 변했는지 분석
  • 데이터 복구 - 백업을 복원하지 않고 실수로 업데이트 되돌리기
  • 서서히 변하는 차원 - 데이터 웨어하우스 타입 2 차원 자동화

일반적인 비즈니스 시나리오에는 급여 변경 및 프로모션을 추적하는 애플리케이션, 재고 동향을 분석하는 재고 관리, 규정 준수를 위한 환자 기록 기록을 유지하는 의료 서비스, 분쟁 해결을 위한 보험 추적 정책 적용 범위 변경 등이 있습니다.

시계열 테이블의 혜택을 고려하십시오

임시 테이블에는 애플리케이션 코드 변경이 필요하지 않으며 투명한 기록 추적이 제공됩니다. 지정 시간 쿼리는 간단한 구문을 사용하고 자동 정리는 이전 기록 데이터를 관리합니다. 그러나 임시 테이블은 대략 두 배의 스토리지 요구 사항입니다.

임시 테이블 은 감사 및 지정 시간 분석을 위해 데이터 변경 내용의 전체 기록을 자동으로 유지 관리합니다.

옵션을 사용하여 SYSTEM_VERSIONING = ON 임시 테이블을 만들 수 있습니다. 임시 테이블에는 각 행 버전의 유효 기간을 추적하는 두 개의 추가 DATETIME2 열과 PERIOD FOR SYSTEM_TIME 이러한 타임스탬프를 추적하는 열을 정의하는 절이 필요합니다. 예제는 다음과 같습니다.

-- Create temporal table with automatic history tracking
CREATE TABLE Employee (
    EmployeeID INT PRIMARY KEY,
    EmployeeName NVARCHAR(100),
    Department NVARCHAR(50),
    SysStartTime DATETIME2 GENERATED ALWAYS AS ROW START,
    SysEndTime DATETIME2 GENERATED ALWAYS AS ROW END,
    PERIOD FOR SYSTEM_TIME (SysStartTime, SysEndTime)
) WITH (SYSTEM_VERSIONING = ON);

-- Query historical data
SELECT * FROM Employee
FOR SYSTEM_TIME AS OF '2026-01-01' 
WHERE EmployeeID = 1;

임시 테이블을 만들 때 SQL Server는 자동으로 기록 테이블을 만들어 이전 행 버전을 저장하고 두 테이블을 투명하게 관리합니다.

외부 테이블 사용

최신 데이터 아키텍처에는 데이터 레이크, Blob Storage 및 여러 시스템에 분산된 데이터가 있는 경우가 많습니다. 일반적으로 쿼리하기 전에 모든 데이터를 데이터베이스에 ETL(추출, 변환, 로드)해야 합니다. 외부 테이블을 사용하면 데이터 가상화를 사용하여 데이터를 이동하지 않고 데이터가 있는 위치를 쿼리하여 스토리지 비용과 ETL 복잡성을 절약할 수 있습니다.

외부 테이블을 언제 사용하는지 이해하기

외부 테이블은 분산 스토리지 시스템에서 데이터를 쿼리하는 데 탁월합니다.

  • Data Lake 통합 - Azure Data Lake Storage의 Parquet/CSV 파일을 가져오지 않고 쿼리합니다.
  • 데이터 탐색 - 가져올 데이터를 결정하기 전에 원시 데이터 분석
  • 비용 최적화 - 이미 다른 곳에 저장된 데이터 복제 방지
  • 페더레이션 쿼리 - 데이터베이스 테이블을 외부 시스템의 파일과 조인
  • 보관 스토리지 - 저렴한 Blob Storage에 저장된 기록 데이터에 액세스

일반적인 시나리오에는 트랜잭션 데이터와 함께 데이터 레이크에서 수년간의 로그 파일을 쿼리하고, 라이브 데이터베이스 레코드를 보관된 Blob Storage 데이터와 결합하고, 전체 마이그레이션 없이 레거시 데이터에 액세스하고, 가져오지 않고 수백만 개의 IoT 센서 JSON 파일을 쿼리하는 것이 포함됩니다.

성능 제약 조건 고려

외부 테이블은 원본 간에 통합 쿼리를 제공하지만 제한 사항이 있습니다.

  • 데이터 이동 또는 스토리지 중복 없음
  • 네트워크 대기 시간 및 파일 구문 분석으로 인해 네이티브 테이블보다 느린 경우가 많습니다.
  • 읽기 전용(대부분의 시나리오에서는 업데이트/삭제할 수 없습니다).
  • 제한된 인덱싱 및 최적화

데이터 원본 및 파일 형식의 CREATE EXTERNAL TABLE 문을 사용하여 외부 테이블을 만들 수 있습니다. 예제는 다음과 같습니다.

-- Create external table pointing to data lake
CREATE EXTERNAL TABLE dbo.ExternalSalesData (
    OrderID INT,
    CustomerID INT,
    OrderAmount DECIMAL(10,2),
    OrderDate DATE
) WITH (
    LOCATION = '/raw/sales/',
    DATA_SOURCE = DataLakeSource,
    FILE_FORMAT = ParquetFormat
);

원장 테이블 사용

규제 산업에서는 데이터가 변조되지 않았음을 증명하는 것이 중요합니다. 기존 데이터베이스는 관리자가 데이터를 수정하거나, 기록 경과 변경을 수행하거나, 감사 로그를 삭제할 수 있습니다. 원장 테이블은 블록체인 기술에서 영감을 받은 암호화 확인을 사용하여 독립적으로 확인할 수 있는 변조 방지 레코드를 만들어 데이터 무결성에 대한 암호화 증명을 제공합니다.

원장 테이블을 사용하는 시기를 이해하기

원장 테이블은 규정 준수 및 포렌식 감사 요구 사항을 충족합니다.

  • 금융 거래 - 은행, 결제 처리, 암호 화폐 교환
  • 공급망 - 제품 원본, 양육권 및 신뢰성 추적
  • 법률 기록 - 불변성을 요구하는 계약, 계약, 법적 서류
  • 의료 - 처방전 기록, 환자 동의 양식
  • 정부 - 투표 기록, 토지 등록, 발급 허가

예를 들어 은행은 원장 테이블을 사용하여 거래 레코드를 저장할 수 있으므로 감사자가 게시 후 변경된 트랜잭션이 없는지 확인할 수 있습니다. 공급망 회사는 원장 테이블을 사용하여 제품 출처를 추적하여 고객에게 신뢰성 증명을 제공할 수 있습니다.

업데이트 가능한 원장과 추가 전용 원장 중에서 선택

원장 테이블은 두 가지 유형이 있습니다. 업데이트 가능한 원장 테이블은 INSERT, UPDATE, DELETE 작업을 허용하면서 모든 변경 내용을 암호화하여 추적합니다. 시스템은 임시 테이블과 유사하지만 변조 방지 확인의 추가 혜택을 통해 이전 버전을 기록 테이블에 자동으로 저장합니다. 추가 전용 원장 테이블은 오직 INSERT 작업만 허용하므로 절대 데이터 무결성이 필요한 시나리오에 대해 정말로 변경 불가능한 기록을 생성합니다.

두 기술을 결합하려면 업다이팅 가능한 원장 테이블과 임시 테이블이 모두 있는 테이블을 만들고 특정 시점 쿼리 기능과 함께 암호화 확인을 얻을 수 있습니다.

예를 들어, 제약 회사는 임상 시험 데이터에 대해 추가 전용 기록 테이블을 사용하여, 독립적인 감사자는 제출 후 테스트 결과가 변경되지 않았음을 암호화 증명으로 확인할 수 있습니다.

옵션을 사용하여 LEDGER = ON 원장 테이블을 만들 수 있습니다. 예제는 다음과 같습니다.

-- Create ledger table
CREATE TABLE dbo.FinancialTransaction (
    TransactionID INT PRIMARY KEY IDENTITY,
    AccountNumber NVARCHAR(20),
    Amount DECIMAL(15,2),
    TransactionType NVARCHAR(20)
) WITH (LEDGER = ON);

-- Append-only ledger provides immutability
CREATE TABLE dbo.AuditLog (
    LogID INT PRIMARY KEY IDENTITY,
    EventDescription NVARCHAR(500),
    EventTimestamp DATETIME2
) WITH (LEDGER = ON, APPEND_ONLY = ON);

원장 테이블을 만들 때 SQL Server는 숨겨진 열을 자동으로 추가하고 암호화 체인을 추적하는 지원 데이터베이스 개체를 만듭니다. 모든 행 수정은 이전 작업에 연결되는 암호화 해시를 생성하여 변조 방지 감사 내역을 만듭니다. sys.database_ledger_transactions 같은 기본 제공 시스템 뷰와 암호화 체인의 유효성을 검사하는 sp_verify_database_ledger 같은 절차를 사용하여 데이터 무결성을 확인할 수 있습니다.

그래프 테이블 사용

관계형 데이터베이스는 구조화된 데이터를 능가하지만 많은 조인이 필요한 고도로 연결된 데이터로 어려움을 겪습니다. 기존 테이블에서는 "친구의 친구"나 "3단계 카테고리를 통해 연결된 제품"을 찾는 것이 복잡해집니다. SQL Graph 기능은 기본적으로 노드 (엔터티) 및 에지 (관계)를 모델링하여 복잡한 관계 쿼리를 간단하고 성능 있게 만듭니다.

그래프 테이블은 관계 모델링을 간소화하지만 새 구문을 학습해야 합니다. 연결된 데이터의 직관적인 모델링, 관계 통과를 위한 간단한 쿼리 및 다중 홉 쿼리의 성능 향상을 제공합니다. 유연한 스키마는 진화하는 관계를 수용합니다. 그러나 그래프 테이블에는 구문에 대한 MATCH 학습 곡선이 있으며 읽기가 많은 관계 쿼리에 가장 적합합니다.

데이터베이스에는 그래프 데이터를 모델링하기 위해 함께 작동하는 여러 노드 및 에지 테이블이 포함될 수 있습니다. 노드를 나타내는 테이블과 데이터 관계에 따라 가장자리를 나타내는 테이블을 정의합니다.

비고

그래프 테이블은 모든 시나리오에 최적이 아닙니다. 단순한 부모-자식 관계에서 외래 키가 잘 작동하는 경우나, 복잡한 관계가 없는 주로 트랜잭션 데이터, 또는 고도로 구조화되어 안정적인 스키마 등의 경우에는 이를 사용하지 마세요.

그래프 테이블 구조 이해

SQL Graph는 두 가지 유형의 테이블을 사용하여 관계를 모델링합니다. 노드 테이블 은 엔터티를 저장하고 각 노드를 고유하게 식별하는 숨겨진 $node_id 열을 자동으로 포함합니다. 에지 테이블은 노드 간의 관계를 저장하고 숨겨진 열을 $edge_id$from_id포함하며 $to_id 연결을 유지 관리합니다. 이러한 특수 열을 사용하면 MATCH 구문이 관계를 효율적으로 탐색할 수 있습니다.

및 AS NODE 구문을 사용하여 AS EDGE 그래프 테이블을 만들 수 있습니다. 예제는 다음과 같습니다.

-- Create graph tables
CREATE TABLE Person AS NODE;
CREATE TABLE Manages AS EDGE;
CREATE TABLE Knows AS EDGE;

-- Insert nodes
INSERT INTO Person VALUES (1, 'Alice'), (2, 'Bob'), (3, 'Charlie');

-- Insert edges (relationships)
INSERT INTO Manages VALUES (1, 2), (2, 3);

-- Query relationships
SELECT Person1.name, Person2.name 
FROM Person AS Person1, Manages, Person AS Person2
WHERE MATCH (Person1-(Manages)->Person2)
AND Person1.id = 1;

노드 및 에지 테이블을 만들 때 SQL Server는 효율적인 그래프 순회 쿼리를 가능하게 하는 숨겨진 시스템 열을 자동으로 관리합니다.

각 특수 테이블 유형에는 절충이 있습니다. 메모리 내 테이블에는 RAM, 임시 테이블 이중 스토리지가 필요하고, 외부 테이블은 네트워크 대기 시간을 추가하고, 원장 테이블은 삭제를 방지하고, 그래프 테이블에는 새 구문이 필요합니다. 이러한 결정은 배포 후 변경하기 어렵기 때문에 디자인 중에 올바른 테이블 형식을 선택하는 것이 좋습니다.