객체에 대한 접근 및 조작의 용이성을 제공하는 것에 대해 이야기할 때마다, 객체 관계형 매퍼 (ORM)은 반드시 등장할 것입니다. Entity Framework Core 및 NHibernate와 같은 ORM은 일반 이전 CLR 개체(POCO) 데이터베이스 정보에 대한 인스턴스, 연관 관리, 제약 조건 등
그러나 code-to-SQL 기능을 사용하면 성능 지연 및 저하가 발생할 수 있으며, 가장 일반적인 원인은 N+1 문제입니다. StackExchange의 사람들은 인프라 요구 사항에 대한 ORM의 성능에 만족하지 않았고 날씬한, 매우 빠르고 데이터베이스 모델에 대한 개체 매핑을 매우 쉽고 직관적으로 만드는 ADO.NET 주변의 마이크로 ORM 경량 래퍼입니다.
Dapper 통합 NCache
Dapper는 주로 IDb연결 클래스이며 자주 복잡한 ADO.NET 작업에 대한 전면을 제공합니다. 그것이 경량 특성과 고속의 주요 이유입니다. 그러나 데이터베이스로의 왕복을 피하기 위해 데이터가 메모리에 유지되도록 하려면 다음을 사용하십시오. NCache. 다음과 같은 분산 캐시를 사용하면 NCache, 아래 그림과 같이 데이터 소스 공급자를 사용하여 성능을 훨씬 더 조정할 수 있습니다.
NCache 세부 정보 데이터 소스 공급자 Dapper를 사용한 데이터 소스
데이터 소스 제공업체가 있는 타사 Dapper
데이터 소스 공급자는 읽기 및 쓰기 목적으로 백엔드 마스터 데이터 소스에 액세스해야 할 때마다 최상의 솔루션입니다. 이러한 공급자는 Dapper 작업을 서버 측으로 오프로드합니다.
내 애플리케이션이 데이터 소스 공급자와 함께 Dapper 라이브러리를 제공하는 방법을 살펴보겠습니다.
이 간단한 구현 전체 읽기 Dapper 라이브러리가 있는 공급자는 다음을 사용하여 데이터 소스에서 직접 데이터를 읽습니다. NCache 결과를 캐싱하면 애플리케이션의 성능이 향상됩니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
public ProviderCacheItem LoadFromSource(string key) { var customerId = key.Replace("Customer:CustomerID:", "").Trim(); var commandDefinition = new CommandDefinition($@" SELECT * FROM dbo.Customers WHERE CustomerID = @cId", new { cid = customerId }, flags: CommandFlags.NoCache); var customer = Connection.Query<Customer>(commandDefinition).FirstOrDefault(); var providerCacheItem = new ProviderCacheItem(customer) { Dependency = GetCustomerSqlDependency(customerId), ResyncOptions = new ResyncOptions(true) }; return providerCacheItem; } |
NCache 세부 정보 데이터 소스 공급자 Dapper를 사용한 데이터 소스
마찬가지로 데이터 저장소에 직접 데이터를 쓰려면 NCache 를 제공합니다 연속 기입 사용자로부터 데이터를 가져와서 캐시된 복사본을 유지하면서 데이터 저장소에 쓰는 공급자입니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
public OperationResult WriteToDataSource(WriteOperation operation) { Customer customer = null; if (operation.OperationType == WriteOperationType.Add || operation.OperationType == WriteOperationType.Update) { customer = operation.ProviderItem.GetValue<Customer>(); } if (operation.OperationType == WriteOperationType.Add) { var commandDefinition = new CommandDefinition(// INSERT sql command for customer data with customer id , customer, flags: CommandFlags.NoCache); Connection.Execute(commandDefinition); } else if (operation.OperationType == WriteOperationType.Update) { var commandDefinition = new CommandDefinition(// UPDATE sql command for customer data with customer id, customer, flags: CommandFlags.NoCache); Connection.Execute(commandDefinition); } else if (operation.OperationType == WriteOperationType.Delete) { var customerId = operation.Key.Replace("Customer:CustomerID:", "").Trim(); var commandDefinition = new CommandDefinition(// delete sql script for given customer id , new { cId = customerId }, flags: CommandFlags.NoCache); Connection.Execute(commandDefinition); } } |
NCache 세부 정보 데이터 소스 공급자 Dapper를 사용한 데이터 소스
이 자세한 솔루션은 다음 위치에서 찾을 수 있습니다. NCache Dapper 라이브러리를 사용하여 데이터 저장소를 채우고 읽습니다. GitHub의.
내가 느낀 이점을 나열 할 것입니다 NCache- 멋진 콜라보레이션.
이점 # 1: 동기화를 위한 데이터 소스 공급자
캐시에 오래된 데이터를 유지하는 것을 방지하기 위해 데이터 소스 공급자는 데이터베이스 종속성 기능 캐시된 데이터와 데이터베이스의 데이터 동기화를 확인합니다. 캐시를 재동기화하는 모든 작업은 클라이언트 개입 없이 서버 측에서 수행됩니다.
이점 # 2: 예비 클라이언트 애플리케이션에 대한 데이터 소스 공급자
데이터 저장소를 변경하고 싶다고 가정해 보겠습니다. 스키마 업데이트, 테이블 변형, 전체 데이터 저장소를 모두 변경하더라도 다음과 같은 방법이 있습니다. NCache 당신을 위해 프로세스를 단순화합니다. 와 함께 NCache 데이터 소스 공급자는 클라이언트 애플리케이션을 변경할 필요가 없으며 데이터 소스 구현을 업데이트하는 것으로 충분합니다.
이점 3: 확장성 NCache 쿼리 결과 저장
애플리케이션의 여러 인스턴스가 캐시를 공유하는 로드 밸런서(예: 서버 팜, Kubernetes 클러스터) 뒤에서 실행되는 환경에서 애플리케이션이 실행되는 경우 다음과 같습니다. NCache 하는 일: 인스턴스 중 하나가 데이터 소스를 쿼리하면 결과가 분산 캐시에 저장되므로 다른 인스턴스가 동일한 결과를 쿼리할 때 데이터 소스를 왕복할 필요 없이 캐시에서 바로 가져옵니다.
이렇게 하면 데이터베이스에 대한 적중이 줄어들고 확장 가능하므로 NCache 클러스터를 중단할 필요 없이 실시간으로 클러스터를 간단히 확장함으로써 요청 로드 증가를 수용할 수 있습니다.
NCache 세부 정보 데이터 소스 공급자 Dapper를 사용한 데이터 소스
그것을 요 약하기
ORM이 사용자에게 용이함을 제공하는 경우 애플리케이션에 부담을 주어 예상치 못한 성능 저하를 유발할 수 있습니다. 그러나 Dapper는 매우 가볍고 효율적인 쿼리 및 명령을 설계할 때 이러한 지식을 염두에 두어야 하는 개발자에게 더 많은 제어 권한을 제공합니다.
이제 능숙해지면 다음과 같은 분산 캐시를 사용해 보십시오. NCache 그것으로? NCache, 인메모리 및 확장하기 쉬운 기능으로 Dapper 라이브러리를 매우 정밀하게 보완하여 결과가 놀랍습니다. 그래서, 가서 NCache 지금!