MongoDB에서 CouchDB를 사용하는 경우와 그 반대의 경우

이 두 NoSQL 데이터베이스 사이에 붙어 있습니다.

내 프로젝트에서 데이터베이스 내에 데이터베이스를 만들 것입니다. 예를 들어 동적 테이블을 만들려면 솔루션이 필요합니다.

따라서 사용자는 열과 행이있는 테이블을 만들 수 있습니다. MongoDB 또는 CouchDB가 이것에 좋을 것이라고 생각하지만 어느 것이 확실하지 않습니다. 효율적인 페이징도 필요합니다.

C, A & P (Consistency, Availability & Partition tolerance) 중 어느 것이 더 중요합니까? NoSQL 시스템에 대한 비주얼 가이드 빠른 참조

• MongodB : 일관성 및 파티션 허용
• CouchDB : 가용성 및 파티션 공차

블로그 게시물, 카산드라는 MongoDB를 대 CouchDB를 대 레디 스 대 Riak 대 HBase를 대 Membase 대 Neo4j 비교 대 '한 최저 사용 에 비해 각되는 NoSQL 데이터베이스에 대한 시나리오를'. 링크를 인용하면

• MongoDB : 동적 쿼리가 필요한 경우 함수를 매핑 / 축소하지 않고 인덱스를 정의하려는 경우. 큰 DB에서 좋은 성능이 필요한 경우. CouchDB를 원했지만 데이터가 너무 많이 변경되어 디스크를 채우는 경우.
• CouchDB : 미리 정의 된 쿼리를 실행할 누적 데이터, 때때로 변경되는 데이터 용. 버전 관리가 중요한 곳.

Riyad Kalla 의 최근 (2012 년 2 월) 및보다 포괄적 인 비교 ,

• MongoDB : 마스터-슬레이브 복제 만
• CouchDB : 마스터-마스터 복제

두 가지를 모두 시도한 누군가의 블로그 게시물 (2011 년 10 월) 인 A MongoDB Guy 는 CouchDB가 CouchDB의 페이징이 유용하지 않다고 언급했습니다.

날짜가 (2009 6월가) 벤치 마크 에 의해 크리스티나 초도 로우 ( MongoDB를 뒤 팀의 일원 )

MongoDB에 갈 것입니다.

도움이 되길 바랍니다.

무엇보다도 그 대답은 이야기를 복잡하게합니다.

1. 모바일 구성 요소를 사용하거나 데스크톱 사용자가 오프라인으로 작업 한 다음 작업을 서버에 동기화하려면 CouchDB가 필요합니다.
2. 코드가 서버에서만 실행될 경우 MongoDB를 사용하십시오.

그게 다야. 모바일 및 데스크탑 장치에 복제 할 수있는 CouchDB의 (멋진) 기능이 필요하지 않은 한, MongoDB는 현재 성능, 커뮤니티 및 툴링 이점을 가지고 있습니다.

아주 오래된 질문이지만 Google 위에 있으며 여기에 나와있는 답변이 마음에 들지 않습니다.

CouchApps를 개발하는 능력보다 Couchdb에는 훨씬 더 많은 것이 있습니다. 대부분의 사람들은 클래식 3 계층 웹 아키텍처에서 CouchDb를 사용합니다.

실제로 대부분의 사람들이 결정하는 요소는 MongoDb가 SQL과 같은 구문으로 임시 쿼리를 허용하지만 CouchDb는 그렇지 않지만 (이 뷰를 생성하더라도 일부 사람들을 끄는 맵 / 축소 뷰를 만들어야 함) 사실입니다. 빠른 응용 프로그램 개발에 익숙합니다. 저장 프로 시저와 아무 관련이 없습니다.

허용 된 답변에서 제기 된 요점을 해결하려면 : CouchDb에는 훌륭한 버전 관리 시스템이 있지만 버전 관리가 중요한 장소에만 적합하다는 것을 의미하지는 않습니다. 또한 couchdb는 추가 전용 특성으로 인해 쓰기에 매우 친숙합니다 (데이터가 손실되지 않도록 보장하면서 쓰기 작업이 즉시 완료됩니다).

누구도 언급하지 않은 매우 중요한 것은 CouchDb가 b-tree 인덱스에 의존한다는 사실입니다. 이것은 당신이 1 "행"을 가지고 있든 200 억을 가지고 있든, 쿼리 시간은 항상 10ms 미만으로 유지됨을 의미합니다. 이것은 CouchDb를 대기 시간이 짧고 읽기 쉬운 데이터베이스로 만드는 게임 체인저이며 실제로 간과해서는 안됩니다.

공정하고 철저한 MongoDb가 CouchDb보다 우위를 점하는 것은 툴링 및 마케팅입니다. 모든 주요 언어 및 플랫폼을위한 최고 수준의 시민 도구가있어 온 보딩이 쉬워지고 애드혹 쿼리에 추가되어 SQL에서 더 쉽게 전환 할 수 있습니다.

CouchDb에는 현재 사용할 수있는 라이브러리가 많더라도 CAPID 수준의 툴링이 없지만 CouchDb는 HTTP API로 노출되어 있으므로 선호하는 언어로 래퍼를 작성하여 대화하기가 매우 쉽습니다. 나는 팽창을 피하고 원하는 것을 취할 수 있기 때문에 개인적 으로이 접근법을 좋아합니다 (인터페이스 분리 원리).

그래서 나는 하나 또는 다른 것을 사용하는 것이 그들의 패러다임에 대한 위안과 선호의 문제라고 말합니다. CouchDb 접근 방식은 특정 사람들에게는 "적합"하지만 데이터베이스 기능에 대해 배운 후에 (완전한 공식 안내서에서 ) "지옥 한"순간이 없다면 아마도 계속 나아가 야 할 것입니다.

"올바른 작업에 적합한 도구"를 사용하려는 경우 CouchDb를 사용하지 않는 것이 좋습니다. 당신은 그런 식으로 그것을 사용할 수 없다는 것을 알게 될 것이고 결국 "CouchDb의 조인은 어디에 있습니까?"와 같은 블로그 게시물을 작성하게 될 것입니다. "트랜잭션 관리는 어디에 있습니까?" 실제로 Couchdb는 역설적으로 매우 투명하지만 동시에 패러다임 전환과 문제에 접근하는 방식을 바꿔야 실제로 빛을 발하고 작동합니다.

그러나 일단 당신이 그 일을 실제로 지불하면. 다른 데이터베이스를 선택하려면 프로젝트에 개인적으로 매우 강력한 이유나 주요 거래 차단기가 필요하지만 지금까지 나는 어떤 것도 충족하지 못했습니다.

이 질문을 직접 하시겠습니까? 그리고 당신은 당신의 DB 선택을 결정할 것입니다.

1. 마스터 마스터 가 필요하십니까 ? 그런 다음 CouchDB. 주로 CouchDB는 마스터-마스터 복제를 지원하여 장기간 노드 연결이 끊길 것으로 예상합니다. MongoDB는 그 환경에서 좋지 않습니다.
2. MAXIMUM R / W 처리량 이 필요 합니까? 그런 다음 MongoDB
3. 단일 DB 서버 만 있기 때문에 최고의 단일 서버 내구성 이 필요 합니까? 그런 다음 CouchDB.
4. 미친 처리량을 유지하면서 샤딩이 필요한 대규모 데이터 세트 를 저장하고 있습니까? 그런 다음 MongoDB.
5. 강력한 데이터 일관성 이 필요하십니까 ? 그런 다음 MongoDB.
6. 고 가용성 데이터베이스 가 필요하십니까 ? 그런 다음 CouchDB.
7. 당신은 희망하고 다중 데이터베이스 및 멀티 테이블 / 컬렉션을? 그런 다음 MongoDB
8. 당신은이 사용자가 오프라인 모바일 앱 및 서버에 자신의 활동 데이터를 동기화 할? 그런 다음 CouchDB가 필요합니다.
9. 다양한 쿼리 엔진 이 필요하십니까 ? 그런 다음 MongoDB
10. DB를 사용 하려면 대규모 커뮤니티 가 필요 합니까? 그런 다음 MongoDB

이 기사에서 찾은 답변을 요약합니다.

http://www.quora.com/How-does-MongoDB-compare-to-CouchDB-What-are-the-advantages-and-disadvantages-of-each

MongoDB : 더 나은 쿼리, BSON의 데이터 스토리지 (빠른 액세스), 더 나은 데이터 일관성, 여러 컬렉션

CouchDB : 마스터에서 마스터로의 복제 및 충돌 해결, JSON의 데이터 스토리지 (휴식 가능, REST 서비스를 통한 더 나은 액세스), 맵 감소를 통한 쿼리를 통한 복제 향상.

결론적으로 MongoDB는 더 빠르며 CouchDB는 더 안전합니다.

또한 : http://nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb

MongoDB의 희소 고유 인덱스 관련 문제에 유의하십시오. 나는 그것을 명중했으며 해결 방법은 매우 번거 롭습니다.

문제는 이것입니다. 필드가 있으면 고유하며 필드가없는 모든 객체를 찾으려고합니다. 희소 고유 인덱스가 Mongo에서 구현되는 방법은 해당 필드가없는 객체가 전혀 인덱스에 {$exists: false}없는 것입니다. 해당 필드의 쿼리로 검색 할 수 없으며 작동하지 않습니다.

내가 찾은 유일한 해결 방법은 빈 값이 uuid에 연결된 특수 접두사 (예 : null :)로 변환되는 특수 null 계열 값 을 갖는 것입니다. 쓰기 / 쓰기 / 읽기를 할 때 빈 값으로 변환하거나 빈 값에서 변환해야하기 때문에 이는 매우 어려운 문제입니다. 큰 성가신.

나는 MongoDB에서 서버 측 자바 스크립트 실행을 사용한 적이 없으며 (어쨌든 권장하지는 않음) Mongo 노드가 하나만있을 때 맵 / 축소가 끔찍한 성능을 발휘합니다. 이 모든 이유 때문에 이제 CouchDB를 확인하려고합니다. 아마도 특정 시나리오에 더 적합 할 수 있습니다.

BTW, 희소 고유 인덱스 문제를 설명하는 각 몽고 문제에 대한 링크를 알고 있다면 공유하십시오.

나는 당신이 Mongo (더 익숙한)로 할 수 있다고 확신하고, 소파로도 할 수 있다고 확신합니다.

둘 다 문서 지향 (JSON 기반)이므로 문서에는 "열"이 아니라 필드가 있지만 완전히 동적 일 수 있습니다.

그들은 모두 당신이 사용하는 다른 요소, 당신이 관심있는 다른 기능, 인기 등을보고 싶을 수도 있습니다.

당신은 그것을 시도 할 수 있습니다 당신은 5 분 안에 몽고를 가질 수 있어야한다고 생각합니다.