지난 주부터 지속되는 성능 향상을 위한 방법

• 기본적인 CRUD는 가닥이 잡혔으나 그 구조에 대해 성능 이슈가 있었다.
  • URL 별 옵션을 수정했을 때 하위 URL+QueryString 캐시를 수정 / 삭제를 해야한다.
  • 기존에 Keys나 Scan을 활용한 조회 및 삭제 수정은 데이터베이스를 전체 조회를 해야함으로 하나의 캐시를 O(1)로 생각했을 때 캐시가 무수히 많을 때 O(n)의 성능을 가진다.
  • 해당 문제에 관련된 성능 향상을 구상해야한다.

데이터 계층화, 그룹화

• 지속적으로 나왔던 방향은 데이터에 계층을 두어서 상위 계층의 변화가 있을 때 하위 계층을 삭제하는 방향이었다.
  • 그러나 해당 방식을 구현하기 위한 방법을 찾기 어려웠다.
  • URL 데이터에 하위 캐시에 대한 key-value Map을 둔다고 가정하면
    • url 하위의 값을 저장해놓는 형태라 Expire Time이 자동 관리되지 않는다.
  • URL별로 캐시를 관리한다고 했을 때 실제 코드 상에서는 어떻게 구현할지도 애매했다.
    • 각 Url 별로 캐시 매니저를 생성해서 RedisTemplate로 접근하는 방식을 구상했다.
      • 그러나 결국 하나의 Redis 서버를 활용하는 것이기에 잘 못 실수하면 각 캐시 매니저에 영향을 줄 수 있다.
      • Redis 서버를 늘리거나 한 Redis 서버가 16개의 데이터베이스를 제공하는 것을 생각했을 때 URL 별로 데이터베이스를 제공하고 부족하면 서버를 늘리는 방안도 생각했다
      • 이 문제는 URL 별로 캐시량이 달라서 낭비가 데이터베이스 낭비가 발생할 수 있는 부분과 URL이 많아지면 서버가 무수히 많아지는 낭비가 발생할 수 있었다.
  • 결국 하나의 Redis 데이터베이스내에서 해결할 방법을 찾는 게 최선이었다.

Chat GPT는 모든걸 알고 있다.

• GPT를 통해서 여러 캐시를 효과적으로 삭제하는 방향에 대해 찾고 있는 과정에서 키워드를 몇개 얻었다.

  

  velog.io/@ddongbu/Redis

  • 조합된 캐시 키 사용
  • HashOperations

• HashOperations를 사용해서 캐시에 대한 상위 그룹을 생성하고 각 캐시를 상위 그룹에 저장하는 것이다.

• 해당 그룹을 삭제하는 것으로 하위 캐시를 삭제할 수 있다는 답변도 들었다.

  • deleteGroupCache 메서드를 호출하면 그룹 캐시인 **group1**에 속한 모든 키와 값을 삭제합니다. 따라서 하위 캐시들도 자동으로 삭제됩니다. 예를 들어, group1 그룹에 속한 key1, key2, key3 등의 키들과 그에 해당하는 값들이 함께 삭제됩니다.

테스트 코드를 작성해보자.

• 키워드를 얻었으니 다음 섹션에서는 코드를 작성해봐야할 것같다.

2023년 11월 27일 오전 2:00 (GMT+9) ~

HashOperations는 못 써먹겠다.

• 캐쉬를 생성한 이후로 그룹키에 Key를 삽입했다.
• 그리고 해당 그룹키에 속한 Key를 검색했을 때 잘 나왔다.