sql 튜닝책을 읽다가 데이터베이스 버퍼 캐시가 있는데 왜 별도의 캐시 시스템을 활용할까? 라는 궁금증이 생겼다.
생각해보기
데이터베이스가 캐시의 역할만 수행한다면 문제가 없을거같다. 그러나 그렇지 않다.
데이터 관리를 수행하면서 캐시의 역할까지 수행한다는것은 무엇보다 모든 요청이 몰려들어온다는것으로 이해했다.
별도의 캐시시스템을 둔 경우 해당 캐시시스템이 다운되더라도 데이터베이스는 살아있으니
요청 처리는 진행될 수 있으며, 캐시시스템을 복구하여 대응할 수 있다.
이게 가장 핵심이라고 생각한다.
수 많은 트래픽에서 가장 핵심되는 포인트는 안정성이라고 생각한다.
즉, 어떤 시스템이 죽더라도 다른이가 이를 대신하여 사용자는 불편함을 느끼지 못하게...
또한 캐시 전략은 다양함을 떠올렸다.
예를들어 어떤 글에 대한 조회수를 저장한다고 생각해보면..
자주 변하는 count컬럼.. 특히 이 경우 그 횟수가 가장 빈번할 조회에 의해 결정된다고 생각한다.
이 상황에서 최신성을 고려하며 빠른 데이터 액세스를 위해서 조회 count를 데이터베이스에 업데이트하는게아니라
먼저 앞단에 있는 캐시에 update하고 추후 데이터베이스에 반영하는식을 고려해볼 수 있을거같다.
개요
생각해보기
별도의 캐시시스템을 둔 경우 해당 캐시시스템이 다운되더라도 데이터베이스는 살아있으니 요청 처리는 진행될 수 있으며, 캐시시스템을 복구하여 대응할 수 있다.
이게 가장 핵심이라고 생각한다. 수 많은 트래픽에서 가장 핵심되는 포인트는 안정성이라고 생각한다. 즉, 어떤 시스템이 죽더라도 다른이가 이를 대신하여 사용자는 불편함을 느끼지 못하게...
또한 캐시 전략은 다양함을 떠올렸다. 예를들어 어떤 글에 대한 조회수를 저장한다고 생각해보면.. 자주 변하는 count컬럼.. 특히 이 경우 그 횟수가 가장 빈번할 조회에 의해 결정된다고 생각한다. 이 상황에서 최신성을 고려하며 빠른 데이터 액세스를 위해서 조회 count를 데이터베이스에 업데이트하는게아니라 먼저 앞단에 있는 캐시에 update하고 추후 데이터베이스에 반영하는식을 고려해볼 수 있을거같다.
다양한 캐시 전략에 따른 설계를 하기위해선 별도의 시스템이 필요하지 않을까라고 생각한다.