InstantSearch 캐시 전략

InstantSearch 캐시 전략

빠르고 원활한 검색을 구현하고 싶습니다.검색된 항목 수가 많지 않습니다. 최대 100개까지입니다.각 항목에는 페이스북 이벤트가 저장될 수 있는 데이터 양이 들어 있습니다.초기 로드에 모두 표시됩니다(아마도 인피트 스크롤).데이터는 자주 변경되지 않습니다.동시 사용자 수는 100명을 넘지 않습니다.

위의 조건에 맞는 최선의 검색 결과 캐싱 전략은 무엇입니까?

가장 확장성이 높은 전략은 무엇입니까?

스택

• 프런트 엔드:Nuxt(VueJS) + InstantSearch(Algolia 없음)
• 백엔드: 스프링 부트
• 도커라이즈

생각할 수 있는 해결책

1. 백엔드의 추가 캐싱 서비스(예: reddis, memcached) + 각 검색 작업에서 UI를 server로 이동합니다.이는 기본적으로 각 키 입력의 백엔드에 스팸을 보냅니다.
2. 모든 항목을 로컬 스토리지(Vuex 등)에 로드하고 직접 검색합니다.이로 인해 앱의 메모리 용량이 증가하여 시간이 초과될 수 있습니다.
3. 둘의 조합?

캐시 레이어는 확실히 문제가 되지 않습니다.사용자 수는 문제가 되지 않습니다.aws의 작은 ec2 인스턴스라도 쉽게 처리할 수 있습니다.

텍스트 상자에 약간의 지연을 추가하여 모든 키 입력이 검색을 시작하지 않고 최대 50ms의 여유 시간을 줄 수 있습니다.검색창에 타이핑할 때 어떤 느낌인지 봐야지

이미지 등의 정적 자산을 Vuex에 직접 로드하지 않는 한 100개 항목의 Vuex도 매우 빠릅니다.JSON 데이터에는 100개까지는 많지 않지만, 앱에 갑자기 10000개의 항목이 있으면 확장성이 떨어집니다.

내 의견으로는 최상의 시나리오:

• 많은 요청이 매우 유사하거나 동일하기 때문에 캐시를 리디스합니다.캐시의 유효 기간에 대한 최적의 정보를 찾기만 하면 됩니다.
• 백엔드와 프런트엔드의 로드밸런싱(CPU 사용량이 특정 임계값을 초과할 경우 요청 급증 가능성을 처리하기 위해 필요에 따라 도커 이미지의 인스턴스를 더 생성)
• 백엔드가 단순히 검색만 하는 것이 아닌 경우 해당 검색을 전용 인스턴스로 아웃소싱하여 "일반 요청"을 방해하지 않도록 합니다.
• 중요: 검색 결과를 빠르게 얻으려면 데이터베이스에 인덱스를 생성하십시오. 가능한 한 전체 검색을 피하십시오.
• 24시간 365일 트래픽이 없는 앱이라면 서버리스로 전환하는 것도 생각할 수 있습니다.

편집: - 인스턴스 간의 통신을 멀리 이동할 필요가 없도록 API, 캐시 및 데이터베이스를 서로 닫으십시오.

언급URL : https://stackoverflow.com/questions/61339510/instantsearch-caching-strategy