답변:
Redis와 MongoDB는 좋은 결과와 함께 사용할 수 있습니다. MongoDB 및 Redis (MySQL 및 Sphinx와 함께)를 실행하는 것으로 잘 알려진 회사는 Craiglist입니다. Jeremy Zawodny 의이 프레젠테이션 을 참조하세요 .
MongoDB는 지속적이고 문서 지향적이며 다양한 방식으로 인덱싱 된 데이터에 대해 흥미 롭습니다. Redis는 휘발성 데이터 또는 지연 시간에 민감한 반영구 데이터에 더 흥미 롭습니다.
다음은 MongoDB 위에 Redis를 구체적으로 사용하는 몇 가지 예입니다.
2.2 이전 MongoDB에는 아직 만료 메커니즘이 없습니다. 제한된 컬렉션은 실제 TTL을 구현하는 데 실제로 사용할 수 없습니다. Redis에는 TTL 기반 만료 메커니즘이있어 휘발성 데이터를 편리하게 저장할 수 있습니다. 예를 들어 사용자 세션은 일반적으로 Redis에 저장되는 반면 사용자 데이터는 MongoDB에 저장되고 인덱싱됩니다. MongoDB 2.2는 수집 수준에서 정확도가 낮은 만료 메커니즘을 도입했습니다 (예 : 데이터 제거에 사용).
Redis는 편리한 집합 데이터 유형 및 관련 작업 (연합, 교차, 여러 집합의 차이 등)을 제공합니다. 이 기능 위에 기본 패싯 검색 또는 태그 엔진을 구현하는 것은 매우 쉽습니다. 이는 MongoDB의 전통적인 인덱싱 기능에 흥미로운 추가 기능입니다.
Redis는 목록에서 효율적인 차단 팝 작업을 지원합니다. 임시 분산 큐잉 시스템을 구현하는 데 사용할 수 있습니다. 백엔드 애플리케이션이 시간 초과가있는 여러 큐를 수신하고 항목을 원자 적으로 다른 큐로 전송할 수 있기 때문에 MongoDB 테일러 블 커서 IMO보다 더 유연합니다. 애플리케이션에 큐잉이 필요한 경우 Redis에 큐를 저장하는 것이 좋습니다. , MongoDB에 영구 기능 데이터를 유지합니다.
Redis는 게시 / 구독 메커니즘도 제공합니다. 분산 응용 프로그램에서는 이벤트 전파 시스템이 유용 할 수 있습니다. 이것은 Redis의 훌륭한 사용 사례이며 영구 데이터는 MongoDB에 보관됩니다.
Redis보다 MongoDB를 사용하여 데이터 모델을 설계하는 것이 훨씬 쉽기 때문에 (Redis는 더 낮은 수준), 주 영구 데이터에 대한 MongoDB의 유연성과 Redis에서 제공하는 추가 기능 (낮은 대기 시간)의 이점을 활용하는 것이 흥미 롭습니다. , 항목 만료, 대기열, 게시 / 구독, 원자 블록 등). 참으로 좋은 조합입니다.
동일한 시스템에서 Redis 및 MongoDB 서버를 실행해서는 안됩니다. MongoDB 메모리는 교체되도록 설계되었지만 Redis는 그렇지 않습니다. MongoDB가 일부 스와핑 활동을 트리거하면 Redis의 성능이 치명적일 것입니다. 다른 노드에서 격리되어야합니다.
분명히 이것보다 훨씬 더 많은 차이점이 있지만 매우 높은 개요를 위해 :
사용 사례의 경우 :
기술적으로 :
겹치는 부분이 있지만 둘 다 사용하는 것이 매우 일반적입니다. 그 이유는 다음과 같습니다.
Redis는 기존 데이터 저장소를 대체 할 수 있지만 Mongo, Postgresql, MySQL 등과 같은 다른 일반 "긴"데이터 저장소 와 함께 가장 자주 사용 됩니다 .
Redis는 MongoDB를 캐싱 서버로 훌륭하게 작동합니다. 여기에 무슨 일이 벌어집니다.
mongoose가 캐시 쿼리를 실행할 때마다 먼저 캐시 서버로 이동합니다.
캐시 서버는 정확한 쿼리가 이전에 실행되었는지 확인합니다.
그렇지 않은 경우 캐시 서버가 쿼리를 받아 mongodb로 보내면 Mongo가 쿼리를 실행합니다.
그런 다음 해당 쿼리의 결과를 가져 와서 캐시 서버로 돌아가서 캐시 서버가 쿼리 결과를 자체에 저장합니다.
이 쿼리를 실행할 때마다이 응답을 받게되므로 발행 된 쿼리와 해당 쿼리에서 돌아 오는 응답 사이에 기록을 유지할 것입니다.
캐시 서버는 응답을 받아 몽구스로 다시 보내고, 몽구스는이를 익스프레스에 제공하고 결국 애플리케이션 내부에서 끝납니다.
동일한 쿼리가 다시 실행될 때마다 mongoose는 동일한 쿼리를 캐시 서버로 보내지 만 캐시 서버가이 쿼리가 실행 된 것을 확인한 경우 mongodb로 쿼리를 보내지 않고 대신 응답을받습니다. 마지막으로 얻은 쿼리를 즉시 몽구스로 다시 보냅니다. 여기에는 인덱스도없고 전체 테이블 스캔도없고 아무것도 없습니다.
이 쿼리가 실행되었는지 확인하기 위해 간단한 조회를 수행하고 있습니다. 예? 좋아요, 요청을 받아 즉시 다시 보내고 mongo에 아무것도 보내지 마세요.
몽구스 서버, 캐시 서버 (Redis) 및 Mongodb가 있습니다.
캐시 서버에는 모든 키가 이전에 발행 된 일부 유형의 쿼리이고 해당 쿼리의 결과 값인 데이터 저장소의 키 값 유형이있는 데이터 저장소가있을 수 있습니다.
그래서 아마도 우리는 _id의 블로그 포스트를 찾고있을 것입니다.
따라서 여기에있는 키는 이전에 조회 한 레코드의 _id 일 수 있습니다.
따라서 mongoose가 _id가 123 인 블로그 게시물을 찾으려고하는 새 쿼리를 실행하고 쿼리가 캐시 서버로 이동하고 캐시 서버가 _id를 찾고 있던 쿼리에 대한 결과가 있는지 확인한다고 가정 해 보겠습니다. 123의.
캐시 서버에 없으면이 쿼리를 가져와 mongodb 인스턴스로 보냅니다. Mongodb는 쿼리를 실행하고 응답을 받고 다시 보냅니다.
이 결과는 해당 결과를 가져와 즉시 몽구스로 다시 보내는 캐시 서버로 다시 전송되어 최대한 빠른 응답을 얻습니다.
그 직후 캐시 서버는 또한 발행 된 쿼리를 가져 와서 발행 된 쿼리 모음에 추가하고 쿼리 결과를 가져 와서 쿼리에 대해 바로 저장합니다.
따라서 앞으로 동일한 쿼리를 다시 실행하면 캐시 서버에 도달하고 모든 키를 살펴보고 오, 이미 해당 블로그 게시물을 찾았습니다. mongo에 도달하지 않습니다. 쿼리 결과를 몽구스에게 직접 보냅니다.
우리는 복잡한 쿼리 로직을 수행하지 않고 인덱스도 없습니다. 가능한 한 빨리. 간단한 키 값 조회입니다.
이것이 캐시 서버 (Redis)가 MongoDB와 작동하는 방식에 대한 개요입니다.
이제 다른 문제가 있습니다. 데이터를 영원히 캐싱하고 있습니까? 레코드를 어떻게 업데이트합니까?
우리는 항상 캐시에 데이터를 저장하고 캐시에서 읽는 것을 원하지 않습니다.
캐시 서버는 쓰기 작업에 사용되지 않습니다. 캐시 레이어는 데이터 읽기에만 사용됩니다. 데이터를 쓰는 경우 쓰기는 항상 mongodb 인스턴스로 넘어 가고 데이터를 쓸 때마다 Mongo에서 방금 업데이트 한 레코드와 관련된 캐시 서버에 저장된 모든 데이터를 지워야합니다.