Time Window Compaction Strategy

Time Window Compaction Strategy (TWCS)

Time Window Compaction Strategy(TWCS)은 시계열(time-series)과 만료되는 TTL(Time-To-Live) 워크로드에 권장되는 컴팩션 전략이에요. 데이터를 시간 윈도 단위로 묶어서, 만료된 윈도의 SSTable 전체를 통째로 버리는 방식이라 디스크 공간을 확실하게 회수할 수 있어요.

출처: Time Window Compaction Strategy (TWCS)

본문

The Unified Compaction Strategy (UCS) is the recommended compaction strategy for most workloads starting with {cass-50}. If you are creating new tables, use this strategy.

5.0(Cassandra 5.0)부터는 대부분의 워크로드에 UCS가 권장돼요. 새 테이블을 만들 때는 UCS를 쓰세요. TWCS는 시계열·TTL 만료 워크로드에 권장돼요. 워크로드의 데이터가 타임스탬프 기준으로 묶여 있다면, TWCS로 SSTable을 시간 윈도 기준으로 묶고 만료되면 SSTable 전체를 버릴 수 있어요. 그래서 STCS나 LCS보다 훨씬 확실하게 디스크 공간을 회수할 수 있어요.

TWCS는 일련의 시간 윈도 버킷으로 SSTable을 컴팩션해요. 활성 시간 윈도 동안에는 메모리에서 플러시된 모든 SSTable을 STCS를 사용해 더 큰 SSTable로 컴팩션해요. 시간 구간이 끝나면 이 SSTable들이 SSTable 최대 타임스탬프를 기준으로 단일 SSTable로 컴팩션돼요. 한 시간 윈도에 대한 메이저 컴팩션이 완료되면 그 데이터에 대해 더 이상의 컴팩션은 일어나지 않아요. 다음 시간 윈도에 기록된 SSTable부터 과정이 다시 시작돼요. 각 TWCS 시간 윈도에는 서로 다른 양의 데이터가 포함된다는 점을 기억하세요. 다음 윈도가 시작되면 과정이 반복돼요.

TimeWindowCompactionStrategy 운영상 고려사항

TWCS의 주된 목적은 데이터를 디스크에서 타임스탬프 기준으로 분리하고, 완전히 만료된 SSTable을 더 효율적으로 버리는 거예요. 이런 최적 동작이 무너질 수 있는 한 가지 경우는 데이터가 순서에 어긋나게(out of order) 쓰여서 새 데이터와 옛 데이터가 같은 SSTable에 섞이는 거예요.

순서가 어긋난 데이터는 두 가지 방식으로 나타날 수 있어요:

  • 사용자가 전통적인 쓰기 경로에서 옛 데이터와 새 데이터를 섞으면, 데이터가 멤테이블에서 섞인 채로 같은 SSTable로 플러시되고 계속 섞여 남아요.
  • 사용자의 옛 데이터 읽기 요청으로 인한 읽기 복구(read repair)가 옛 데이터를 현재 멤테이블로 끌어오면, 그 데이터가 섞여 같은 SSTable로 플러시돼요.

TWCS는 섞인 데이터의 영향을 최소화하려 하지만, 사용자는 이 동작을 피해야 해요. 특히 CQL USING TIMESTAMP로 타임스탬프를 명시적으로 설정하는 쿼리는 피해야 해요. 또한 자주 복구(repair)를 실행해야 해요(복구는 데이터가 섞이지 않도록 스트리밍해요).

The SizeTieredCompactionStrategy is the default compaction strategy. Any other compaction strategy must be defined in the cassandra.yaml file.

STCS가 기본 컴팩션 전략이고, 다른 전략은 cassandra.yaml 파일에 정의해야 해요.

TWCS Options (TWCS 옵션)

TWCS 옵션은 테이블 옵션으로 설정해요. 주요 옵션은 다음과 같아요.

Subproperty Description
enabled 백그라운드 컴팩션을 활성화해요. Default value: true
tombstone_compaction_interval SSTable 생성 후 Cassandra가 툼스톤 컴팩션을 고려하기까지의 최소 시간(초). 테이블이 tombstone_threshold 비율을 초과하면 해당 SSTable이 툼스톤 컴팩션 대상이 돼요. Default value: 86400
tombstone_threshold 모든 컬럼 중 가비지 컬렉션 가능한 툼스톤의 비율. 이 한도를 초과하면 Cassandra가 해당 테이블만 따로 컴팩션해 툼스톤을 정리해요. Default value: 0.2
unchecked_tombstone_compaction true로 설정하면 대상 테이블 사전 검사 없이 툼스톤 컴팩션을 실행할 수 있어요. 사전 검사가 없어도 Cassandra는 툼스톤을 안전하게 제거할 수 있는 SSTable인지 확인해요. Default value: false
log_all 전체 클러스터에 고급 로깅을 활성화해요. Default value: false
compaction_window_unit 버킷 크기를 정의하는 데 쓰는 시간 단위. 값은 Java TimeUnit을 기준으로 해요. 유효한 값 목록은 Java API TimeUnit 문서(docs.oracle.com/javase/8/docs/api/java/util/concurrent/TimeUnit.html)를 참고하세요. Default: days
compaction_window_size 버킷당 단위 수. Default value: 1
timestamp_resolution 데이터 삽입 시 사용하는 타임스탬프 해상도. MILLISECONDS, MICROSECONDS 등이 될 수 있어요(Java TimeUnit이 이해할 수 있어야 해요). USING TIMESTAMP(또는 클라이언트에서 그에 상응하는 방식)로 변형을 수행하지 않으면 이 값을 바꾸지 마세요. Default: microseconds
expired_sstable_check_frequency_seconds 만료된 SSTable을 얼마나 자주 확인할지 결정해요. Default: 10 minutes
unsafe_aggressive_sstable_expiration 만료된 SSTable이 다른 SSTable의 데이터를 가리고 있는지 확인하지 않고 버려요. 단일 SSTable 컴팩션에서 unchecked_tombstone_compaction이 하는 것보다 더 나아가, 데이터 손실이나 삭제된 데이터가 다시 나타나는 위험이 있는 잠재적으로 위험한 옵션이에요. 위험 때문에 JVM도 옵션 -Dcassandra unsafe_aggressive_sstable_expiration=true로 시작해야 해요. Default: false

종합하면, 운영자는 거의 모든 크기의 윈도를 지정할 수 있고, TWCS는 그 윈도 안에서 쓰인 데이터에 대해 단일 SSTable을 만들기 위해 동작해요. 쓰기 효율을 위해 가장 새로운 윈도는 STCS로 컴팩션돼요.

이상적으로 운영자는 약 20~30개의 윈도를 만들어내는 compaction_window_unit과 compaction_window_size 조합을 선택해야 해요. 예를 들어 90일 TTL로 쓰는 경우 3일 윈도가 합리적인 선택이며, 옵션을 'compaction_window_unit':'DAYS'와 'compaction_window_size':3으로 설정하면 돼요.

Changing TimeWindowCompactionStrategy Options (TWCS 옵션 변경)

기존 데이터에 TWCS를 활성화하려는 운영자는 먼저 메이저 컴팩션을 실행해 모든 기존 데이터를 단일(옛) 윈도에 넣어 두는 것을 고려해야 해요. 이후의 새 쓰기는 예상대로 일반적인 SSTable을 만들 거예요.

compaction_window_unit이나 compaction_window_size를 바꾸는 것도 가능하지만, 인접한 윈도가 합쳐지면서 추가 컴팩션이 트리거될 수 있어요. 윈도 크기를 줄이면(예: 24시간에서 12시간으로) 기존 SSTable은 수정되지 않아요. TWCS는 기존 SSTable을 여러 윈도로 분할할 수 없어요.

더 알아보기 (Learn more)