데이터를 캐시하거나 데이터베이스에 충돌해야합니까?

나는 캐싱 메커니즘을 사용하지 않았으며 다음 시나리오에서 .net 세계에서 내 옵션이 무엇인지 궁금합니다.

우리는 기본적으로 사용자가 범주 (생각 폴더)의 ID를 전달하는 REST 서비스를 가지고 있으며이 범주에는 많은 하위 범주가있을 수 있으며 각 하위 범주에는 다음과 같은 정보가 포함 된 1000 개의 미디어 컨테이너 (생각 파일 참조 객체)가있을 수 있습니다 NAS 또는 SAN 서버에있을 수있는 파일 (이 경우 비디오 파일) 이러한 범주 간의 관계는 일부 권한 규칙 및 하위 범주에 대한 메타 데이터와 함께 데이터베이스에 저장됩니다.

UI 관점에서 우리는 각 하위 폴더를 클릭하여 사용자가 구동하는 느리게로드 된 트리 컨트롤을 가지고 있습니다 (Windows 탐색기 생각). 비디오 파일의 URL에 도달하면 비디오를 볼 수 있습니다.

사용자 수는 1000 년대로 증가 할 수 있으며 하위 범주 및 비디오는 시스템이 성장함에 따라 10000 초에있을 수 있습니다.

문제는 각 요청이 데이터베이스에 도달하는 위치에서 현재 작동하는 방식을 계속 수행해야합니까, 아니면 데이터 캐싱에 대해 생각해야합니까?

우리는 IIS 6/7과 Asp.net을 사용하고 있습니다.

먼저 데이터 공급자를 쉽게 전환 할 수 있도록 코드가 분할되어 있는지 확인하십시오. 여기서 인터페이스 분리 및 기타 SOLID 원리에 대해 이야기하고 있습니다.

다음으로 다음에 대한 답을 알아야합니다.

1) 데이터가 자주 변경됩니까? 2) 애플리케이션이 이러한 업데이트를 얻기 위해 REST 서비스를 자주 폴링합니까? 3) 데이터베이스가 다른 목적으로 사용됩니까? 4) 현재 성능 문제를 알고 있습니까? 5) 응용 프로그램에서 데이터를 업데이트하고 해당 업데이트를 앱에 반영해야합니까?

흥미로운 점은 데이터베이스를 사용하여 기술적으로 이미 데이터를 캐싱한다는 것입니다. 그것이 데이터베이스가하는 일입니다. 많은 R & D가 데이터를 검색 할 때 데이터베이스를 최대한 빨리 만드는 데 사용합니다. 예를 들어 자주 사용하는 데이터에는 자체 메모리 캐시를 사용합니다.

캐시 공급자를 교체하여 얻을 수있는 것이 무엇인지 스스로에게 물어보십시오. 그리고 현재 해결해야 할 한계는 무엇입니까?

현재 속도가 느려지지 않는다면 간단히 "아니요, 전환 할 필요가 없습니다"라고 말하면됩니다.

정말 큰 주제입니다. 캐시는 데이터를 지리적으로 분산해야 할 때 실제로 잘 작동하지만 관리 측면에서 엄청난 오버 헤드가 있습니다.

나는 정확히 같은 종류의 결정을 내리는 순간에 프로젝트를 수행하고 있습니다.

지금까지 내 솔루션은 데이터베이스 만 사용하고 각 클라이언트의 폴링 요청으로 데이터베이스를 많이 사용하는 것입니다. 유쾌하게 들리지만, 필요한 것보다 훨씬 확장 (테스트 중)되며 코드는 매우 간단합니다.

즉, 내 코드는 기본 응용 프로그램의 데이터 공급자를 데이터베이스 코드에서 추상화하는 일종의 저장소 패턴을 사용합니다. GemFire와 같은 캐시 공급자에서 교체하려면 아주 적은 양의 코드가 필요합니다.

Thorbjørn의 의견에 따르면 정보가 충분하지 않습니다.

캐싱이 잘못되면 사용자와 사용자에게 많은 슬픔이 생길 수 있습니다. 응용 프로그램을 너무 복잡하게 만들기 전에 캐싱에 대해 걱정해야합니다.

따라서 실제로 캐시해야 함을 나타내는 정보가 없으면 캐시하지 마십시오.

[일반적인 최적화 규칙 : 무언가를해야하는지 물어보아야한다면 대답은 '아니오'입니다.] *
대답이 '예'인 대부분의 장소에서는 질문이 아니라 진술이 될 것입니다.