이것은 일반적인 캐싱 사용 시나리오입니다. 사용하는 기술 솔루션에 따라 고려해야 할 몇 가지 사항이 있습니다.
mongodb를 선택했으므로 쿼리 시나리오는 하나의 키를 사용하여 전체 문서의 데이터를 얻으려고 해야 합니다. 이러한 종류의 쿼리는 mongodb가 가장 적합하며 이론적으로 추가 최적화가 필요하지 않습니다.
위의 상황 외에 원하는 결과를 얻기 위한 쿼리가 여러 개라면 캐시 사용을 고려해 볼 수 있습니다. 이제는 Memcached보다 Redis를 사용하는 것이 더 유연하다고 생각합니다. 더 구체적인 단계:
(1) 각 쿼리에 대해 먼저 캐시로 이동하여 이미 값이 있는지 확인합니다
(2) 그렇지 않은 경우 특정 규칙에 따라 쿼리 조건을 키로 사용하고 쿼리 결과를 값으로 사용하여 캐시에 저장하고 이 쿼리의 결과를 반환합니다.
(3) 그렇다면 직접 반환합니다(비즈니스 요구에 따라 유효 기간이나 신규 쓰기 등 캐시 무효화 제어도 수행해야 함)
포스터가 얼마나 사업을 하는지 모르겠습니다. Mongodb도 인메모리 데이터베이스 부분을 가지고 있습니다. Mongodb는 쓰기 병목 현상이 심하지 않으므로 읽기 사업은 순수 데이터베이스에 배치해야 합니다. Redis와 같은 In-Memory 데이터베이스를 걱정할 필요 없이 Mongo에 직접 저장하는 것이 더 좋지 않을까요?
이것은 일반적인 캐싱 사용 시나리오입니다. 사용하는 기술 솔루션에 따라 고려해야 할 몇 가지 사항이 있습니다.
(1) 각 쿼리에 대해 먼저 캐시로 이동하여 이미 값이 있는지 확인합니다
(2) 그렇지 않은 경우 특정 규칙에 따라 쿼리 조건을 키로 사용하고 쿼리 결과를 값으로 사용하여 캐시에 저장하고 이 쿼리의 결과를 반환합니다.
(3) 그렇다면 직접 반환합니다(비즈니스 요구에 따라 유효 기간이나 신규 쓰기 등 캐시 무효화 제어도 수행해야 함)
"먼저 특정 콘텐츠를 memcache에 저장한 다음, 쿼리 중에 데이터베이스에서 얻은 인덱스 값을 통해 memcache에서 해당 데이터를 얻습니다." 이 문장이 잘 이해가 되지 않습니다. 다운된 경우 데이터가 사라집니다.
포스터가 얼마나 사업을 하는지 모르겠습니다. Mongodb도 인메모리 데이터베이스 부분을 가지고 있습니다. Mongodb는 쓰기 병목 현상이 심하지 않으므로 읽기 사업은 순수 데이터베이스에 배치해야 합니다. Redis와 같은 In-Memory 데이터베이스를 걱정할 필요 없이 Mongo에 직접 저장하는 것이 더 좋지 않을까요?