확장 메서드를 통해 EF Core에서 .NET 캐싱 사용
녹화된 웨비나
론 후세인과 닉 줄피카르
EF(Entity Framework) Core는 Microsoft의 인기 있는 Entity Framework의 새로운 크로스 플랫폼 및 경량 버전입니다. EF Core는 개발자가 작성하는 대부분의 데이터 액세스 코드가 필요하지 않은 .NET용 개체 관계형 매핑 엔진입니다.
EF Core는 트랜잭션이 많은 서버 애플리케이션(ASP.NET, WCF 및 기타 .NET 서버 앱)에서 점점 더 많이 사용되고 있습니다. 그리고 이러한 애플리케이션은 속도 저하 없이 대량의 사용자 요청을 처리할 수 있는 확장성이 필요합니다. 그러나 데이터베이스는 병목 현상이 발생하며 이러한 병목 현상을 제거하려면 분산 캐싱을 사용해야 합니다.
다음과 같은 분산 캐시를 사용하는 방법을 배우십시오. NCache 귀하의 EF Core 애플리케이션 데이터베이스 확장성 병목 현상을 제거하기 위한 것입니다.
이 웨비나는 다음을 다룹니다(실습 소스 예제 포함:
- EF Core 소개 및 새로운 기능(모델, 쿼리, 데이터 저장)
- EF Core의 데이터베이스 확장성 병목 현상 및 분산 캐시가 이를 해결하는 방법
- 다양한 사용 옵션 NCache EF Core(직접 API 및 EF Core 확장 메서드)
- 캐싱을 위한 EF Core 확장 메서드 사용에 대한 세부 정보
- 참조 및 트랜잭션 데이터에 대한 컬렉션 및 관계 캐싱을 처리하는 방법은 무엇입니까?
- 좋은 분산 캐시의 몇 가지 중요한 기능은 다음과 같습니다. NCache
EF Core는 .NET 및 .NET Core 응용 프로그램. 이를 통해 개발자는 일반적으로 해당 코드를 직접 작성해야 하는 데이터 액세스 코드를 자동으로 생성할 수 있습니다. 비슷하다 .NET Core, EF Core는 또한 크로스 플랫폼이며 Windows, Linux, Mac에서 실행할 수 있으며 개발자 커뮤니티에서 매우 인기를 얻고 있습니다.
이 웨비나에서는 EF Core 앱의 성능 및 확장성 요구 사항에 대해 이야기하고 EF Core 확장 방법을 사용하여 참조 및 트랜잭션 데이터를 캐시하는 다양한 전략을 시연합니다. 일반적인 EF Core 애플리케이션에서 직면하게 될 성능 및 확장성 문제는 무엇이며 Entity Framework Core 애플리케이션 내에서 캐싱을 사용하는 다양한 옵션에 대해 설명합니다.
주로 Entity Framework 핵심 응용 프로그램에 대해 구현한 EF 확장 메서드인 확장 메서드에 중점을 둘 것입니다. 따라서 다음의 모든 Entity Framework 핵심 확장 방법을 살펴보겠습니다. NCache 그런 다음 Nick이 제안한 대로 참조 데이터와 트랜잭션 데이터를 처리하는 다양한 전략에 대해 이야기하겠습니다. 또한 분산 캐시를 사용하기 시작할 때 데이터가 서로 다른 두 위치에 존재할 때 데이터를 동기화 상태로 유지하는 방법도 알아봅니다. 이것이 오늘 웨비나의 안건입니다. 빨리 시작하겠습니다. 다루어야 할 것이 많습니다. 보여주고 싶은 실습 사례가 많이 있습니다. 자, 빨리 시작합시다.
Entity Framework/EF Core란 무엇입니까?
따라서 첫 번째 슬라이드는 Entity Framework 및 EF Core에 대한 소개에 가깝습니다.
EF 및 EF Core, 이것은 .NET 및 .NET core 응용 프로그램. Entity Framework의 최신 버전은 EF Core로 명명됩니다. 최근에 EF Core 2.1이 함께 출시된 것을 보았습니다. .NET Core 2.1. 알다시피, 그것은 데이터베이스 프로그래밍을 단순화합니다. 데이터 액세스 모델을 자동으로 생성할 수 있습니다. 따라서 직접 작성하지 않아도 됩니다. 이를 위해 필요한 개발 노력을 줄입니다. 일반적으로 ADO.NET 수준에서 직접 작성하는 지속성 코드를 작성할 필요가 없으며 데이터 모델과 개체 모델 간에 매핑이 있어야 합니다. 그래서, 그것은 단순히 당신을 위해 그것을 최적화합니다.
따라서 매우 유연합니다. 개발자 커뮤니티와 교차 플랫폼 내에서 매우 인기를 얻고 있으며 .NET 및 .NET Core 애플리케이션, 특히 많은 요청 로드를 처리하는 높은 트랜잭션 애플리케이션.
Entity Framework의 아키텍처 다이어그램
이것은 Entity Framework의 아키텍처 다이어그램입니다.
EF Core에도 적용됩니다. EF와 EF Core 간에는 몇 가지 차이점이 있습니다. EF Core는 경량화되었습니다. 모듈식 접근 방식이 있습니다. 많지 않으므로 전체 설치를 거칠 필요가 없습니다. 모듈식 접근 방식을 사용할 수 있습니다. 더 작은 패키지로 분해했으므로 관심 있는 패키지로 작업할 수 있습니다.
따라서 해당 문제에 대해 전체 설치를 거칠 필요가 없으며 .edmx 및 해당 매핑 파일도 제거했습니다. 따라서 NuGet 패키지와 몇 가지 명령을 실행하고 모델을 생성한 다음 애플리케이션 계층에서 LINQ to Entities API로 작업하기만 하면 됩니다. 전반적인 접근 방식은 동일하게 유지됩니다.
확장성이란 무엇입니까?
일반적으로 알고 있는 EF Core 애플리케이션에서는 성능 및 확장성의 요구 사항에 대해 설명합니다. 확장성은 애플리케이션이 처리해야 하는 요청의 양을 늘릴 수 있는 애플리케이션 내의 기능입니다. 예를 들어, 사용자 로드가 증가하거나 요청 로드에 기여하는 사용자, 해당 요청 로드가 애플리케이션 내에서 증가하고 애플리케이션이 느려지면 해당 애플리케이션을 확장할 수 없습니다.
따라서 최대 로드 하에서의 고성능은 우리가 확장성으로 분류하는 것입니다. 애플리케이션이 XNUMX밀리초 미만, 사용자 XNUMX명 미만의 대기 시간으로 꽤 잘 작동하는 경우 동일한 종류의 성능, 동일한 종류의 대기 시간, 예를 들어 사용자 XNUMX명 또는 XNUMX명 미만의 낮은 대기 시간과 많은 요청 부하를 가져야 합니다.
따라서 높은 스트레스 부하, 최대 부하 하에서 고성능이 확장성으로 분류됩니다. EF 코어.
확장성이 필요한 애플리케이션은 무엇입니까?
ASP.NET 웹 응용 프로그램일 수 있습니다. ASP.NET 또는 ASP.NET Core 많은 요청을 처리할 수 있습니다. .NET일 수 있고 .NET Core 웹 서비스, 다시 웹 사이트에서. 그런 다음 IoT 서버 응용 프로그램이 있습니다. 다시 .NET 또는 .NET Core 또는 기타 일반 .NET 및 .NET Core 자체 도메인에서 많은 요청 또는 사용자를 처리할 수 있는 애플리케이션.
따라서 이들은 확장성의 후보입니다.
확장성 문제는 정확히 어디에 있습니까?
일반적으로 EF 및 EF Core는 웹 팜에 배포됩니다. 웹 애플리케이션인 경우 선형적으로 확장됩니다. 애플리케이션 계층에는 확장성 문제가 없지만 항상 백엔드 관계형 데이터 소스와 통신해야 합니다. SQL Server 일 수 있습니다. Oracle Server일 수도 있고 EF 또는 EF Core에서 지원하는 다른 데이터 스토리지일 수도 있습니다. EF Core에는 많은 데이터 공급자가 있습니다. 선택할 수 있는 공급자 목록이 있습니다. 따라서 결국 데이터베이스와 대화하게 됩니다.
애플리케이션 계층은 훌륭하게 확장되지만 이 데이터 스토리지, 데이터베이스, 관계형 데이터베이스는 경합의 원인이 됩니다. 메모리에 없기 때문에 시작하는 것이 느립니다. EF Core가 메모리 내 데이터 공급자를 제시했지만 이는 InProc, 저장 및 로컬 테스트용입니다. 이렇게 하면 테스트가 쉬워지지만 애플리케이션이 프로덕션 환경에 배포되면 느리고 확장되지 않는 관계형 데이터베이스를 처리해야 합니다. 스토리지에 매우 적합하지만 애플리케이션 내에서 확장성이 실제로 필요할 때 확장되지 않습니다.
따라서 극한의 부하에서 질식할 수 있는 단일 소스입니다.
솔루션
솔루션은 다음과 같은 교란된 캐싱 시스템을 사용하기 시작하는 매우 간단합니다. NCache, EF 핵심 응용 프로그램의 경우 관계형 데이터베이스와 함께 사용합니다.
배포 아키텍처
다음은 배포 아키텍처입니다. NCache.
우선 인 메모리입니다. 비교하면 초고속입니다. 그런 다음 일반적으로 백엔드 관계형 데이터 소스에서 가져올 수 있는 데이터를 저장하는 여러 서버가 있습니다. 캐시로 가져올 수 있으며 ASP.NET 또는 ASP일 수 있습니다..NET Core 앱, .NET 또는 .NET, 웹 서비스 또는 .NET 또는 .NET Core 서버 애플리케이션 또는 모든 종류의 .NET 또는 .NET Core 응용 프로그램 또는 Java 응용 프로그램도 이 분산 캐싱 시스템을 활용할 수 있습니다. 관계형 데이터 원본에 대한 비용이 많이 드는 여행을 저장합니다. 인 메모리입니다. 더 많은 서버를 추가할 수 있으며 선형 방식으로 이 캐시 클러스터의 용량을 늘릴 수 있습니다.
따라서 단일 실패 지점이 아닙니다. 성능, 병목 현상이 아닙니다. 확장성 병목 현상이 아닙니다. 따라서 이것이 권장되는 접근 방식이며 오늘 우리가 자세히 다룰 내용인 .NET 캐싱을 사용하는 방법과 그것이 될 것입니다. NCache 확장 메서드를 통해 EF Core 애플리케이션의 예제 제품으로.
일반적으로 사용되는 3가지 분산 캐싱 사용 사례
분산 캐시의 몇 가지 일반적인 사용 사례. 데이터 캐싱에 사용할 수 있습니다. 직접 API 호출을 사용할 수 있습니다. 또는 EF Core 응용 프로그램에 대해서도 Entity Framework 또는 확장 메서드를 사용하고 여행을 가능한 한 많이 데이터베이스에 저장합니다.
그런 다음 웹 사이트, 사물의 웹 사이트에는 ASP.NET, ASP가 있습니다..NET Core 캐싱. 웹 애플리케이션 또는 웹 서비스일 수 있습니다. 웹 애플리케이션인 경우 세션을 사용할 수 있습니다. ASP.NET 및 ASP를 사용하고 싶을 수 있습니다..NET Core SignalR Backplane, ASP에 대한 응답 캐싱.NET Core. 마찬가지로 IDistributedCache 인터페이스를 사용할 수 있으며 상태 및 출력 캐싱을 볼 수 있습니다. 이들은 모두 귀하의 애플리케이션을 위한 코드 옵션이 아닙니다.
그리고 강력한 Pub/Sub 메시징이 있습니다. 구독하는 주제를 가질 수 있으며 다른 애플리케이션 간에 메시지를 공유할 수 있습니다. 게시자와 구독자는 서로에게 메시지를 보낼 수 있습니다.
그래서, 그것은 일반적인 생각입니다. 오늘은 EF Core 애플리케이션 내에서 데이터 캐싱에 더 중점을 두고 시작하는 간단한 단계를 안내한 다음 실제로 더 확장하여 다양한 시나리오에 대한 자세한 정보를 공유하겠습니다.
자, 이것으로 빨리 시작합시다.
APP 데이터 캐싱: EF 핵심 엔터티
오늘 가장 먼저 다루고 싶은 것은 애플리케이션 데이터 캐싱입니다.
EF Core 엔터티가 있습니다. 따라서 해당 엔티티를 캐시해야 합니다. 따라서 단일 엔터티를 볼 수 있습니다. 예를 들어 합계가 있습니다. 그것은 가치이거나 할 수 있습니다. 정렬을 수행하고 첫 번째 고객을 꺼내거나 기준은 단일 고객, 단일 제품, 단일 주문을 반환하는 것과 같습니다. 단일 엔터티인데 어떻게 캐시합니까? 마찬가지로 엔터티 컬렉션일 수 있는 쿼리 결과가 있습니다. 따라서 단일 개체가 아닙니다. 엔터티 모음입니다. 두 가지 옵션이 있습니다. 전체 컬렉션을 캐시에 하나의 항목으로 캐시하거나 각 컬렉션 항목, 해당 컬렉션 내의 각 엔터티를 분산 캐시에 개별적으로 캐시할 수 있습니다.
EF Core 엔터티 캐싱 옵션
따라서 이에 대한 접근 방식을 살펴보겠습니다.
앞에서 설명한 것처럼 직접 사용할 수 있습니다. NCache 아피스. NCache API는 키 값 저장소이며 데이터를 추가합니다. NCache 그런 다음 직접 수신하거나 EF Core 확장 메서드를 사용하여 이 단일 엔터티 및 엔터티 수집을 담당할 수 있습니다.
그럼 먼저 직접 보여드리겠습니다 NCache 모든 종류의 애플리케이션에 공통적인 API 접근 방식입니다. EF Core에서 사용할 수 있습니다. 일반 EF 또는 기타 .NET 애플리케이션에서 사용할 수 있으며, 그런 다음 EF 핵심 애플리케이션용으로 특별히 설계된 EF Core 확장 메서드에 대해 이야기하겠습니다. 이 메서드는 많은 작업을 자동으로 수행하고 쿼리와 함께 이 확장 메서드를 호출하기만 하면 됩니다. 따라서 이 두 가지 접근 방식을 하나씩 보여 드린 다음 앞으로 확장 방법에 더 중점을 둘 것입니다.
EF Core 단일 엔터티 캐싱: NCache 다이렉트 API
따라서 첫 번째 예는 EF Core 단일 엔터티를 캐싱하는 것입니다.
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;
}
}바로 여기에 GetCustomer 메서드가 있습니다. 이를 위해 제가 공식화한 샘플 애플리케이션의 도움으로 이것을 보여드리겠습니다. 이것이 우리의 첫 번째 방법입니다. 내 화면을 볼 수 있기를 바랍니다. 따라서 Get Customer가 있습니다. 여기에서 고객 ID와 아이디어를 사용하여 이것이 단일 엔터티를 반환한다는 것입니다. 맞습니다. 따라서 일반적으로 직접 API를 사용하는 경우 문제는 직접 구현해야 하는 것을 고려해야 하거나 고려해야 한다는 것입니다.
우선 키가 있어야 하고 그 키는 내부의 엔터티를 식별하는 것입니다. NCache 모든 키를 동일한 형식으로 유지 관리해야 합니다. 화면에 표시된 대로 샘플 형식을 제시할 수 있습니다. 고객 키워드와 고객 ID 그리고 캐시 키를 만드는 고객 ID의 런타임 매개변수가 있습니다.
In NCache 모든 것은 키 값 쌍에 저장됩니다. 키는 문자열 키이고 값은 .NET 허용 개체이며 모든 EF Core 엔터티일 수도 있지만 키를 공식화한 다음 엔터티를 저장할 개체로 사용합니다. NCache. 이제 먼저 cache.Get을 호출하여 해당 키가 캐시에 이미 존재하는지 여부를 확인하고 캐시에서 해당 고객을 직접 가져오는 경우 이는 직접 NCache API cache.Get, 키를 전달하고 해당 고객을 받으면 null이 아닌 경우 여기에서 코드를 반환합니다. 그러나 예를 들어 null인 경우 해당 쿼리를 처음으로 실행하는 것이므로 아직 캐시에 아무것도 없습니다. 따라서 이 경우 데이터베이스에 대한 LINQ API인 Entity Framework Core에 대해 실행한 다음 데이터베이스에서 해당 고객을 가져오고 캐시를 호출합니다. 삽입하고 공식화한 것과 동일한 키로 저장한 다음 고객이 추가하려는 엔터티이고 반환합니다.
이것이 올바른 API를 사용하여 단일 엔터티를 실제로 처리하는 방법입니다.
EF Core 엔터티 컬렉션 캐싱: NCache 다이렉트 API
그런 다음 컬렉션. 컬렉션은 단일 개체로서의 컬렉션일 수도 있고 단일 엔터티로서의 컬렉션일 수도 있습니다.
List<Customers> GetCustomersByCity (string CustomerCity)
{
string key = "Customers:City = " + CustomerCity;
List<Customers> custList;
custList = (List<Customers>)_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;
}
} 각 컬렉션 항목은 캐시에 별도로 추가된 단일 엔터티일 수 있습니다. 이를 위해 도시별로 고객을 확보했으므로 이것이 다음 방법입니다. 고객 목록을 반환하고 있습니다. 역시나 고객시를 기준으로 통과하고 있습니다. 다시 한 번 키를 공식화합니다. 다시 말하지만 이것은 아시다시피 도시를 기반으로 하는 고객 모음을 나타내며 여기에서 이 도시는 런타임 매개변수가 될 수 있습니다. New York, Paris, London 그런 다음 캐시를 호출하여 먼저 가져옵니다. 캐시에서 직접 가져온 다음 캐시에 존재하는지 확인하고, 캐시에 있으면 여기에서 반환하고, 그렇지 않으면 단순히 단일 컬렉션으로 저장합니다.
따라서 이 고객 목록은 하나의 개체로 저장됩니다. 다른 대안은 개별 목록, 고객 엔터티의 고객 및 통화 캐시를 반복하는 것입니다. 바로 여기에 표시된 대로 개별적으로 삽입하십시오. 오른쪽? 따라서 직접 사용하는 단일 엔터티 및 엔터티 컬렉션 NCache API는 이러한 접근 방식을 사용하여 캐시됩니다. 이제 직접 API를 다루었습니다. 이것은 모든 응용 프로그램에서 사용할 수 있는 것입니다.
EF Core 단일 엔터티 캐싱: EF Core 확장 메서드
Entity Framework 핵심 확장 메서드에 초점을 맞추겠습니다. 따라서 다음을 사용하는 단일 엔터티 및 엔터티 컬렉션과 동일합니다. NCache 확장 방법. 그래서 FromCache를 소개하려고 합니다.
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;
}이것이 우리의 첫 번째 확장 방법이며 이 확장 방법을 사용하려면 먼저 소개해야 합니다. NCache 애플리케이션 내부의 NuGet 패키지 Entity Framework Core NuGet 패키지입니다. 그래서, 그것은 필수입니다. 설치된 곳으로 가면, Alachisoft.NCache.EFCore NuGet 패키지. 그것이 당신이 당신의 애플리케이션 내부에 도입해야 하는 것입니다. 그것은 하나이고 그 후에 당신이 해야 할 일은 컨텍스트를 여는 것입니다. 따라서 컨텍스트 내에서 간단히 호출합니다. NCacheConfiguration.Configure 그리고 앱 설정에서 읽고 있는 cacheID를 사용하고 있으며 종속성을 사용하는 경우 Entity Framework Core 확장 메서드 내의 고급 기능인 유형도 사용합니다. 데이터 소스의 유형을 제공해야 합니다.
하지만 일단 전화를 걸면 NCache Configure 메소드는 이 메소드가 요청하는 다양한 것들이 있습니다. 로거를 설정할 수도 있지만 그게 전부입니다. 통화를 시작할 수 있습니다. NCache, 애플리케이션 내부의 EF Core 확장 메서드.
EF Core 엔터티 컬렉션 캐싱: EF Core 확장 메서드
아시다시피 방법이지만 이번에는 확장 방법을 통해 고객을 확보하십시오.
List<Customers> GetCustomersByCity (string CustomerCity)
{
List<Customers> 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;
}그것은 모든 것을 훨씬 더 간단하게 만들 것입니다. 캐시에 있는 데이터를 직접 확인할 필요가 없고 삽입을 명시적으로 직접 호출할 필요가 없으며 가장 중요한 것은 호출할 필요가 없으며 캐시 키를 직접 구성할 필요가 없다는 것입니다. 이것은 이 'FromCache' 구현의 일부로 완전히 자동화됩니다.
자, 행동적 관점에서 이것은 정확히 우리가 이전에 보여준 것입니다. FromCache는 우선 캐싱 옵션을 사용하며 옵션과 'cacheKey'는 아웃 참조입니다. 따라서 백그라운드에서 자동으로 캐시 키를 구성합니다. 확장 방법으로 쿼리와 함께 캐시에서 호출하기만 하면 됩니다. if를 저장하는 옵션을 전달하면 항상 컬렉션을 반환합니다. 따라서 이 경우 별도의 엔터티 또는 별도의 컬렉션으로 선택할 수 있습니다. 따라서 항목의 모음일 수도 있고 해당 모음에서 분리된 항목일 수도 있습니다.
따라서 FromCache는 실행한 엔터티 또는 쿼리와 해당 결과 엔터티가 이미 캐시에 있는 경우 다음에서 가져오는 방식으로 작동합니다. NCache 자동으로. 그러나 이 경우 캐시에 없으면 데이터베이스에 대해 해당 쿼리를 자동으로 실행하고 결과 집합이 반환되며 동시에 캐시되고 후속 호출을 위해 데이터베이스 컨텍스트도 연결됩니다.
예를 들어 FromCache를 처음 호출하면 이를 캐시합니다. 다음에 동일한 쿼리가 실행될 때 분명히 캐시에 대해 실행되지만 데이터베이스에 대해서는 실행되지 않습니다. 이번에는 컨텍스트가 이전에 삭제되었고 이 요청에 대해 해당 변경 사항을 컨텍스트에 첨부하는 엔터티를 변경한 경우 해당 문제에 대한 구문을 사용하고 있었습니다. 그리고 Save Changes를 호출하면 캐시에서 가져온 엔티티에 대해 수행된 모든 변경 사항이 실제로 데이터베이스에 적용됩니다. 그래서, 그것은 약간, 다시 약간 진보된 개념입니다. 나중 단계에서 좀 더 시간을 할애하겠지만, 알려드리자면 from cache 방법은 무언가가 캐시에 없으면 데이터베이스에서 가져와 캐시하는 방식으로 작동합니다. 그러나 캐시에서 이미 사용 가능한 항목이 있는 경우 해당 항목을 반환합니다. 따라서 전체 직접 API 접근 방식을 자동화하지만 키도 구성합니다. 또한 데이터를 별도의 엔터티 또는 별도의 컬렉션에 자동으로 구성하고 캐시에서 호출하고 out 키와 옵션을 전달하기만 하면 됩니다.
컬렉션의 경우도 마찬가지입니다. 컬렉션의 경우 고객을 도시별로 가져옵니다. 컬렉션으로 저장한 다음 다시 캐시에서 호출할 수 있습니다. 따라서 Entity Framework Core 확장 메서드를 시작하는 것이 얼마나 간단합니다.
EF Core에서 캐시할 데이터는 무엇입니까?
다음 주제는 캐시에 있는 데이터 유형의 사용에 관한 것입니다.
참조 데이터 또는 트랜잭션 데이터가 있을 수 있습니다. 질문이 있습니까?
네, 론 여기에 질문이 있습니다. 확장 방법 NCache EF Core로 작업하는 것이 좋습니다. .NET Core 2.0 프레임워크 또는 .NET Framework?
괜찮은. 따라서 EF Core 자체는 .NET뿐만 아니라 .NET Core, 매우 유연합니다. NCache 확장 방법은 절대적으로 잘 작동합니다. 사실 저는 이 샘플 애플리케이션을 다음에서 실행하고 있습니다. .NET framework 4.6.1 작업 중인 또 다른 샘플 응용 프로그램이 있습니다. .NET core 2.0. 그래서 이것은 .NET Core 2.0. 따라서 두 가지 모두에서 작동합니다. .NET frameworks 및 기본적으로 사용하는 것이 좋습니다 .NET Core, 하지만 유연합니다. 둘 다 작동합니다. 귀하의 질문에 대한 답변이 되었기를 바랍니다.
계속해서 프레젠테이션의 다음 부분은 올바른 캐싱 계획을 시작할 때이며 분명히 엔터티 프레임워크 핵심 확장 방법은 캐싱 측면에서 삶을 훨씬 쉽게 만듭니다. 따라서 실제로 많은 작업이 자동으로 수행됩니다. 자, 다음 질문은 어떤 데이터를 캐시할 것인가 하는 것입니다. 맞습니까?
그래서 데이터를 두 가지 범주로 분류했습니다. 참조 데이터가 있습니다. 그것은 조회 데이터이며 동적으로 생성되고 매우 자주 변경되는 트랜잭션 데이터가 있습니다. 따라서 참조 데이터, 간단한 예는 제품, 직원입니다. 100% 정적 데이터는 아니지만 자주 변경되지 않는 데이터입니다. 그러나 그것은 변합니다. 변화의 빈도는 그리 크지 않습니다. 이를 위해 전체 참조 데이터를 캐싱할 계획을 세워야 합니다. 모든 참조 데이터는 반드시 캐시되어야 하며 트랜잭션 데이터는 동적으로 생성되는 데이터입니다. 주문, 계정, 일부 특정 컬렉션에 대한 일부 워크플로 처리, 데이터 및 해당 컬렉션 범위는 해당 워크플로에만 적용됩니다. 해당 워크플로우가 실행을 완료하면 해당 데이터는 더 이상 필요하지 않으며 이 데이터도 매우 자주 변경될 수 있습니다. 1분 안에 변경될 수 있습니다. 반면 참조 데이터는 일반적으로 시간 사이에 변경될 수 있는 조회 데이터입니다. 2~5시간, 10~XNUMX시간 또는 며칠 단위로.
여기에 질문이 있습니다. 키가 자동으로 생성되는 것처럼 EF 확장을 사용하여 검색할 때 이 캐시된 개체를 어떻게 식별합니까? 실제로 특정 키를 검색하는 것이 아니라 삭제하는 것입니까?
괜찮은. 따라서 검색을 위한 확장 메서드가 있습니다. 확장 메서드는 EF Core와 함께 실행됩니다. 따라서 반환 개체는 LINQ 쿼리에서 식별하는 것과 동일한 줄에서 식별됩니다. 내가 생각하는 질문은 레코드 업데이트를 계획할 때 발생하는 일과 이에 대한 API 세트가 있는 것에 더 초점이 맞춰져 있습니다. 엔터티에 대해 키를 생성할 수 있는 메서드를 제공합니다. 공개한 키 생성 방법이 있습니다. 따라서 캐시를 직접 변경하기 전에 이 질문은 캐시에서 무언가를 삭제하거나 캐시에서 무언가를 업데이트하거나 캐시에서 명시적으로 무언가를 제거 또는 추가하는 데 더 초점을 맞추고 있다고 가정합니다. 잠시 후에 보여드릴 캐시 클래스를 노출한 다음 키 생성이 있습니다. 다시 한 번 문자열을 전달하고 out 참조를 사용하고 엔터티도 전달합니다. 따라서 해당 엔터티에 대해 동일한 접근 방식을 사용하며 키를 제공하고 해당 키를 사용하여 해당 엔터티 개체를 식별할 수 있습니다. 개체가 캐시에 있는 경우 이를 업데이트하고 제거할 수 있어야 합니다.
끝으로 이를 달성하는 방법의 예를 보여드리겠지만 알려드리자면 우리가 노출된 방법이 있습니다. NCache 또한. 귀하의 질문에 대한 답변이 되었기를 바랍니다.
EF Core에서 참조 데이터 캐싱
계속. 지금까지 조회 데이터와 동적으로 생성된 데이터에 대해 이야기했습니다.
따라서 이를 처리하기 위한 다양한 접근 방식을 하나씩 살펴보겠습니다. 따라서 먼저 EF Core의 참조 데이터에 대해 이야기하겠습니다. 내가 언급했듯이 이것은 일반적으로 조회 데이터입니다. 따라서 반드시 해야 할 두 가지가 있습니다. 먼저 전체 데이터, 전체 참조 데이터를 반드시 캐시에 로드해야 하며, 여기서 동기는 이 데이터가 그렇게 자주 변경되지 않는 것이라는 점입니다. 전자 상거래 애플리케이션의 EF에 있는 제품 카탈로그입니다. 할인이 활성화된 동안 특정 제품에 대해 약간의 할인이 있습니다. 예를 들어 XNUMX일 동안입니다. 해당 제품은 변경되지 않을 수 있으므로 해당 제품을 모두 캐시하는 것이 좋습니다. NCache 값비싼 데이터베이스 여행을 저장하여 가능한 한 많이 수행하십시오. 100%, 데이터는 캐시에 로드되어야 합니다. 따라서 데이터 원본으로 돌아가서 항상 별도의 엔터티로 캐시할 필요가 없습니다. 왜? 제품 때문에 전체 데이터 세트는 수천 개의 제품이 될 수 있습니다.
Northwind 데이터베이스를 예로 들어 보겠습니다. 제품의 범위는 50,000개에서 100,000개 사이일 수 있습니다. 그러나 주어진 요청에 대해 그 중 10개 또는 100개만 필요할 수 있습니다. 따라서 별도의 엔터티로 저장하면 LINQ 쿼리를 실행할 수 있습니다. NCache 에서 LINQ도 지원합니다. NCache 곧장. 따라서 엔터티의 하위 집합을 쿼리하는 데이터의 하위 집합을 가져올 때 LINQ를 실행할 수 있습니다. NCache 뿐만 아니라.
따라서 이것은 반드시 따라야 하는 두 가지 규칙이며 예제가 있습니다. 여기서는 Load Into the Cache라는 두 번째 확장 방법을 소개합니다.
EF Core에서 참조 데이터 캐싱: 사전 로드 캐시이제 이것은 이러한 방식으로 작동하며 이것은 참조 데이터만을 대상으로 합니다. 이것은 캐시에 대한 프리로더입니다.
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();
}따라서 여기에서 동기 부여는 이 메서드를 호출해야 한다는 것입니다. 모든 제품 로드라고 가정하고 별도의 엔터티로 저장하고 있는지 확인하고 데이터베이스 제품의 제품 및 제품 선택이라는 쿼리를 실행해야 합니다. 따라서 60,000개 제품 모두를 캐시에 로드한 다음 LoadIntoCache를 사용한다는 의미의 기준을 지정하지 않습니다. 별도의 엔터티를 말할 때 이 옵션을 전달하기만 하면 됩니다. 캐시의 각 제품에 대해 별도의 엔터티를 생성하면 이것이 다시 프리로더입니다. 미리 로드해야 합니다..
두 가지 옵션이 있습니다. 이를 위해 캐시 사전 로드를 담당할 수 있는 별도의 애플리케이션을 실행할 수 있습니다. 이는 응용 프로그램 시작 또는 별도의 응용 프로그램일 수 있으며 다음의 캐시 로더 구현일 수 있습니다. NCache 또한. 캐시 로더가 있으며 향후 릴리스에서도 캐시 새로 고침에 대해 작업했습니다.
캐시 로더의 책임은 캐시 시작 시 실제로 실행되고 캐시에 로드하려는 모든 데이터가 그 일부로 로드되는지 확인하는 것입니다. 그것은 당신의 구현이지만 NCache 단순히 호출합니다. 그러나 내가 언급한 것처럼 이와 같은 방법을 제시하고 응용 프로그램 시작 시 한 번만 호출하거나 별도의 응용 프로그램에서 이 작업을 수행하고 모든 응용 프로그램 인스턴스에서 이 데이터를 공유하도록 할 수 있습니다.
이제 이 작업이 완료되면 캐시에서 해당 지점에서 데이터를 쿼리하는 방법입니다. 세 번째 확장 방법인 From Cache Only를 소개하겠습니다.
EF Core에서 참조 데이터 캐싱: 캐시에서만 참조 데이터 검색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;
}따라서 첫 번째 확장 방법은 FromCache로, 캐시에 무언가가 있으면 거기에서 가져옵니다. 그렇지 않은 경우 자동으로 데이터베이스로 이동하여 가져옵니다. LoadIntoCache는 항상 데이터베이스에 대해 실행됩니다. 반환되지만 캐시에 대해 실행되지는 않지만 데이터 세트가 새로 고쳐지도록 필수로 데이터베이스에서 반환됩니다. 새 데이터가 로드되고 캐싱되며 FromCacheOnly는 다음에 대해서만 실행됩니다. NCache 이는 참조 데이터용으로만 설계되었기 때문입니다. 따라서 참조 데이터의 경우 LoadIntoCache 조합을 사용합니다. 따라서 모든 데이터 세트가 캐시에 별도의 엔터티로 존재하도록 한 다음 FromCacheOnly를 호출하여 관심 있는 데이터 세트, 즉 이 경우 단종된 제품만 캐시에서 가져오도록 합니다. 따라서 데이터베이스에 전혀 갈 필요가 없습니다. 데이터베이스에서 데이터가 변경될 때 이 데이터를 최신 상태로 유지하는 방법에 대해 이야기하겠습니다. 그래서 이것이 의미가 있기를 바랍니다. 바로 여기에서 이 예를 보여드리겠습니다.
따라서 여기에서 이 메서드를 호출한 다음 간단한 EF, LINQ API를 직접 사용하여 단종된 제품 목록을 반환합니다. NCache 엔티티.
따라서 이것은 데이터베이스에 대해 전혀 실행되지 않습니다. 이것은 확장 방법인 FromCacheOnly를 사용하고 있기 때문에 캐시에 대해서만 실행됩니다. 이게 도움이 되길 바란다. 트랜잭션 데이터 사용 사례에 더 가까운 FromCache의 세 가지 확장 방법을 다룬 다음 LoadIntoCache 및 FromCacheOnly를 다루었습니다. 참조 데이터의 경우 LoadIntoCache를 사용하여 전체 데이터를 사용하는 데 집중한 다음 엔터티를 분리한 다음 쿼리의 경우 FromCacheOnly를 사용해야 합니다.
EF Core에서 트랜잭션 데이터 캐싱
다음으로 트랜잭션 데이터에 대해 이야기한 다음 참조 및 트랜잭션 모두에 대해 이 데이터를 최신 상태로 유지하는 방법에 대해 설명합니다.
이제 트랜잭션 데이터는 일반적으로 작업 집합입니다. 동적으로 생성된 데이터라는 것은 이미 다뤘습니다. 현재 사용자, 현재 요청 또는 워크플로가 실행 중인 경우에만 필요하며 일단 실행되면 해당 데이터가 더 이상 필요하지 않을 수 있습니다. 따라서 해당 엔터티가 해당 응용 프로그램 인스턴스에서만 필요한 데이터를 실제로 검색하는 응용 프로그램 인스턴스만 있을 가능성이 있습니다. 따라서 모든 트랜잭션 데이터를 캐시에 저장하는 것은 이치에 맞지 않습니다. 요구 사항이 아닙니다. 작업 집합만 캐시해야 합니다. 이것이 2단계입니다. 따라서 쿼리 결과를 캐시해야 합니다. 가장 쉽게 액세스할 수 있는 엔터티를 가져올 수 있으며 두 번째 단계는 2a, XNUMXb의 두 가지 옵션이 있습니다.
컬렉션으로 가져오기 및 캐시트랜잭션 데이터를 전체 컬렉션으로 캐시할 수 있습니다. 선호되는 접근 방식입니다.
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;
}일반적으로 항상 전체 컬렉션이 필요합니다. 왜냐하면 작업 중이고 별도의 엔터티도 저장할 수 있기 때문입니다. 전적으로 사용자에게 달려 있으며 이는 컬렉션을 캐시했지만 해당 컬렉션에서 XNUMX~XNUMX개의 엔터티만 필요할 수 있기 때문에 여전히 별도의 엔터티로 저장하는 시나리오를 위한 것입니다. 따라서 컬렉션을 저장할 때 세분화된 접근 방식을 사용하는 것이 좋으며 GetCustomerOrders가 있습니다. 주문은 상당히 거래적인 데이터입니다. 특정 주문을 처리하는 처리 장치가 있어야 하며 작업을 수행하는 각 작업 흐름에는 고유한 주문 세트가 있을 가능성이 있습니다.
그래서 이 예를 아주 빠르게 보여드리겠습니다. 따라서 많은 캐싱 옵션을 추가하는 방식으로 작동합니다. 여기서 자세히 다루지는 않겠습니다. 컬렉션으로 저장합니다. 이것이 컬렉션으로 저장하도록 선택한 다음 FromCacheOnly를 사용하는 방법입니다. 트랜잭션 데이터를 사용하는 이유는 데이터가 캐시에 존재할 수 있기 때문에 FromCache를 사용하고 있으며 전체 컬렉션을 수행하는 경우 이를 사용하기만 하면 됩니다. 데이터베이스에 갈 필요가 없습니다. 그러나 캐시에 존재하지 않고 이 데이터도 매우 자주 변경되는 경우 만료 시간(예: 30초)을 설정했으므로 데이터베이스로 돌아가고 싶을 수 있습니다. FromCacheOnly를 사용하는 경우 캐시에 존재하지 않거나 이미 만료된 경우 null 값을 반환할 수 있습니다.
따라서 트랜잭션 데이터의 경우 확장 메서드인 From Cache를 사용하고, 참조 데이터의 경우 LoadIntoCache를 사용하여 미리 로드한 다음 FromCacheOnly를 사용합니다. 그래서 그것이 그것에 대해 접근하는 접근 방식입니다.
별도의 엔터티로 가져오기 및 캐시개별 엔터티의 경우 저장하고 호출하기만 하면 됩니다.
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;
}이것을 사용하고 별도의 엔터티를 사용하는 대신에 (댓글을 달았어야 했습니다.) 예, 별도의 엔터티로 저장합니다. 그게 당신이해야 할 전부입니다.
그래서, 론 당신이 이것을 검토하는 동안 질문이 있습니다. 이전 예에서 참조 데이터를 쿼리할 때 인덱싱이 있습니까? 왜냐하면, 그것이 당신이 그것을 만들기 위해 데이터베이스에서 할 것이기 때문입니다…
매우 좋은 질문이며 참조 데이터의 경우 이 LINQ 쿼리는 캐시 전용에 대해 실행되기 때문에 이 LINQ 쿼리는 LINQ 쿼리를 실행하는 제품과 특성이 인덱싱되어야 하며 사실 저는 인덱스 데이터를 사용하고 있으며 인덱싱이 매우 간단합니다. 유형, 모델을 제공한 다음 인덱싱해야 하는 속성을 제공하기만 하면 됩니다. 따라서 이들은 인덱스 속성이며 실제로 인덱스 속성에 대해 쿼리를 실행하고 있습니다. 귀하의 질문에 대한 답변이 되었기를 바랍니다.
캐시를 최신 상태로 유지
실습 부분으로 빠르게 이동하여 작동 중인 실제 제품을 보여주고 데이터베이스와 비교하여 캐시 데이터를 최신 상태로 유지하는 방법과 참조 데이터 및 트랜잭션 데이터와 관련하여 이 웨비나의 가장 중요한 부분을 보여드리겠습니다.
자, 이제 새로운 프로젝트를 열겠습니다. 좋습니다. 실습 데모 부분에서는 분산 캐싱이 어떻게 생겼는지 알 수 있도록 실제 제품을 신속하게 보여드리겠습니다. 그런 다음 애플리케이션을 실행하여 최신 상태로 유지하는 방법, 데이터 및 캐시를 최신 상태로 유지하는 방법을 보여드리겠습니다.
이미 설치했습니다 NCache 내 상자 107과 108 중 두 개에 있습니다. 바로 여기에서 내 캐시 서버와 내 개인 컴퓨터로 사용할 것입니다. 내 노트북은 클라이언트 역할을 할 것입니다.
그럼 우선 실행하겠습니다. NCache 함께 설치되는 관리자 도구 NCache 캐시를 생성하겠습니다. 이름을 EF Core 캐시로 지정하겠습니다. 두 대의 서버를 사용하겠습니다. 파티션 복제본을 캐싱 토폴로지로 유지한 다음 비동기 복제 옵션을 유지하십시오. 더 빠르기 때문입니다. 여기서는 캐시를 호스트할 서버를 지정했습니다. 그래서 데모 1과 데모 2의 두 서버와 통신용 TCP/IP 포트가 있습니다. 서버와 클라이언트 간의 통신에 관한 한 TCP/IP에 의해 구동되는 모든 것입니다.
캐싱할 계획인 데이터를 기반으로 하는 캐시 크기입니다. 참조 데이터인 경우 모든 제품, 모든 고객을 로드하고 있음을 고려해야 합니다. 마찬가지로 트랜잭션 데이터인 경우 작업 집합과 그에 대한 추가 공간도 고려해야 합니다. 모든 것을 단순하게 유지하고 마무리를 선택하면 됩니다. 시작하는 방법은 간단합니다. NCache 캐시를 구성합니다.
내 컴퓨터에서 응용 프로그램을 실행하고 있으므로 상자를 클라이언트 컴퓨터로 추가하기만 하면 됩니다. 이 캐시 클러스터를 시작하고 테스트할 수 있으며 그 후에 샘플 애플리케이션을 실행하여 연결할 수 있습니다. 그래서 그것이 얼마나 간단합니다. 우리는 정기적으로 NCache 아키텍처 및 확장 .NET 앱 웨비나에서 이러한 구성에 대해 자세히 설명합니다. 따라서 질문이 있는 경우 해당 웨비나도 살펴보고 싶을 수 있습니다.
몇 가지 모니터링 측면도 보여 드리겠습니다. 통계 창을 열겠습니다 NCache 함께 제공되는 스트레스 테스트 도구 응용 프로그램을 실제로 실행할 수 있도록 모니터링 도구 NCache 실제 상황을 확인하세요. 따라서 이것은 스트레스 테스트 도구입니다. 내 상자가 클라이언트이기 때문에 이에 대해 실행하겠습니다. 이름만 제공하면 여기에 연결되고 내 캐시 클러스터에서 일부 더미 로드를 시뮬레이트할 수 있어야 합니다. 캐시 크기가 커지고 항목이 추가되고 초당 요청 로드도 두 서버 모두에서 활동을 표시한 다음 이 모니터링 도구에 시간이 걸리는 것 같습니다. 대시보드를 만들고 있습니다.
이제 시작하겠습니다. 그 동안 서버 자체에서 이 도구의 다른 인스턴스를 실행하겠습니다. 내 잘못이야. 좋습니다. 그러면 초당 요청 수가 증가하는 것을 볼 수 있습니다. 어떤 이유로 모니터링 도구인 대시보드를 로드하는 데 시간이 좀 걸립니다. 돌아오는 대로 바로 여기에 두어야 할 것 같습니다. 이 도구의 모니터링 내역을 보여드리겠습니다.
캐시를 최신 상태로 유지: 참조 데이터
좋습니다. 이 웨비나의 다음 부분은 Entity Framework Core 애플리케이션 내에서 캐시 데이터를 최신 상태로 유지하는 것입니다. 이를 위해 참조 데이터와 트랜잭션 데이터 예제를 다시 사용하겠습니다. 따라서 참조 데이터부터 시작하겠습니다.
참조 데이터를 캐시하려면 캐시에 전체 데이터 세트를 캐시해야 한다고 이미 설정했습니다. 예를 들어 제품이 있는 경우 모든 제품을 캐시에 로드한 다음 별도의 엔터티로 로드해야 합니다. 그렇다면 이것의 문제는 무엇입니까?
이후, 참조 데이터, 전체 참조 데이터를 캐시에 넣은 다음 FromCacheOnly 확장 방법을 사용하여 캐시만 사용합니다. 이제 캐시에서 부분적인 데이터 세트를 감당하고 싶지 않습니다. 단종된 제품이거나 일부 기준을 실행 중인 경우 캐시에 있는 모든 제품을 원할 것입니다. 그러나 해당 제품이 실제로 데이터베이스에서 변경될 가능성이 있습니다. 이제 데이터는 서로 다른 두 위치에 존재합니다. 마스터 복사본인 데이터베이스가 있고 전체 데이터를 캐시에 로드했지만 애플리케이션 범위 밖에서 데이터베이스가 업데이트될 가능성이 여전히 있습니다.
따라서 캐시 데이터를 최신 상태로 유지하려면 데이터와 캐시를 자동으로 업데이트하는 일종의 메커니즘이 있는지 확인해야 하며 여기에는 두 가지 옵션이 있습니다. 첫 번째 옵션은 만료를 사용하는 것입니다.
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();
}이것은 시간 기반 만료이며 혼합하여 자동 새로 고침 기능과 함께 사용합니다. NCache 만료 기능을 사용하면 데이터를 만료하고 지정된 기간(예: 5시간, 10시간)이 지난 후 데이터를 제거할 수 있습니다. 참조 데이터의 경우 긴 실행 데이터이므로 조회 데이터, 마스터 데이터이므로 변경 빈도가 그다지 높지 않으므로 편안한 숫자를 알 수 있습니다. 시간 또는 5시간, 10시간, 24시간이 될 수 있습니다. 따라서 이를 기반으로 만료 시간을 설정할 수 있습니다. 그러나 앞에서 언급했듯이 캐시에서 해당 데이터를 잃거나 제거하는 것을 실제로 원하지는 않습니다.
정말로 필요한 것은 변경되는 데이터, 예를 들어 10개의 제품이 지정된 만료를 기준으로 만료된다는 것입니다. 자동 재로드 메커니즘을 사용하여 해당 데이터를 캐시에 자동으로 다시 로드해야 합니다. 그리고 NCache read-through 처리기의 도움으로 이를 제공합니다. 따라서 해야 할 일은 전체 데이터를 다시 로드하고 캐시에 로드를 사용하여 캐시를 로드하고 별도의 엔터티를 사용하지만 이러한 특성과 함께 사용하는 것입니다. 예를 들어 절대 만료를 설정합니다.
이것이 캐시에 로드될 모든 제품에 설정하는 만료 값이며 기본적으로 내부에서 읽기 제공자를 호출하는 재동기화 제공자를 설정합니다. NCache. Read-through는 만료와 결합됩니다. 따라서 캐시에서 데이터를 제거하는 대신 실제로 다시 로드합니다. 모든 키와 모든 데이터베이스 관련 정보를 알고 있기 때문에 컨텍스트를 전달하고 해당 컨텍스트를 기반으로 실제로 공급자를 자동 및 재동기화라고 합니다. 데이터 소스에서 업데이트된 값을 얻습니다.
작동하는 예를 보여 드리겠습니다. 방법은 다음과 같습니다. 나는 이것을 별도의 엔터티로 저장하고 있습니다. 일반적으로 만료 시간을 5시간으로 설정하지만 그렇게 많은 시간이 없으므로 실제로 할 일은 만료 시간을 약 30초로 설정하고 바로 여기에 중단점을 설정하고 모든 제품을 캐시에 로드하는 것입니다. 만료가 작동하는 방식을 보여주기 위해 이 시점에서 재동기화 공급자를 설정하지는 않겠습니다. 만료가 시작되면 캐시에서 항목을 제거한 다음 제거하는 대신 read-through 핸들러를 사용하여 다시 로드하는 방식으로 이 시나리오를 처리하는 방법을 보여 드리겠습니다.
따라서 이 샘플 비트에 대해 로컬 캐시를 사용하겠습니다. 안전을 위해 내용을 지운 다음 이 코드를 실행하고 중단점에 도달합니다. 오른쪽. 그래서 30초의 유효기간이 있고 그냥 치고 단종된 제품을 받았죠. 따라서 여기에 모든 제품이 있고 여기에는 약 천 개의 항목이 있습니다. 30초 후에 이 천 개의 항목이 이 절대 만료를 기반으로 만료될 것입니다. 우리가 설정한 플래그입니다. 이 쿼리를 다시 실행하면 캐시에 아무것도 없기 때문에 아무것도 반환하지 않는다는 것을 알 수 있습니다. From Cache Only를 사용하고 있습니다. 따라서 만료된 항목이 있습니다. 이것을 한 번 더 실행하면 값이 0인 것을 알 수 있습니다.
따라서 이것은 권장되거나 선호되는 것이 아닙니다. 이것이 참조 데이터이고 전체 데이터가 이미 캐시에 로드되었으며 From Cache Only 확장 메서드를 호출하고 있다는 점을 고려하면 좋습니다. 따라서 부분 응답이나 누락된 데이터가 아닌 필수로 사용 가능한 모든 데이터가 필요하며 동시에 만료 후 다시 로드되어야 합니다. 제거하는 대신 다시 로드해야 하며 이것이 바로 이 Set Resync Provider 이름의 도움으로 수행할 작업입니다.
IReadThruProvider라는 샘플 재동기화 공급자가 있습니다. 이것이 실제로 하는 일은 기본 구현을 제공한 것입니다.
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();
}
}
}이것은 IReadThruProvider입니다. 당신이 해야 할 일은 우리가 구성한 캐시의 도움으로 이것을 보여주자는 것입니다. read-through 핸들러를 설정해야 합니다. 예를 들어 새 캐시를 생성하고 로컬 캐시를 생성하겠습니다. 오른쪽. 따라서 로컬 캐시일 뿐입니다. 백업 소스를 설정하겠습니다. 읽기를 활성화하고 추가하고 EF 기본값을 설정해야 하며 프로젝트로 사용할 수 있으며 구현이 이미 완료되었다고 가정해 보겠습니다.
IReadThru 핸들러를 구현한 방식으로 작동합니다. 이것이 기본 재동기화 공급자입니다. 몇 가지 방법이 있습니다. DB 컨텍스트를 초기화하는 초기화 기능이 있습니다. 만료 시 호출되는 LoadFromSource는 데이터베이스에서 항목을 가져옵니다. 정의 내부로 들어가면 실제로 모든 데이터베이스 관련 호출을 처리하며 이는 우리가 구현의 일부로 제공하는 것입니다. NuGet 패키지는 이를 일부로 다룹니다. 따라서 우리는 키를 가져오고 해당 키를 기반으로 컨텍스트를 전달하고 컨텍스트는 데이터베이스에서 직접 실제 개체를 가져오는 데 사용됩니다.
이 EF 기본 재동기화 공급자를 알고, 상속하고, 구현하고, 자체 구현을 제공하고, 데이터베이스 컨텍스트를 제공하기만 하면 됩니다.
이것은 우리가 여러분에게 제공한 추상 클래스입니다. Northwind 데이터베이스 컨텍스트 또는 가지고 있는 데이터베이스 컨텍스트를 제공하기만 하면 됩니다. 일단 이 메서드가 재정의/구현되면 이를 기반으로 캐시에 등록하기만 하면 됩니다. 예를 들어 이것은 재동기화 공급자입니다. 열어보면 XNUMX개가 들어있어요. 하나는 기본값이고 다른 하나는 구현이며 필요한 경우 연결 문자열 및 기타 정보를 전달할 수 있습니다. 이것을 배포하기만 하면 됩니다. 이 부분으로 가져가면 성공할 것입니다. 그래서 그렇게 해야 합니다. 내가 언급했듯이 이것은 이미 일부로 수행되었습니다. NCache, 구현. NuGet 패키지에는 여기에서 이 특정 메서드를 구현하고 컨텍스트를 제공하여 간단하게 구현할 수 있는 재동기화 공급자와 함께 제공되며 작업의 나머지 부분은 실제로 확장 메서드가 작동하는 것과 동일한 라인에서 작동하는 이 샘플 기본 재동기화 공급자에 의해 수행됩니다.
우리는 귀하의 키를 구성하므로 어떤 키가 어떤 엔터티를 나타내는지 알고 해당 엔터티와 해당 키 정보를 기반으로 Entity Framework, API를 사용하여 실제로 데이터베이스를 쿼리합니다. 이제 이것은 내 캐시에 대해 이미 수행되었습니다. 여기서 내가 한 것은 성공적으로 배포되었다는 것입니다. 그래서, 내 캐시를 위해 나는 이미 이것을 했습니다. 이 EF 기본값이 있고 배포했습니다. 따라서 동일한 사용 사례를 실행하지만 이번에는 단순히 만료하는 대신 실제로 다시 로드합니다. 그래서 그게 제가 할 일입니다. 재동기화 공급자 이름을 설정한 다음 일부 값도 업데이트할 계획이므로 60초를 사용하겠습니다. 일반적으로 참조 데이터의 경우 5시간 이상과 같이 절대 만료로 훨씬 더 많은 시간을 지정해야 합니다. 그래서 60초로 실행하겠습니다. 이번에는 재동기화 공급자가 설정되어 있는 것을 볼 수 있습니다.
따라서 이 사용 사례를 한 번 더 실행하고 이것이 만료되는 대신 제거되는 대신 업데이트되는 방법을 보여 드리겠습니다. 그래서 이것은 실행되었으며 바라건대 이 시점으로 돌아올 것입니다. 괜찮은. 그래서 우리는 제품을로드했습니다. 이것을 한 번 더 실행하고 이번에는 만료 시간이 60초이므로 이 특정 제품인 제품 ID를 업데이트하겠습니다. 17 그리고 우리가 할 일은 업데이트라고 말하는 것입니다.
데이터베이스에서는 업데이트되지만 캐시 데이터만 사용하고 아직 만료되지 않았기 때문에 애플리케이션 컨텍스트에서는 아직 업데이트되지 않습니다. 따라서 우리는 이전 값을 계속 가져오고 내 캐시에 수천 개의 항목이 있고 Readthru/sec가 있다는 것을 알게 되면 60초 후에 몇 가지 활동을 표시한 다음 방금 설정한 read-through 핸들러를 자동으로 호출합니다.
따라서 한 번만 더 실행하고 주문 값을 다시 기대하고 있습니다. 이미 다시 로드되지 않은 경우 다시 로드되는 지점이 있을 것이고 그 후에는 단순히 만료되는 대신 999를 다시 로드할 것입니다. 제품의. 추가 항목이 하나 있는데 일반적으로 참조입니다. 자. 따라서 만료 대신 하나의 항목만 만료되었습니다. 키 목록이기 때문입니다. 그렇지 않으면 제 쿼리를 기반으로 하는 모든 참조 데이터가 쿼리를 보여드리겠습니다. 제품 ID가 1000보다 작은 곳이 표시됩니다. 따라서 실제로는 1000개의 제품을 나타냅니다.
따라서 이 쿼리를 한 번 더 실행하겠습니다. 이번에는 데이터가 제거되는 대신 만료 시 이미 업데이트되었기 때문입니다. 그래서 업데이트된 제품이 캐시에 추가되길 기대하고 있습니다. 자, 여기 있습니다. 그래서 내 제품이 이것의 일부로 업데이트되었습니다. 따라서 이것은 만료를 사용하지만 자동 재로드 기능이 있는 옵션 번호 24의 일부로 권장하는 것입니다. 따라서 만료 대신 단순히 데이터를 다시 로드하면 캐시 데이터를 최신 상태로 유지할 수 있습니다. 따라서 캐시에 데이터를 보관할 수 있는 편안한 시간을 생각해냅니다. 오래된 데이터를 계속 가져오고 해당 오래된 데이터가 만료되자마자 하루, 즉 2시간이 될 수 있고 애플리케이션 내에서 편안한 시간인 XNUMX일, 일주일이 될 수 있습니다. 몇 시간이 걸릴 수도 있고 그 후에는 해당 데이터를 캐시에 다시 로드합니다.
이것이 우리의 옵션 번호 XNUMX입니다. 나는 그것이 매우 간단하기를 바랍니다.
두 번째 옵션은 만료를 사용하지 않는 것입니다. 따라서 데이터가 항상 캐시에 존재하는 바로 여기에서 이 문제를 처리할 것입니다. 그러나 데이터는 캐시에서 부실할 수 있으며 영원히 부실할 수 있습니다. 이를 위해서는 수동으로 다시 로드해야 하며 그것도 매우 간단합니다.
void LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}여러분이 해야 할 일은 주기적 간격 후에 이 Load All Products를 호출하기만 하면 됩니다. 예를 들어, 바로 여기 이 부분으로 돌아간다면. 따라서 이 메서드는 일정 간격 후에 호출되어야 하며 앞서 언급한 것처럼 이것은 일반적으로 응용 프로그램 시작 시 수행되며 이 메서드를 담당하는 응용 프로그램 중 하나일 수 있습니다. 이 모든 것을 처리합니다. 그래서 그것은 그 일 수도 있고 그것을 하는 별도의 애플리케이션인 애플리케이션 중 하나일 수도 있습니다. 따라서 애플리케이션이 될 수도 있고 애플리케이션 인스턴스 중 하나가 될 수도 있고 별도의 애플리케이션이 될 수도 있으며 해당 애플리케이션은 예를 들어 5시간, 24시간 후에 주기적으로 이 메서드를 호출할 수 있습니다.
따라서 LoadIntoCache는 데이터베이스에 대해 실행되고 새로운 복사본을 캐시에 로드하는 특정 시나리오를 처리합니다. 이것이 참조 데이터를 담당하는 방법입니다. 내가 꽤 솔직했으면 좋겠다.
캐시를 최신 상태로 유지: 트랜잭션 데이터
트랜잭션 데이터를 사용하는 다음 세그먼트로 이동하겠습니다. 이제 트랜잭션 데이터는 수명이 짧은 것입니다. 앞에서 설명한 대로 작업 세트입니다. 따라서 5~10분의 만료 시간을 사용할 수 있습니다. 따라서 여기서 실제로 해야 할 일은 캐시에 대해 실행되는 FromCache를 사용하고 있기 때문에 캐시에 존재하고 캐시에 존재하지 않으면 항상 데이터베이스에 대해 자동으로 실행됩니다. 따라서 이것은 캐시에 대해서만 실행되는 참조 데이터 시나리오와 함께 사용하는 FromCacheOnly와 달리 이 확장 메서드에 내장되어 있습니다. 따라서 데이터를 컬렉션으로 저장하든 별도의 엔터티로 저장하든 일부 데이터를 사용할 수 있는 것은 괜찮습니다.
짧은 만료, 자동 재장전 없음 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;
}따라서 짧은 만료를 사용합니다. 예를 들어 참조 데이터에 대해 60초를 사용했지만 이는 이 특정 데모를 위한 것이었지만 참조 데이터의 경우 일반적으로 5~10시간의 만료가 있고 트랜잭션 데이터의 경우 60초 또는 관련 만료가 연결되어 있고 From Cache를 사용하고 있으므로 실제로 Get Customer Orders를 살펴보겠습니다.
자, 여기에서 일부 만료를 설정하고 이 FromCache 확장 메서드를 호출하면 캐시에 존재하지 않는 경우 데이터베이스에서 가져오는 작업을 담당하고 작업 세트가 캐시에서 활성화되었는지 여부를 일정 시간 후에 캐시에서 가져올 수 있습니다. 캐시에서 활성화되어 있지 않으면 더 이상 필요하지 않을 가능성이 있습니다. 따라서 결국 데이터베이스로 돌아가게 될 수 있으며 이는 트랜잭션 데이터와 관련된 올바른 작업입니다. 따라서 참조 데이터와 트랜잭션 데이터 시나리오 및 이 두 가지와 관련하여 캐시 데이터를 최신 상태로 유지하는 방법을 다루기를 바랍니다.
캐시에서 관계 처리
다음 세그먼트인 캐시의 관계 처리로 이동하겠습니다.
론, 여기에 몇 가지 질문이 있습니다. 는 NCache 또는 캐시된 항목이 NCache 서버 또는 각 응용 프로그램 서버에서 섀도 처리됩니까?
그들은 거주 NCache. 맞습니다. 항목이 실제로 NCache, 오른쪽. 따라서 실제 저장소는 NCache 실제로 이러한 엔터티 메서드와 함께 키와 개체를 구성합니다. 그래서 여기 아이디어가 있습니다.
또 다른 질문은 캐시에 참조 데이터를 추가할 때 여러 개의 캐시 로더를 구성하거나 모든 캐시 로더를 하나로 구성해야 하는지 여부입니다.
캐시에 로드하는 것이 일반적인 방법이기 때문에 가능합니다. 따라서 올바르게 실행하려는 쿼리를 실제로 로드합니다. 따라서 쿼리에 바인딩됩니다. 캐시에 여러 번 로드할 수 있으며 하나의 별도 애플리케이션이 있거나 애플리케이션 내의 다른 위치에 있을 수 있습니다. 따라서 그 측면에서도 매우 유연합니다.
캐시에서 관계 처리: 일대다
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;
}강조하고 싶은 몇 가지 중요한 개념이 있습니다. 관계를 처리하는 방법? 일대다, 다대다 예.
일대다에 집중합시다. 지역이 있고 지역의 일부인 지역이 있고 지역과 지역 간에 진행되는 일대다 관계가 있는 경우. 동기화 접근 방식으로 이동하고 내부에서 실제로 여기에서 영역을 가져오겠습니다.
자, 영토가 있는 지역을 얻습니다. 여기서 기본 아이디어는 Include 키워드가 있고 FromCache를 사용하고 항상 별도의 엔터티로 저장한다는 것입니다. 여기서 아이디어는 영역의 상위 항목이 캐시에 별도의 항목으로 저장된다는 것입니다. 지역도 지역과 일대다 관계를 가지며 각 지역 엔터티 내부에 지역 모음이 있으므로 NCache 그것에 순종할 것입니다. FromCache를 호출하자마자 지역을 가져오고 모든 지역은 별도의 엔터티로 저장되며 지정한 범위에 따라 FromCache의 도움으로 모든 지역이 각 지역 내에 별도의 컬렉션으로 저장됩니다.
따라서 여러 측면을 갖는 하나의 개체입니다. 컬렉션 측면은 관련 객체입니다. 이것이 일대다 사용 사례를 다루는 방법입니다.
집계 작업 캐싱
그런 다음 집계 작업 캐싱이 있습니다. 알다시피, 엔티티가 되거나 값이 될 수 있습니다.
예를 들어 첫 번째 또는 기본 배송업체를 받는 것이 맞습니다. 예를 들어 여기에서 First 또는 Default를 수행하면 첫 번째 배송업체를 가져온 다음 이를 기반으로 알 수 있습니다. NCache.
마찬가지로 카운트 합계가 될 수 있습니다. 모든 집계 작업이 될 수 있으므로 값이 될 수 있습니다. 다시 이것은 다음 위치에 저장할 수 있습니다. NCache 별도의 엔티티로.
Shippers GetFirstShipperInstance (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
Shippers shipper = database.Shippers.DeferredFirstOrDefault()
.FromCache(out string cacheKey, options);
return shipper;
}마찬가지로 카운트 합계가 될 수 있습니다. 모든 집계 작업이 될 수 있으므로 값이 될 수 있습니다. 다시 말하지만 이것은 다음 위치에 저장할 수 있습니다. NCache 별도의 엔티티로.
int GetTotalShippersCount (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
int count = database.Shippers.DeferredCount()
.FromCache(out string cacheKey, options);
return count;
}분산 캐싱 아키텍처
따라서 기술적인 부분에 관한 웨비나를 다룹니다. 끝으로 몇 가지 분산 캐싱 아키텍처를 보여 드리겠습니다.
고 가용성
NCache 제품은 매우 확장 가능하고 빠릅니다. 프로토콜의 피어 투 피어 아키텍처를 기반으로 하는 것입니다. 단일 실패 지점이 없습니다. 실행 중인 캐시에서 즉시 서버를 추가하거나 제거할 수 있습니다. 캐시 또는 캐시에 연결된 클라이언트를 중지할 필요가 없습니다. 따라서 실행 중인 캐시 클러스터를 동적으로 변경할 수 있습니다.
캐싱 토폴로지
그런 다음 가장 인기 있는 토폴로지는 파티션 복제 캐시. 이를 통해 파티션 형태로 모든 서버에 데이터를 간단히 배포할 수 있습니다. 따라서 그들은 메모리 리소스, 계산 리소스를 함께 풀링하고 논리적 용량을 제공하며 각 서버에는 백업도 있습니다. Server1은 2의 백업입니다. Serve2는 1의 백업이고 Serve3은 Serve1의 백업입니다. 따라서 라운드 로빈 방식으로 각 서버는 다른 서버에 백업을 가지고 있습니다.
클라이언트 캐시(캐시 근처)
마찬가지로 이것은 매우 빠르고 확장 가능하며 가장 널리 사용되는 토폴로지입니다. 당신은 또한 가질 수 있습니다 클라이언트 캐시 자신의 응용 프로그램 상자에서 실행할 수 있습니다. 로컬 캐시이지만 서버 캐시와 동기화되어 있습니다. 데이터의 하위 집합은 코드 변경 없이 자동으로 캐시로 가져옵니다. 데이터가 대부분 참조 특성인 경우 이렇게 하면 성능이 향상됩니다. 따라서 일단 캐시에 로드한 다음 FromCacheOnly 클라이언트 캐시를 호출하여 이 데이터 하위 집합을 호출하기 시작하면 이 경우에 정말 도움이 됩니다.
캐시의 WAN 복제
WAN 복제 또 다른 기능인 브리지 복제입니다. 활성-수동 또는 활성-활성 데이터 사이트를 가질 수 있습니다. 모든 데이터, EF Core 데이터, ASP.NET 세션 또는 일반 데이터는 활성-수동 또는 활성-활성 방식으로 WAN을 통해 대상 사이트로 전송될 수 있습니다. 자, 이것이 바로 NCache 그것의 일부로 덮습니다.
결론
다시 한 번 말씀드리지만 Nick에게 전달하기 전에 XNUMX분 더 시간을 갖겠습니다. 그래서 우리는 직접 API를 사용하여 단일 엔터티 및 저장 엔터티 컬렉션에 대해 이야기했습니다. 그것은 확장 방법 측면에서 약간 달랐고 본질적으로 매우 단순하고 본질적으로 더 유연한 확장 방법에 대해 이야기했습니다. FromCache는 직접 구현해야 하는 직접 API와 달리 캐시가 있으면 캐시에서 가져오고, 없으면 데이터 소스에서 자동으로 가져오는 첫 번째 방법이었습니다. 또한 여기에서 설정한 키 및 관련 옵션을 구성합니다.
그런 다음 참조 및 트랜잭션 데이터에 대해 이야기했습니다. 참조 데이터를 처리하려면 LoadIntoCache를 사용하여 전체 데이터를 로드해야 하며 FromCacheOnly를 호출해야 합니다. LoadIntoCache는 항상 데이터베이스에 대해 실행되고 FromCacheOnly는 캐시에 대해서만 실행되며 FromCache의 도움으로 처리할 수 있는 트랜잭션 데이터에 대해 이야기하고 일부 만료를 설정했습니다. 참조 데이터를 최신 상태로 유지하려면 만료를 사용한 다음 자동 다시 로드를 사용하거나 만료를 사용하지 않고 LoadIntoCache를 사용하여 수동으로 다시 로드해야 합니다. 그런 다음 캐시에 존재하는 경우 얻을 수 있도록 일종의 만료 및 FromCache를 사용해야 하는 트랜잭션 데이터에 대해 이야기했습니다. 캐시에 없으면 항상 데이터베이스에서 가져옵니다.
이것으로 프레젠테이션을 마칩니다. 질문이 있으면 알려주십시오.
당신은 항상 우리에게 연락 할 수 있습니다 support@alachisoft.com. 기술적인 질문이 있는 경우 다음을 통해 문의할 수도 있습니다. sales@alachisoft.com. 제품을 살펴보고 싶다면 제품을 다운로드하고 당사 웹 사이트로 이동할 수 있습니다. alachisoft.com에서 다운로드할 수 있습니다. NCache 사용할 수 있는 30일 평가판이 함께 제공되며 질문이 있으면 알려주세요. 그렇지 않으면 오늘 이 쇼, 웨비나에 참석해 주셔서 감사합니다. 다음에 뵙겠습니다. 론 정말 감사합니다. 감사합니다.