내가 원하는 것은 Redis와 MongoDB를 비교하는 것이 아닙니다. 나는 그들이 다르다는 것을 압니다. 성능과 API는 완전히 다릅니다.
Redis는 매우 빠르지 만 API는 매우 '원자 적'입니다. MongoDB는 더 많은 리소스를 사용하지만 API는 매우 사용하기 쉽고 매우 만족합니다.
두 가지 모두 멋지 기 때문에 가능한 한 배포에서 Redis를 사용하고 싶지만 코드 작성은 어렵습니다. 가능한 한 개발 용 MongoDB를 사용하고 싶지만 비싼 기계가 필요합니다.
그럼 두 가지 모두의 사용에 대해 어떻게 생각하십니까? 레디 스를 골라야 할 때? 언제 MongoDB를 고를 수 있습니까?
나는 당신이 개발팀의 종류와 당신의 어플리케이션이 필요로하는 종류에 달려 있다고 말할 것입니다.
예를 들어,질의이는 대부분 개발자가 효율적으로 각 유형의 객체에 맞게 사용자 정의 된 다양한 특수 데이터 구조에 데이터가 저장 될 수있는 Redis를 사용하는 것이 더 많은 작업이된다는 것을 의미합니다. MongoDB에서는 구조가 데이터 전반에 걸쳐 일관성이 있기 때문에 동일한 쿼리가 더 쉬울 수도 있습니다. 반면에, 레디 스에서는,얇은 속도이러한 쿼리에 대한 응답은 데이터가 저장 될 수있는 다양한 구조를 다루는 추가 작업에 대한 결과입니다.
MongoDB는 전통적인 DB와 SQL 경험을 가진 개발자들에게 간결함과 학습 곡선을 단축시켜줍니다. 그러나 레디 스의 비 전통적 접근 방식은 학습하는 데 더 많은 노력이 필요하지만 유연성은 더 커집니다.
예 : 에이은닉처레이어가 Redis에서 더 잘 구현 될 수 있습니다. 더 많은 스키마 가능 데이터를 얻으려면 MongoDB가 더 좋습니다.[참고 : MongoDB와 Redis는 기술적으로 스키마가 없습니다.]
여러분이 저에게 묻는다면, 제 개인적인 선택은 대부분의 요구 사항에 대한 Redis입니다.
마지막으로, 지금까지 당신이 본 것을 희망합니다.http://antirez.com/post/MongoDB-and-Redis.html
나는이 질문이 아주 오래된 것으로 나타났습니다. 그럼에도 불구하고 다음과 같은 측면을 추가 할 가치가 있다고 생각합니다.
아직 데이터를 쿼리하는 방법을 모른다면 MongoDB를 사용하십시오.
MongoDB는 Hackathons, 신생 기업 또는 삽입 한 데이터를 어떻게 쿼리할지 모를 때마다 적합합니다. MongoDB는 기본 스키마에 대한 어떠한 가정도하지 않습니다. MongoDB는 스키마가없고 비 관계형이지만 이것이 스키마가 전혀 없다는 것을 의미하지는 않습니다. 단순히 스키마 (예 : 몽구스 사용)를 앱에 정의해야한다는 의미입니다. 그 외에도 MongoDB는 프로토 타입을 작성하거나 시도하는 데 적합합니다. 그 성능은 그렇게 좋지는 않으며 Redis와 비교할 수 없습니다.
기존 응용 프로그램의 속도를 높이려면 Redis를 사용하십시오.
Redis는 쉽게 통합 할 수 있습니다.LRU 캐시. Redis를 독립형 데이터베이스 시스템으로 사용하는 것은 매우 드뭅니다 (일부 사람들은이를 "키 - 값"저장소로 언급하는 것을 선호합니다). Craigslist 사용과 같은 웹 사이트기본 데이터베이스 옆에있는 Redis. Antirez (Redis 개발자)는 Lamernews를 사용하여 실제로 Redis를 독립형 데이터베이스 시스템으로 사용할 수 있음을 입증했습니다.
Redis는 귀하의 데이터를 기반으로 어떠한 가정도하지 않습니다.
Redis는 유용한 데이터 구조 (예 : 집합, 해시, 목록)를 제공하지만 데이터를 저장하는 방법을 명시 적으로 정의해야합니다. 요컨대, Redis와 MongoDB는 비슷한 것을 달성하기 위해 사용될 수 있습니다. Redis는 단순히 더 빠르지 만 프로토 타이핑에는 적합하지 않습니다. 이것은 MongoDB를 선호하는 일반적인 사용 사례입니다. 그 외에 레디 스는정말융통성 있는. 그것이 제공하는 기본 데이터 구조는 고성능 DB 시스템의 빌딩 블록입니다.
캐싱
MongoDB를 사용한 캐싱은 단순히 의미가 없습니다. 그것은 너무 느릴 것입니다.
DB 디자인에 대해 생각할 충분한 시간이 있다면.
Redis에 문서를 던지기 만하면됩니다. 데이터를 저장하고 구성하려는 방식을 생각해야합니다. 한 가지 예는 Redis의 해시입니다. 이들은 "전통적인"중첩 된 객체와 완전히 다릅니다. 즉, 중첩 된 문서를 저장하는 방식을 다시 생각해야합니다. 한 해법은 다른 해시에 해시 내부에 참조를 저장하는 것입니다 (키 : [두 번째 해시의 ID]). 또 다른 아이디어는 * SQL 배경을 가진 대부분의 사람들에게 반 직관적 인 것으로 보이는 JSON으로 저장하는 것입니다.
필요한 경우정말고성능.
Redis가 제공하는 성능을 상회하는 것은 거의 불가능합니다. 데이터베이스가 캐시만큼 빠르다고 상상해보십시오. Redis를 사용하여레알데이터 베이스.
당신이 상관하지 않는다면그스케일링에 관한 많은 것.
Redis 스케일링은 예전처럼 어렵지 않습니다. 예를 들어, 여러 Redis 인스턴스간에 데이터를 분배하기 위해 일종의 프록시 서버를 사용할 수 있습니다. 마스터 - 슬레이브 복제가 아닙니다.그복잡하지만 여러 Redis-instances간에 키를 배포하는 작업은 응용 프로그램 사이트에서 수행해야합니다 (예 : 해시 함수, 모듈러스 등 사용). MongoDB를 비교해 보면 훨씬 간단합니다.
프로토 타이핑, 신생 기업, Hackathons
MongoDB는 신속한 프로토 타이핑에 완벽하게 적합합니다. 그럼에도 불구하고 성능은 그렇게 좋지 않습니다. 또한 응용 프로그램에서 일종의 스키마를 정의해야 할 가능성이 높습니다.
스키마를 신속하게 변경해야하는 경우.
스키마가 없기 때문에! 전통적인 관계형 DBMS에서 테이블을 변경하는 것은 비용이 많이 들고 느립니다. MongoDB는 기본 데이터에 대해 많은 가정을하지 않아이 문제를 해결합니다. 그럼에도 불구하고 스키마를 정의 할 필요없이 가능한 한 최적화를 시도합니다.
TL, DR- 성능이 중요하고 데이터 최적화 및 구성에 많은 시간을 할애하려는 경우 Redis를 사용하십시오. - DB에 대해 너무 걱정하지 않고 프로토 타입을 작성해야하는 경우 MongoDB를 사용하십시오.
추가 읽기 :
Redis. PHP로 사이트를 작성했다고 가정 해 보겠습니다. 어떤 이유로 든 인기가 있으며 시간보다 앞서거나 포르노가 있습니다. 당신은이 PHP가 매우 놀랍다는 것을 깨닫습니다. "페이지를 10 초 동안 기다리지 않기 때문에 팬을 잃을 것입니다." 웹 페이지에 상수 URL (절대 변경되지 않습니다.), 기본 키 (원할 경우), 그리고 디스크가 느리고 php가 더 느린 동안 메모리가 빠름을 생각하면 갑자기 깨닫게됩니다. 그런 다음 웹 페이지 콘텐츠가 "가치"라고 부르는 동안 메모리와이 URL을 사용하여 저장 메커니즘을 구현합니다. 키와 내용 - "밈 캐시"라고 부릅니다. 당신은 리차드 도킨스가 굉장하기 때문에 마음에 듭니다. 다람쥐처럼 너의 html을 캐시하면 너는 쓰레기 PHP 코드를 다시 쓸 필요가 없다. 너는 행복하다. 그러면 다른 사람들이 해냈다는 것을 알 수있다. 다른 하나는 고양이의 이미지를 혼란스럽게 만들고 일부는 송곳니를 사용합니다.
몽고. 당신은 사이트를 작성했습니다. 당신은 많은 언어로 썼습니다. 그 악몽 같은 SQL 조항을 쓰는 데 많은 시간을 소비한다는 것을 알고 있습니다. 당신은 dba가 아니지만 아직 거기에 어리석은 SQL 문을 쓰고 있습니다. "이것을 선택하고 그것을 선택하십시오". 그러나 특히 당신은 짜증나는 WHERE 절을 기억합니다. 성은 "thornton"이고 영화는 "bad santa"와 같습니다. 응. "왜 그 dbas가 그냥 일을하고 저에게 저장 프로 시저를 줄까요?"라고 생각합니다. 그런 다음 middlename과 같은 사소한 필드를 잊어 버린 다음 테이블을 삭제하고 10G의 큰 데이터를 모두 내보내고이 새로운 필드로 다른 데이터를 만들고 데이터를 가져와야합니다. 그러면 다음 14 일 동안 10 일 동안 진행됩니다. 인사말, 제목과 같은 외설적 인 내용을 계속 기억하고 주소가있는 외래 키를 추가하십시오. 그런 다음 성을 lastName으로 지정해야합니다. 하루에 거의 하나의 변화. 그럼 너는 멍청이야. 나는 웹 사이트 / 시스템을 작성하고 작성해야하며,이 데이터 모델 BS는 신경 쓰지 않아야한다. 그래서 당신은 google, "나는 SQL 작성을 싫어한다. SQL을 멈추게한다."하지만 pop 'nosql'을 누른 다음 몇 가지 내용을 읽으면 스키마없이 데이터가 덤프된다고한다. 지난 주에 큰 실수로 더 많은 테이블과 미소가 떨어 졌다는 것을 기억하십니까? 그런 다음 적당한 사람의 렌탈 사이트에서 '에어 버스'와 같은 큰 사람들이 사용하기 때문에 몽고를 선택합니다. 단. 계속 변화하는 모델을 가지고 있기 때문에 더 이상 데이터 모델이 변경되지 않습니다.
You don't need to rewrite your crap php code?, k-v store는 어떻게 이것을 해결합니까? :) - Roy Lee
어쩌면이 자원은 둘 사이에서 결정하는데 도움이 될 것입니다. 또한 몇 가지 다른 NoSQL 데이터베이스에 대해서도 다루고 있습니다."내가 그것을 위해 무엇을 쓸 것인가"각각에 대한 설명.
답하기 어려운 질문 - 대부분의 기술 솔루션과 마찬가지로 문제는 실제로 상황에 따라 다르며 해결하려는 문제를 설명하지 않았으므로 어떻게 솔루션을 제안 할 수 있습니까?
둘 중 어느 것이 만족하는지 확인하기 위해 둘 다 테스트해야합니다.너의필요합니다.
MongoDB는 값 비싼 하드웨어를 필요로하지 않습니다. 다른 데이터베이스 솔루션과 마찬가지로 더 많은 CPU와 메모리로 더 잘 작동하지만 확실히 초기 요구 사항은 아닙니다.
레디 스는메모리에데이터 저장소디스크 상태를 유지하다(재시작 후 복구가 가능하도록). 그러나 인 메모리 데이터 저장소라는 것은 단일 노드에있는 데이터 저장소의 크기가 시스템의 총 메모리 공간 (물리적 RAM + 스왑 공간)을 초과 할 수 없다는 것을 의미합니다. 실제로 Redis는이 공간을 시스템의 다른 많은 프로세스와 공유하고 있기 때문에 시스템 메모리 공간이 고갈되면 운영 체제에 의해 제거 될 가능성이 훨씬 적습니다.
몽고는디스크 기반데이터 저장소를 사용하면 가장 효율적입니다.작업 집합물리적 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 단어를 수여하면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, 등등. 템플릿 엔진을 통해 실행되는 6 개 데이터베이스 쿼리의 출력을 캐시 한 필드. 일반적으로이 페이지를 표시 할 때 다음과 같이 말합니다.
$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는 범용 도구로 제공됩니다. 이것은 많은 오버 헤드를 초래합니다.
레디 스는 몽고보다 10 배 빠르다고하는 말이있었습니다. 그것은 더 이상 사실이 아닐 수도 있습니다. MongoDB (정확하게 기억한다면)는 메모리 구성이 동일하다면 문서 저장 및 캐싱을 위해 memcache를 이겼다고 주장합니다.
아무리 해도. Redis good, MongoDB는 좋습니다. 하위 구조에 관심이 있고 집계가 필요한 경우 MongoDB를 사용하십시오. 키와 값을 저장하는 것이 주요 관심사 인 경우 Redis에 관한 모든 것입니다. (또는 다른 키 값 저장소).
Redis와 MongoDB는 비 관계형 데이터베이스이지만 서로 다른 범주에 속합니다.
Redis는 키 / 값 데이터베이스이며 매우 빠른 속도를내는 메모리 내장 스토리지를 사용합니다. 그것은 캐싱 물건과 임시 데이터 저장소 (메모리)를위한 좋은 후보이고 Azure, AWS와 같은 대부분의 클라우드 플랫폼이이를 지원하기 때문에 메모리 사용은 확장 가능합니다. 그러나 만약 당신이 당신의 컴퓨터에서 제한된 리소스, 메모리 사용량을 고려하십시오.
한편, MongoDB는 문서 데이터베이스입니다. 커다란 텍스트, 이미지, 비디오 등을 유지하기위한 좋은 옵션입니다. 트랜잭션을 제외한 데이터베이스를 사용하는 거의 모든 작업을 수행 할 수 있습니다. 예를 들어 블로그 나 소셜 네트워크를 개발하려면 MongoDB가 적절한 선택입니다. 수평 확장 전략으로 확장 가능합니다. 디스크를 저장 매체로 사용하므로 데이터가 지속됩니다.
프로젝트가 중단되면 환경에 충분한 RAM 메모리를 확보 할 수 있습니다. 답변은 Redis입니다. 특히 클러스터 기능을 갖춘 새로운 Redis 3.2를 고려하십시오.