Redis vs NCache
녹화된 웨비나
론 후세인(Ron Hussain)과 잭 칸(Zack Khan)
NCache 트랜잭션이 많은 .NET에서 매우 인기 있는 네이티브 .NET 오픈 소스 분산 캐시입니다. .NET Core 및 자바 애플리케이션. Redis 에 의해 개발 된 Redis Labs이며 현재 Azure의 Microsoft에서 사용하고 있습니다. 이 웨비나에서 방법을 알아보세요. NCache 과 Redis 서로 비교하십시오. 이 웨비나의 목표는 특히 기능, 성능, 확장성, 고가용성, 데이터 안정성 및 관리와 같은 정성적 측면에서 두 제품을 더 쉽고 빠르게 비교하는 작업을 수행하는 것입니다.
이 웨비나에서 다루는 내용은 다음과 같습니다.
- 성능 및 확장성
- 캐시 탄력성(고가용성)
- 캐시 토폴로지
- SQL 및 LINQ 캐시 검색
- 타사 통합(EF, EF Core, NHibernate 등)
오늘은 매우 유사하지만 많은 면에서 다른 두 제품을 비교하는 주제를 가지고 있습니다. 그래서 우리는 NCache .NET용 주요 분산 캐싱 제품이며 .NET Core 그런 다음 기능 관점에서 다음과 비교할 것입니다. Redis. 그래서 우리는 이것에서 다룰 것이 많습니다. 플랫폼 및 기술 스택에서 시작하여 많은 기술적 세부 사항을 살펴보겠습니다. 그런 다음 클러스터링에 대해 이야기하겠습니다. 캐시 클러스터링과 관련하여 이 두 제품을 비교하는 방법과 이러한 제품을 사용하여 얻을 수 있는 다른 이점은 무엇입니까? NCache 더 나은 다음 다른 기능에 대해 이야기하겠습니다. 우린 갈거야 기능별 기능 비교 이러한 제품을 사용할 수 있는 다양한 사용 사례와 기능 비교 관점에서 이 두 제품을 비교하는 방법에 대해 설명합니다.
이번 웨비나에서 저는 NCache Enterprise 5.0.2까지 Redis 우리는 주로 Azure에 집중할 것입니다. Redis. 그게 오픈소스다. Redis 4.0.1.4. 그러나 나는 또한 당신에게 Redis 오픈소스 프로젝트 뿐만 아니라 Redis 실험실은 Redis. 그래서 비교해보겠습니다 NCache 이러한 모든 특징을 가지고 있지만 우리의 주요 초점은 Microsoft Azure가 될 것입니다. Redis, 호스팅 모델 Redis Microsoft Azure에서 얻을 수 있습니다.
확장성 문제
따라서 시작하기 전에 먼저 이 두 제품에 대한 소개 세부 정보를 살펴보겠습니다. 그렇다면 정확히 분산 캐싱 솔루션이 필요한 이유는 무엇입니까?
그래서 그 후에 다른 제품을 계속 비교합니다. 따라서 일반적으로 애플리케이션 내에서 경험할 수 있는 것은 확장성 및 성능 문제입니다. 애플리케이션에 많은 데이터 로드가 발생하고 애플리케이션 계층이 매우 확장 가능하지만 항상 웹 팜을 생성할 수 있고 애플리케이션 계층에 더 많은 리소스를 추가할 수 있지만 이러한 모든 애플리케이션 인스턴스는 돌아가서 백엔드 데이터 소스와 통신해야 할 수 있습니다. 그리고 데이터베이스, 일반적으로 관계형 데이터베이스는 트랜잭션 부하 처리 측면에서 느리기 때문에 돌아가서 성능 문제가 있는 데이터 원본과 대화해야 할 때.
이와 관련된 성능 문제가 있고 확장 측면에서 예를 들어 많은 요청 처리 용량 또는 요구 사항이 필요하고 많은 요청을 처리해야 하고 애플리케이션이 많은 사용자 로드를 생성하는 경우 데이터베이스는 이러한 극단적인 트랜잭션 로드를 처리하도록 설계되지 않았습니다. 많은 데이터를 저장할 수 있지만 해당 데이터에 대한 트랜잭션 부하가 발생하는 스토리지는 데이터베이스에 적합하지 않은 스토리지에 매우 적합합니다. 질식할 수 있습니다. 속도가 느려지고 최종 사용자 경험이 저하될 수 있습니다.
따라서 성능에 영향을 미칠 수 있으며 애플리케이션 아키텍처 내에서 용량을 늘릴 수 없습니다.
솔루션: 메모리 내 분산 캐시(NCache)
솔루션은 매우 간단합니다. 다음과 같은 메모리 내 분산 캐싱 시스템을 사용하는 것입니다. NCache 메모리에 있기 때문에 초고속입니다. 따라서 관계형 데이터베이스나 파일 시스템 또는 메모리 기반이 아닌 다른 데이터 소스와 비교할 때 데이터를 메모리, 인메모리에 저장하는 것과 비교하여 디스크에서 오는 경우 초고속으로 만들 것입니다. 그래서, 당신이 얻을 수 있는 첫 번째 이점은 초고속 성능을 얻을 수 있다는 것입니다. NCache.
두 번째 이점은 캐시 클러스터라는 것입니다. 단일 소스가 아닙니다. 하나의 서버로 시작할 수 있지만 일반적으로 최소 두 개의 서버가 있고 캐시 클러스터를 생성하는 것이 좋습니다. 캐시 클러스터를 생성하는 즉시 모든 서버에 로드를 분산하고 런타임에 더 많은 서버를 계속 추가하면 개선될 것입니다.
따라서 용량을 확장할 수 있고 더 많은 서버를 추가하여 런타임 시 용량을 늘릴 수 있으며 이를 백엔드 관계형 데이터베이스와 함께 사용할 수도 있습니다. 이는 기존의 관계형 데이터베이스를 대체하는 것이 아니며 몇 가지 사용 사례에 대해 나중에 이야기하겠습니다.
분산 캐시 배포(NCache)
다음은 일반적인 배포입니다.
내가 사용하고 있습니다 NCache 지금은 예를 들어 설명하지만 이 프레젠테이션 내에서 어떻게 Redis 배치 및 방법 NCache 배포되고 이러한 제품 내에서 사용할 수 있는 유연성은 무엇입니까?
그래서 NCache, 매우 유연합니다. Windows 및 Linux 환경에 배포하도록 선택할 수 있습니다. 온프레미스에서 사용할 수 있을 뿐만 아니라 클라우드 환경에서도 지원됩니다. Azure뿐만 아니라 Azure에서도 사용할 수 있습니다. AWS marketplace에스. 따라서 사전 구성된 이미지를 얻을 수 있습니다. NCache 시작하세요. Windows 및 Linux용 Docker 컨테이너를 사용할 수 있으며 이를 사용해야 하는 모든 플랫폼에서 사용할 수 있습니다.
일반적으로 애플리케이션은 온프레미스에서 호스팅되든 클라우드에서 호스팅되든 앱 서비스일 수 있습니다. Cloud service, 마이크로서비스일 수도 있고, Azure 웹사이트일 수도 있으며, 모든 종류의 애플리케이션이 클라이언트-서버 모델에서 연결할 수 있고 애플리케이션과 백엔드 데이터베이스 사이에 위치하며 이것이 일반적인 사용 모델입니다. 여기서 아이디어는 내부에 데이터를 저장한다는 것입니다. NCache 결과적으로 백엔드 데이터베이스에 대한 비용이 많이 드는 여행을 절약할 수 있습니다. 가능한 한 데이터베이스에 대한 여행을 저장하고 데이터베이스로 이동해야 할 때마다 항상 데이터베이스로 이동하여 데이터를 가져와서 다음에 데이터가 존재하고 데이터베이스로 이동할 필요가 없도록 캐시로 가져올 것입니다. 그리고 결과적으로 성능을 향상시키는 인메모리 액세스가 있으므로 애플리케이션 성능과 전반적인 확장성이 향상됩니다. 귀하의 요청, 데이터 요청을 호스팅하고 제공하는 여러 서버가 있습니다. 따라서 비교할 때 더 확장 가능합니다. 그리고 고가용성 및 데이터 안정성 기능도 내장되어 있습니다. NCache 실험 계획안.
NCache 애플리케이션이 실행되는 동일한 상자에서 호스팅될 수 있습니다. 아니면 별도의 계층일 수도 있습니다. 클라우드에서 선호되는 접근 방식은 별도의 전용 캐시 계층을 사용한 다음 애플리케이션이 각 계층에서 애플리케이션 인스턴스를 실행하는 것입니다. 그러나 두 모델 모두 지원되는 한 NCache 걱정이다.
일부 확장성 수치. 우리는 최근 AWS 연구실에서 이러한 테스트를 수행했습니다. 여기에서 읽기 및 쓰기 요청 로드를 시뮬레이션하고 로드를 계속 증가시켰으며 서버가 최대가 되는 것을 확인했을 때 캐시 클러스터의 서버 수를 늘렸습니다. 따라서 서버가 2개에서 3개로, 그 다음에는 3개에서 4개로, 단 2개의 서버로 초당 5백만 요청 처리량을 달성할 수 있었습니다. NCache 서버와 이것은 터치 앤 고 데이터가 아닙니다. 이것은 실제 애플리케이션 데이터였지만 애플리케이션 내의 AWS 랩에서 시뮬레이션되었습니다. 그리고 대기 시간 요소도 매우 최적화되었습니다. 우리는 이 모든 것을 마이크로초 대기 시간 내에 달성할 수 있었습니다. 따라서 이 모든 부하를 처리할 수 있을 때 개별 요청 성능이 저하되지 않았습니다.
일반적인 사용 사례: 분산 캐시
일부 사용 사례와 이것은 일반적인 것입니다. Redis 방법에 대해 이야기하겠습니다. NCache 비교할 것이다.
앱 데이터 캐싱
일반적으로 백엔드 데이터베이스에서 가져오는 거의 모든 것을 캐시하고 데이터가 데이터베이스에 존재하며 이제 이를 캐시하려고 합니다. 따라서 데이터베이스에 대한 비용이 많이 드는 여행을 저장하고 데이터베이스가 느리고 트랜잭션 로드 처리 측면에서 그다지 최적이 아니라는 것을 이미 설정했습니다. 우리는 이 줄에 많은 데이터베이스 동기화 기능을 가지고 있지만 여기서는 단순히 연결만 하면 됩니다. NCache 기본적으로 API를 사용하여 연결하고 데이터를 호출합니다. NCache. 따라서 거의 모든 것을 캐시할 수 있습니다. 도메인 개체, 컬렉션, 데이터 세트, 이미지가 될 수 있으며, 데이터 캐싱 모델을 사용하여 모든 종류의 애플리케이션 관련 데이터를 캐시할 수 있습니다.
ASP.NET/ASP.NET Core 캐싱
그런 다음 ASP.NET과 ASP가 있습니다..NET Core 특정 캐싱. 이는 ASP.NET 또는 ASP에 사용할 수 있는 기술적 사용 사례입니다..NET Core 세션 상태 캐싱. ASP.NET 또는 ASP.NET Core SignalR Backplane. NCache 백플레인으로 연결할 수 있습니다. ASP의 경우.NET Core 응답 캐싱에도 사용할 수 있습니다. IDistributedCache 인터페이스 및 세션 IDistributedCache 인터페이스에서 이 두 기능도 지원됩니다. NCache 레거시 애플리케이션의 경우 보기 상태 및 출력 캐싱에도 사용할 수 있습니다. Ron에게 간단한 질문을 던지고 싶었습니다.
우리가 들어왔어, 질문은 NCache Azure는 서버리스 프로그래밍 모델을 지원합니까?
전적으로. 이는 Azure 배포 측면에서 응용 프로그램을 서버에 배포하거나 응용 프로그램 부분에 관한 한 응용 프로그램을 서버리스 응용 프로그램이 될 수 있는 것입니다. 애플리케이션 내부에 NuGet 패키지를 포함하기만 하면 해당 애플리케이션에서 다음을 수행할 수 있습니다. NCache 필요할 때마다 전화하십시오. 설치가 필요하지도 않습니다. NCache 또는 응용 프로그램 리소스에 관한 한 서버를 설정하십시오. 하지만, 어디까지나, NCache 서버측 배포 자체가 우려되는 이유는 NCache 는 데이터 소스이므로 애플리케이션이 연결 및 검색하고 데이터를 추가하는 VM 또는 VM 집합이 있어야 합니다.
따라서 서버에서 NCache 필요한 소스로 캐시 서버 관점 NCache 서버이지만 애플리케이션에 관한 한 엄격하게 서버리스일 수 있으며 문제가 없습니다. 마이크로서비스 아키텍처도 마찬가지입니다. 이것은 마이크로 서비스가 많은 마이크로 서비스가 있는 매우 일반적인 예입니다. 방금 수행 중이고 많은 데이터를 처리하고 데이터를 가져올 수 있는 Azure 함수가 있을 수 있습니다. NCache. 그래서, 당신은 치료 NCache 데이터 소스로. 반면에 애플리케이션은 서버리스일 수 있으며 NCache 해당 모델과 완벽하게 호환됩니다.
Pub/Sub 메시징 및 이벤트
그런 다음 다른 사용 사례가 있습니다. 게시/구독 메시징 이는 서버리스 애플리케이션에 메시징을 사용할 수 있는 인상적인 사용 사례 중 하나이기 때문에 마이크로서비스를 중심으로 합니다. 마이크로서비스는 느슨하게 결합된 서버리스 애플리케이션이며 마이크로서비스 간에 통신을 구축하는 것은 큰 과제입니다. 따라서 이벤트 기반 비동기 이벤트 전파 메커니즘을 활용할 수 있는 Pub/Sub 메시징 플랫폼을 사용할 수 있습니다. 여러 애플리케이션이 메시지를 게시할 수 있는 위치 NCache 구독자는 이러한 메시지를 받을 수 있습니다.
비동기 이벤트 기반 메커니즘을 기반으로 하기 때문에 게시자 응용 프로그램은 승인 또는 메시지가 전달될 때까지 기다릴 필요가 없으며 마찬가지로 구독자는 메시지를 기다리거나 폴링할 필요가 없습니다. 알림 시 콜백을 통해 알림을 받습니다. 따라서 매우 유연하며 사용할 수 있는 또 다른 사용 사례입니다. NCache 애플리케이션을 위한 Pub/Sub 메시징 플랫폼으로 사용할 수 있습니다.
NCache 연혁
좀 더 자세히 알아보고 차이점에 대해 이야기하겠습니다. NCache 과 Redis. NCache 2005년에 출시되었습니다. 출시된 지 15년이 넘었습니다. 현재 버전 NCache 5.0, 15번째 버전입니다. 우리는 아주 많은 고객을 보유하고 있습니다. NCache 오픈 소스 버전에서도 사용할 수 있습니다. 웹 사이트와 GitHub 저장소에서 다운로드할 수 있습니다.
일부 NCache 고객
일부 고객. 자세한 목록도 얻을 수 있습니다.
플랫폼 및 기술
다음으로 방법에 대해 이야기하겠습니다. NCache 와 비교 Redis 첫 번째 세그먼트는 일반적으로 기술에 대한 몇 가지 소개 세부 정보를 기반으로 합니다. 이것은 분산 캐싱 기술에 대한 정보가 될 것입니다. 이제 우리는 방법에 직접 초점을 맞출 것입니다. NCache 와 비교 Redis 제가 공식화한 일부 세그먼트가 있습니다.
따라서 우리가 정의한 첫 번째 섹션은 플랫폼과 기술이며 처음에 우리가 목표로 삼고 있다고 언급한 바 있습니다. NCache 5.0.2. 그래서, NCache 5.0 SP2는 기본 버전입니다. NCache 사이트와 Redis 우리는 Azure를 사용할 것입니다. Redis 비교를 위해 오픈 소스에 대해서도 이야기하고 Redis 그 일환으로 연구실. 이러한 세부 사항의 대부분은 Redis.
네이티브 .NET 캐시
따라서 Azure 배경에서 오는 제품을 선택할 계획이라면 가장 중요한 것은 플랫폼과의 호환성일 것입니다.
그래서, NCache 자체는 100% .NET으로 작성되었습니다. 기본 .NET이거나.NET Core 응용 프로그램에 관한 한 제품이 맞습니다. 따라서 기본적으로 .NET으로 작성되었으며 주로 .NET 애플리케이션용이며 Windows Server 2016, 2019, 심지어 2012에도 배포됩니다. NCache is .NET framework or .NET Core 그 문제에 대한. 반면에 Redis, C++로 작성되었습니다. NCache .NET으로 작성되었습니다. 100% 개발되었으며 실제로 C#은 우리가 사용하는 주요 기술 언어이며 100% 기본 .NET이며 .NET Core. 이므로 Redis C++ Linux 기반 솔루션입니다.
따라서 Windows 관점, Windows 배경 및 .NET으로 작성된 응용 프로그램이 있는 경우 자연스러운 선택은 동일한 기술 스택에 있도록 .NET으로도 작성된 제품을 사용하는 것입니다. 애플리케이션 개발 스택 내에 많은 변형이 있을 필요가 없습니다. 따라서 이것이 이 두 제품 간의 한 가지 문제 또는 한 가지 차이점입니다.
두 번째 측면은 Windows 대 Linux이며 다음에서 사용 가능한 항목을 알고 있습니다. NCache 에서 사용할 수 있는 것 Redis 옆. 윈도우즈의 관점에서 NCache 선호하는 배포이지만 우리는 또한 우리의 도움으로 Linux 배포를 사용할 수 있습니다. .NET Core 서버 출시. 따라서 우리는 Windows 2012, 2016, 2019에서 완벽하게 호환됩니다. Docker 이미지는 Windows 변형에서도 사용할 수 있습니다. 변형 NCache. 따라서 Docker 이미지를 다운로드하고 Windows 이미지를 회전하기만 하면 됩니다. NCache 필요에 따라 프로덕션 환경에서 완벽하게 지원합니다. 우리 측의 공식적인 지원입니다. 반면 비교해보면 Redis Microsoft Azure에서도 Redis Linux에서 호스팅됩니다. 선호하는 접근 방식, 선호하는 배포 모델은 다음을 위한 Linux입니다. Redis. Windows 변형은 타사 프로젝트입니다. Microsoft Open Tech에는 이식된 버전이 있습니다. 의 공식 지원은 없습니다. Redis 그 자체. 프로젝트 자체가 보류되었습니다. 버그가 많고 불안정하며 심지어 Azure Redis, 앞에서 설명한 것처럼 Linux 버전을 사용하며 이것의 큰 문제는 공식 지원이 없다는 것입니다. Redis의 제조업체 Redis 또는 관점에서 볼 때 오픈 소스 프로젝트를 사용하고 자신의 전제에 배포하려는 경우 많은 문제가 발생합니다.
이것의 일부로 다른 한 가지 측면을 강조하고 싶습니다. NCache 온-프레미스에서 마이그레이션하고 Azure에서 사용하려는 경우 동일한 소프트웨어가 있는 그대로 작동합니다. 따라서 이사로 인한 변경이 필요하지 않습니다. NCache 온프레미스에서 Azure로. 마찬가지로 클라우드 공급업체 내에서 사용하려는 경우 NCache Azure에서는 필요한 경우 AWS로 마이그레이션할 수 있습니다. 모든 플랫폼에서 완전히 동일한 소프트웨어를 사용할 수 있기 때문입니다. 반면, Redis 우려되는 Azure Redis 백엔드 배포와 관련하여 Linux에 배포되는 호스팅 모델이지만 온프레미스에서 사용할 수 있는 동일한 변형이 없습니다. 따라서 오픈 소스를 다루어야 합니다. Redis 또는 일부 타사 공급자. 심지어 완전히 다른 제품인 상업용 변형 제품을 사용해야 합니다.
그래서 여기서 강조하고 싶은 핵심은 Redis 오픈 소스 또는 일부 상용 버전인 온프레미스 대 Redis Azure에서 또는 Redis Elastic Cache인 AWS에서. 이들은 완전히 별개의 제품입니다. 그래서 전환이 있고 많은 변화가 있습니다. 이식할 수 없습니다. Redis 약간의 변경 없이 한 환경에서 다른 환경으로 이동할 수 있습니다. 일부 기능 세트가 누락되었습니다. 일부 API는 다릅니다. 배포 모델은 이러한 제품 간에 완전히 변경됩니다. 따라서 유지하면 변경 사항이 없습니다. NCache Windows 또는 Linux의 온프레미스에서 이제 마이그레이션하고 Azure로 이동하려고 합니다. 정확히 동일한 제품이 될 것이며 이제 Azure에서 AWS로 변경하고 싶고 클라우드 공급업체를 변경하려고 합니다. Redis. 그래서, NCache 훨씬 유연합니다.
리눅스 지원, NCache 완벽하게 호환되며 공식적으로 지원됩니다. 성능도 테스트되었으며 Linux 성능은 NCache 윈도우에서. Docker 이미지를 사용할 수 있습니다. 프로덕션에서 완벽하게 지원되며 완벽하게 통합된 모니터링 및 관리 도구가 있습니다. 웹 관리 및 모니터링 도구 어디서든 액세스할 수 있습니다. 따라서 Windows 배포를 배포하고 관리하고 모니터링하는 것처럼 Linux 배포도 관리하고 모니터링할 수 있습니다. NCache. Linux도 지원됩니다. Redis. 따라서 생산 지원은 Redis 랩. 하늘빛 Redis Linux 버전에서도 호스팅됩니다. 따라서 공급업체 자체에서 지원합니다.
플랫폼 이후의 두 번째 측면은 다시 .NET 및 .NET Core, 기술 스택. 공식 고객이 있습니다. 우리는 그것을 구현했습니다. 우리는 그것을 완벽하게 지원하고 기능 세트가 있는 경우 이것이 이유입니다. NCache 전반적으로 호환됩니다. 따라서 온프레미스나 Azure 또는 AWS 환경을 선택하면 NCache 클라이언트는 전반적으로 사용할 수 있습니다. 그리고 변경해야 할 사항이 있으면 프로젝트뿐만 아니라 모든 것을 소유하고 있기 때문에 변경 사항을 공식적으로 제공합니다. 반면에 Redis 제XNUMX자입니다. 따라서 다른 언어의 경우 다른 언어에서 제공되는 지원도 다른 공급업체에서 제공됩니다. 따라서 기능 세트 차이가 있을 수 있습니다. 릴리스 주기 차이가 있을 수 있습니다. 따라서 클라이언트 요구 사항에 관한 한 기술적인 한 타사 클라이언트에 의존해야 합니다.
그래서 주변의 몇 가지 측면을 강조하고 싶습니다. NCache 네이티브 .NET이고 .NET Core 제품용. NCache Windows뿐만 아니라 Linux에서도 완벽하게 지원됩니다. 반면, Redis Windows에서 매우 안정적이지 않습니다. 타사 포팅 버전이고 Linux 지원을 사용할 수 있으므로 Linux 지원에 최대한 의존해야 합니다. Redis 우려됩니다. 따라서 Microsoft 기술 배경에서 오는 것은 의존해야 하는 것입니다.
캐시 성능 및 확장성
두 번째 측면은 캐시 성능입니다. 그것은 또한 매우 중요한 측면입니다.
두 제품 모두 매우 빠릅니다. NCache 과 Redis, 그러한 제품을 선택하는 주된 이유는 성능 향상 측면입니다. 우리는 데이터베이스가 느리고 확장성이 높지 않다는 것을 이미 확인했습니다. 이러한 제품은 비교적 빠르고 확장성이 뛰어납니다. 그래서 나는 아무것도 빼앗지 않을 것입니다. Redis. 다만 윈도우 버전이 안정적이지 않고 성능 문제가 있지만 리눅스 버전이 있다면 역시 빠르고 확장성이 뛰어나며 매우 빠르고 NCache 또한 매우 빠릅니다. 매우 확장 가능합니다. 우리는 매우 최적화되고 성능이 매우 강력한 TCP/IP 기반 클러스터링 프로토콜을 자체적으로 구현했습니다.
그러나 여기에도 몇 가지 차이점이 있습니다. 이내에 NCache 우리는 많은 성능 향상 기능을 가지고 있습니다. 우리는 최근 웨비나를 진행하여 개선할 수 있는 XNUMX가지 방법을 다뤘습니다. NCache 성능. 설정하면 NCache 기본적으로 매우 우수한 성능을 제공하지만 사용 사례에 따라 다양한 기능을 활성화하고 성능을 더욱 향상시킬 수 있으며 이러한 기능 중 하나가 클라이언트 캐시입니다.
NCache: 클라이언트 캐시(캐시 근처)
클라이언트 캐시는 NCache. Redis 이 기능이 없습니다.
이는 클라이언트 측 로컬 캐시로, 애플리케이션 프로세스 내에서 InProc 복사본을 가질 수 있는 서버리스 애플리케이션에서도 가능하며 서버 기반 애플리케이션의 경우 프로세스 외 클라이언트 캐시를 사용할 수 있습니다. 여기서 아이디어는 네트워크를 통해 캐시 클러스터로의 비싼 여행을 절약할 수 있다는 것입니다. 이 캐시는 이미 백엔드 데이터 소스로의 이동을 저장하고 있었습니다. 이제 그 사이에 캐시를 두고 캐시에 100개의 항목이 있다고 가정할 수 있습니다. 응용 프로그램 측에서 일부 항목을 제공한 경우 10개 항목이 있다고 가정해 보겠습니다. 이 10개 항목은 자동으로 클라이언트 캐시로 다시 가져와 다음에 응용 프로그램이 해당 데이터를 응용 프로그램에 더 가깝게 찾을 수 있으므로 결과적으로 비용이 많이 드는 네트워크 이동을 절약할 수 있습니다.
그리고 이것은 동기화된 클라이언트 캐시입니다. 동기화는 다음에서 관리합니다. NCache. 변경 사항 클라이언트 캐시 마스터 복사본이기 때문에 서버 캐시에 많이 전파됩니다. 이것은 데이터의 하위 집합이며 해당 변경 사항은 다른 클라이언트 캐시에도 전파됩니다. 참조 데이터 시나리오가 있는 경우. 읽기와 쓰기가 많은 경우 클라이언트 캐시를 켜고 데이터베이스에 대해 실행 중인 캐시와 비교하여 매우 우수한 성능을 제공하는 것이 좋습니다.
우리는 최근 고객 중 한 명, 더 큰 고객 중 한 명과 POC를 수행했습니다. 기본 구성으로 약 46초가 소요되는 워크플로가 있는 경우. 그들은 무리를 만들고 있었다 NCache 호출 및 데이터 검색. 따라서 주로 읽기 집약적인 사용 사례였습니다. 프로세스 외부에서 클라이언트 캐시를 켰습니다. 두 가지 방법이 있습니다. 별도의 캐시 프로세스가 응용 프로그램 상자에서 실행됨을 의미하는 프로세스를 유지하거나 클라이언트 캐시가 응용 프로그램 프로세스 내에서 실행되는 InProc을 가질 수 있습니다. InProc에는 통신 오버헤드를 처리하기 위한 직렬화 또는 프로세스가 없습니다. 따라서 매우 빠릅니다. OutProc과 비교해도 더 빠릅니다. 따라서 해당 고객의 경우 작업 흐름을 시작하는 데 약 46초가 걸렸습니다. 그런 다음 프로세스 클라이언트 캐시를 켜고 3~4초로 줄인 다음 InProc 클라이언트 캐시를 켜고 이 모든 작업을 400~500밀리초 내에 달성할 수 있었습니다. 46초에서 400에서 500밀리초로, 이것이 바로 우리가 말하는 개선 사항이며 이 기능은 다른 제품이나 다른 버전에서는 전혀 사용할 수 없습니다. Redis를 포함한 Redis 오픈 소스 프로젝트 및 Azure를 포함한 랩 Redis.
따라서 클라이언트 캐시를 사용하여 성능을 조정할 수 있으며 코드 변경 작업이 필요하지 않습니다. 켜는 구성일 뿐입니다.
대량 작업은 양쪽 모두에서 지원되지만 NCache 우리의 대량 작업은 전체 캐시 클러스터에서 작동합니다. 즉, XNUMX개의 서버가 있고 완전히 분산된 데이터가 있는 경우 대량 호출은 모든 서버에서 데이터를 가져오고 통합된 결과를 검색합니다. 따라서 모든 것이 서로 조합되어 결과를 공식화한 다음 본질적으로 완전한 결과를 얻습니다. 반면 Redis 대량 작업은 샤드 수준에 있습니다. 따라서 주어진 샤드에서 데이터를 처리해야 합니다. 그래서 그것이 한계입니다. 가지고 있는 경우 캐시 클러스터에 여러 노드가 있고 사용 가능한 마스터 샤드가 있으므로 지정된 샤드에서 대량 작업을 수행할 수 있습니다.
그래서 그것이 한계입니다. 그렇지 않으면 개별 요청에 대해 앞뒤로 이동하는 대신 큰 요청을 보내고 모든 데이터를 한 번에 가져와 결과적으로 성능을 입증하는 좋은 성능 개선 기능입니다.
직렬화는 또 다른 기능이며 대부분의 시간이 데이터를 직렬화 및 역직렬화하는 데 소비되기 때문에 또 다른 측면이 있습니다. NCache 뿐만 아니라 Redis. 기본적으로 두 제품 모두 직렬화 및 역직렬화되지만 NCache 직렬화 및 역직렬화 오버헤드를 개선하는 방법이 있습니다. 우리는 일반적으로 응용 프로그램에 걸리는 직렬화 시간을 최적화하는 빠르고 복잡한 직렬화를 가지고 있습니다. 개체가 복잡해집니다. 따라서 코드를 변경하지 않고 압축 유형으로 정의할 수 있으며 NCache 런타임에 압축 직렬화를 실행하고 직렬화 및 역직렬화 오버헤드를 개선합니다.
마지막으로 압축 기능도 있습니다. 압축은 클라이언트 측에서 수행됩니다. 일반적으로 더 큰 개체, 예를 들어 2MB, 3MB 또는 500킬로바이트를 다루는 경우 더 큰 개체입니다. 따라서 일반적으로 작은 개체를 처리하는 것을 권장하지만 큰 개체가 있을 경우 네트워크 사용량이 많아져 성능도 저하됩니다. 와 함께 NCache 압축을 켤 수 있습니다. 이는 코드 변경 없음 옵션으로, Redis 캐시에 추가하는 동안 항목을 자동으로 압축합니다. 따라서 더 작은 개체가 추가되고 응용 프로그램과 캐시 간에 전송되고 이동하며 유사하게 동일한 더 작은 개체가 응용 프로그램 끝에서도 다시 검색됩니다. 더 작은 페이로드를 처리하면 애플리케이션 성능이 향상됩니다. 따라서 압축을 켜면 전체 응용 프로그램 성능이 향상됩니다.
따라서 100KB보다 큰 개체를 권장합니다. 예를 들어 반드시 압축을 켜야 하며 활성화할 수 있는 임계값이 있으며 더 큰 개체만 압축되고 작은 개체는 그대로 유지됩니다.
따라서 이러한 모든 성능 향상 기능, 클라이언트 캐시, 대량 작업, 압축 직렬화, 압축을 사용할 수 없거나 Redis. 예를 들어 클라이언트 캐시를 사용할 수 없습니다. 대량 작업이 가능하지만 제한적입니다. 직렬화 최적화 옵션이 없으며 압축을 사용할 수 없습니다. 그래서, 그것은 당신이 사이에 분명한 차이점이있는 곳입니다 NCache 과 Redis어디로 NCache 많은 성능 중심 기능이 내장된 완전한 패키지입니다.
고 가용성
다음 세그먼트는 고가용성입니다. NCache 과 Redis. 고가용성은 이러한 부분을 비교할 수 있는 또 다른 측면입니다. 미션 크리티컬 애플리케이션의 경우 이는 소스가 필요한 매우 중요한 측면입니다. 이제 일반적으로 데이터베이스에 있는 데이터를 가져오고 데이터베이스 내에서 일종의 미러링, 일종의 백업이 있을 것입니다. 맞습니까?
따라서 분산 캐시인 제품에서 데이터를 이동하면 성능이 향상되지만 확장성이 매우 높지만 고가용성이 매우 중요한 측면입니다. 미션 크리티컬 애플리케이션의 경우 중단 시간은 허용되지 않습니다. 비즈니스에 영향을 미치고 사용자 경험에 영향을 미칠 수 있습니다. 그래서 저렴하지 않습니다. 따라서 애플리케이션이 데이터가 존재하는 캐시에서 항상 응답을 받을 수 있는 것이 매우 중요합니다. 따라서 여기에는 엄청난 기능 차이가 있습니다.
캐시 클러스터
NCache 100% PXNUMXP 아키텍처 캐시 클러스터입니다.
역동적이고 자가 치유가 가능하며 어떻게 작동하는지에 대해 이야기하겠습니다. Redis 마스터/슬레이브를 사용합니다. 따라서 피어 투 피어 아키텍처가 되는 것입니다. NCache 서버를 자동으로 추가 및 제거할 수 있으며 애플리케이션에 원활하게 연결됩니다. 계속해서 필요한 만큼 서버를 추가할 수 있습니다. 예를 들어, 2개의 서버로 시작했습니다. 이제 세 번째 서버를 추가하고 싶으면 즉시 수행할 수 있습니다. 캐시 또는 해당 캐시에 연결된 클라이언트 애플리케이션을 중지할 필요가 없습니다. 원활한 경험이 관찰됩니다. 따라서 고가용성 및 데이터 안정성 기능을 통해 애플리케이션이 다운타임이나 데이터 손실 없이 계속 작동할 수 있습니다. 반면에 Redis 새 샤드를 자동으로 추가할 수 없습니다. 자동 데이터 재조정이 없기 때문입니다. 이것이 캐시 클러스터의 동적 특성의 핵심입니다. 이내에 NCache, 새 서버를 추가하려는 경우 데이터 균형을 자동으로 재조정합니다.
따라서 두 가지 시나리오가 있습니다. 새 서버를 추가하여 용량을 늘리고 확장성을 높이는 시나리오와 서버를 중단시키는 시나리오가 있습니다.
따라서 먼저 노드가 추가되는 시나리오를 다루겠습니다. 새 노드가 결합됩니다. 와 함께 NCache, 데이터가 자동으로 배포됩니다.
예를 들어 서버가 2개에서 3개일 때 2개를 더 추가하면 여기에 6개의 항목이 있고 다른 서버를 추가하면 기존 데이터가 전송될 서버가 새로 추가된 서버로 균형이 맞춰집니다. 따라서 해당 서버는 기존 서버에서 데이터 청크를 가져와 자동으로 수행됩니다. 본질적으로 역동적입니다. 따라서 자동 데이터 재조정이 발생합니다. 와 함께 Redis, 이는 데이터의 수동 재조정이며 이는 Azure에 해당됩니다. Redis Azure에서 사용할 수 있는 계층 집합이 다르기 때문입니다. 기본이 있고 중급이 있고 고급이 있습니다. 클러스터링은 여기에서 고급으로만 작동하며, 이는 또한 비용이 많이 들고 그 위에 최소 3개의 서버가 필요하며 이는 다시 제한 사항입니다.
와 NCache 단 2대의 서버로 클러스터링을 완전히 가동하고 실행할 수도 있으며 그 위에 새 서버를 추가하려면 수동 데이터 재조정이 필요합니다. 그것은 큰 문제입니다. 따라서 애플리케이션과 용량 추가를 계획할 때 일종의 제한이 있을 수 있습니다. 반면에 NCache 런타임에 이를 달성할 수 있습니다. 즉석에서 더 많은 서버를 추가할 수 있습니다.
두 번째 측면은 서버가 다운되는 것입니다. 따라서 우리는 Redis 우리는 마스터와 슬레이브 개념을 가지고 있습니다. 마스터는 데이터를 슬레이브에 복제합니다. 노예 조각이 있습니다. 따라서 마스터는 데이터를 복제해야 하며 동기화 또는 비동기 방식일 수 있습니다. ~ 안에 Redis, 슬레이브 샤드가 다운되면 마스터 자체가 중지되어 클러스터를 사용할 수 없게 됩니다. 그래서 그것은 큰 문제이며 항상 일어날 수 있습니다. 오픈 소스가 있는 온프레미스 배포 또는 Redis 실험실 배치 Redis. 이 경우 서버가 다운되고 마스터 샤드의 슬레이브가 되면 클러스터 자체를 사용할 수 없게 됩니다. 따라서 해당 시나리오에서 복구하려면 참여하고 수동 개입을 수행해야 합니다. 반면에 NCache 자동입니다. 따라서 모든 서버가 다운될 수 있고 살아남은 노드는 활성화되거나 백업될 수 있습니다.
예를 들어, 이 서버는 다운되고 이것은 활성 파티션이며 백업 파티션도 있습니다. 이 전체 서버가 다운되면 백업이 활성화됩니다. 백업 파티션이 활성 상태로 승격되고 살아남은 노드에서 모든 데이터를 가져오며 여기에 내장된 연결 장애 조치가 있습니다. 클라이언트가 다운되는 모든 서버는 런타임에 이를 감지하고 살아남은 노드로 결정하고 장애 조치할 것입니다. 여기에서 이러한 개념을 강화하고 싶습니다. Redis 최소 3개의 서버가 필요합니다. 이것이 다수결의 개념입니다. 클러스터 조정자는 선거에서 승리해야 합니다. 의 경우는 그렇지 않습니다 NCache. 단 2개의 노드로 완전히 작동하는 캐시 클러스터를 시작할 수 있으며 완전한 고가용성 기능을 제공합니다. 모든 서버가 다운되고 살아남은 노드는 문제 없이 완벽하게 작동할 수 있습니다. Redis.
동적 구성. 런타임에 클러스터 구성을 변경할 수 있으며 여기에는 새 서버 추가, 서버 제거 또는 캐시 클러스터의 일부 설정 변경이 포함됩니다. 이는 중지하지 않고 런타임에 전체 크래시 클러스터에 적용할 수 있는 것입니다. 반면에 Redis, 제한적입니다. 수동으로 적용해야 하는 구성이 많고 다음에서 사용할 수 있는 많은 클러스터 상태 이벤트가 있습니다. NCache 구독할 수 있습니다. 그 위에 모니터링 및 관리 도구를 사용할 수 있습니다. 반면, Redis 해당 기능이 없습니다.
따라서 이것은 매우 중요한 개념입니다. 요약하겠습니다. 서버 추가 및 제거 Redis 그것은 당신에게 많은 문제를 줄 것입니다. 데이터 추가는 자동으로 재조정되지 않습니다. 따라서 XNUMX% PXNUMXP 아키텍처가 아닙니다. 따라서 캐시 클러스터는 용량이 제한됩니다. 마찬가지로 슬레이브 샤드가 다운되면 클러스터 자체를 사용할 수 없게 됩니다. 이제 수동으로 관리해야 하는 배포 문제가 있기 때문입니다. 장애 조치도 수동입니다. 따라서 서버가 다운되면 수동으로 장애 조치하고 생존 노드를 사용하여 시작해야 합니다. 새 서버를 추가하는 경우 새로 추가된 서버로 수동으로 전환해야 합니다.
따라서 이것이 여러분이 가질 수 있는 모든 제한 사항이며 이러한 특성의 프로덕션 배포를 사용하는 것을 보면 놀랄 것입니다. 이제 용량을 늘리거나 유지 관리를 위해 서버를 중단해야 합니다. 따라서 다음과 같은 제품으로는 매우 어려울 것입니다. Redis. 이므로, NCache 원활한 경험을 제공합니다. 아무 것도 영향을 주지 않고 즉시 서버를 추가하거나 제거할 수 있습니다.
동적 파티션/샤드
이제 클러스터 내의 또 다른 개념은 자가 치유 메커니즘입니다.
NCache 동적 파티션이 있습니다. 더 많은 서버를 추가하면 데이터가 redis공물, 새 파티션은 런타임에 공식화됩니다. 마찬가지로 서버를 중단하면 클러스터가 백업을 사용 가능하게 만들고 자체적으로 복구하고 2개에서 3개로 중단한 다음 안정성 측면에서 건강한 2개 노드 캐시 클러스터를 공식화합니다. 복제 파티션 권한이 있으며 다음에서도 사용할 수 있습니다. Redis 슬레이브의 형태로 사용되지만 고가용성은 복제에 따라 달라집니다. 그들은 가지고 있지 않습니다 Redis 슬레이브 샤드가 구성되어 있지 않으면 고가용성이 없습니다. 따라서 슬레이브 샤드를 사용할 수 있어야 합니다. 반면, NCache, 토폴로지가 있습니다.
예를 들어 마스터 샤드, 마스터 파티션이 있는 파티션된 캐시가 있습니다. 이 서버가 다운되더라도 클라이언트가 이를 감지하고 장애 조치하고 생존 노드를 사용하기 시작하기 때문에 여전히 고가용성을 유지할 수 있습니다. 그들은 데이터 손실이 있을 것이고 그것은 사실입니다 Redis 또한. 복제가 없기 때문에 데이터 손실이 있지만 여전히 가용성이 높으며 복제 지원도 제공하는 개선 사항이 있습니다. 이 서버가 다운되면 서버 백업이 가능할 뿐만 아니라 클라이언트가 자동으로 장애 조치됩니다. 그래서, Redis 제한됩니다. 고가용성은 복제에 따라 달라집니다. 제한 요인이기도 한 복제가 켜져 있지 않으면 가용성이 높지 않습니다.
그런 다음 수동 개입이 필요하지 않지만 자가 치유 메커니즘이 있습니다.
3개의 서버로 시작하면 서버를 다운시키고 활성 파티션, 마스터를 사용하고 다른 서버의 슬레이브도 잃게 됩니다. 따라서 이 경우 서버 3의 백업이 서버 1에 있었으므로 이것이 활성화됩니다. 런타임에 활성 파티션에 결합됩니다. 개입이 필요하지 않습니다. 수동 작업이 필요하고 파티션 서버 2는 서버 1에서 정상 파티션을 구성합니다. 따라서 클러스터는 자동으로 자체 복구되며 이것이 동적 특성입니다. NCache 비교해서 Redis. 어디에 Redis, 샤드는 런타임 시 재조정할 수 없습니다. 슬레이브 샤드가 다운되면 클러스터가 중지됩니다. 자료 redis분배는 역동적이지 않습니다. 고가용성은 다음과 같은 경우가 아닌 복제에 의존합니다. NCache. NCache 복제 없이도 고가용성을 제공합니다.
그래서 당신이 얻을 수 있는 이 모든 혜택은 NCache, 완전히 누락되었거나 기능이 제한되어 있기 때문에 훨씬 더 우수한 제품입니다. Redis 이는 Azure에 해당됩니다. Redis. 이는 오픈 소스의 경우에도 마찬가지입니다. 이는 매우 유사한 제품이기 때문입니다. Redis 실험실 Redis 제공도 합니다.
NCache Rescale과 함께 비즈니스를 가속화하는 방법에 대해 알아보세요.
이제 실제 제품을 보여드리는 데 시간을 할애할 것입니다. NCache 구성됩니다. 이것이 우리의 데모 환경입니다. 나는 그것으로 작업했습니다. 그래서 그냥 새 캐시를 만들겠습니다. 이것은 함께 설치되는 웹 관리 도구입니다. NCache. 직렬화 모드는 바이너리 또는 JSON일 수 있습니다. 전적으로 귀하에게 달려 있습니다. 캐시에 이름을 지정하고 캐시 클러스터를 생성하고 클라이언트 애플리케이션을 연결하고 이를 모니터링 및 관리하는 방법을 보여드리겠습니다.
따라서 이 웨비나의 주요 초점은 NCache 대 Redis, 그래서 모든 세부 사항을 간단하게 유지하겠습니다. Partitioned Replica는 가장 권장되는 토폴로지입니다. 활성 및 백업 간의 비동기 복제. 따라서 동기화를 선택할 수 있습니다. 비동기가 더 빠르므로 함께 가겠습니다. 캐시 클러스터의 크기입니다. 그런 다음 이러한 서버 노드를 지정하겠습니다. NCache 이미 설치되어 있습니다. TCP 포트. NCache TCP/IP 기반 통신 프로토콜입니다. 따라서 모든 것을 단순하게 유지하고 여기에서 축출을 활성화하여 캐시가 가득 차도록 하겠습니다. 따라서 캐시에서 일부 항목을 자동으로 제거하고 결과적으로 새 항목을 위한 공간을 만듭니다. 이 캐시를 시작하고 완료하십시오. 서비스 시작 시 자동으로 시작되므로 서버가 재부팅될 때마다 자동으로 캐시 클러스터에 연결됩니다. 이것이 바로 캐시 클러스터를 구성하고 사용하는 것이 얼마나 간단한지입니다. 다음에 보여드리겠습니다.
클라우드 지원(Azure 및 AWS)
따라서 우리의 관리형 서비스 모델이 등장하고 있습니다. 우리의 다음 릴리스는 앞으로 XNUMX~XNUMX주가 걸릴 것으로 생각되는 것에 초점을 맞추고 있습니다. 따라서 우리는 완전히 관리되는 NCache Azure 및 AWS의 서비스 모델로서의 소프트웨어.
지금은 VM 모델이 될 것입니다. 온프레미스가 있는 경우 물리적 또는 VM 상자를 사용할 수 있습니다. Azure를 선택하는 경우 마켓플레이스를 통해 VM을 설정하거나 VM을 설정한 다음 설치할 수 있습니다. NCache 당사 웹 사이트에서 다운로드하여 소프트웨어. 그리고 컨테이너화된 환경도 있습니다. Docker 이미지가 있으며 Azure Kubernetes Service, EKS - Elastic Kubernetes Service 및 기타(예: OpenShift Kubernetes 플랫폼)에서 완벽하게 지원됩니다. NCache 이미 해당 플랫폼에서 완벽하게 통합되고 완벽하게 지원됩니다. 관리되는 측면에 관한 한, 그것은 다가오고 있는 것입니다. 따라서 지금부터 XNUMX~XNUMX주가 지나면 완전히 사용할 수 있게 됩니다.
그래서 perfmon 카운터인 통계 창과 이러한 모니터링 옵션을 사용할 수 있는 방식을 보여 드리겠습니다. NCache, 측면에서 NCache Windows뿐만 아니라 Linux 환경에서도 마찬가지죠?
그래서 저는 스트레스 테스트 도구를 실행할 것입니다. 다른 캐시에 대해 이미 실행 중인 것이 있다고 생각합니다. 계속해서 하나 더 실행하면 캐시 클러스터의 더미 로드를 시뮬레이트합니다. 이름을 지정하기만 하면 구성 파일을 사용하여 서버를 자동으로 검색하고 연결하기만 하면 됩니다.
따라서 완전히 연결된 클러스터 상태, 처리량을 보여주는 초당 요청 수, 캐시 작업당 평균 마이크로초의 대기 시간, 추가, 가져오기, 업데이트, 삭제, 캐시 크기, CPU, 메모리가 있습니다. 따라서 중앙 집중식 모니터링 보기를 얻을 수 있습니다. 이 도구를 사용할 수 있습니다. Windows perfmon을 사용할 수도 있습니다.
Linux 기반의 경우 맞춤형 모니터링이 있습니다. 따라서 Linux 서버용 모니터링 도구를 직접 사용할 수 있으며 모니터링을 위해 타사 도구를 사용할 수도 있습니다. NCache 또한. 지금까지 캐시 생성 프로세스를 간략히 살펴보았습니다. 일부 모니터링 및 관리 측면.
그래서 돌아옵니다. 우리는 몇 가지 세부 사항을 논의하기 때문에. 다음으로 논의하고 싶은 것은 클라우드 오퍼링/클라우드 지원입니다. 지금 Redis 관리되지 않는 캐시를 선택할 수도 있고 관리되는 캐시를 선택할 수도 있습니다. 그런 다음 사용할 수 있는 호스팅 서비스가 있고 관리 옵션은 타사 공급업체에서 제공합니다. 호스팅 옵션은 Azure에서 제공됩니다. Redis의 오픈 소스 변형을 가질 수 있습니다. Redis Microsoft에서 사용자 지정했으며 호스팅된 모델로 사용할 수 있습니다. 반면에 NCache 측면에는 캐시 서버 모델, VM 모델이 있습니다. 이미 컨테이너 접근 방식에 대해 논의했습니다. Windows 및 Linux 컨테이너와 완벽하게 호환됩니다. Windows 컨테이너용 Azure Service Fabric, 마이크로 서비스 아키텍처 세부 정보에 대한 비디오 데모가 있습니다. Linux 컨테이너를 사용하는 Azure Kubernetes Service가 있습니다. EKS – Elastic Kubernetes Service 그리고 쿠버네티스를 통해 Red Hat OpenShift 컨테이너도 수행했다고 생각합니다.
따라서 그것들은 모두 사용 가능한 컨테이너 배포 옵션이며 유연합니다. 플랫폼은 특정 플랫폼이 아닙니다. 따라서 아무 문제 없이 모든 종류의 컨테이너화된 플랫폼에 배포할 수 있습니다. 관리형 서비스가 출시될 예정이므로 이미 논의했습니다. 그래서, 그것은 어딘가에 NCache 서비스를 관리했을 것이지만 그것은 우리의 다음 버전에 있습니다.
한 가지 중요한 측면은 서비스 대신 VM에 연결해야 하지만 모든 것을 제어할 수 있지만 VM 모델 사용의 이점입니다. 다음에 다룰 서버 측 코드를 실행할 수 있지만 가장 중요한 측면은 성능 측면입니다. 우리는 이미 내부에 많은 성능 기능이 있다는 것을 논의했습니다. NCache에서 누락된 Redis. Azure를 사용하기로 선택한 경우 Redis, Azure 인프라에 연결해야 합니다. 따라서 이들은 별도의 가상 네트워크에서 실행되는 VM입니다. 이들은 근처에 있지만 다시 멀리 떨어져 있습니다. Microsoft Azure에 있고 모든 애플리케이션 배포가 있는 자체 가상 네트워크와는 다릅니다.
와 NCache 당신은 우리를 선택할 수 있습니다 NCache 애플리케이션 가상 네트워크와 동일한 가상 네트워크에 배포합니다. 예를 들어 앱 서비스, Azure 웹 사이트, Azure Microservices는 Azure 가상 네트워크에서 실행됩니다. 동일한 가상 네트워크에 Azure VM을 배포하고 애플리케이션 성능을 향상하도록 선택할 수 있습니다. 실험실 내 자체 테스트를 기반으로, NCache 의 SaaS 모델보다 XNUMX~XNUMX배 더 빠릅니다. Redis 일반적으로 Microsoft Azure에서 얻을 수 있습니다. 그래서 그것은 제가 강조하고 싶은 매우 중요한 측면입니다.
게다가 VM에 대한 많은 제어권을 얻을 수 있습니다. 캐시 시작, 크기 증가, 전체 용량 확보에 대한 완전한 제어 권한이 있습니다. 요청 단위에 제한이 없고 크기에 제한이 없으며 사용 공간이 없으며 그 일부로 비용이 청구되지 않습니다. 자신의 라이선스를 가져오고 영구적일 수도 있고 구독 라이선스일 수도 있으며 라이선스 측면에서 매우 유연할 수 있습니다. 그 위에 서버 측 코드를 실행할 수 있습니다. NCache 서버. 이를 완벽하게 관리할 수 있습니다. 이를 완전히 최적화할 수 있습니다. 많은 인터페이스를 작성할 수 있습니다. read-through, write-through, write-behind, 캐시 로더 및 MapReduce, Aggregator, Entry 프로세서와 같은 일부 컴퓨팅 그리드 기능과 같은 기능은 다음을 통해서만 가능합니다. NCache. 이러한 모든 제품을 사용할 수 있는 호스팅 모델인 SaaS 모델도 있습니다. Redis. 이것이 우리 플랫폼입니다.
캐시를 최신 상태로 유지
다음 세그먼트, 다음 15분 동안 저는 기능 수준 비교에 소비할 것이며 이를 위해 일부 세그먼트를 정의했습니다. 따라서 캐시를 최신 상태로 유지해야 하는 경우 시작하겠습니다. 이는 매우 중요합니다. 애플리케이션 사용 사례와 관련하여 특히 백엔드 데이터 소스와 관련하여 캐시를 최신 상태로 유지하는 방법에 대한 별도의 웹 세미나가 있어야 합니다.
그래서 비교해보면 Redis, 알잖아, NCache 이쪽에도 많은 기능이 있습니다.
우리는 절대적이고 슬라이딩적인 시간축 만료를 가지고 있지만 자동 재로드 메커니즘도 사용할 수 있습니다. Redis 재로드 메커니즘 없이 절대 및 슬라이딩 만료만 있습니다. 다시 로드하기 위해 서버 측 코드인 read-through 핸들러라는 인터페이스를 구현할 수 있습니다. 다시 말하지만, 가능하기 때문에 NCache VM에 대한 전체 액세스 권한을 부여할 수 있습니다. NCache 호스팅됩니다. 따라서 서버 측 코드를 NCache 사용 NCache 백업할 수 있는 계산 능력.
캐시를 데이터베이스와 동기화할 수 있습니다. NCache 데이터베이스 동기화에 매우 강력합니다. SQL 종속성이 있습니다. DB만 준수하는 DB 종속성이 있습니다. .NET CLR 저장 프로시저가 있습니다. 따라서 이러한 모든 기능을 통해 캐시를 데이터베이스와 동기화할 수 있습니다. 여기에서 아이디어는 데이터베이스에 변경 사항이 있고 데이터베이스의 레코드가 변경되고 해당 레코드가 캐시된 경우 이 두 소스가 동기화되지 않을 수 있다는 것입니다. 그래서, NCache, 데이터베이스에 변경 사항이 있는 경우 해당 데이터를 자동으로 무효화하거나 다시 로드할 수 있습니다. NCache 런타임에. 이것은 고유의 기능입니다. NCache. 다른 제품에는 이 기능이 없습니다. 따라서 백엔드 데이터베이스와 완전히 동기화된 캐시를 가질 수 있으며 이는 관계형 데이터베이스에만 해당되는 것이 아니라 비관계형 데이터 소스 측면에도 기능이 있습니다.
파일 종속성은 파일에 종속된 항목을 만들 수 있는 또 다른 기능입니다. 파일 내용, 내용이 변경되면 항목이 자동으로 제거되거나 다시 로드됩니다. 그리고 사용자 지정 종속성은 모든 소스에서 사용할 수 있습니다. 그것은 NoSQL database, 파일 시스템 또는 관계형, 모든 커넥터, 모든 웹 서비스가 될 수 있습니다. 따라서 유연한 요구 사항에 따라 검증된 항목을 만들 수 있습니다. Cosmos DB를 사용하여 이 종속성을 구현했습니다. 그래서 동기화를 구현했습니다. NCache 코스모스DB와 함께 당신이 사용하는 경우 NCache 코스모스 DB와 함께 사용자 지정 종속성을 사용할 수 있으며 이에 대한 웨비나도 수행한 것 같습니다.
관계형 데이터 처리. 따라서 관계형 데이터에는 관계가 있습니다. 캐시의 항목은 키 값 쌍이므로 다른 항목 간의 관계를 만들 수 있으며 이는 사용할 수 없는 항목입니다. Redis 옆. 따라서 별도의 장점에 따라 항목을 처리해야 합니다. 반면에 NCache 항목을 일대일, 일대다 또는 다대다 그룹으로 결합할 수 있습니다. 상위 항목이 변경되면 하위 항목은 필요에 따라 자동으로 무효화되거나 다시 로드될 수 있습니다.
데이터 그룹화, SQL 및 LINQ 검색
또 다른 측면은 데이터 그룹화 및 검색입니다. NCache 매우 강하고 & Redis 아무런 기능이 없습니다. 그리고 이것은 Azure의 경우에도 마찬가지입니다. Redis 어쨌든 매우 제한적입니다. 오픈 소스 Redis 약간 앞서 있지만 여전히 기능면에서 제한적입니다. 심지어 Redis Lab의 상용 버전 Redis, 이러한 기능을 갖추고 있지 않습니다.
SQL 검색이 가능합니다. 내에서 항목을 검색할 수 있습니다. NCache 개체 속성을 기반으로 합니다. 개체가 캐시에 추가됩니다. 속성에 대한 인덱스를 정의할 수 있습니다. 예를 들어, 제품은 ID, 가격, 범주에 대한 인덱스에 있을 수 있으며 이제 이러한 속성을 사용하여 해당 제품에 대한 검색을 실행할 수 있습니다. 전형적인 예는 제품 도트 카테고리가 무언가이거나 제품 도트 가격이 10보다 크고 제품 도트 가격이 100보다 작은 제품을 선택하는 것입니다. NCache 모든 서버에서 모든 항목에 대해 메모리 내 검색을 실행하고 결과를 통합하고 결과 집합을 다시 가져옵니다. 따라서 더 이상 키를 다룰 필요가 없습니다. 기준에 따라 데이터를 검색합니다.
LINQ 검색도 가능합니다. 우리는 .NET과 .NET Core 앱. LINQ 검색을 사용하는 경우 다음에서 LINQ 검색을 실행할 수 있습니다. NCache 또한. 그래서 그것은 독특한 기능입니다 NCache 어디에 Redis 지원이 없습니다. Redis 어떤, 모든 맛 Redis, 이 지원이 없습니다.
그룹, 하위 그룹을 가질 수 있습니다. 내부에서 논리적으로 컬렉션을 만들 수 있습니다. NCache. 다음에서 사용할 수 없습니다. Redis 해당 그룹을 기반으로 데이터를 검색, 업데이트 및 제거할 수 있습니다.
태그 및 명명된 태그는 속성이 지정될 수 있습니다. 예를 들어 항목에 첨부할 수 있는 키워드를 사용할 수 있습니다. 일반적인 예는 고객 태그로 모든 고객을 태그할 수 있다는 것입니다. 주문 태그가 있는 모든 주문과 특정 고객의 주문도 태그로 고객 ID를 붙일 수 있습니다. 주문이 필요할 때 get by tag라고 말하고 주문을 태그로 제공하면 모든 주문을 받을 수 있습니다. 특정 고객의 주문이 필요할 때 get by any tag 또는 get by tag라고 말하고 고객 ID를 제공하면 해당 고객 ID에 대해서만 모든 주문을 받을 수 있습니다. 따라서 태그와 명명된 태그를 유연하게 사용할 수 있습니다. NCache. Redis 이것들을 지원하지 않습니다.
서버측 .NET 코드
우리는 일반적으로 캐시 배제 패턴을 사용한다는 점에 대해 이미 논의했습니다. 먼저 캐시에서 데이터를 확인하고, 캐시에서 데이터를 찾으면 반환하고, 캐시에서 데이터를 찾지 못하면 애플리케이션의 백엔드 데이터베이스로 이동한 다음 해당 데이터를 가져와서 캐시로 가져옵니다. 따라서 null이 있고 null을 검색한 다음 데이터베이스로 이동합니다. Read-Thru 핸들러를 사용하여 이를 자동화할 수 있습니다. 그것은 당신의 컴퓨터에서 실행되는 서버측 코드입니다. NCache 서버. 관리형 서비스에도 이 기능이 있습니다. 따라서 모든 데이터 소스에 연결할 수 있는 이 인터페이스를 구현합니다. 웹 서비스일 수도 있고 관계형 데이터 소스 또는 비관계형 데이터 소스일 수도 있으며 캐시에서 null이 발견되는 즉시 호출되는 여러 메서드가 있습니다.
따라서 Cache.Get 메서드를 호출하고 Read-Thru 플래그를 활성화합니다. 항목이 캐시에 없으면 호출이 Read-Thru 핸들러로 전달되고 결과적으로 해당 핸들러 코드를 통해 백엔드 데이터베이스에서 데이터를 가져옵니다. 실행 중인 사용자 코드는 무엇입니까 NCache 서버 측. 따라서 원활하게 진행할 수 있습니다. NCache 필요한 데이터를 얻을 수 있습니다.
연속 기입(Write-through)은 그것의 반대이며 또한 지원되며 Redis 에는 캐시에서 무언가를 업데이트할 수 있는 기능이 없으며 이제 데이터베이스를 업데이트하려는 경우 write-through 핸들러를 호출하여 데이터베이스를 업데이트할 수 있습니다. 이 write-through 핸들러를 구현하고 등록하고 NCache 백엔드 데이터베이스를 업데이트하기 위해 호출하고 write-behind는 그 반대입니다. 캐시에 대한 모든 업데이트, 클라이언트 애플리케이션 반환 및 NCache 뒤에서 백엔드 데이터베이스를 비동기식으로 업데이트합니다. 그래서, NCache 데이터베이스에 대한 쓰기 작업의 성능을 향상시킬 수도 있습니다. Redis 또는 서버 측 코드를 실행할 수 없는 경우 다른 제품. 그리고 이것은 순전히 네이티브 .NET이며 .NET Core 인터페이스를 통해 읽기 및 쓰기로 구현 및 등록할 수 있는 클래스 라이브러리. NCache.
캐시 로더는 또 다른 기능입니다. 인터페이스를 구현하고 등록하여 캐시를 미리 채울 수 있는 위치 NCache. 따라서 캐시를 다시 시작할 때마다 일부 중요한 데이터를 내부에 자동으로 로드합니다. NCache 이것은 모든 서버에서 동시에 실행됩니다. 그래서 초고속입니다. 따라서 모든 데이터를 미리 채울 수 있으며 다시는 데이터베이스로 이동할 필요가 없습니다. 데이터를 미리 로드했기 때문에 항상 해당 데이터를 찾을 수 있습니다.
사용자 지정 종속성, 엔트리 프로세서, 이들은 다시 고유한 기능입니다. NCache 그리고 이러한 기능을 사용할 수 없는 주된 이유. 가장 먼저, Redis 이러한 기능이 없으며 모듈은 Azure에서 지원되지 않습니다. Redis 또는 오픈 소스에서도 Redis. 서버 측, Azure에서는 코드가 불가능합니다. Redis. 주로 기본 VM에 대한 액세스 권한이 없기 때문에 이전에 언급한 주된 이유였습니다. NCache 현재 VM 모델에서 배포 위치, 제어 방법, 관리 방법에 대한 전체 액세스 권한이 있습니다. 그래서, 당신은 모든 권한을 가지고 있습니다. 블랙박스가 아니라 Redis 이다.
다중 데이터 센터를 위한 WAN 복제
좀 더 자세히 알아보고 이만 마치겠습니다. WAN 복제는 또 다른 측면입니다.
액티브-패시브는 다음에서 지원됩니다. Redis, 한 데이터 센터에서 다른 데이터 센터로 전체 데이터 센터, 캐시를 전송할 수 있습니다. ~ 안에 NCache, 능동-수동이 있습니다. 따라서 한 데이터 센터에서 다른 데이터 센터로 데이터를 단방향으로 전환합니다. 또한 두 사이트를 모두 활성화할 수 있는 매우 시급하고 매우 중요한 사용 사례인 활성-활성도 있습니다. 사이트 XNUMX의 업데이트가 사이트 XNUMX에 필요하고 그 반대도 마찬가지입니다. 그래서 그것은 능력이 아닙니다. Redis 옆. 당신은 그 능력이 없기 때문에 활성-활성 사이트를 실행할 수 없습니다. Redis. 과 NCache 이는 업데이트되는 두 사이트의 데이터가 있는 앱 데이터 캐싱 사용 사례에 해당되며 다중 사이트 세션을 통해서도 가능합니다. 그래서 그것은 또 다른 공간입니다. NCache 확실한 승자입니다.
캐시 토폴로지
그런 다음 다른 세부 사항. 캐싱 토폴로지. 우리는 캐싱 토폴로지의 거대한 목록을 가지고 있습니다. Redis.
따라서 서로 다른 사용 사례를 기반으로 미러링, 복제, 파티셔닝, 파티션 복제를 수행한 다음 이미 토론한 다음 방법에 대해 논의했습니다. NCache 클러스터링은 일반적으로 더 좋으며 클러스터링에 비해 훨씬 더 많은 옵션이 있습니다. Redis 제공합니다.
GUI 도구 - 캐시 관리 및 모니터링
그런 다음 GUI 도구가 있습니다. 여기 비교가 있습니다. 매니저, 모니터.
반면 PowerShell 도구, 덤프 및 다시 로드 도구, 전체 관리, 모니터링 측면이 내장되어 있습니다. 반면, Redis 그 전면에 국한되어 있으며 그 일부로 몇 가지 세부 정보를 보여 드렸으며 이는 Windows 및 Linux 배포에 해당됩니다. NCache.
ASP.NET 특정 기능
일부 ASP.NET 특정 캐싱 기능.
세션, 다중 사이트 세션, ASP.NET to ASP.NET Core 세션 공유가 다가오고 있습니다. 다중 사이트 ASP.NET 및 ASP.NET Core 세션을 사용할 수 있습니다. 상태 보기, 출력 캐싱. Redis 세션 만 있습니다. 이는 매우 기본적인 것입니다. NCache. 세션 잠금, 세션 공유는 NCache. 출력 캐싱은 양쪽 끝에서 지원되며 추가적으로 우리는 SignalR Backplane, ASP.NET Core 응답 캐싱. 따라서 이 모든 것이 웹 특정 캐싱 요구 사항에 대한 완전한 기능 세트를 만듭니다. 따라서 기능 세트를 자세히 검토할 수 있습니다.
이벤트와 런타임 데이터 공유
그런 다음 Pub/Sub 메시징이 있습니다.
아이템 레벨 이벤트가 있고 기준 기반 이벤트 알림 시스템도 있습니다. Redis. Pub/Sub 메시징에 대한 별도의 웨비나가 있습니다. 따라서 궁금한 점이 있으면 검토하는 것이 좋습니다. 그래서 저는 이쯤에서 결론을 내릴 것 같습니다.
타사 통합
마지막으로 타사 통합입니다.
NHibernate와 Entity Framework도 있습니다. AppFabric 래퍼를 사용할 수 있습니다. Memcached 래퍼를 사용할 수 있습니다. 따라서 이러한 제품에서 전환하는 경우 다음으로 원활하게 전환할 수 있습니다. NCache 비교해서 Redis.
보안 및 암호화
에 대한 몇 가지 세부 정보 보안 암호화 이미 정시에 도달한 것 같습니다.
결론
따라서 결론을 내리기에 좋은 시기입니다. 따라서 첫 번째는 여러분이 원할 때 언제든지 www를 방문할 수 있다는 것입니다.alachisoft.com의 엔터프라이즈 버전을 다운로드할 수 있습니다. NCache 귀하의 환경에서 어떻게 작동하는지 개인적으로 보여줄 것입니다. 따라서 웹 사이트로 바로 이동하여 Enterprise의 30일 무료 평가판을 받을 것을 권장합니다. 데모 일정을 잡는 것은 우리의 기쁨입니다. 그 외에도 이 웨비나의 녹화본을 제공할 예정입니다. 따라서 저희가 귀하에게 알려드릴 때 이메일과 소셜 미디어를 주시하십시오. 오늘 귀하의 질문에 답하지 못했고 앞으로 더 많은 질문이 있을 것이며 바로 직전에 있다면 이메일을 보내주십시오. support@alachisoft.com.
기술적인 문의 사항이 있는 경우 답변을 드릴 것이며 진행 및 지원에 관심이 있는 경우 NCache 당신의 환경에서 당신은 연락할 수 있습니다 sales@alachisoft.com 뿐만 아니라.