객체에 대한 접근 및 조작의 용이성을 제공하는 것에 대해 이야기할 때마다, 객체 관계형 매퍼 (ORM)은 반드시 등장할 것입니다. Entity Framework Core 및 NHibernate와 같은 ORM은 일반 이전 CLR 개체(POCO) 데이터베이스 정보에 대한 인스턴스, 연관 관리, 제약 조건 등
그러나 code-to-SQL 기능을 사용하면 성능 지연 및 저하가 발생할 수 있으며, 가장 일반적인 원인은 N+1 문제입니다. StackExchange의 사람들은 인프라 요구 사항에 대한 ORM의 성능에 만족하지 않았고 날씬한, 매우 빠르고 데이터베이스 모델에 대한 개체 매핑을 매우 쉽고 직관적으로 만드는 ADO.NET 주변의 마이크로 ORM 경량 래퍼입니다.
주요 요점
밀리초 미만 성능: Dapper Micro-ORM과 결합 NCache SQL 직접 왕복을 고속 인메모리 데이터 액세스로 대체하여 데이터베이스 병목 현상을 제거합니다.
자동 데이터 동기화: 사용 NCache 읽기 통과 및 쓰기 통과 공급자는 수동 캐시 관리 코드 없이도 Dapper 애플리케이션이 데이터베이스와 동기화 상태를 유지하도록 보장합니다.
애플리케이션 운영 비용 절감: 데이터 검색 및 영구 저장 작업을 오프로딩합니다. NCache 클라이언트 애플리케이션을 "예비" 상태로 만들어 애플리케이션 서버의 CPU 및 메모리 사용량을 크게 줄입니다.
선형 확장성: 분산 캐시 클러스터를 통합하면 Dapper 기반 애플리케이션이 선형적으로 확장되어 증가하는 트랜잭션 볼륨을 손쉽게 처리하기 위해 캐시 노드를 추가할 수 있습니다.
Dapper Micro-ORM을 통합하는 방법 NCache
Dapper는 주로 IDb연결 클래스이며 자주 복잡한 ADO.NET 작업에 대한 전면을 제공합니다. 그것이 경량 특성과 고속의 주요 이유입니다. 그러나 데이터베이스로의 왕복을 피하기 위해 데이터가 메모리에 유지되도록 하려면 다음을 사용하십시오. NCache.
방법 NCache Dapper의 성능과 확장성을 향상시킵니다.
| 제품 특장점 | 댄디한 (표준) | 멋쟁이 + NCache |
|---|---|---|
| 데이터 검색 | 직접 데이터베이스 입출력(SQL) | 분산형 인메모리 속도 |
| 확장성 | 데이터베이스 연결 풀에 의해 제한됨 | 선형적으로 확장 가능한 클러스터 노드 |
| 데이터 신선도 | 항상 실시간(직접 DB 쿼리) | 동기화 공급자를 통한 자동화 |
| 아키텍처 | 간단한 2계층 구조(앱에서 데이터베이스까지) | 확장 가능한 3계층 구조(앱에서 캐시, 데이터베이스까지) |
분산 캐시와 같은 경우 NCache, 아래 그림과 같이 데이터 소스 공급자를 사용하여 성능을 훨씬 더 조정할 수 있습니다.
그림 1: Dapper Micro-ORM 통합 NCache 데이터 소스 공급자
NCache 세부 정보 데이터 소스 공급자 Dapper를 사용한 데이터 소스
타사 Dapper 구현 NCache 데이터 소스 공급자
데이터 소스 공급자는 읽기 및 쓰기 목적으로 백엔드 마스터 데이터 소스에 액세스해야 할 때마다 최상의 솔루션입니다. 이러한 공급자는 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: 데이터 소스 공급자를 통한 데이터 동기화 자동화
캐시에 오래된 데이터를 유지하는 것을 방지하기 위해 데이터 소스 공급자는 데이터베이스 종속성 기능 캐시된 데이터와 데이터베이스의 데이터 동기화를 확인합니다. 캐시를 재동기화하는 모든 작업은 클라이언트 개입 없이 서버 측에서 수행됩니다.
두 번째 이점: 고객 측 간접비 절감 NCache 공급 업체
데이터 저장소를 변경하고 싶다고 가정해 보겠습니다. 스키마 업데이트, 테이블 변형, 전체 데이터 저장소를 모두 변경하더라도 다음과 같은 방법이 있습니다. NCache 당신을 위해 프로세스를 단순화합니다. 와 함께 NCache 데이터 소스 공급자는 클라이언트 애플리케이션을 변경할 필요가 없으며 데이터 소스 구현을 업데이트하는 것으로 충분합니다.
이점 #3: Dapper 쿼리 결과 확장 NCache 분산 클러스터
애플리케이션의 여러 인스턴스가 캐시를 공유하는 로드 밸런서(예: 서버 팜, Kubernetes 클러스터) 뒤에서 실행되는 환경에서 애플리케이션이 실행되는 경우 다음과 같습니다. NCache 하는 일: 인스턴스 중 하나가 데이터 소스를 쿼리하면 결과가 분산 캐시에 저장되므로 다른 인스턴스가 동일한 결과를 쿼리할 때 데이터 소스를 왕복할 필요 없이 캐시에서 바로 가져옵니다.
이렇게 하면 데이터베이스에 대한 적중이 줄어들고 확장 가능하므로 NCache 클러스터를 중단할 필요 없이 실시간으로 클러스터를 간단히 확장함으로써 요청 로드 증가를 수용할 수 있습니다.
NCache 세부 정보 데이터 소스 공급자 Dapper를 사용한 데이터 소스
그것을 요 약하기
ORM이 사용자에게 용이함을 제공하는 경우 애플리케이션에 부담을 주어 예상치 못한 성능 저하를 유발할 수 있습니다. 그러나 Dapper는 매우 가볍고 효율적인 쿼리 및 명령을 설계할 때 이러한 지식을 염두에 두어야 하는 개발자에게 더 많은 제어 권한을 제공합니다.
이제 능숙해지면 다음과 같은 분산 캐시를 사용해 보십시오. NCache 그것으로? NCache, 인메모리 및 확장하기 쉬운 기능으로 Dapper 라이브러리를 매우 정밀하게 보완하여 결과가 놀랍습니다. 그래서, 가서 NCache 지금!
자주 묻는 질문 (FAQ)
Q : 어떻게합니까? NCache Dapper의 2차 캐시 역할을 하나요?
A: Dapper는 내장 캐싱 레이어가 없는 경량 마이크로 ORM이지만, 직접 구현할 수 있습니다. NCache 분산형 2차 캐시로 사용합니다. Dapper 쿼리 로직을 다음으로 래핑하면 됩니다. NCache API 호출 시 매핑된 객체를 클러스터에 저장하여 중복 SQL 실행을 방지하고 데이터베이스 부하를 줄일 수 있습니다.
Q: Dapper에서 IReadThruProvider를 사용하면 어떤 이점이 있나요?
A: IReadThruProvider는 허용합니다 NCache Dapper 애플리케이션과 데이터베이스 사이에 위치합니다. 캐시에서 쿼리 결과가 누락된 경우, NCache Dapper를 사용하여 소스에서 데이터를 자동으로 가져오고, 캐시를 채우고, 애플리케이션으로 반환하여 코드의 "캐시 저장" 로직을 간소화합니다.
Q : 할 수 있습니다 NCache Dapper 애플리케이션의 데이터베이스 쓰기 작업을 처리할 수 있습니까?
A: 네, IWriteThruProvider를 통해 가능합니다. Dapper 애플리케이션이 레코드를 업데이트할 때, NCache 동기식 또는 비동기식(쓰기 지연)으로 백엔드 데이터베이스를 업데이트할 수 있습니다. 이를 통해 캐시와 데이터베이스가 동기화된 상태를 유지하면서 메인 애플리케이션 스레드에서 영구 저장 책임을 분산시킬 수 있습니다.
Q : 왜 NCache Dapper 기반 웹 팜에서 로컬 MemoryCache보다 선호되는 것은 무엇인가요?
A: 현지와는 달리 MemoryCache이는 단일 서버에만 국한됩니다. NCache 선형적으로 확장 가능한 분산 클러스터를 제공합니다. 이를 통해 로드 밸런싱 환경의 모든 웹 서버가 동일한 캐시된 Dapper 결과에 액세스할 수 있으므로 애플리케이션 계층 전체에서 데이터 일관성이 유지됩니다.
