2.2 저장 및 실행 구조

조회 시간은 SQL 문장의 길이만으로 결정되지 않습니다. 얼마나 많은 데이터를 읽는지, 조건으로 읽을 범위를 얼마나 줄일 수 있는지, 정렬·조인·집계에 어떤 처리가 필요한지가 중요합니다. 이 절에서는 저장, 인덱스와 캐시를 각각 어떤 비용을 줄이는 기술인지 설명합니다.

Machbase 아키텍처 개요

사용자는 machsql이나 SDK를 통해 서버에 입력·조회 요청을 보냅니다. 서버는 SQL의 문법, 객체와 권한을 확인하고 실행 방법을 결정한 뒤 저장 데이터에 접근해 결과를 반환합니다. 저장·실행 방식은 테이블 유형과 Edition에 따라 다릅니다.

Standard Edition 구조

Standard Edition은 단일 데이터베이스 서버에서 SQL 처리와 데이터 저장을 수행합니다. LOG·TAG의 시계열 입력뿐 아니라 TRANSACTION의 관계형 변경, LOOKUP·VOLATILE의 기준 정보와 상태 관리도 각각의 테이블 특성에 맞는 경로로 처리합니다.

클라이언트: machsql 또는 SDK
          │ 입력·조회 요청
          ▼
Machbase DBMS 서버
  SQL 분석과 실행 계획
  테이블별 저장·인덱스 접근
  메모리 버퍼와 백그라운드 처리
          │
          ▼
테이블 유형에 따른 저장 데이터

이 그림은 역할을 나타낸 개념도입니다. 모든 요청이 같은 저장 경로를 거치거나 API 호출 즉시 디스크 파일에 기록된다는 의미는 아닙니다.

Cluster Edition 구조

Cluster Edition은 여러 노드가 역할을 나누어 수행합니다. 일반적인 애플리케이션 SQL 접속은 Broker를 통해 이루어지며, Warehouse는 시계열 데이터를 저장하고 쿼리를 실행합니다. Coordinator는 클러스터 메타데이터와 노드 상태를 관리하고, Lookup은 기준 정보 처리를, Deployer는 배포와 노드 관리를 담당합니다.

데이터를 여러 그룹에 분산하는 것은 처리량과 용량을 나누는 일이고, 같은 그룹에서 복제하는 것은 장애에 대비하는 일입니다. 두 목적은 다릅니다. 노드를 추가한다고 모든 쿼리가 같은 비율로 빨라지거나 모든 장애를 자동으로 극복하는 것은 아닙니다.

구성별 기능 차이는 Edition 개념에서, 실제 배포와 장애 대응은 Cluster 설치와 Cluster 운영에서 확인합니다.

입력과 조회의 흐름

입력은 대상 테이블·컬럼 확인, 값 변환과 검증, 데이터 전달·저장 단계로 생각할 수 있습니다. SQL과 Append API는 처리 결과를 확인하는 방식이 다르므로 애플리케이션은 선택한 경로의 오류 처리와 완료 조건을 따라야 합니다.

조회는 SQL 분석과 실행 계획 수립, 대상 데이터 접근, 조건 평가와 집계·조인·정렬, 결과 반환으로 이어집니다. 모든 데이터가 반드시 같은 순서로 처리되는 것은 아니며 실제 실행 계획에 따라 접근 순서가 달라집니다.

컬럼형 저장과 압축

행 지향과 컬럼 지향

행 지향 저장은 한 행에 속한 값을 함께 다루는 방식이고, 컬럼 지향 저장은 같은 컬럼의 값을 묶어 다루는 방식입니다. 아래 그림은 두 방식의 차이를 나타낸 예시이며 실제 파일 배치를 그대로 표현한 것은 아닙니다.

논리적 행:
  (시각1, 센서A, 23.1)
  (시각2, 센서A, 23.5)
  (시각3, 센서B, 18.0)

행 지향:    [시각1, 센서A, 23.1] [시각2, 센서A, 23.5] ...
컬럼 지향:  [시각1, 시각2, 시각3] [센서A, 센서A, 센서B] [23.1, 23.5, 18.0]

Machbase의 LOG·TAG 시계열 저장은 컬럼 단위 접근과 압축을 활용합니다. 많은 행에서 일부 컬럼만 읽는 분석에서는 읽을 데이터의 양을 줄이는 데 도움이 됩니다. 다만 온도 평균을 조회하더라도 센서·시각 조건이 있으면 해당 조건을 평가할 데이터도 필요합니다.

행 지향 시스템도 인덱스나 파티션을 이용해 필요한 범위만 읽을 수 있습니다. “행 지향은 항상 전체 행을 읽고 컬럼 지향은 언제나 빠르다”는 식으로 비교하지 말고, 읽을 행·컬럼 수와 접근 경로를 함께 살펴보십시오. TRANSACTION의 관계형 저장이나 LOOKUP·VOLATILE의 메모리 특성을 LOG·TAG와 같은 구조로 해석해서도 안 됩니다.

압축이 효과적인 조건

같은 컬럼에는 같은 타입의 값이 모이고, 센서 값이나 시각에는 반복되거나 비슷한 패턴이 나타날 수 있습니다. 이런 특성은 압축에 유리합니다. 반면 잡음이 큰 값, 불규칙한 문자열과 입력 순서가 섞인 데이터는 다른 결과를 보일 수 있습니다.

시계열 시각이 반드시 단조 증가하는 것은 아닙니다. 늦게 도착한 측정값과 여러 수집원의 입력이 섞일 수 있습니다. 실제 압축률과 처리 성능은 타입, 값의 분포, 입력 순서와 설정에 따라 측정해야 하며 특정 압축 알고리즘이나 비율을 전제하지 않습니다.

파티션과 읽기 범위

파티션은 데이터를 관리 가능한 부분으로 나누는 단위입니다. 조회 조건과 저장된 범위 정보를 활용해 관련 없는 부분을 건너뛰면 읽기 작업을 줄일 수 있습니다. 이를 파티션 가지치기(partition pruning)라고 합니다.

LOG·TAG의 저장 단위가 사용자가 지정한 하루·한 달과 반드시 일치하는 것은 아닙니다. 태그와 축의 조건, 데이터 분포와 테이블별 저장 구조에 따라 실제 접근 범위가 달라집니다. 시간 조건을 작성했다는 이유만으로 필요한 데이터만 읽는다고 단정하지 말고 실행 계획과 측정 결과를 확인합니다.

인덱싱 기본 원리

인덱스는 조건에 맞는 데이터를 찾는 접근 경로입니다. 찾을 대상이 전체 데이터의 작은 부분이면 도움이 될 수 있지만, 대부분의 행을 읽는 집계에서는 다른 경로가 유리할 수 있습니다. 인덱스는 저장 공간과 입력·변경 시 관리 비용도 필요합니다.

예를 들어 “전체 센서의 한 달 평균”과 “센서 A의 최근 1분 값”은 읽을 데이터의 비율이 다릅니다. 같은 테이블이라도 두 쿼리에 같은 성능을 기대하기 어렵습니다. 조인에서는 각 입력의 행 수와 조인 조건도 중요합니다.

지원 인덱스와 제한은 스키마 객체 정의에서, 측정과 조정 방법은 인덱스 튜닝에서 확인합니다.

Cache와 실행 계획 개념

SQL 실행 과정

서버는 SQL의 문법과 타입·객체를 확인하고, 조건과 인덱스 등으로 실행 가능한 접근 경로를 정한 뒤 실제 데이터를 처리합니다. 실행 계획은 이 처리 방법을 나타냅니다. 계획을 만드는 비용과 계획에 따라 데이터를 읽는 비용은 서로 다릅니다.

실행 계획 재사용과 PVO Cache

PVO Statement Cache는 재사용 가능한 SQL의 파싱·검증·최적화 결과와 실행 계획을 재사용해 반복 준비 비용을 줄입니다. 조회 결과 행을 저장하는 캐시가 아니므로 계획을 재사용해도 데이터를 읽고 조건을 평가하는 작업은 필요합니다.

Min-Max Cache처럼 저장 데이터의 범위 정보를 활용하는 캐시는 읽을 대상을 줄이는 목적을 가집니다. 실행 계획 캐시와 데이터 접근용 캐시를 하나로 생각하지 마십시오. 어떤 캐시를 크게 할지는 적중률과 메모리 사용량을 확인한 뒤 판단합니다.

EXPLAIN으로 실행 계획 확인

다음 예제는 데이터 모델 개념에서 만든 sensor_values 테이블을 사용합니다.

EXPLAIN SELECT AVG(value)
FROM sensor_values
WHERE name = 'temp_sensor_01'
  AND time >= TO_DATE('2026-07-01', 'YYYY-MM-DD')
  AND time <  TO_DATE('2026-07-03', 'YYYY-MM-DD');

실행 계획으로 데이터 접근과 조건 적용 방법을 확인합니다. 실행 계획이 존재한다는 사실만으로 실제 응답 시간이나 디스크 읽기량까지 알 수 있는 것은 아니므로 대표 데이터에서 실행 시간도 함께 측정합니다. 캐시가 비어 있는 첫 실행과 재사용한 실행의 조건을 구분하면 결과를 해석하기 쉽습니다.

PVO Cache의 적중·제거 통계는 V$PVO_CACHE_STAT, 캐시된 SQL은 V$PVO_CACHE_LIST에서 확인합니다. 설정과 진단은 캐시와 메모리 튜닝(영문)을 참고하십시오.