Impala · Trino · Hive 같은 것을 흔히 "SQL 엔진" 이라 부른다. SQL 을 받아 처리한다는 점은 RDBMS 와 같지만, 저장을 직접 하지 않는다는 점이 결정적으로 다르다.
| 항목 | RDBMS (Oracle · PostgreSQL · MySQL) | SQL 엔진 (Impala · Trino) |
|---|---|---|
| 저장 | 자기 형식으로 직접 저장하고 소유한다 | 저장은 HDFS · S3 · 다른 DB 가 한다 |
| 스키마 | 쓸 때 강제한다 (schema on write) | 읽을 때 적용한다 (schema on read) |
| 트랜잭션 | ACID 를 전제로 설계됐다 | 제한적이거나 테이블 포맷에 의존한다 |
| 갱신·삭제 | 행 단위로 자유롭다 | 비싸거나 제약이 있다 |
| 확장 | 주로 수직 확장. 읽기는 복제로 분산 | 수평 확장이 기본 |
| 잘하는 일 | 짧은 트랜잭션, 개별 행 접근 | 대량 스캔과 집계 |
RDBMS 는 데이터의 주인이고, SQL 엔진은 이미 어딘가에 있는 데이터를 해석해 읽는 쪽에 가깝다.
RDBMS 는 INSERT 시점에 타입과 제약을 검사한다. 통과하지 못하면 저장 자체가 거부된다. 그래서 저장된 데이터는 항상 스키마를 만족한다.
빅데이터 쪽은 원본 파일을 그대로 두고, 조회 시점에 테이블 정의를 씌워 해석한다. 적재가 빠르고 같은 파일에 다른 스키마를 씌워 볼 수도 있다. 대신 잘못된 데이터가 걸러지지 않은 채 들어와 조회할 때 드러난다. 컬럼이 밀려 들어가도 적재 단계에서는 아무도 막지 않는다.
SQL 엔진은 "어느 경로에 어떤 형식으로 무슨 컬럼이 있다"는 정보를 따로 보관한다. Hive Metastore 가 대표적이고, 보통 MySQL 이나 PostgreSQL 위에 올린다.
메타스토어에 들어가는 것은 대략 이렇다.
데이터 자체는 들어 있지 않다. 메타스토어를 잃으면 파일은 남아 있어도 테이블 정의를 다시 만들어야 한다. 반대로 파일을 직접 지우거나 옮기면 메타스토어와 어긋나 조회가 실패한다.
통계는 옵티마이저가 조인 순서와 방식을 고르는 근거다. 통계가 없거나 낡으면 계획이 크게 빗나간다.
ANALYZE TABLE sales COMPUTE STATISTICS FOR COLUMNS; -- Hive
COMPUTE STATS sales; -- Impala
RDBMS 의 UPDATE 는 블록 안의 행을 바꾸고 변경 전 이미지를 undo 에 남긴다. 되돌릴 수 있고 동시에 읽는 세션은 이전 값을 본다.
객체 저장소 위의 파일은 대개 덮어쓸 수 없다. 그래서 Iceberg · Delta Lake · Hudi 같은 테이블 포맷은 새 파일을 쓰고 어느 파일이 현재 유효한지를 메타데이터로 가리키는 방식을 쓴다. 갱신은 기존 파일을 남긴 채 새 스냅샷을 만드는 일이 된다.
여기서 따라오는 것이 둘 있다. 과거 스냅샷이 남아 있으므로 특정 시점 조회(time travel)가 가능하다. 그리고 작은 파일이 계속 쌓이므로 주기적으로 병합(compaction)하고 오래된 스냅샷을 만료시켜야 한다. 이 정리를 하지 않으면 메타데이터가 커지며 조회가 느려진다.
| 요구 | 맞는 쪽 |
|---|---|
| 주문 · 결제 같은 짧은 트랜잭션 | RDBMS |
| 단건 조회와 갱신이 많은 서비스 | RDBMS |
| 수억 행 스캔·집계 리포트 | SQL 엔진 |
| 여러 소스를 한 쿼리로 조인 | Trino 같은 연합 질의 엔진 |
| 원본을 그대로 쌓아 두고 나중에 해석 | 객체 저장소 + SQL 엔진 |
둘을 대체 관계로 보지 않는다. 운영계는 RDBMS 가 받고, 그 데이터를 분석계로 옮겨 SQL 엔진이 읽는 구성이 일반적이다. 이때 운영계와 분석계 사이에 원본에 가까운 형태로 쌓아 두는 영역을 ODS 라 부른다. 원본을 거의 그대로 두고 분석계가 운영계에 직접 질의하지 않게 하는 완충 역할을 한다.