내가 원하는 것은 Redis와 MongoDB의 비교가 아닙니다. 나는 그들이 다르다는 것을 안다. 성능과 API는 완전히 다릅니다.
Redis는 매우 빠르지 만 API는 매우 '원자'입니다. MongoDB는 더 많은 리소스를 소비하지만 API는 사용하기가 매우 쉽고 매우 만족합니다.
둘 다 훌륭하고 가능한 한 배포에서 Redis를 사용하고 싶지만 코딩하기가 어렵습니다. 가능한 한 개발에 MongoDB를 사용하고 싶지만 비싼 기계가 필요합니다.
두 가지 사용에 대해 어떻게 생각하십니까? 언제 Redis를 선택해야합니까? MongoDB를 언제 고르나요?
답변:
나는 그것이 당신의 개발자 팀의 종류와 응용 프로그램 요구에 달려 있다고 말합니다.
예를 들어, 많은 쿼리가 필요한 경우 , 개발자가 Redis를 사용하는 것이 더 많은 작업을 의미합니다. 여기서 데이터는 효율성을 위해 각 유형의 개체에 맞게 사용자 정의 된 다양한 특수 데이터 구조에 저장 될 수 있습니다. MongoDB에서는 데이터가 구조적으로 일관성이 있기 때문에 동일한 쿼리가 더 쉬울 수 있습니다. 반면 Redis에서 이러한 쿼리에 대한 응답 속도 는 데이터가 저장된 다양한 구조를 처리하는 추가 작업에 대한 대가입니다.
MongoDB는 전통적인 DB 및 SQL 경험이있는 개발자에게 단순하고 훨씬 짧은 학습 곡선을 제공합니다. 그러나 Redis의 비 전통적인 접근 방식은 배우는 데 더 많은 노력이 필요하지만 더 큰 유연성이 필요합니다.
예 : 캐시 층은 아마도 더 나은 레디 스에서 구현 될 수있다. 스키마가 가능한 데이터가 많을수록 MongoDB가 더 좋습니다. [참고 : MongoDB와 Redis는 기술적으로 스키마가 없습니다]
당신이 저에게 묻는다면, 나의 개인적인 선택은 대부분의 요구 사항에서 Redis입니다.
마지막으로, 지금까지 http://antirez.com/post/MongoDB-and-Redis.html 을 보셨 기를 바랍니다.
방금이 질문이 상당히 오래되었다는 것을 알았습니다. 그럼에도 불구하고 다음 측면을 추가 할 가치가 있다고 생각합니다.
데이터 쿼리 방법을 아직 모르는 경우 MongoDB를 사용하십시오.
MongoDB는 해커 톤, 스타트 업 또는 삽입 한 데이터를 쿼리하는 방법을 모르는 경우에 적합합니다. MongoDB는 기본 스키마를 가정하지 않습니다. MongoDB는 스키마가없고 관계가 없지만 스키마가 전혀 없다는 의미는 아닙니다. 이는 단순히 스키마를 앱에서 정의해야 함을 의미합니다 (예 : Mongoose 사용). 그 외에도 MongoDB는 프로토 타이핑이나 시험해보기에 좋습니다. 성능은 그다지 좋지 않으며 Redis와 비교할 수 없습니다.
기존 애플리케이션 속도를 높이려면 Redis를 사용하십시오.
Redis는 LRU 캐시 로 쉽게 통합 할 수 있습니다 . Redis를 독립형 데이터베이스 시스템으로 사용하는 것은 매우 드문 일입니다 (일부 사람들은이 시스템을 "키-값"저장소라고 부릅니다). Craigslist와 같은 웹 사이트 는 기본 데이터베이스 옆에 Redis를 사용 합니다 . Antirez (Redis 개발자)는 Lamernews를 사용하여 Redis를 독립형 데이터베이스 시스템으로 사용할 수 있음을 시연했습니다.
Redis는 귀하의 데이터를 근거로 어떠한 가정도하지 않습니다.
Redis는 유용한 데이터 구조 (예 : 세트, 해시, 목록)를 제공하지만 데이터 저장 방법을 명시 적으로 정의해야합니다. 간단히 말해서 비슷한 것을 달성하기 위해 Redis와 MongoDB를 사용할 수 있습니다. Redis는 더 빠르지 만 프로토 타이핑에는 적합하지 않습니다. 그것은 일반적으로 MongoDB를 선호하는 유스 케이스입니다. 그 외에도 Redis는 정말 유연합니다. 그것이 제공하는 기본 데이터 구조는 고성능 DB 시스템의 빌딩 블록입니다.
캐싱
MongoDB를 사용한 캐싱은 그다지 의미가 없습니다. 너무 느릴 것입니다.
DB 디자인에 대해 생각할 시간이 충분하다면.
Redis에 문서를 넣을 수는 없습니다. 데이터를 저장하고 구성하려는 방식을 고려해야합니다. 한 가지 예는 Redis의 해시입니다. 그것들은 "전통적인"중첩 된 객체와는 상당히 다르기 때문에 중첩 된 문서를 저장하는 방식을 재고해야합니다. 한 가지 해결책은 해시 내부에 다른 해시에 대한 참조를 저장하는 것입니다 ( 키 와 같은 것 : [id of second hash] ). 또 다른 아이디어는 JSON으로 저장하는 것인데, 이는 * SQL 배경을 가진 대부분의 사람들에게 직관적이지 않은 것처럼 보입니다.
정말로 고성능 이 필요한 경우 .
Redis가 제공하는 성능을 능가하는 것은 거의 불가능합니다. 데이터베이스가 캐시만큼 빠르다고 상상해보십시오. 이것이 Redis를 실제 데이터베이스 로 사용하는 느낌 입니다.
스케일링에 관심 이 없다면
Redis 확장은 예전처럼 어렵지 않습니다. 예를 들어, 여러 Redis 인스턴스간에 데이터를 분배하기 위해 일종의 프록시 서버를 사용할 수 있습니다. 마스터 - 슬레이브 복제가되지 않는 것을 복잡하지만 (예를 들어, 해시 함수를 사용하여 모듈로 등) 응용 프로그램 사이트에서 할 수 당신에게 여러 레디 스 - 인스턴스의 요구 사이에서 키를 배포. 비교하여 MongoDB를 확장하는 것이 훨씬 간단합니다.
프로토 타이핑, 스타트 업, 해커 톤
MongoDB는 신속한 프로토 타이핑에 완벽하게 적합합니다. 그럼에도 불구하고 성능은 그렇게 좋지 않습니다. 또한 응용 프로그램에서 일종의 스키마를 정의해야 할 수도 있습니다.
스키마를 빠르게 변경해야 할 때.
스키마가 없기 때문에! 기존의 관계형 DBMS에서 테이블을 변경하면 비용이 많이 들고 속도가 느립니다. MongoDB는 기본 데이터에 대해 많은 가정을하지 않음으로써이 문제를 해결합니다. 그럼에도 불구하고 스키마를 정의하지 않고도 가능한 한 최적화하려고합니다.
TL; DR- 성능이 중요하고 데이터를 최적화하고 구성하는 데 시간을 투자 할 의사가있는 경우 Redis를 사용하십시오. -DB에 대해 너무 걱정하지 않고 프로토 타입을 빌드해야하는 경우 MongoDB를 사용하십시오.
더 읽을 거리 :
레디 스 PHP로 사이트를 작성했다고 가정 해 봅시다. 어떤 이유로 든 인기가 높아지고 시간이 앞서거나 포르노가 있습니다. 이 PHP가 너무 느리다는 것을 알고 있습니다. "팬들이 페이지를 10 초 동안 기다리지 않기 때문에 팬을 잃을 것입니다." 웹 페이지에 일정한 URL (변경되지 않음)이 있으면 기본 키가 있다는 것을 갑자기 깨달았으며 디스크가 느리고 PHP가 느릴 때 메모리가 빠르다는 것을 기억합니다. :( 그런 다음 메모리와이 URL을 사용하여 "키"라고 부르는 웹 페이지 컨텐츠를 "값"이라고 부르는 스토리지 메커니즘을 구성합니다. 이것이 바로 키와 컨텐츠입니다. "meme cache"라고 부릅니다. 리차드 도킨스 (Richard Dawkins)는 좋아하기 때문에 다람쥐가 견과류를 캐싱하는 것처럼 HTML을 캐시하므로 크랩 PHP 코드를 다시 작성할 필요가 없습니다. 당신은 행복하다. 그런 다음 다른 사람들이 그것을 한 것을 알 수 있습니다.하지만 다른 고양이는 송곳니와 고양이의 혼란스러운 이미지를 가지고 있기 때문에 Redis를 선택합니다.
몽고. 당신은 사이트를 작성했습니다. 당신은 많은 언어로 작성했습니다. 당신은 많은 시간이 그 유능한 SQL 절을 작성하는 데 소비된다는 것을 알고 있습니다. 당신은 dba가 아니지만, 어리석은 SQL 문을 작성하고 있습니다 ... 단지 하나가 아니라 모든 곳에서 괴물입니다. "이것을 선택하십시오". 그러나 특히 자극적 인 WHERE 절을 기억하십시오. 성은 "thornton"이고 영화는 "bad santa"입니다. 어. 당신은 "그 dbas는 왜 그들의 일을하고 저장 프로 시저를 제공하지 않습니까?"라고 생각합니다. 그런 다음 중간 이름과 같은 사소한 필드를 잊어 버린 다음 테이블을 삭제하고 10G의 모든 빅 데이터를 내보내고이 새로운 필드로 다른 필드를 만들고 데이터를 가져와야합니다. 그러면 14 일 동안 10 번 계속됩니다 인사말, 제목, 주소가 포함 된 외래 키 추가. 그런 다음 성은 성이어야한다고 생각합니다. 하루에 거의 한 번 변경됩니다. 그럼 당신은 darnit를 말합니다. 웹 사이트 / 시스템을 작성하고 작성해야 하며이 데이터 모델 BS는 신경 쓰지 마십시오. 그래서 당신은 구글, "나는 SQL 작성을 싫어, 제발 SQL을 중지, 중지"하지만 팝업 'nosql'을 읽은 다음 일부 스키마를 읽지 않고 데이터를 덤프한다고 말합니다. 지난 주에 일어난 더 많은 테이블과 미소를 잃어버린 위기를 기억합니다. 그런 다음 apt 임대 사이트 'airbud'과 같은 일부 큰 사람들이 그것을 사용하기 때문에 mongo를 선택하십시오. 단. 계속 변경하려는 모델이 있으므로 더 이상 데이터 모델이 변경되지 않습니다.
You don't need to rewrite your crap php code?, 어떻게 KV 저장소 해결할 수있는 문제를 않습니다이? :)
이 리소스는 둘 다를 결정하는 데 도움이 될 수 있습니다. 또한 몇 가지 다른 NoSQL 데이터베이스에 대해 설명하고 각 데이터베이스에 대한 "내가 사용하는 대상"에 대한 간략한 특성 목록을 제공 합니다.
대답하기 어려운 질문-대부분의 기술 솔루션과 마찬가지로, 이는 실제로 상황에 따라 다르며 해결하려는 문제를 설명하지 않았으므로 어떻게 솔루션을 제안 할 수 있습니까?
어느 것이 당신의 요구를 만족시키는 지 확인하기 위해 둘 다 테스트 해야합니다.
따라서 MongoDB에는 고가의 하드웨어가 필요하지 않습니다. 다른 데이터베이스 솔루션과 마찬가지로 더 많은 CPU 및 메모리에서 더 잘 작동하지만 특히 초기 개발 목적으로 요구 사항은 아닙니다.
Redis는 메모리 데이터 저장소에 있으며,이 상태는 디스크에 대한 상태를 유지할 수 있습니다 (다시 시작한 후 복구 가능). 그러나 메모리 내 데이터 저장소는 단일 노드의 데이터 저장소 크기가 시스템의 총 메모리 공간 (실제 RAM + 스왑 공간)을 초과 할 수 없음을 의미합니다. 실제로 Redis는 시스템의 다른 많은 프로세스와 해당 공간을 공유하므로 시스템 메모리 공간을 소진하면 운영 체제에 의해 종료 될 수 있습니다.
Mongo는 디스크 기반 데이터 저장소로, 작업 세트가 모든 소프트웨어와 같이 실제 RAM에 맞는 경우 가장 효율적 입니다. 디스크 기반 데이터라는 것은 Mongo 데이터베이스의 크기에 본질적인 제한이 없음을 의미하지만 구성 옵션, 사용 가능한 디스크 공간 및 기타 문제는 특정 제한을 초과하는 데이터베이스 크기가 실용적이지 않거나 비효율적 일 수 있음을 의미 할 수 있습니다.
Redis와 Mongo는 모두 고 가용성, 백업 및 전체 데이터 스토어 크기를 위해 클러스터링 할 수 있습니다.
이 글을 쓰는 시점의 모든 답변은 각 Redis, MongoDB 및 SQL 기반 관계형 데이터베이스가 본질적으로 동일한 도구 인 "데이터 저장"이라고 가정합니다. 그들은 데이터 모델을 전혀 고려하지 않습니다.
MongoDB는 문서 저장소입니다. SQL 기반 관계형 데이터베이스와 비교 : 관계형 데이터베이스는 색인화 된 CSV 파일로 단순화합니다. 각 파일은 테이블입니다. 문서 저장소는 색인화 된 JSON 파일로 단순화하며, 각 파일은 문서이며 여러 파일이 함께 그룹화됩니다.
JSON 파일은 구조가 XML 및 YAML 파일과 비슷하며 Python과 같은 사전과 유사하므로 이러한 종류의 계층 구조에서 데이터를 생각하십시오. 인덱싱 할 때 구조는 키입니다. 문서에는 추가 문서, 배열 또는 스칼라 값을 포함하는 명명 된 키가 포함됩니다. 아래 문서를 고려하십시오.
{
_id: 0x194f38dc491a,
Name: "John Smith",
PhoneNumber:
Home: "555 999-1234",
Work: "555 999-9876",
Mobile: "555 634-5789"
Accounts:
- "379-1111"
- "379-2574"
- "414-6731"
}
위의 문서에는 키 PhoneNumber.Mobile가 있으며 값은 555 634-5789입니다. , 키에 PhoneNumber.Mobile값이 있는 문서 모음을 검색 할 수 있습니다 . 그들은 색인됩니다.
또한 Accounts여러 인덱스를 보유 하는 배열이 있습니다. 이 문서를 조회 할 수 있습니다 Accounts포함 정확하게 , 일부 값 집합을 모든 가치의 일부 부분 집합의, 또는 어떤 값의 일부 하위 집합. 즉 Accounts = ["379-1111", "379-2574"], 위를 검색 하고 찾을 수 없습니다. Accounts includes ["379-1111"]위의 문서를 검색 하고 찾을 수 있습니다. Accounts includes any of ["974-3785","414-6731"]위의 문서와 "974-3785"계정이있는 문서를 검색 하고 찾을 수 있습니다 (있는 경우).
문서는 원하는만큼 깊어집니다. PhoneNumber.Mobile배열 또는 하위 문서 ( PhoneNumber.Mobile.Work및 PhoneNumber.Mobile.Personal)를 보유 할 수 있습니다 . 데이터가 고도로 구조화 된 경우 관계형 데이터베이스에서 문서가 크게 향상됩니다.
데이터가 대부분 평평하고 관계형이며 엄격하게 구조화 된 경우 관계형 데이터베이스를 사용하는 것이 좋습니다. 다시 말하지만, 데이터 모델이 서로 관련된 CSV 파일 모음 또는 XML / JSON / YAML 파일 모음에 가장 적합한 지 여부가 큰 신호입니다.
대부분의 프로젝트의 경우 SQL 또는 문서 저장소가 맞지 않는 일부 작은 영역에서 약간의 해결 방법을 받아 들여 타협해야합니다. 광범위한 데이터 분산 (많은 열; 행은 관련이 없음)을 저장하는 크고 복잡한 프로젝트의 경우 일부 데이터를 한 모델에 저장하고 다른 데이터를 다른 모델에 저장하는 것이 좋습니다. Facebook은 SQL과 그래프 데이터베이스를 모두 사용합니다 (데이터는 노드에 배치되고 노드는 다른 노드에 연결됨). Craigslist는 MySQL과 MongoDB를 사용했지만 MongoDB로 전적으로 이동하려고했습니다. 하나의 모델에 놓으면 데이터의 범위와 관계가 심각한 핸디캡에 직면하는 곳입니다.
Redis는 가장 기본적으로 키-값 저장소입니다. Redis를 사용하면 키를 제공하고 단일 값을 찾을 수 있습니다. Redis 자체는 문자열, 목록, 해시 및 기타 몇 가지를 저장할 수 있습니다. 그러나 이름 만 찾습니다.
캐시 무효화는 컴퓨터 과학의 어려운 문제 중 하나입니다. 다른 하나는 이름을 짓는 것입니다. 즉, 백엔드에 대한 수백 번의 과도한 조회를 피하고 싶을 때 Redis를 사용하지만 새로운 조회가 필요한 시점을 파악해야합니다.
무효의 가장 눈에 띄는 경우가 쓰기에 대한 업데이트입니다 : 당신이 읽는다면 user:Simon:lingots = NOTFOUND, 당신은 할 수 SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simon및 결과를 저장 100로 SET user:Simon:lingots = 100. 당신은 사이먼 5 lingots을 수여 할 때 다음, 당신은 읽고 user:Simon:lingots = 100, SET user:Simon:lingots = 105하고 UPDATE Store s INNER JOIN UserProfile u ON s.UserID = u.UserID SET s.Lingots = 105 WHERE u.Username = Simon. 이제 데이터베이스와 Redis에 105가 있으며 데이터베이스 user:Simon:lingots를 쿼리하지 않고도 얻을 수 있습니다 .
두 번째 경우는 종속 정보를 업데이트하는 것입니다. 페이지 청크를 생성하고 출력을 캐시한다고 가정 해 봅시다. 헤더에는 플레이어의 경험, 레벨 및 금액이 표시됩니다. 플레이어의 프로필 페이지에는 통계를 보여주는 블록이 있습니다. 기타 등등. 플레이어는 약간의 경험을 얻습니다. 자, 이제 당신은 몇 가지가있다 templates:Header:Simon, templates:StatsBox:Simon, templates:GrowthGraph:Simon당신이 쿼리 템플릿 엔진을 통해 실행 대여섯 데이터베이스의 출력을 캐시 한 곳 등이 필드. 일반적으로 이러한 페이지를 표시하면 다음과 같이 말합니다.
$t = GetStringFromRedis("templates:StatsBox:" + $playerName);
if ($t == null) {
$t = BuildTemplate("StatsBox.tmpl",
GetStatsFromDatabase($playerName));
SetStringInRedis("Templates:StatsBox:" + $playerName, $t);
}
print $t;
의 결과를 방금 업데이트 했으므로 키-값 캐시 GetStatsFromDatabase("Simon")에서 삭제 templates:*:Simon해야합니다. 이러한 템플릿을 렌더링하려고하면 응용 프로그램에서 데이터베이스 (PostgreSQL, MongoDB)에서 데이터를 가져 와서 템플릿에 삽입합니다. 그런 다음 결과를 Redis에 저장하고 다음에 해당 출력 블록을 표시 할 때 데이터베이스 쿼리 및 렌더링 템플릿을 작성하지 않아도됩니다.
또한 Redis를 사용하면 게시자 구독 메시지 큐 등을 수행 할 수 있습니다. 그것은 또 다른 주제입니다. 여기서 Redis는 키-값 캐시이며 관계형 데이터베이스 또는 문서 저장소와 다릅니다.
필요에 따라 도구를 선택하십시오. 코드가 얼마나 복잡하고 오류가 발생하기 쉬운 지 결정하기 때문에 가장 큰 요구는 일반적으로 데이터 모델입니다. 전문화 된 응용 프로그램은 성능과 C 및 어셈블리를 혼합하여 모든 것을 쓰는 장소에 의존합니다. 대부분의 응용 프로그램은 일반화 된 사례를 처리하고 고성능 SQL 데이터베이스 나 문서 저장소보다 훨씬 빠른 Redis 또는 Memcached와 같은 캐싱 시스템을 사용합니다.
그리고 RAM이 충분한 경우 어느 쪽도 사용하지 않아야합니다. Redis와 MongoDB는 범용 도구의 가격에 도달했습니다. 이로 인해 많은 오버 헤드가 발생합니다.
Redis가 Mongo보다 10 배 빠르다는 말이있었습니다. 그것은 더 이상 사실이 아닐 수도 있습니다. MongoDB (정확하게 기억한다면)는 메모리 구성이 동일하다면 문서를 저장하고 캐싱하는 memcache를 이길 것이라고 주장했습니다.
아무리 해도. Redis, MongoDB가 좋습니다. 하위 구조에 관심이 있고 집계가 필요한 경우 MongoDB로 이동하십시오. 키와 값을 저장하는 것이 Redis의 모든 관심사입니다. (또는 다른 키 값 저장소).
Redis와 MongoDB는 비 관계형 데이터베이스이지만 서로 다른 범주입니다.
Redis는 키 / 값 데이터베이스이며 인 메모리 스토리지를 사용하여 매우 빠릅니다. 캐싱 및 임시 데이터 스토리지 (메모리)를 캐싱하기에 좋은 후보이며 대부분의 클라우드 플랫폼 (예 : Azure, AWS)이 지원하므로 메모리 사용량을 확장 할 수 있습니다. 제한된 자원이라면 메모리 사용량을 고려하십시오.
반면에 MongoDB는 문서 데이터베이스입니다. 큰 텍스트, 이미지, 비디오 등 트랜잭션을 제외한 데이터베이스에서 수행하는 거의 모든 작업을 유지하는 데 좋은 옵션입니다. 예를 들어 블로그 또는 소셜 네트워크를 개발하려는 경우 MongoDB가 올바른 선택입니다. 스케일 아웃 전략으로 확장 가능합니다. 디스크를 저장 매체로 사용하므로 데이터가 유지됩니다.