EF Core 앱을 최고의 성능으로 확장하는 방법은 무엇입니까?
녹화된 웨비나
론 후세인(Ron Hussain)과 잭 칸(Zack Khan)
EF Core는 트랜잭션이 많은 .NET 서버 애플리케이션(ASP.NET, 웹 서비스, 마이크로 서비스 및 기타 서버 앱)에서 점점 더 많이 사용되고 있습니다. 그리고 이러한 애플리케이션은 EF Core 내부의 분산 캐싱을 사용하여 제거할 수 있는 데이터베이스의 확장성 병목 현상에 직면합니다.
- EF Core의 새로운 기능 소개(모델, 쿼리, 데이터 저장)
- 분산 캐시가 EF Core 데이터베이스 병목 현상을 해결하는 방법
- EF Core 앱에서 분산 캐싱을 사용하는 다양한 방법
- 캐싱을 위한 EF Core 확장 메서드 사용에 대한 세부 정보
- 컬렉션 및 데이터 관계의 캐싱 처리
Entity Framework Core 또는 EF Core는 개발자가 작성하는 대부분의 데이터 액세스 코드가 필요하지 않은 .NET용 Microsoft의 새로운 플랫폼 간 경량 개체 관계형 매핑 엔진입니다. 비슷하다 .NET Core, EF Core는 크로스 플랫폼이기도 합니다. 즉, Windows, Linux, Mac에서 사용할 수 있으며 개발자 커뮤니티 내에서 매우 인기를 얻고 있습니다.
극한의 성능과 요청 처리 용량의 선형 증가를 달성하기 위해 애플리케이션을 확장하는 방법은 무엇입니까? 따라서 다음을 사용하여 앱, Entity Framework Core 애플리케이션을 확장할 수 있습니다. NCache 확장 방법. 그래서 우리는 당신이 활용할 수 있는 몇 가지를 나열했습니다. 제가 그려본 다양한 시나리오를 바탕으로 소개하겠습니다. NCache 사용자 환경의 일반적인 Entity Framework Core 애플리케이션 내에서 사용할 수 있는 확장 메서드 및 개체 캐싱 기능입니다.
Entity Framework/EF Core란 무엇입니까?
먼저 일반적으로 Entity Framework 및 Entity Framework Core에 대해 이야기하겠습니다. 모두가 EF 및 EF Core에 대해 알고 있다고 확신하지만 완전성을 위해 몇 가지 소개 세부 정보를 작성합니다.
Entity Framework는 .NET에 사용할 수 있는 ORM이며 EF Core와 함께 .NET 및 .NET Core. Entity Framework는 데이터베이스 프로그래밍을 단순화합니다. 개념적 개체 모델에서 작업할 수 있습니다. 따라서 데이터 모델로 직접 작업할 필요가 없으며 전체 데이터 액세스 프로그래밍을 단순화합니다. 영구 코드를 직접 작성할 필요가 없습니다. Entity Framework Core에서 생성된 데이터베이스 액세스를 사용하고 보유하고 있는 데이터 모델에 대한 애플리케이션 내의 개체 계층 간에 많은 상호 작용을 생성할 수 있습니다.
.NET 및 .NET Core 응용 프로그램. 모든 종류의 응용 프로그램에서 사용할 수 있습니다. 즉, 웹 응용 프로그램일 수도 있고 일반적인 서버 응용 프로그램, .NET 또는 .NET Core 웹 서비스, IOT 사용 사례 또는 기타 서버 응용 프로그램은 인기와 사용 용이성 때문에 이를 활용할 수 있습니다. 설정이 매우 쉽고 시작할 수 있습니다.
Entity Framework Core는 새로운 변형입니다. 그것이 바로 Microsoft가 취하는 새로운 방향입니다. 첫 번째로 오픈 소스인 크로스 플랫폼입니다. 따라서 다음을 사용하는 응용 프로그램을 실행할 수 있습니다. .NET Core 또는 .NET을 알고 있습니다. .NET 및 .NET Core Windows 및 Linux 환경에서 실행할 수 있으며 유사하게 Entity Framework 코어 소송을 따르지, 그렇지? 따라서 요구 사항인 경우 Linux 환경뿐만 아니라 Windows에서도 실행할 수 있으며 본질적으로 매우 가볍고 모듈식입니다. 이는 본질적으로 이전에 사용했던 Entity Framework 내의 모든 구성 요소를 거칠 필요가 없다는 것을 의미합니다. EF Core는 필요한 구성 요소로 작업할 수 있습니다. 이에 대한 NuGet 패키지만 얻을 수 있으며 이를 기반으로 애플리케이션 내에서 복잡성을 점진적으로 구축할 수 있습니다.
따라서 필요한 경우 해당 문제에 대해 애플리케이션 내에서 복잡한 시나리오를 관리해야 합니다. 그리고 무엇보다 매우 빠르기 때문에 .NET Core 특정 초점이나 성능 측면도 있습니다. 따라서 Entity Framework Core는 성능이 달성할 수 있는 핵심 요소 중 하나인 동일한 지침에 따라 설계되었습니다.
Entity Framework의 아키텍처 다이어그램
여기 Entity Framework Core의 아키텍처 다이어그램이 있습니다.
여전히 적용되는 Entity Framework 다이어그램을 찾았습니다. Entity Framework Core 아키텍처에도 여전히 많은 것이 적용됩니다. 이것은 MSDN에서 가져온 것입니다. EF Core를 사용하면 ADO.NET 데이터 공급자가 있습니다. SQL Server를 데이터 소스 예제로 사용하고 명령 트리, 데이터 액세스 시나리오를 구축하는 Entity Client 데이터 판독기가 있고 개체 서비스가 있고 응용 프로그램 측에서 Entity로 작업합니다. SQL 쿼리 또는 LINQ 엔티티에. 따라서 다시 개체 모델로 작업하고 배후에서 Entity Framework Core가 다른 모든 세부 사항을 처리합니다.
런타임에 매핑 및 모델을 생성하기 위해 실행하는 명령이 있으므로 개념적 모델, EDMX, 모든 매핑 파일이 Entity Framework Core 내에서 제거되었습니다. 따라서 다시 설정하는 것은 매우 쉽습니다. 다시 말하지만 모듈식입니다. 따라서 NuGet 패키지를 도입하고 몇 분 만에 매우 간단한 Entity Framework Core 애플리케이션을 빌드할 수 있습니다.
확장성이란 무엇입니까?
다음으로 제가 강조하고 싶었던 또 다른 개념인 확장성에 대해 이야기하겠습니다. Entity Framework Core를 사용하는 애플리케이션에서 캐싱이 필요한 이유는 무엇입니까? 우선 확장성이라는 개념이 있습니다. 이는 애플리케이션 내에서 매우 좋은 기능이며, 최고 부하에서도 높은 애플리케이션 성능을 달성할 수 있습니다. 맞습니까? 따라서 짧은 대기 시간과 가장 낮은 대기 시간을 가질 수 있고 낮은 사용자 로드에서 낮은 대기 시간을 유지할 수 있다면 XNUMX~XNUMX명의 사용자가 있다고 가정해 보겠습니다. 막대한 양의 사용자 요청 부하 하에서 대기 시간이 짧은 경우 해당 애플리케이션은 매우 확장 가능한 애플리케이션으로 분류됩니다.
그리고 선형 확장성은 더 많은 서버를 추가할 수 있고 부하를 분산할 수 있으며 여러 서버에 부하를 분산함으로써 더 많은 서버가 실제로 요청 처리 용량을 증가시키고 그 증가는 선형 방식으로 증가하는 추가 관련 개념입니다. 따라서 서버를 추가함에 따라 용량이 증가하고 선형 확장 가능한 애플리케이션으로 분류되는 선형 증가 배너를 수행하는 애플리케이션이 있는 경우.
확장성이 필요한 애플리케이션은 무엇입니까?
따라서 일반적으로 ASP.NET 또는 ASP와 같이 본질적으로 트랜잭션이 많은 애플리케이션.NET Core 웹 앱, 웹 서비스, IOT, 빅 데이터 애플리케이션 또는 기타 일반 .NET 또는 .NET Core Entity Framework Core를 사용하는 애플리케이션은 높은 확장성을 요구하죠? 따라서 아키텍처 내에서 처리 용량의 높은 트랜잭션 로드가 필요합니다.
확장성 문제는 정확히 어디에 있습니까?
그렇다면 문제는 정확히 어디에 있습니까? 그 문제를 극복하기 위해 캐싱 시스템이 필요한 이유는 무엇입니까? 웹 팜 또는 앱 팜을 생성하여 Entity Framework Core 애플리케이션이 자체적으로 선형적으로 확장할 수 있는 웹 팜 및 앱 팜을 항상 생성할 수 있습니다. 로드 밸런서를 앞에 둘 수 있습니다. 그래서 그것은 주요 관심사가 아닙니다. 애플리케이션 계층은 항상 확장할 수 있습니다. 이것이 Entity Framework Core 및 일반적인 .NET 또는 .NET Core 응용 프로그램이 설계되었습니다. 요청을 여러 서버로 라우팅할 수 있고 여전히 서로 조합하여 사용할 수 있습니다.
주요 문제는 데이터 스토리지 병목 현상입니다. 일반적으로 관계형 데이터베이스인 경우 이것이 우리가 사용하는 예입니다. 데이터베이스는 일반적으로 모든 데이터 스토리지에 대한 하나의 단일 소스입니다. 그들은 저장을 위해 아주 좋습니다. 그것은 그들이 가장 잘하는 것입니다. 그러나 극단적인 양의 요청 로드를 처리하는 경우, 예를 들어 애플리케이션에서 들어오는 많은 트랜잭션 및 참조 데이터 로드가 있는 경우 데이터베이스는 증가된 요청 로드를 처리하도록 설계되지 않았습니다. 낮은 사용자 부하에서는 잘 작동하지만 CPU 쪽, 메모리 쪽에서 용량을 소비하기 시작하면 모든 요청이 라우팅되는 DBMS 터널이 있습니다. 데이터 스토리지가 확장성 병목 현상이 될 가능성이 있습니다. 런타임에 생성되는 대기열 요청을 넣으면 성능이 저하됩니다. 따라서 다른 데이터베이스 서버를 추가할 수 있는 방법이 없습니다.
우선 시작하는 데 비용이 많이 들고 두 대의 서버를 서로 조합하여 사용할 수 있는 방법이 없습니다. 따라서 성능 가치에 합산되지 않으면 성능이 저하되고 최종 사용자 경험에도 영향을 미치며 비즈니스에도 영향을 미칠 수 있습니다. 왜냐하면 애플리케이션의 성능이 느리면 많은 사용자가 애플리케이션의 느리거나 느린 동작을 좋아하지 않기 때문입니다. 따라서 애플리케이션은 항상 낮은 대기 시간과 높은 처리량이 필요하며 높은 처리량을 유지하면 성능 손실이 발생합니다. 데이터베이스는 애플리케이션 속도를 저하시키거나 대부분의 경우 완전히 멈추는 경향이 있습니다.
솔루션
이 섹션에서는 이 문제를 해결하는 방법에 대해 설명합니다. 해결책은 매우 간단합니다. 당신이 사용할 수있는 에 의한 분산 캐싱 시스템 NCache. 메모리에 있기 때문에 매우 빠릅니다. 단일 소스가 아니기 때문에 확장성이 매우 뛰어납니다. 필요한 만큼의 서버를 캐시 클러스터에 추가할 수 있으며 캐시 클러스터의 해당 서버는 서로 조합하여 작동합니다. 데이터를 분산한 다음 요청 처리 로드를 분산하고 더 많은 서버를 추가하여 시스템 외부에서 더 많은 확장성을 얻을 수 있습니다. 기존의 관계형 데이터베이스를 대체하는 것이 아닙니다. EF Core 애플리케이션 내에서 데이터베이스와 함께 분산 캐시를 사용합니다. 따라서 가장 쉽게 액세스할 수 있는 데이터인 참조 데이터를 캐시하거나 일부 트랜잭션 데이터도 캐시합니다.
그리고 다양한 캐싱 시나리오를 처리하는 방법, 애플리케이션 내에서 활용할 수 있는 캐싱 전략에 대해 이야기하겠습니다.
배포 아키텍처
다음은 관계형 데이터베이스와 비교하여 더 나은 옵션인 이유를 몇 가지 더 명확히 하는 배포 아키텍처입니다.
우선, 분산 캐시는 애플리케이션과 데이터베이스 계층 사이에 위치합니다. 그리고 본질적으로 응용 프로그램이 여기에서 데이터를 찾으면 먼저 캐시를 사용하고 여기에서 데이터를 찾지 못하면 반환해야 하며 그런 다음 백엔드 데이터베이스로 이동해야 합니다. 따라서 논리적으로 보면 애플리케이션과 데이터베이스 사이에 위치합니다.
배포에 관한 한 애플리케이션을 VM, 물리적 상자, 온프레미스 또는 클라우드에 배포할 수 있습니다. NCache Microsoft Azure는 물론 AWS에서 사전 구성된 이미지 형태로 지원되거나 다른 클라우드에서 당사 웹 사이트에서 다운로드할 수 있는 설치 프로그램을 사용할 수 있으며 설치를 시작하면 매우 쉽게 시작할 수 있습니다. 설정. NCache 자체 계층에 있을 수 있으며, 별도의 전용 서버는 NCache 또는 동일한 상자에서 실행할 수 있습니다. 애플리케이션이 배포된 상자가 있는 경우 배포할 수 있습니다. NCache 그것도 같은 등급에서. 별도의 상자를 사용하는 것이 좋으며 XNUMX~XNUMX개의 서버를 추가하여 시작한 다음 요청 처리 요구 사항에 따라 더 많은 서버를 추가할 수 있습니다.
10,000명의 사용자 및 관련 요청 로드를 처리해야 하는 경우 몇 가지 테스트를 실행하고 필요한 서버 수를 확인할 수 있습니다. 일반적으로 최근 테스트에 따르면 초당 4~5개의 요청만으로 초당 XNUMX백만 요청을 처리할 수 있었습니다. NCache 서버 맞죠? 따라서 애플리케이션 로드 요구 사항을 처리하기 위해 필요한 서버 수를 확인할 수 있습니다. 만 전제 조건 NCache .NET 또는 .NET Core. Windows, Windows Nano 및 Linux 서버에서 실행됩니다. 마찬가지로 애플리케이션은 Windows 플랫폼 또는 Linux 플랫폼에 있을 수 있습니다.
그리고 몇 가지 강력한 데이터베이스 동기화 기능도 있습니다. 앞서 말했듯이 기존 데이터베이스를 대체하는 것이 아닙니다. 그것은 당신의 데이터베이스를 사용하고, 당신의 데이터베이스와 함께 사용됩니다, 그렇죠? 따라서 일부 데이터는 캐시되지만 모든 데이터는 관계형 데이터베이스인 영구 저장소에 항상 존재합니다. 그리고 잠시 후 캐싱에 대한 방법에 대해 이야기하겠습니다.
일반적으로 사용되는 3가지 분산 캐싱 사용 사례
다음은 몇 가지 일반적인 사용 사례입니다. 분산 캐시의 일반적인 사용 사례이며 가장 두드러진 것은 앱 데이터 캐싱입니다. 여기에 Entity Framework Core가 있습니다.
애플리케이션 데이터 캐싱
따라서 가장 일반적인 사용 사례인 첫 번째 사용 사례는 앱 데이터 캐싱 사용 사례입니다. 여기에서 일반적으로 데이터베이스에 속한 데이터를 캐시합니다. 여기에서 동기 부여는 값비싼 데이터베이스 여행을 가능한 한 많이 절약하고 데이터 검색을 위한 고성능이라는 이점을 얻는 것입니다. 데이터베이스는 메모리 내 액세스에 비해 느리기 때문에 메모리 내 액세스이므로 초고속이며 애플리케이션에서 요청을 호스팅하고 제공하는 여러 서버가 있습니다. 따라서 시스템에서 더 많은 확장성과 더 많은 처리량을 얻을 수 있으며 분산 캐시에 주어진 낮은 대기 시간을 유지하면서 대부분의 경우 복제되지 않을 수 있는 데이터베이스와 달리 선택한 토폴로지를 기반으로 가용성과 안정성이 높습니다. 다른 서버에 걸쳐.
앱 데이터 캐싱을 사용하면 거의 모든 것을 캐시할 수 있습니다. 직접 API를 사용할 수 있습니다. 도메인 개체, 컬렉션, 데이터 세트, 단일 항목, 결과, 캐시하려는 모든 데이터를 캐시할 수 있으며 해당 데이터가 다시 필요한 경우 개체 캐싱 및 Entity Framework Core를 사용하는 것을 고려해야 합니다. 직접 API 또는 확장 방법을 다시 사용할 수 있습니다.
ASP.NET 세션 캐싱 및 SignalR Backplane
그런 다음 다른 사용 사례 NCache 그것은 ASP.NET 및 ASP입니다.NET Core 특정 캐싱. 세션 캐싱이 있습니다. ASP의 세션 캐싱.NET Core IDistributedCache를 통해 NCache 세션 제공자도 마찬가지입니다. 이것이 두 번째 옵션이고 다음이 있습니다. SignalR Backplane. 그것은 당신이 활용할 수 있는 또 다른 옵션입니다. SignalR 애플리케이션이 있는 경우 다음을 사용할 수 있습니다. NCache 백플레인으로. 이것은 다시 코드 변경 없음 옵션이며 응답 캐싱, 보기 상태 및 출력 캐싱이 있습니다. 따라서 이들은 모두 ASP.NET에 고유한 기능이며 이 외에도 필요한 경우 웹 응용 프로그램 내에서 앱 데이터 캐싱을 사용할 수도 있습니다.
Pub/Sub 메시징 및 연속 쿼리
그런 다음 강력한 Pub/Sub 메시징 및 연속 쿼리 이벤트가 있거나 Pub/Sub 메시징 및 이벤트라고 말할 수 있습니다. 당신이 사용할 수있는 NCache 여러 애플리케이션이 연결되고 해당 애플리케이션이 Pub/Sub Messaging을 사용하여 서로 통신할 수 있는 메시징 플랫폼입니다. 애플리케이션은 다음에 메시지를 게시할 수 있습니다. NCache, 통신 채널 역할을 합니다. 여기에는 주제라는 개념이 있으며 이러한 구독자 애플리케이션은 해당 주제에 연결되어 있으면 해당 메시지를 수신할 수 있습니다. 따라서 필요한 경우 사용자 정의 메시지뿐만 아니라 데이터 공유를 서로 조정할 수 있습니다. 그리고 우리는 소셜 미디어 시스템을 구축할 수 있습니다. 채팅 시스템을 가질 수 있습니다. 리더보드를 가질 수 있습니다. 응용 프로그램이 서로 조정하는 다양한 구성 요소가 필요한 모든 종류의 산업에서 필요에 따라 사용할 수 있습니다.
마이크로서비스 간 통신
마이크로서비스는 서버리스 마이크로서비스 애플리케이션이 있어야 하고 서로 상호 작용해야 하는 또 다른 사용 사례입니다. NCache 통신 요구 사항을 충족하고 연속 쿼리 이벤트도 있습니다. 데이터가 추가, 업데이트 또는 제거되는 정기 이벤트입니다. 애플리케이션 전송 이벤트 대신, NCache 데이터 변경 사항을 기반으로 애플리케이션에 이벤트를 보낼 수 있으며 이는 모든 항목 또는 선택적 항목 또는 데이터 세트를 매핑하는 연속 쿼리를 기반으로 할 수 있습니다. NCache 와 NCache 지정된 데이터 세트에 대한 이벤트만 전송합니다.
네 번째 사용 사례도 있습니다. 전체 텍스트 검색 기능이 있습니다. 전자 상거래 응용 프로그램에서 매우 일반적입니다. 와 함께 NCache Lucene .NET API를 구현했습니다. 따라서 전체 텍스트 검색 기능에 관심이 있는 경우, NCache 그것도 완벽하게 갖추고 있습니다.
EF Core의 앱 데이터 캐싱
일반적인 Entity Framework Core 애플리케이션에서 캐싱을 사용하는 방법에 대해 이야기해 보겠습니다.
샘플 애플리케이션 설정
그래서 우선 이 어플을 가지고 있습니다. 샘플 애플리케이션이 바로 여기에 있습니다. 함께 설치되는 샘플 중 하나입니다. NCache 또한. 따라서 C:\Program Files\로 이동하면NCache\, 이 샘플은 바로 여기에서 사용할 수 있습니다.
.NET 및 .NET Core 샘플은 별도로 배치됩니다. 그래서, 나는 계속할 것입니다 .NET Core 및 Entry Framework, 바로 여기에 EF Core 샘플이 있습니다. 그래서 제가 사용하는 샘플입니다.
이 웨비나에서 발표할 계획인 이러한 시나리오 중 일부를 시연하기 위해 약간 변경했습니다. 그렇지 않으면 POC에 대한 기본 작업을 수행합니다. 자, 이것이 샘플입니다. 다음으로 할 일은 데모 환경에 로그온하고 실제로 캐시 클러스터를 사용하고 거기에서 바로 가져올 수 있도록 캐시 클러스터를 만드는 것부터 시작하겠습니다.
클러스터형 캐시 생성
따라서 캐시 생성을 위해 웹 관리 도구를 실행하고 있습니다. 빨리 하나 만들어 보겠습니다. 이제 클러스터된 캐시를 추가해 보겠습니다. 그것을 democache라고 부르자. 몇 개의 정수를 추가하겠습니다. democache111. 그런데 직렬화가 관련된 한 JSON 또는 이진 형식을 유지할 수 있습니다. 자. 따라서 Binary 또는 JSON 직렬화 형식을 가질 수 있습니다. Binary가 기본 옵션이므로 계속 진행하겠습니다. 선택할 수 있는 네 가지 캐싱 토폴로지가 있으며 다음과 같은 다른 웨비나도 있습니다. NCache 특별히 목표로 하는 아키텍처는 NCache 건축학. 따라서 Partitioned Replica Cache를 계속 사용하겠습니다. 왜냐하면 이것은 읽기와 쓰기에 매우 잘 작동하고 읽기 및 쓰기 요청 용량에 대해 매우 확장 가능하기 때문입니다. 서버를 계속 추가하고 복제본도 함께 제공되는 경우 , 따라서 애플리케이션에도 다운타임이나 데이터 손실이 없습니다.
그래서 저는 모든 것을 단순하고 기본값으로 유지할 것입니다. 활성 파티션과 해당 백업 간의 비동기 복제. 그래서 저는 그것을 선택하겠습니다. 더 빠릅니다. 캐시 클러스터의 크기와 여기에서 내 캐시 클러스터를 호스트할 서버를 지정했습니다. 내가 말했듯이 우리의 주요 초점은 Entity Framework Core이기 때문에 캐시를 빠르게 만들 것입니다. 그렇지 않으면 정기 웨비나에서 NCache 아키텍처 또는 Azure 애플리케이션 확장 NCache, 해당 웨비나는 이러한 모든 기능에 대해 자세히 설명했습니다. 따라서 이 특정 웨비나에서는 계속해서 빠르게 캐시를 생성하겠습니다. 따라서 기본 포트 TCP/IP를 지정하고 이 캐시를 자동으로 시작하여 서버가 재부팅될 때 자동으로 시작되도록 합니다. 그래서 거의 다입니다.
스트레스 시뮬레이션 및 캐시 통계 모니터링
캐시 구성에 관한 한 이 마법사를 따르기만 하면 여러 서버에 캐시가 생성됩니다. 저도 시작했다고 생각합니다. 통계 창을 연 다음 NCache 함께 설치되는 또 다른 도구인 모니터 창 NCache. 현재 활동이 없지만 계속해서 스트레스 테스트 도구 응용 프로그램을 실행할 수 있습니다. 이것은 테스트 스트레스 도구라고 하며 내 캐시 클러스터에 대한 더미 활동, 더미 로드를 시뮬레이트합니다. 모든 것을 확인하기 위해 제대로 구성되었습니다. 알다시피 서버 XNUMX과 서버 XNUMX에 의해 초당 약 천에서 XNUMX개의 요청을 볼 수 있습니다. 따라서 전체적으로 초당 약 XNUMX개의 요청을 처리하며 대기 시간을 검토할 수 있습니다. 캐시 작업 지연 시간당 평균 마이크로초가 매우 적습니다. 제 생각에는 XNUMX~XNUMX 마이크로초 정도입니다.
따라서 이 그래프는 업데이트되고 단위는 감소합니다. 알다시피 부하를 더 추가합니다. 실제로 진행해 보겠습니다. 오른쪽. 그래서 다른 인스턴스가 실행 중입니다. 이제 바로 여기에서 증가된 가치를 보여줘야 한다는 것을 보여드리기 위해 여기 있습니다. 이전에는 각 서버에서 초당 약 XNUMX개의 퀘스트를 처리했습니다. 이제 각 서버에서 초당 XNUMX~XNUMX개의 요청이 발생하고 캐시 작업당 평균 마이크로초가 작업당 약 XNUMX~XNUMX마이크로초임을 알 수 있습니다. 엄청난 성능 향상입니다. 응용 프로그램이 최대가 아니거나 서버가 전혀 최대가 아닌 것을 고려하십시오. 따라서 다음을 사용할 때 애플리케이션에서 밀리초 미만 또는 마이크로초 미만의 응답을 기대할 수 있습니다. NCache. 그래서 우리 환경이 구성되었습니다. 모든 것이 설정되었습니다. 이제 가도 될 것 같습니다. 이 테스트를 중지하고 캐싱 시나리오에 대해 설명하는 샘플 애플리케이션을 만들고 검토해 보겠습니다.
캐시할 EF Core 엔터티는 무엇입니까?
먼저 Entity Framework Core 내에서 캐싱하는 방법에 대해 이야기해 보겠습니다. 캐시할 EF Core 엔터티는 무엇입니까? 일반적으로 두 가지 옵션이 있습니다. 단일 엔터티가 있거나 엔터티 컬렉션인 쿼리 결과가 있을 수 있습니다. 맞습니까? 단일 항목이 반환되거나 컬렉션일 수 있습니다. 단일 엔티티는 있는 그대로 저장됩니다. 컬렉션은 단일 항목으로 저장하거나 각 컬렉션 항목을 캐시에 개별적으로 추가할 수 있으며 이에 대한 방법에 대해 이야기해 보겠습니다.
EF Core 엔터티 캐싱 옵션
직접 NCache 아피스. 두 가지 접근 방식이 있습니다. 우선, 당신은 사용할 수 있습니다 NCache API가 직접 맞죠? 따라서 이는 오픈 소스, 엔터프라이즈 또는 프로페셔널에서도 사용할 수 있는 것입니다. 그런 다음 시간을 할애할 Entity Framework 핵심 확장 메서드가 있습니다.
EF Core 단일 엔터티 캐싱: NCache 다이렉트 API
직접 API. Direct API에 대한 세부정보는 다음과 같습니다. 여기서부터 보여드리죠?
Customers GetCustomer (string CustomerId)
{
string key = "Customer:CustomerId:" + CustomerId;
Customers customer = (Customers)_cache.Get(key);
if (customer != null)
{
return customer;
}
else
{
customer = (from cust in database.Customers
where cust.CustomerId == CustomerId
select cust).FirstOrDefault();
_cache.Insert(key, customer);
return customer;
}
}따라서 일반적으로 이것은 고객 확보 방법입니다. 직접 API를 사용하는 경우 고객 ID가 있을 가능성이 있습니다. 따라서 우선 캐시 키를 구성해야 합니다. 그래서 반드시 해야 할 일입니다. 왜냐하면, 이내 NCache 모든 것은 키 값 쌍에 저장됩니다. 키는 개체를 식별하기 위한 문자열 키입니다. 개체 부분은 캐시에 추가하려는 실제 값, 실제 속성입니다. 애플리케이션에 대해 캐시하려는 실제 데이터입니다.
그래서 키워드로 고객을 지정한 다음 고객 ID를 지정한 다음 나에게 전달되는 런타임 매개변수를 제공하는 이 핵심 조직을 생각해 냈습니다. 맞습니까? 따라서 고유한 고객 ID를 사용하여 바로 여기에서 이 특정 고객을 식별할 수 있습니다. 맞습니까? 따라서 고유하게 해당 고객을 식별한 다음 cache.Get을 호출하여 캐시에서 항목을 검색할 수 있습니다. 오른쪽? 따라서 무엇보다 먼저 캐싱을 사용하는 경우 키가 구성되었는지 확인한 다음 먼저 cache.Get을 호출하여 캐시에서 데이터를 사용할 수 있는지 확인해야 합니다. 이 캐시 핸들은 캐시를 초기화할 때 반환되는 것 맞죠?
그래서 바로 여기에서 이 캐시를 사용하고 있습니다. NCache.InitializeCache. 캐시를 초기화하고 연결할 수 있습니다. 고객이 null이 아니었음을 의미하는 캐시에서 항목을 찾으면 여기에서 돌아온 것입니다. 비용이 많이 드는 여행을 데이터베이스에 저장하고 이것이 캐싱 시스템을 사용하는 주요 동기입니다. NCache 당신의 데이터를 가질 것입니다. 따라서 백엔드 데이터베이스를 통해 비용이 많이 드는 여행을 저장합니다. 데이터베이스에 갈 필요가 없습니다. 하지만, 이 어플리케이션을 처음 시작하는 것이기 때문에. 따라서 이 경우 캐시에는 데이터가 없습니다.
따라서 이 경우 Entity Framework Core를 실행하고 Entity Framework Core 내부에 연결합니다. 단일 항목 또는 컬렉션을 반환합니다. 단일 항목 시나리오이고 cache.Insert를 호출하여 다음에 사용할 수 있도록 실제로 추가하고 고객도 반환합니다. 따라서 다음에 이 데이터가 변경되지 않거나 데이터와 동기화되지 않는 한 항상 캐시에서 이 데이터를 찾을 수 있습니다. 그래서 이것이 우리가 Entity, Direct API를 단독으로 사용하는 것입니다.
EF Core 엔터티 컬렉션 캐싱: NCache 다이렉트 API
Collections의 경우 Direct API는 매우 유사합니다.
List GetCustomersByCity (string CustomerCity)
{
string key = "Customers:City = " + CustomerCity;
List custList;
custList = (List)_cache.Get(key);
if (custList != null)
{
return custList;
}
else
{
custList = (from cust in database.Customers
where cust.City == CustomerCity
select cust).ToList();
_cache.Insert(key, custList);
return custList;
}
} 도시별로 고객이 있습니다. 고객 도시는 런타임 매개변수입니다. 고객 목록을 구성하고 다음에서 해당 컬렉션 목록을 가져오려고 합니다. NCache cache.Get, 고객 목록을 가져옵니다. 여기에서 null 반환이 아닌 경우 null이면 백엔드 데이터베이스에서 검색하고 다음에 사용할 수 있도록 캐시에 추가해야 합니다. 따라서 이러한 고객 항목을 개별적으로 저장하려는 경우 이 custList를 반복하고 각 컬렉션 항목에 고유한 키를 제공하여 개별적으로 cache.Insert를 호출할 수도 있습니다. 따라서 활용할 수 있는 또 다른 옵션입니다.
하지만 먼저 키를 구성하고 캐시에서 항목을 가져와야 합니다. 있는 경우 null 처리를 수행한 다음 없는 경우 데이터베이스에서 가져오고 데이터 논리를 실행한 다음 추가합니다. 이것이 바로 Direct와 관련이 있는 것입니다. NCache 아피스. 일반적인 데이터베이스 캐싱의 가장 일반적인 사용 사례입니다. 앱 데이터 캐싱의 경우 일반적으로 수행하는 작업입니다.
EF Core 단일 엔터티 캐싱 - EF Core 확장 메서드
그러나 확장 방법을 통한 또 다른 접근 방식이 있으며 이것이 주요 특징입니다. 전체 컬렉션을 하나의 항목으로 캐시하거나 확장 메서드를 통해 각 컬렉션 항목을 개별적으로 다시 캐시할 수 있습니다.
Customers GetCustomer (string CustomerId)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
Customers customer = (from cust in database.Customers
where cust.CustomerId == CustomerId
select cust).FromCache(out string cacheKey,
options).FirstOrDefault();
return customer;
} 보여드리고 싶은 첫 번째 확장 방법은 다음과 같습니다. 알겠습니다. From Cache라고 하지만 많은 자동화를 수행합니다. 우선 캐싱 옵션을 구성할 수 있도록 하는 방식으로 작동합니다. 맞습니까? 따라서 먼저 캐싱 옵션을 만들고 이 시점에서 소개하는 속성 중 하나는 Store As입니다. 그래서, NCache 컬렉션을 단일 항목, 개별 항목, 컬렉션 항목으로 저장해야 하는지 여부를 선택할 수 있습니다. 컬렉션에 10개의 항목이 있다고 가정해 보겠습니다. 따라서 이러한 항목은 10개의 개별 항목으로 추가됩니다. NCache 아니면 바로 여기에 있는 컬렉션으로 저장하고 싶습니까? 이것이 두 번째 옵션입니다. 이 경우 캐시에 하나의 항목으로 저장됩니다.
그래서 별도의 엔터티를 사용하고 있습니다. 따라서 여기에서 이 코드를 실행하면 From Cache라는 확장 메서드가 있고 이 정의를 보여주면 NCache Alachisoft .NCache.EntityFrameworkCore. 이것이 기본 네임스페이스이며 바로 여기에 와서 NuGet 패키지를 보여드리겠습니다. 설치됨에서 우리는 Alachisoft .NCache.EFCore NuGet 패키지. 이것이 소개해야 하는 NuGet 패키지이며 그 후에 이러한 확장 메서드를 시작할 수 있습니다. 우선 외부 참조 캐시 키이므로 캐시 키는 다음에 의해 생성됩니다. NCache 그리고 당신에게 주어진. 이것이 바로 유연성이며 옵션을 매개변수로 사용합니다. 따라서 많은 자동화를 수행하고 뒤에서 많은 작업을 수행합니다. FromCache는 먼저 캐시의 데이터를 자동으로 확인하는 방식으로 작동합니다. 이것이 발견되면 데이터베이스로 이동하지 않는 동작입니다.
그러나 캐시에 없는 경우 규칙에 따라 데이터베이스로 이동하여 쿼리를 실행하고, 결과 집합을 검색한 다음 채워지는 이 캐시 키를 사용하여 캐시에 추가한 다음 이러한 캐싱 옵션을 해당 항목에 설정합니다. . 따라서 이것과 비교하면 캐시 키를 구성할 필요가 없습니다. null 처리를 확인하거나 캐시에서 직접 가져올 필요가 없습니다. 캐시에 삽입할 필요가 없습니다. 이 확장 방법을 사용하기만 하면 됩니다. 따라서 많은 것들이 자동화되고 애플리케이션을 위한 매우 단순화된 프로그래밍 모델이 됩니다.
EF Core 엔터티 컬렉션 캐싱: EF Core 확장 메서드
그리고 컬렉션으로 저장하려는 경우와 마찬가지로 컬렉션으로 저장할 캐싱 옵션을 제공하기만 하면 됩니다. 이 경우 반환할 고객 목록이 있습니다. 따라서 쿼리를 실행한 다음 FromCache를 다시 호출하기만 하면 됩니다. 이것으로 첫 번째 확장 방법과 소개를 마쳤습니다.
List GetCustomersByCity (string CustomerCity)
{
List custList;
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
custList = (from cust in database.Customers
where cust.City == CustomerCity
select cust).FromCache(out string cacheKey,
options).ToList();
return custList;
} EF Core에서 캐시할 데이터는 무엇입니까?
다음으로 참조 및 트랜잭션 데이터에 대해 설명하겠습니다. 이것은 주요 세그먼트입니다.
읽기가 많은 응용 프로그램, 쓰기보다 읽기가 많은 데이터를 다룰 수 있고 읽기와 쓰기가 있는 응용 프로그램 시나리오가 있을 수 있습니다. 맞습니까? 예를 들어 조회 데이터 제품, 직원은 자주 변경되지 않지만 정적 데이터가 아니며 변경되지만 변경 빈도는 그다지 크지 않으며 전체 데이터가 캐시에 존재해야 합니다. 이 특정 시나리오에서는 몇 시간 또는 며칠 후에 만료되어야 하는 이유를 설명하겠습니다. 이것이 캐시를 최신 상태로 유지하는 방법이며 또 다른 부분입니다.
그런 다음 트랜잭션 데이터가 있습니다. 트랜잭션 데이터 캐싱을 처리하는 방법에 대해 이야기하겠습니다. 동적으로 생성됩니다. 주문, 계정, 그것들은 예입니다. 매우 자주 변경되며 일반적으로 역사적으로 트랜잭션 데이터는 캐싱에 선호되지 않았습니다. 사용자가 활성 상태인 동안 변경되고 애플리케이션에서 사라져야 했기 때문에 해당 시점에만 필요합니다. 그러나 경험에 비추어 볼 때 트랜잭션 데이터에 대해서도 캐싱을 활성화하는 것이 좋습니다. 변경하지 않는 동안 데이터는 여전히 활성 상태이므로 여러 번 읽을 수 있고 수백만 명의 사용자가 로그인한 경우 해당 데이터에 대한 수백만 건의 요청이 데이터베이스로 돌아가고 캐시되어 있으며 변경되는 동안 XNUMX~XNUMX개의 요청이 있을 수 있으며 성능 관점에서 여전히 도움이 될 것입니다. 따라서 전부는 아니더라도 트랜잭션의 일부를 캐싱하는 것을 고려해야 합니다.
EF Core에서 참조 데이터 캐싱
좋습니다. EF Core에서 참조 데이터 캐싱을 처리하는 방법은 무엇인가요?
이를 위한 XNUMX단계 프로세스가 있습니다. 캐시에 전체 데이터를 로드할 수 있습니다. 이는 필수 항목입니다. 따라서 모든 참조 데이터는 캐시에 로드되어야 합니다. 이것이 우리가 필수로 권장하는 것입니다. 왜? 데이터베이스에 전혀 가고 싶지 않으니까요, 그렇죠? 계속해서 데이터베이스에서 모든 데이터를 로드하기 시작해야 합니다. NCache 이를 즉시 처리한 다음 캐시만 사용하고 데이터베이스 트립을 방지하는 확장 방법이 있습니다.
XNUMX단계는 항상 별도의 엔터티로 캐시됩니다. 그것은 모든 제품 또는 다른 모든 제품을 컬렉션으로 캐시해서는 안 된다는 또 다른 팁입니다. 맞습니까? 수천 개의 제품이 될 수도 있고 수백만 개의 제품이 될 수도 있습니다. 그러나 개별적으로 저장하면 나중에 데이터의 하위 집합을 가져올 수 있습니다. 예를 들어 모든 제품을 로드하지만 나중에 캐시에서 단종된 제품만 있으면 됩니다. 따라서 캐시에 개별적으로 저장한 경우 예를 들어 XNUMX만 개의 제품을 보여 드리겠습니다. 그 시점에서 필요한 것만 찾을 수 있습니다. 따라서 전체 제품 데이터 세트를 처리할 필요가 없으며 비용이 많이 드는 데이터베이스 여행을 다시 절약할 수 있습니다.
EF Core에서 참조 데이터 캐싱: 사전 로드 캐시그래서 우리는 LoadIntoCache라는 확장 메서드를 가지고 있습니다. 다음에는 이것에 대한 작업 예제를 보여드리겠습니다.
void LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
// Loads all products into cache as individual entities
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}
이제 LoadIntoCache는 우선 캐싱 옵션을 '별도의 엔터티로 저장'으로 설정한 다음 모든 제품을 로드하는 쿼리를 실행해야 합니다. 그런 다음 LoadIntoCache를 호출한 다음 옵션을 제공해야 합니다. 그러면 모든 제품에 대한 캐시 키가 개별적으로 자동으로 생성됩니다. 그리고 캐시에 있는 모든 항목을 계속 로드한 다음 이와 같은 LINQ 쿼리를 실행할 수 있으며 이 LINQ 쿼리는 NCache. 확장 방법을 사용하지 않습니다. product.Discontinued가 있고 FromCache만 있는 데이터베이스 제품에서 제품을 호출합니다. 데이터베이스에 전혀 가지 않습니다. 에서 가져오는 것입니다 NCache 직접.
EF Core에서 참조 데이터 캐싱: 캐시에서만 참조 데이터 검색참조 데이터가 있는 경우 먼저 별도의 엔터티를 로드해야 합니다. 캐시에 로드를 사용하여 모든 제품을 로드합니다. NCache. 이 작업을 완료하면 데이터베이스로 이동할 필요가 없습니다. 그런 다음 FromCache 대신 FromCacheOnly를 사용합니다. 첫 번째 확장 방법은 캐시를 확인한 다음 캐시에 없으면 데이터베이스로 이동하는 FromCache였습니다. 그러나 LoadIntoCache는 모든 제품을 로드한 다음 FromCacheOnly는 모든 데이터가 캐시에 로드된다는 가정하에 캐시와만 통신하도록 합니다.
List<Products> FindDiscontinuedProducts (NorthwindContext database)
{
//Fetch discontinued products only out of all products
List<Products> discontinuedProducts;
discontinuedProducts = (from product in database.Products
where product.Discontinued == true
select product).FromCacheOnly().ToList();
return discontinuedProducts;
}이 코드를 실행해 보겠습니다. 실제로 작동하는 것을 볼 수 있습니다. 이 테스트를 위해 바로 여기에 구성된 캐시가 있으며 통계를 보여드리겠습니다. 나는 그것을 가지고 놀았습니다. 60,000개의 제품이 로드됩니다. 그럼 내용을 지우고 넘어가겠습니다. 자, 통계를 검토해 봅시다. 내 캐시는 어디에 있습니까? 자. 맞습니다. 항목이 XNUMX개이므로 계속해서 실행하겠습니다. 단일 항목을 캐시한 다음 제가 보여드린 모든 코드 예제를 수집하지만 LoadIntoCache가 작동하는 방식을 보여드리고 이를 기반으로 중단점도 설정하겠습니다.
따라서 처음 두 가지 예는 단일 항목을 로드한 다음 컬렉션을 로드하는 것이었습니다. 제가 보여드린 초기 코드와 여기에서 실제로 참조 데이터 시나리오를 보여주기 위해 모든 제품을 로드하고 있습니다. 우선, 별도의 엔터티로 저장하고 몇 가지 우선 순위, 일부 종속성을 설정합니다. 그런 다음에는 모든 제품을 로드하고 데이터베이스에서 가져오므로 계속 실행하는 것이 좋습니다. 일정 간격 후에 캐시에 로드된 제품을 로드하여 데이터베이스에서 데이터를 검색하고 캐시에 로드하면 항상 데이터베이스에 대해 작동합니다. 항상 데이터베이스로 이동하고 데이터베이스에 있는 것이 무엇이든 데이터베이스에 대해 실행하고 해당 데이터를 다시 가져올 수 있습니다. NCache 그런 다음 나중에 FromCacheOnly를 사용하십시오.
이것이 참조 데이터를 다루는 방법입니다. 우선, 개별적으로 별도로 저장합니다. LoadIntoCache, 데이터베이스에 대해 항상 실행되는 이 확장 메서드 LoadIntoCache를 사용합니다. 캐시를 우선순위로 두지 않습니다. 항상 데이터베이스에 대해 실행한 다음 모든 것을 다시 가져옵니다. NCache 그런 다음 FromCacheOnly를 사용하십시오. 그것이 얼마나 간단합니다.
EF Core에서 트랜잭션 데이터 캐싱
거래 데이터. 작업 세트만 로드할 수 있습니다. 결과 집합 캐싱을 위한 것입니다. 맞습니까?
저는 개인적으로 도시별 고객, 제품 기반 주문에 관심이 있는 경우 일종의 결과 집합 캐싱이 있어야 하며 그렇게 해야 한다고 권장합니다. 컬렉션으로 저장하거나 결과의 크기에 따라 별도의 엔터티로 저장해야 합니다. 컬렉션의 크기가 그다지 크지 않은 경우 최대 100개 또는 200개의 항목을 처리한다고 가정하고 컬렉션으로 저장합니다. 트랜잭션 데이터로 분류되는 여러 제품, 여러 주문 또는 고객 정보입니다. 별도의 엔터티로 저장하십시오. 따라서 하위 집합을 얻을 수 있고 캐싱 사용을 최대화할 수 있습니다.
EF Core에서 트랜잭션 데이터 캐싱 - 컬렉션으로 가져오기 및 캐시이에 대한 사용 사례는 다시 매우 간단합니다. 단순히 컬렉션으로 저장하거나 FromCache를 사용하면 데이터베이스가 캐시에 없는 경우 데이터베이스로 이동하고 싶기 때문에 FromCacheOnly를 사용하지 않습니다.
List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs = StoreAs.Collection,
};
//Fetch from cache. If not found then fetch from DB.
orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder)
.FromCache(out string cacheKey, options).ToList();
return orderList;
}List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
//Fetch from cache. If not found then fetch from DB.
orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder)
.FromCache(out string cacheKey, options).ToList();
return orderList;
}지금까지 세 가지 확장 방법을 소개했습니다. 캐시와 데이터베이스에서 자동으로 작동하고 캐시가 아닌 FromCache는 데이터베이스에서 가져옵니다. LoadIntoCache는 항상 데이터베이스에 대해 실행됩니다. 개체를 가져와서 캐시로 가져오고 FromCacheOnly는 항상 캐시에 대해 실행되며 유일한 진정한 데이터 소스입니다. 데이터베이스로 이동하지 않습니다. 그래서 나는 그것이 많은 것을 명확히하기를 바랍니다.
캐시를 최신 상태로 유지
다음 세그먼트는 Entity Framework Core에서 캐시를 최신 상태로 유지하는 방법을 기반으로 하며 이는 두 가지 다른 소스를 처리할 때 이해해야 하는 또 다른 중요한 개념입니다.
캐싱을 활성화했습니다. 기본 데이터 소스인 백엔드 데이터베이스, 영구 데이터 저장소가 있고 데이터 복사본도 있는 캐싱이 있습니다. 따라서 데이터베이스와 비교하여 캐시가 최신인지 확인하는 방법입니다. 자, 여기서 시간을 좀 보내자.
캐시를 최신 상태로 유지: 참조 데이터
우선, 캐시에 전체 데이터 세트가 있으므로 데이터베이스에 변경 사항이 있으면 어떻게 해야 합니까?
따라서 캐시에서 데이터를 만료해야 하며 이를 위해 만료 후 데이터 자동 다시 로드를 사용하는 것이 좋습니다. 따라서 전략 XNUMX은 만료를 사용하지만 다시 로드하지 않는 것입니다. 따라서 데이터가 만료될 때마다 캐시에도 자동으로 다시 로드되며 이를 위해 바로 여기에서 모든 제품 로드라는 설정이 있습니다.
전략 1: 만료를 사용하지만 자동 새로고침과 함께 사용void LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
options.SetAbsoluteExpiration(DateTime.Now.AddHours(10));
options.SetResyncProviderName("MyEFCoreResyncProvider");
// Load all products into cache with Expiration and Auto-Reload
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}여기부터 보여드리겠습니다. 따라서 먼저 참조 데이터 사용 사례이기 때문에 이를 별도의 엔터티로 저장합니다. 모든 제품으로 로드한 다음 일종의 만료를 설정한 다음 options.SetResyncProvider, 다시 로드 공급자가 있어야 하고 options.IsSyncEnabled를 true로 설정해야 합니다. 따라서 자동 재로드가 만료될 경우 캐시에 자동으로 다시 로드됩니다. 따라서 자동 다시 로드 플래그를 true로 자동 설정하는 SetResyncProviderName과 함께 두 가지 속성이 있습니다.
namespace Alachisoft.NCache.EFSampleResyncProvider
{
public abstract class EFDefaultResyncProvider : IReadThruProvider
{
public virtual void Init(IDictionary parameters, string cacheId)
{
db = InitializedDbContext();
}
public virtual void LoadFromSource(string key, out
ProviderCacheItem cacheItem)
{
cacheItem = new ProviderCacheItem(FetchItemFromDb(key));
cacheItem.AbsoluteExpiration = DateTime.Now.AddHours(10);
cacheItem.ResyncItemOnExpiration = true;
}
public virtual void Dispose()
{
db.Dispose();
}
}
}그리고 바로 여기에 ResyncProvider가 필요합니다. 즉, 샘플 구현이 바로 여기에 있습니다.
namespace Alachisoft.NCache.EFSampleResyncProvider.Provider
{
public class EFResncProvider : EFDefaultResyncProvider,
IReadThruProvider
{
public override DbContext InitializedDbContext()
{
return new NorthwindContext();
}
}
}자. IReadThruProvider를 구현해야 합니다. 데이터 소스를 초기화하고 마지막에 폐기한 다음 LoadFromSource를 사용하면 키를 얻을 수 있고 해당 키를 기반으로 SQL 명령을 구성하고 데이터베이스에서 항목을 가져옵니다. 여기에서 우리가 구성하는 샘플 구현을 제공했습니다. 우리가 가지고 있는 캐시 키의 SQL 쿼리입니다.
맞습니다. 이 샘플 구현의 키는 GitHub에서도 사용할 수 있습니다. 따라서 캐시에 로드된 항목이 한 번 더 캐시에 로드되면 만료가 첨부되는 방식으로 작동합니다. 따라서 XNUMX~XNUMX시간 후에 만료됩니다. 만료 기간이 지나면 이 공급자가 시작되고 핸들러를 통해 자동으로 읽기를 사용하여 LoadFromSource를 호출하고 업데이트된 데이터를 가져옵니다. NCache. 맞습니다. 항목이 만료된 후 캐시가 자동으로 새로워집니다.
전략 2: 만료를 사용하지 않고 수동으로 다시 로드개인적으로 권장하는 두 번째 방법은 표현식을 사용하지 않고 LoadIntoCache를 호출하여 수동으로 다시 로드하는 것입니다. 그리고 이것은 LoadIntoCache 메서드를 생각해 내야 하는 매우 간단한 것입니다. 한 번 더 보여드리겠습니다. 일정 간격 후에 이 메서드를 계속 호출하고 식을 사용하지 마십시오. 이것들을 제거합시다.
void LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}따라서 이 참조 데이터는 XNUMX시간, XNUMX시간, XNUMX일, 주, 월에 대해서만 유효하다는 것을 알고 있습니다. 이 로드를 계속 반복하는 것을 기준으로 모든 제품을 로드합니다. 일정 간격을 두고 호출해야 합니다. 맞습니까?
따라서 만료 간격에 대한 지능적인 추측을 기반으로 수동으로 데이터를 다시 로드해야 한다는 생각입니다. 맞습니까? 따라서 작업 시간을 설정한 후 자동으로 모든 제품 로드를 호출해야 합니다. 따라서 백엔드 데이터베이스에서 자동으로 데이터를 가져오고 참조 데이터를 최신 상태로 유지합니다.
그래서 저는 이것들을 반복할 것입니다. 따라서 두 가지 옵션이 있습니다. 만료 데이터를 사용하는 경우 캐시에서 제거됩니다. 따라서 부분 세트로 끝나게 되므로 자동 재장전이 필수입니다. 그러나 만료를 사용하지 않는 경우 참조 데이터에 대한 모든 데이터를 항상 캐시에 보관한 다음 특정 간격 후에 해당 데이터를 수동으로 다시 로드할 수 있습니다. 나는 그것이 명확하기를 바랍니다.
캐시를 최신 상태로 유지: 트랜잭션 데이터
다음으로 트랜잭션 데이터를 위해 캐시를 최신 상태로 유지하는 방법에 대해 이야기하겠습니다. 이는 매우 간단합니다. 항상 자동 새로고침 없이 짧은 만료를 사용해야 합니다. 이는 다시 XNUMX분에서 XNUMX분 동안만 유효할 수 있는 수명이 짧은 데이터이고 FromCache를 사용해야 캐시에 없는 경우 항상 백엔드 데이터베이스에서 가져와야 하기 때문입니다.
그리고 여기에 그 예가 있습니다. 고객 주문이 있는 경우 컬렉션 또는 개별 항목으로 저장하는 것은 전적으로 귀하에게 달려 있습니다. 필요한 경우 짧은 만료 또는 만료를 사용하지 않거나 만료를 사용한 다음 해당 문제에 대한 자동 재로드를 사용하지 마십시오. 따라서 만료되는 즉시 데이터베이스에서 검색됩니다. 저는 개인적으로 구성 가능한 만료를 사용하거나 이 데이터 세트의 작업 시간임을 확실히 알고 있는 만료를 제안하는 것을 권장합니다. 그 후에는 필요하지 않습니다. 따라서 자동으로 만료된 다음 해당 시점에 데이터베이스 액세스를 시행하고 자동으로 백엔드 데이터베이스에서 가져옵니다.
짧은 만료, 자동 재장전 없음 private List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs = StoreAs.Collection
};
options.SetAbsoluteExpiration(DateTime.Now.AddSeconds(60));
List<Orders> orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder).FromCache(out string cacheKey,
options).ToList();
return orderList;
}지금까지 참조 데이터와 트랜잭션 데이터를 처리하는 방법에 대해 살펴보았습니다. 그런 다음 트랜잭션 데이터뿐만 아니라 참조를 위해 캐시를 최신 상태로 유지하는 방법도 다루었습니다.
캐시에서 관계 처리
일대 다
캐싱과 관련하여 발생할 수 있는 몇 가지 다른 사항입니다. EF Core의 캐시에서 관계를 처리합니다. 다시 말하지만 매우 간단합니다. 포함이 지원되므로 데이터베이스 지역이 있는 지역이 있고 그 옆에 region.Territories가 있는 경우 맞습니까? 따라서 FromCache를 호출하면 지역과 지역을 별도로 저장하고 지역과 지역 간의 관계를 공식화합니다. 그래서 내가 당신에게 영토가있는 지역을 보여 주면.
List<Region> GetRegionWithTerritories(NorthwindContext database)
{
List<Region> regionDetails;
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
regionDetails = (from region in database.Region select region)
.Include(region => region.Territories)
.FromCache(options).ToList();
return regionDetails;
}바로 여기에 있는 예입니다. 오른쪽. 따라서 이 지역 세부 정보에는 FromCache가 포함되어 있습니다. 따라서 지역과 지역 영역을 별도로 저장하고 항목을 분리한 다음 키 기반 종속성을 구성합니다. 지역이 변경되면 지역도 무효화되고 그 반대도 마찬가지입니다. 이것이 일대일 또는 일대다 관계를 처리하는 방법입니다.
집계 작업 캐싱
집계 작업도 지원됩니다. 따라서 Deferred First 또는 Default, FromCache를 사용하여 이러한 확장 방법을 실행할 수 있습니다. Deferred Count, FromCache를 기반으로 할 수 있습니다. 따라서 결과 집합으로 저장합니다. 맞습니까? 따라서 집계 작업의 결과일 뿐이므로 컬렉션 또는 단일 항목으로 저장하는지 여부는 중요하지 않습니다. 이것이 Entity Framework의 또 다른 가능성입니다.
집계 작업 캐싱 - 엔터티 반환
Shippers GetFirstShipperInstance (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
Shippers shipper = database.Shippers.DeferredFirstOrDefault()
.FromCache(out string cacheKey, options);
return shipper;
}집계 작업 캐싱 - 값 반환
int GetTotalShippersCount (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
int count = database.Shippers.DeferredCount()
.FromCache(out string cacheKey, options);
return count;
}분산 캐싱 아키텍처
그래서 마지막으로 분산 캐싱에 대한 몇 가지 아키텍처 세부 사항에 대해 이야기하고 싶습니다. 고려해야 하는 이유. 가용성이 높고 매우 안정적이며 복제가 가능합니다. 피어 투 피어 아키텍처 캐시입니다. 단일 실패 지점이 없습니다. 런타임에 모든 서버를 추가하거나 제거할 수 있으며 클라이언트에는 연결 장애 조치 지원이 구축되어 있습니다. 따라서 100% 가동 시간으로 가용성이 높고 매우 안정적입니다. 많은 캐싱 토폴로지, 클라이언트 캐시, WAN 복제, 분할 및 분할된 복제본이 함께 제공되며 다른 질문이 있는 경우 아키텍처 세부 사항에 대해 구체적으로 이야기할 수 있습니다. 이 시점에서 프레젠테이션을 마치겠습니다.
고 가용성
캐싱 토폴로지
클라이언트 캐시(캐시 근처)
캐시의 WAN 복제
결론
이에 대한 간략한 요약을 드리고자 합니다. 이 웨비나에서는 캐싱 옵션, 직접 API, Entity Framework 핵심 확장 메서드에 대해 이야기했습니다. 따라서 이들 중에서 선택할 수 있는 옵션이 있습니다. 우리는 Entity Framework Core Extension Methods에 더 집중했습니다. 사용하기가 더 쉽습니다. 참조 및 트랜잭션 데이터를 다루는 방법. 따라서 참조 데이터에 대한 전체 데이터를 로드한 다음 별도의 엔터티 접근 방식을 사용한 다음 캐시에 있는 모든 데이터에 대해서만 캐시를 사용하는 접근 방식에 대해 이야기했습니다. 트랜잭션 데이터의 경우 캐시에 없는 경우 데이터베이스로 이동할 수 있도록 결과 집합에만 캐싱한 다음 FromCache 확장 메서드를 사용하는 것이 좋습니다. 그런 다음 캐시를 최신 상태로 유지하기 위해 참조 데이터에 대해 자동 다시 로드와 함께 만료를 사용하거나 만료를 사용하지 않고 일정 간격 후에 수동으로 다시 로드하고 트랜잭션 데이터에 대해 만료를 사용해야 한다고 이야기했습니다. 만료 기간은 짧지만 자동 재로드가 없으므로 다음 사용 시 데이터베이스로 돌아가서 캐시를 새로 고칠 수 있습니다.
당신은 항상 우리에게 연락 할 수 있습니다 support@alachisoft.com. 기술적인 질문이 있는 경우 다음 주소로 연락할 수도 있습니다. sales@alachisoft.com. 제품을 살펴보고 싶다면 다운로드할 수 있습니다. NCache Enterprise 30일 무료 평가판.