Optimizing TTL Manager.md

Optimizing TTL Manager

TTL 정보가 저장된 경우는 컴팩션 수행시 반드시 데이터 별로 저장된 TTL 정보를 확인하여야 한다. 보통 ASL/FSL 자체의 저장 순서와 TTL 정보가 비례하므로, 컴팩션 input 대상 파일의 key range와 동일한 방식으로 각 파일 별 TTL range를 저장하면, discard 대상을 쉽게 찾을 수 있다.

• 각 SST 파일 별 TTL start, end 정보 저장
• 컴팩션 수행시 필터에 따라서 TTL 소거 대상들은 merge를 수행하지 않고 바로 삭제하도록 함

방법 1. 컴팩션 필터 방식

일반 컴팩션 필터 처럼 컴팩션을 진행하는 순간에 필터를 적용하여 TTL 소거 대상들을 제외한다.

현재의 컴팩션 코드에 추가를 하면 된다.

장점

• 현재 RocksDB 컴팩션의 스타일이나 시맨틱을 해치지 않는다.
• TTL 소거를 위한 추가 리소스가 거의 필요하지 않다.

단점

• TTL이 만료된 소거 대상 파일들이 컴팩션의 input 대상으로 선택되지 않는 한 계속 남아있다.
• 이로 인해 Space Amplification을 해결하지 못한다.

방법 2. TTL discarder 쓰레드 방식

백그라운 컴팩션 쓰레드가 동작하는 것처럼, TTL 소거만을 위한 새로운 쓰레드를 생성하고 주기적으로 TTL 탐지 및 소거를 진행하도록 한다.

현재 코드에 큰 변화 없이 새로운 코드를 추가하는 방식으로 진행 할 수 있으며, TTL 주기에 맞춰서 바로바로 동작 할 수 있다. 대상 파일은 FIFO 방식을 통해서 오래된 파일부터 선정하도록 한다.

장점

• 사용자가 원하는 TTL 주기에 완전히 동기화 시켜서 동작하도록 할 수 있다.
• TTL이 만료가 된 데이터가 생긴 뒤 얼마 지나지 않아 TTL discarder에 의해 소거된다.
• 이로 인해 Space amplification을 효율적으로 관리할 수 있다.

단점

• 새로운 쓰레드를 추가해야 하며, 컴팩션 쓰레드와 비슷한 코드를 작성하는 번거로움이 필요하다.
• 쓰레드 관리를 위한 추가 리소스가 필요하다.
• foreground 작업들에 방해가 될 수 있다.

방법 3. FIFO 컴팩션

현재 RocksDB 코드에 구현이 되어 있는 방식으로, FIFO 방식을 통해 오래된 파일부터 컴팩션을 진행할 경우, TTL이 만료된 모든 데이터들이 먼저 소거되게 된다. 이 경우, 따로 TTL 매니저를 호출하지 않아도 된다.

장점

• 이미 구현이 되어 있으며, 간단한 옵션을 통해 사용할 수 있다.

단점

• 그럼에도 Compaction 최적화는 반드시 필요하며, TTL 주기와 컴팩션 주기가 맞지 않을 경우 비효율적일 수 있다.
• 모든 데이터들이 같은 TTL 주기를 가지고 있다면 효율적이지만, 서로다른 TTL 주기를 가지고 있을 경우 섞이는 문제가 발생한다.