4.1 테이블 타입 선택

잘못된 타입 선택은 성능 저하와 기능 제한으로 이어지므로, 설계 초기에 데이터 성격에 맞는 타입을 결정해야 합니다.

• 타입 선택 결정 가이드
• 타입 비교표
• TRANSACTION vs LOOKUP 비교

테이블 타입의 역할과 저장 개념은 데이터 모델 개념을 참고하십시오. 같은 데이터라도 이력을 누적할지, 현재 상태를 갱신할지에 따라 적합한 타입이 달라집니다. 변경·조회·영속성 요구사항을 함께 검토합니다.

선택 전에 작성할 데이터 설명

테이블 이름보다 먼저 한 행이 나타내는 사실을 한 문장으로 적습니다. 같은 설비에서 나온 데이터라도 “온도 측정 한 건”, “현재 운전 상태 한 건”, “정비 작업 한 건”은 서로 다른 행의 단위이며 키와 변경 방식도 달라집니다.

예를 들어 온도 이력은 TAG, 알람 사건은 LOG, 설비 코드표는 LOOKUP이 후보입니다. 부품 재고 변경과 작업 등록을 함께 확정해야 하면 Standard Edition의 TRANSACTION을 검토합니다. 현재 상태 캐시는 원본에서 재구성할 수 있을 때 VOLATILE로 분리할 수 있습니다. 이들을 한 테이블로 합치기보다 각 행의 의미와 실패 시 복구 방법을 먼저 맞춥니다.

타입 선택 결정 가이드

아래 흐름으로 후보를 좁힌 뒤, 필요한 DML과 트랜잭션, 메모리 사용량, Edition 지원 여부를 비교표에서 확인합니다. 예를 들어 기준 정보라도 여러 변경을 하나의 트랜잭션으로 묶어야 한다면 LOOKUP 대신 TRANSACTION을 검토합니다.

결정 흐름

데이터가 센서/기기 계측값인가?
  ├── YES → 시간축인가?    YES → TAG TABLE (BASETIME)
  │            거리축인가?  YES → TAG TABLE (BASEDISTANCE)
  └── NO  ↓

데이터가 이벤트/로그/패킷인가? (추가 전용)
  ├── YES → LOG TABLE
  └── NO  ↓

데이터가 코드 테이블/기준 정보인가? (반복 조회·갱신)
  ├── YES → LOOKUP TABLE
  └── NO  ↓

데이터가 서버 재시작 시 폐기 가능한 인메모리 상태/캐시인가?
  ├── YES → VOLATILE TABLE
  └── NO  ↓

일반 관계형 업무 데이터 (UPDATE/DELETE/SELECT/INSERT 모두 필요)
  └── TRANSACTION TABLE

주요 판단 기준

주의사항

• 이벤트마다 고유한 이름을 태그 식별자로 사용하면 태그 수와 메타데이터가 계속 늘어납니다. 반복 계측 대상이 없는 이벤트는 LOG 테이블을 검토합니다.
• LOG 테이블은 UPDATE와 일반 조건 DELETE가 불가하므로 수정 가능성이 있는 데이터에는 부적합합니다. 보존/정리 목적의 BEFORE, OLDEST, EXCEPT DELETE만 사용합니다.
• TRANSACTION 테이블은 Standard Edition 전용입니다. Cluster Edition 환경에서는 LOOKUP(소규모) 또는 외부 RDBMS를 활용합니다.
• VOLATILE 테이블은 서버 재시작 시 데이터가 소멸됩니다.

타입 비교표

기능 비교

Append API는 테이블뿐 아니라 SDK와 입력 경로에 따라 지원 범위가 달라집니다. SDK Append 지원표에서 사용하는 드라이버와 테이블 조합을 확인합니다.

스토리지 특성

메모리 테이블의 “작다”는 고정 행 수를 의미하지 않습니다. 행 폭, 가변 길이 값과 보조 인덱스를 포함해 실제 메모리 사용량을 측정합니다. 디스크 기반 테이블도 압축률이나 서버 사양만으로 처리량을 보장할 수 없으므로 대표 입력과 조회를 함께 실행합니다.

TRANSACTION 테이블 제약

TRANSACTION 테이블은 다음 제약이 있습니다.

• Cluster Edition 미지원: Standard Edition 전용
• 최소 컬럼 수: 1개 이상

TRANSACTION vs LOOKUP 비교

TRANSACTION 테이블과 LOOKUP 테이블은 모두 관계형 데이터를 저장하지만, 대상 규모와 기능에 차이가 있습니다.

비교표

선택 가이드

TRANSACTION 테이블을 선택하는 경우

• 명시적 트랜잭션과 관계형 DML이 필요한 데이터
• UPDATE·DELETE·INSERT·SELECT가 모두 필요한 일반 관계형 워크로드
• PRIMARY KEY 없이 다양한 컬럼 조합으로 조회하는 경우
• Standard Edition 환경

LOOKUP 테이블을 선택하는 경우

• 코드 테이블과 기준 정보
• PRIMARY KEY 조회와 단건 UPDATE/DELETE가 필요한 경우
• Cluster Edition 환경에서도 사용해야 하는 경우
• 실시간 기준 정보 갱신이 필요한 경우

예시

-- LOOKUP: 국가 코드 테이블 (PK 조회와 조건 기반 UPDATE)
CREATE LOOKUP TABLE country_code (
    code   VARCHAR(4)   PRIMARY KEY,
    name   VARCHAR(64)
);
INSERT INTO country_code VALUES ('KR', 'Republic of Korea');
UPDATE country_code SET name = 'Korea' WHERE code = 'KR';
SELECT code, name FROM country_code WHERE code = 'KR';

-- TRANSACTION: 주문 이력 (대규모, 일반 UPDATE/DELETE 지원)
CREATE TRANSACTION TABLE order_history (
    order_id  LONG PRIMARY KEY,
    item_id   INTEGER,
    qty       INTEGER,
    amount    DECIMAL(18,2)
);
INSERT INTO order_history VALUES (12345, 501, 1, 12000.00);
UPDATE order_history SET qty = 10 WHERE order_id = 12345;
SELECT order_id, qty, amount FROM order_history WHERE order_id = 12345;
DELETE FROM order_history WHERE order_id = 12345;
SELECT COUNT(*) FROM order_history WHERE order_id = 12345;

첫 SELECT는 변경된 국가명을, 주문 SELECT는 수량 10을 반환합니다. 마지막 COUNT는 0입니다. 이 예제의 amount는 수량 변경과 별도로 유지하는 예시 금액이며 자동 재계산되지 않습니다. 실제 주문 모델에서는 단가·수량·합계의 관계와 함께 변경할 컬럼을 명시합니다. 실습을 끝내면 이 예제에서 만든 테이블만 DROP TABLE로 정리합니다.