TIL) 레디스는 왜 영속성일까?

레디스는 인메모리 데이터베이스입니다.
메모리는 데이터가 디스크보다 제한적이므로 전통적인 DB는 디스크에 저장하여 관리합니다.

레디스는 왜 인메모리 캐시인데 영속성을 보장하는 걸까 생각해봤습니다.

레디스는 왜 영속성을 보장할까?

세션 및 장애 전반에 걸쳐 데이터 가용성이 필요해졌다.

애플리케이션은 종종 사용자 세션, 서버 재시작 및 예기치 않은 장애 전반에 걸쳐 데이터를 유지해야합니다.

레디스가 단순한 캐싱 이상의 용도로 사용되는 상황(세션 관리, 실시간 분석, 장바구니)에서는 데이터 손실이 심각한 결과를 초래할 수 있습니다.

레디스 초기 개발자도 쓰기 작업이 많은 워크로드에 대해 디스크 기반의 SQL 데이터베이스의 한계를 극복하기 위해서였습니다.

인메모리 속도와 디스크 간의 간극을 해소한다.

레디스의 핵심은 속도이지만, 영속성을 추가하면 오버헤드가 발생됩니다. 다양한 영속성 옵션을 통해 성능과 내구성 요소를 선택할 수 있습니다.

• 영속성 없이 속도를 우선시 한다.
• 주기적인 스냅샷의 균형을 맞추는 방식을 사용
• 작업 로깅으로 내구성을 극대화 할 수 있습니다.

정리

RDB 특정 시점 스냅샷

메모리에 있는 레디스 데이터 세트의 스냅샷을 찍을 수 있습니다.

전송과 보관이 편한 단일 파일의 특성으로 백업및 재해 복구해 이상적입니다.

수동으로 스냅샷을 찍으면 안전한 스냅샷을 위해 자식 프로세스를 포크한 다음 덤프를 만듭니다.

설계 목적

백업 및 복구의 간결성과 속도입니다.

성능 및 백업 관리가 용이한 대신 간헐적 데이터 손실은 허용이됩니다.

AOF는 녹음 파일이라면 RDB는 기획서이기 때문입니다.

그래서 버전이 존재하여 놓친 기획이 있더라도 다양한 간격으로 생성될 수 있습니다.

RDB는 버전관리의 릴리즈 버전이다.

특정 시점마다 릴리즈 버전을 배포한다고 생각하면 빠른 복구와 재생이 가능하다.

AOF 모든 쓰기 작업 로깅

레디스가 작성하는 명령어를 그대로 저장하는 방식입니다.

실시간으로 저장하다보니 파일 디스크립터에 flush() 뿐만 아니라 sync()를 통해서 파일 I/O를 요청합니다.

무한대로 커질 수 있는 파일이므로 데이터 세트를 위한 최소한의 명령 집합만 포함하는 AOF 파일을 생성하는 기능도 제공합니다.

설계목적

모든 수정 사항을 기록하여 데이터 안정성과 무결성을 보장하려고 합니다.

fsync 정책을 통해 애플리케이션의 중요도에 따라 내구성과 성능 간의 균형을 미세하게 조정합니다.

AOF는 커밋 기록이다.

수정 사항이 생길때마다 커밋을 통해 기록을 남기게 된다.

오류 발생과 설계