모범 사례 캐싱 : 모 놀리 식 대 세분화 된 캐시 데이터

Question

분산 된 캐싱 시나리오에서 일반적으로 캐시에 저장된 모 놀리 식 개체를 사용하거나 피하는 것이 좋습니다?

EAV 스키마가 지원되는 서비스로 작업 중이므로 모든 기본 레코드와 각 속성 컬렉션을 데이터베이스에서 검색 할 때 EAV가 부과하는 성능 저하를 최소화하기 위해 캐싱을 실시합니다. 서비스 시작시 캐시를 준비합니다.

우리는 모든 제품에 대해 특별히 자주 호출하지 않습니다. 클라이언트는 객체 캐시를 사용하여 로컬 캐시를 처음 채운 후에 차등을 호출합니다. 이러한 차등을 수행하기 위해 분산 캐시는 임의적으로 수행되는 데이터베이스의 개별 레코드에 대한 변경 사항을 반영해야하고 클라이언트가 차등을 요청할 때 변경 사항을 처리해야합니다.

첫 번째 생각은 목록이나 사전을 사용하여 분산 캐시에 레코드를 저장하는 것입니다. 전체 컬렉션을 가져 와서 메모리에서 로컬로 검색하거나 전체 컬렉션을 다시 캐시에 저장합니다. 그러나 나중에 생각해 보면 캐시를 개별 레코드로 채우려는 생각이 들었습니다. 각각의 레코드는 캐시에서 개별적으로 검색/캐시 가능하게 만드는 방식으로 작성되었습니다. 이로 인해 모든 데이터를 업데이트 할 때 어떤 방법이 더 효과적 일지 궁금해졌습니다.

우리는 Windows Server AppFabric을 사용 중이므로 BulkGet 작업을 사용할 수 있습니다. 그러나 일괄 업데이트의 개념이 있다고는 생각하지 않습니다.

분산 캐시 개체 크기에 대한 일반적인 생각이 있습니까? 모든 항목에 대한 요청이 더 많아지면 네트워크 대역폭에 대한 우려가 있습니다. 그러나 적어도 지금은 모든 항목에 대한 요구 사항이 상당히 적어야합니다.

그렇습니다. 각 방법을 테스트하고 프로파일 링 할 것입니다. 그러나 여기서 고려해야 할 현재의 범위 밖에있는 것이 있는지 궁금합니다.

Answer 1

우리 시나리오에서는 모 놀리 식 캐시 개체가 선호되는 것으로 보입니다. 데이터 센터에있는 큰 뚱뚱한 파이프 덕분에 30MB 정도의 직렬화 된 제품 데이터가 전선을 가로 지르는 것을 거의 감지 할 수 없습니다. Dictionary<TKey, TValue>을 사용하면 개별 항목을 반환하거나 업데이트하기 위해 컬렉션에서 제품을 빠르게 찾을 수 있습니다.

개별 엔티티 수천 개가 모두 1MB 미만인 경우 캐시에서 대량 작업이 너무 오래 걸립니다. 너무 많은 오버 헤드, 네트워크 작업의 대기 시간.

편집 : 이제 엔티티와 모노리딕 엔티티 컬렉션을 유지 관리하는 것이 고려됩니다. 왜냐하면 모노리딕을 사용하면 개별 엔티티를 검색하는 것이 프로덕션 데이터 세트로 상당히 비싼 프로세스가되기 때문입니다.