Redis 사전 캐시

올해 중 한 전 구글과 아마존 엔지니어가 오픈 소스 메모리 데이터 캐시 시스템 잠자리를 출시했는데, 이 시스템은 C/C++ 로 작성되어 BSL 허가로 배포되었다.

이전 벤치마크 결과에 따르면 잠자리는 세계에서 가장 빠른 메모리 스토리지 시스템일 수 있습니다. Memcached 및 Redis 프로토콜에 대한 지원을 제공하지만 런타임 시 더 높은 성능과 더 적은 메모리 소비로 쿼리할 수 있습니다. 잠자리는 Redis 에 비해 일반적인 워크로드에서 25 배 향상된 성능을 제공합니다. 잠자리 서버는 초당 수백만 개의 요청을 처리 할 수 ​​있습니다. 5GB 스토리지 테스트에서 잠자리는 Redis 보다 30% 적은 메모리를 필요로 합니다.

오픈 소스 소프트웨어로서 잠자리는 단 두 달 만에 9.2K GitHub star 와 177 개의 분기점을 얻었다. 최근 몇 년 동안 KeyDB 및 Skytable 과 같은 비슷한 Redis 호환 메모리 데이터 스토리지 시스템이 많이 등장했지만, 이처럼' 센세이션' 은 없었다. 결국, Redis 는 10 여 년 전에 태어났다. 이때 처음부터 캐시 시스템을 설계하면 역사적 부담을 버리고 자원을 더 잘 활용할 수 있다.

새롭게 부상하는 잠자리에 반격하기 위해, Redis 공동 설립자 겸 CTO 인 Yiftach Shoolman, Redis 랩 수석 설계자 Yossi Gottlieb 및 Redis 랩 성능 엔지니어인 Filipe Oliveira 는 "13 이후 Redis 에 새로운 것이 필요한지 여부" 라는 제목의 기사를 공동 발표했습니다.

문장 중, 이들은 특히 Redis 7.0 비교 잠자리의 벤치마킹 결과를 제시했고, 비교적 공평했다. Redis 의 처리량은 잠자리보다 18%-40% 높았고, Redis 의 구조에 대해 "왜 Redis 의 아키텍처가 여전히 메모리인지" 를 증명하기 위해 몇 가지 의견과 사고를 했다.

Redis 아키텍처가 여전히 동종 제품 중 최고라고 강조하지만 잠자리가 제공하는 신선하고 재미있는 아이디어와 기술을 무시할 수는 없습니다. Redis 에 따르면 이들 중 일부는 앞으로 Redis (예: io_uring, 최신 사전, 보다 전략적인 스레드 사용 등) 에 들어갈 수도 있습니다. ).

또한 Redis 에 따르면 잠자리 벤치마크 비교 방법은 "Redis 가 실제 세계에서 작동하는 방식을 대표할 수 없다" 고 합니다. 이에 대해 일부 네티즌은 Reddit 에서 반박했다.

또 이 문장 는 Redis 팀 이 예의 바르게' 잠자리 는 가장 빠른 캐시 시스템' 이라고 부인했지만, 더 많은 네티즌 은 Redis 가 이미 그들의 마케팅 부서를 대표하여 지고 문장 한 편을 보내' 반격' 을 했다고 말했다.

물론, 우리는 Redis 의 성능을 향상시키고 기능을 확장할 수 있는 혁신적인 방향을 찾고 있습니다. 하지만 여기서는 Redis 가 캐시, 데이터베이스, 그 사이의 모든 것을 포함한 최고의 실시간 메모리 데이터 스토리지 솔루션 중 하나인 이유에 대해 이야기하고 싶습니다.

다음으로 Redis 의 속도 및 아키텍처 차이에 대해 중점적으로 논의한 다음 이를 기준으로 비교합니다. 문장 마지막에 잠자리 프로젝트와의 벤치마킹 결과 및 자세한 성능 비교 정보도 제공할 예정입니다. 여러분 자신의 비교와 참고를 환영합니다.

잠자리 벤치마킹은 실제로 독립적인 단일 프로세스인 Redis 인스턴스 (하나의 코어만 사용 가능) 와 다중 스레드 잠자리 인스턴스 (가상 시스템/서버에서 사용 가능한 모든 코어를 사용 가능) 를 비교합니다. 이러한 대략적인 대비가 실제 장면에서 Redis 의 작동 상태를 나타내는 것은 아닙니다. 기술 구축자로서 Dell 은 자체 기술과 다른 시나리오 간의 차이점을 보다 정확하게 파악하고자 하므로 40 개의 파티션이 있는 Redis 7.0 클러스터의 성능을 최대 인스턴스 유형 (AWS C4GN) 과 비교하는 형평성 조정을 했습니다. 16x 크기) 잠자리 팀이 벤치마킹에 사용합니다.

이번 테스트에서 Redis 의 처리량이 잠자리보다 18% ~ 40% 높은 것으로 나타났습니다. 이는 64 개의 vCore 중 40 개에만 사용됩니다.

우리의 의견으로는, 각 멀티 스레드 프로젝트 개발자는 프로젝트를 설정하기 전에 이전 작업에서 경험한 고통에 따라 아키텍처 결정을 안내합니다. 또한 멀티 코어 장치에서 단일 Redis 프로세스 (일반적으로 수십 개의 코어와 수백 기가바이트 메모리 제공) 를 실행하는 경우 리소스를 충분히 활용할 수 없는 문제가 있음을 인정합니다. 그러나 Redis 는 디자인 초기에는 이를 고려하지 않았으며, 많은 Redis 서비스 공급업체들이 시장에서 자리를 잡을 수 있는 솔루션을 제시했습니다.

Redis 는 Redis 클러스터를 사용하여 여러 프로세스를 실행하여 단일 클라우드 인스턴스의 컨텍스트에 포함된 가로 확장을 수행합니다. Redis 에서는 이 개념을 더욱 발전시키고 Redis Enterprise 를 구축했습니다. Redis Enterprise 는 Redis 를 대규모로 실행할 수 있는 관리 계층을 제공하며 기본적으로 고가용성, 즉각적인 장애 복구, 데이터 지속성 및 백업을 지원합니다.

다음으로, 우리는 배후에서 사용되는 몇 가지 원칙을 공유하고, Redis 의 생산 및 응용 프로그램을 위해 어떻게 잘 설계된 엔지니어링 관행을 소개할 계획입니다. (윌리엄 셰익스피어, Northern Exposure (미국 TV 드라마), 예술명언)

각 가상 시스템에서 여러 Redis 인스턴스를 실행하여 다음을 수행할 수 있습니다.

개별 Redis 프로세스의 크기가 25 GB 를 초과하는 것은 허용되지 않습니다 (플래시에서 Redis 를 실행할 경우 최대 50 GB). 이런 식으로 우리는 다음을 할 수 있습니다.

Redis 성공의 열쇠는 스케일 아웃 방식으로 메모리 데이터 저장소를 유연하게 조작하는 것입니다. 구체적인 이유를 살펴 보겠습니다.

우리는 여전히 지역사회가 내놓은 다양한 흥미로운 아이디어와 기술 솔루션을 높이 평가한다. 이들 중 일부는 앞으로 Redis 에 진입할 것으로 예상된다 (우리는 이미 io _ uring, 현대사전, 풍부한 스레드 사용 전략 등을 연구하기 시작했다. ). 하지만 예측 가능한 미래에는 Redis 가 주장하는 없음 * * * 즐거움, 멀티프로세스 등의 기본 아키텍처 원칙을 포기하지 않을 것입니다. 이 설계는 최적의 성능, 확장성 및 유연성을 제공할 뿐만 아니라 메모리 실시간 데이터 플랫폼에 필요한 다양한 배포 아키텍처도 지원합니다.

부록: Draonfly 의 Redis 7.0 벤치마크 상세 정보

버전:

목표:

클라이언트 구성:

자원 활용 및 구성 최적화

마지막으로 Redis 와 잠자리는 초당 네트워크 패킷 수 또는 전송 대역폭에 의해 제한되지 않습니다. TCP 를 사용하여 두 가상 시스템 (클라이언트와 서버, 모두 c6gn. 16xlarge 인스턴스 사용) 간에 약 300 B 의 패킷 로드를 전송할 경우 초당 패킷 처리량이 654.38+00 백만 개 이상이고 전송 대역폭이 30gb 를 초과할 수 있음을 확인했습니다

단일 GET 채널 대기 시간이 1 ms 미만입니다.

30 개의 수신 채널:

단일 채널 대기 시간 1 ms 미만:

채널 30 개:

각 변수에 대한 Memtier_benchmark 명령:

단일 GET 채널 대기 시간이 1 ms 미만입니다

30 채널 받기

단일 채널 세트의 대기 시간은 1 ms 미만입니다

채널 30 개

이 비교 테스트에서는 클라이언트 (memtier_benchmark 실행) 와 서버 (Redis 및 잠자리 실행) 에서 동일한 가상 시스템 유형을 사용했습니다. 구체적인 사양은 다음과 같습니다.

참조 링크:

/문장 /AlF5NIhHdskayl0MTyQG