[DB] RDBMS의 버퍼캐시 히트율이 100%라면 Redis를 대체할 수 있을까?

버퍼 캐시란

MySQL, Oracle 등 많은 RDBMS는 디스크에서 가져온 데이터를 메모리에 할당된 버퍼캐시에 저장한다.

디스크에서 데이터를 읽는 작업은 고비용의 작업이기 때문에 캐싱해놓은 데이터를 읽음으로써 비용을 줄일 수 있다.

 

RDBMS의 버퍼 캐시 히트율이 100%라면 Redis를 대체할 수 있을까?

캐시 히트율이란 데이터를 캐시에서 찾을 때 그 데이터가 있는 비율을 뜻한다.

캐시 히트율 100%는 내가 찾는 모든 데이터가 캐시된 상태이다.

메모리를 사용하는 RDBMS의 버퍼 캐시에서 캐시 히트율이 100%라면 Redis를 대체할 수 있을 지에 대해 고민해보게 되었다.

 

1. 캐시 데이터 제어

Redis는 어떤 캐시를 등록하거나 삭제하는 등 캐시를 직접 제어할 수 있다.

TTL 등을 지정하여 한번 캐시된 데이터를 얼마나 유지할 것인지에 대해 설정할 수도 있다.

 

하지만 RDBMS는 어떤 데이터를 캐시할 지 직접 등록하거나 삭제하기 어렵다. 간접적으로 데이터들을 한번씩 조회해서 캐시가 되도록 유도는 할 수 있지만, redis처럼 직접적인 제어는 어렵다. 또한 한번 캐시된 데이터가 얼마나 유지될 지 확신하기도 어렵다.

 

2. Lock 오버헤드

Redis는 싱글 스레드로 동작하며 Race Condition을 걱정할 필요가 없으니 락을 거는 비용이 없다.

RDBMS는 여러 트랜잭션이 동시에 데이터를 접근하므로 데이터 정합성을 위해 Lock을 거는 오버헤드가 발생한다.

 

3. 조인

"Redis는 조인을 할 수 없지만, RDBMS는 조인을 할 수 있다" 라고 생각을 했었다.

하지만 실제로는 쿼리 결과를 저장하는 기능은 MySQL 5.7 버전에서 deprecated 되었다.

따라서 A 테이블과 B 테이블을 조인하는 쿼리를 실행하면 그 결과가 캐시되는 것이 아니라, 조인하는 데 필요한 A 테이블의 페이지와 B 테이블의 페이지를 캐시한다.

 

Redis는 그저 조인한 결과를 캐시해놓으면 된다. 따라서 위 문장은 아래와 같이 수정할 수 있다.

"Redis는 조인할 필요가 없지만, RDBMS는 조인을 해야 한다."

 

 

결론

RDBMS의 버퍼캐시는 느린 디스크 I/O 속도를 보완하는 용도일뿐 Redis와 같이 캐싱를 위한 기능은 아니기 때문에 캐시로 사용하기엔 적합하지 않다.

복잡한 조인을 수행해야 하는 경우에는 고비용의 연산을 미리 해놓을 수 있기 때문에 Redis를 사용하는 것이 더 효과적이다.