クイズ: 状態と TTL

사용자별 SUM 을 내는 끝없는 GROUP BY 의 COMPILE PLAN 에서 집계 노드의 state 가 groupAggregateState, ttl 0 ms 였다. 뜻은?

• 상태를 쓰지 않고 매번 원천을 다시 읽는다
• 상태를 지우지 않는다 — 기본값 0 은 영원히 보존이다
• 0밀리초마다 상태를 비워 결과가 매번 새로 시작한다
• 체크포인트를 켜야 비로소 상태가 생긴다

SET 'table.exec.state.ttl' = '30 min' 을 걸었다. 이 값의 정확한 의미는?

• 모든 상태를 30분마다 한꺼번에 비워 처음부터 다시 센다
• 창의 크기를 30분으로 바꿔 결과를 30분 단위로 낸다
• 갱신 없이 30분 넘게 쉰 상태를 그 뒤 언젠가 지운다
• 워터마크보다 30분 넘게 늦은 행을 버린다

잡 기본값 30 min 에 STATE_TTL('o' = '1d', 'p' = '2h') 를 준 orders o ⋈ payments p 조인의 계획에 적히는 값은?

• leftState 30 min · rightState 30 min — 잡 설정이 힌트보다 우선한다
• leftState 2 h · rightState 1 d — 힌트는 알파벳 순서로 붙는다
• leftState 1 d · rightState 1 d — 힌트의 가장 큰 값이 양쪽에 붙는다
• leftState 1 d · rightState 2 h — 힌트가 연산자 수준에서 잡 설정보다 우선한다

조인 둘이 이어진 쿼리에 STATE_TTL('o'='1d','p'='2h','u'='7d') 와 잡 기본값 30 min 을 줬다. 둘째 조인의 leftState 는?

• 30 min — 첫 조인의 결과 자리는 힌트로 이름 붙일 수 없어 잡 설정을 받는다
• 1 d — 왼쪽 입력의 첫 표 o 의 값을 물려받는다
• 7 d — 둘째 조인의 힌트가 양쪽에 붙는다
• 0 ms — 힌트가 있는 쿼리에서는 잡 설정이 무시된다

10분 TUMBLE 창 집계에 잡 TTL 30 min 을 걸고 계획을 뽑았더니 창 집계 노드에 state 항목이 없었다. 이유로 맞는 것은?

• 창 집계는 상태를 전혀 쓰지 않고 한 행씩 바로 내보낸다
• 창 상태는 워터마크가 창 끝을 지나 결과를 낼 때 함께 비우므로 TTL 로 조절할 항목이 없다
• TTL 이 30 min 이라 10분 창보다 길어 계획에서 생략됐다
• blackhole 싱크에 넣는 계획이라 상태가 빠졌다

같은 GROUP BY 를 state.backend.type = rocksdb 로 돌렸다. 기본(hashmap)과 비교해 바뀌는 것은?

• 결과 값 — RocksDB 는 합계를 근사해 저장한다
• 계획의 TTL — RocksDB 는 TTL 을 0 ms 로 고정한다
• 상태를 두는 곳과 모양 — 힙의 자바 객체 대신 로컬 디스크의 직렬화된 바이트
• 결과의 변경 로그 — RocksDB 는 -U 를 내지 않는다