MongoDB 또는 CouchDB-프로덕션에 적합합니까? [닫은]

MongoDB 또는 CouchDB 가 프로덕션 환경에 준비되어 있는지 누군가가 말해 줄 수 있는지 궁금 합니다.

나는 지금이 스토리지 솔루션을보고 있습니다 (현재 MongoDB를 선호합니다). 그러나이 프로젝트는 상당히 젊으므로 관리자가 우리가 이것을 채택해야한다고 확신시키기 위해 열심히 노력해야 할 것으로 예상됩니다 새로운 기술.

내가 알고 싶은 것은 :

1. 오늘날 프로덕션 환경에서 누가 MongoDB 또는 CouchDB를 사용하고 있습니까?

2. MongoDB / CouchDB를 어떻게 사용하고 있습니까?

3. 이 새로운 스토리지 메커니즘을 채택했을 때 어떤 문제가 있었습니까 (그리고 어떻게 극복 했습니까)?

4. 처리해야 할 마이그레이션 문제를 어떻게 처리 했습니까?

5. 공유하고 싶은 솔루션 중 하나에 대해 좋은 / 나쁜 경험이 있습니까?

저는 10gen (MongoDB 개발자)의 CTO이므로 약간 편향되어 있지만 프로덕션 환경에서 MongoDB를 사용하는 일부 사이트도 관리합니다.

사업자 는 현재 1 년 이상 몽고를 생산하고 있습니다. 그들은 사용자와 블로그 게시물에서 사이트의 모든 이미지에 이르기까지 모든 것을 위해 그것을 사용하고 있습니다.

shopwiki 는 실시간 분석 및 캐싱 계층을 포함한 몇 가지 용도 로이를 사용하고 있습니다. 그들은 상당히 큰 데이터베이스에 초당 1000 회 이상의 쓰기를 수행하고 있습니다.

mongodb Production Deployments 페이지 로 이동하면 프로덕션 에서 mongo 를 사용하는 사람들이 있습니다.

프로덕션 배포의 규모 나 범위에 대해 궁금한 점이 있으면 사용자 목록에 게시하면 기꺼이 도와 드리겠습니다.

BBC 와 meebo.com는 생산에 CouchDB를 사용하고 나의 클라이언트 중 하나 않습니다. 소파를 사용하는 다른 사람들의 목록은 다음과 같습니다.CouchDB를

주요 과제는 문서를 구성하고 관계형 데이터 측면에서 생각을 멈추는 방법을 아는 것입니다.

SourceForge 는 MongoDB를 사용합니다. 참조 이 프리젠 테이션을 하거나 여기에 읽기 .

우리는 상점을위한 MySQL의 대용품으로 CouchDB를 운영하고 있습니다 (점당 70.0000 품목, 모든 품목의 총 4 백만 속성, 품목 간 상호 연결).

우리의 목표는 다음과 같습니다.

1. master-db에서 다른 문서를 가진 여러 클라이언트로 쉽게 복제 할 수 있습니다.

2. "이 속성에 해당하는 부품 수와 해당 조건에 맞는 필터 수"와 같은 빠른 사전 계산 데이터

사리:

1. 우리 상점은 이제 MySQL보다 훨씬 빠르게 실행되고 있으며 mysql-database는 1 ~ 3 일의 사전 계산이 필요하기 때문에 (한 달에 두 번 업데이트) 데이터 계산 및 필터링 준비가 완료되었으며 CouchDB는 5 시간이 소요됩니다. 매일 밤 제품 데이터를 업데이트 할 수 있습니다)
2. 작업장 노드에 대한 (필터링 된) 데이터 배포 및 백업 설정이 빠르고 쉽습니다.

또한 :

1. 맵 / 축소와 조인이없는 한계를 이해하는 것은 매우 어렵습니다.
2. 외부 프로그램없이 "where where"또는 "update where"와 같은 데이터에 대한 작업이 없습니다
3. 문제가 없으면 복제가 잘 작동합니다. 그 이유가 무엇인지 찾기가 정말 어렵습니다 (초보자)
4. 리눅스 괴짜가 아니라면 바이너리없이 CouchDB를 설치하는 것은 어렵습니다 (그렇습니다. 그러나 CouchDB 커뮤니티는 도움이되고 (#couchdb) 운 좋게도 무료 비즈니스에서 대기업에 이르는 서비스를 제공하는 회사가 있습니다.
5. CouchDB는 앞으로 나아가고 있으므로 작업 방식에 변화를 줄 수있는 많은 변화 (개선)가 진행되고 있습니다. 그러나 기본적인 것은 안정적입니다.

결과 : 데이터 생성 및 유지 관리를위한 데이터베이스 인 MySQL은 신뢰할 수 있고 이해하기 쉽고 처리하기 쉽습니다. 나는 우리가 이것을 바꾸지 않을 것이라고 생각합니다. 그러나 CouchDB 뷰의 힘과 복제 설정의 용이성을 놓치지 않으려 고합니다.

프로덕션 소파는 구성 오류 및 잊어 버린 로그 로테이션 (빌딩이 너무 오래 걸리거나 중단, 복제 중지)으로 인해 수 개월 동안 작업 한 후에 문제를 일으켰지 만 데이터 손실이 없어 항상 쉽게 재설정 할 수있었습니다.

프로덕션에서 CouchDB를 사용하고 있습니다. 현재는 원래 DB 스키마에 없었던 모든 '선택적'필드를 저장합니다. 그리고 지금은 모든 데이터를 CouchDB로 옮길 생각입니다.

매우 위험한 단계입니다. 첫째, 아직 v1.0이 아니기 때문입니다. 둘째, 드라이브 공간이 부족하기 때문입니다. 내 계산에 따르면 CouchDB 파일 (인덱스 포함)은 동일한 행을 가진 MySQL 데이터베이스보다 ~ 30 배 더 큽니다. 그러나 나는 그것이 잘 작동 할 것이라고 확신합니다.

CouchDB 0.11 (3 월 말에 출시)은 1.0의 기능 정지 버전입니다. 즉, 현재 API 1.0과의 호환성을 유지할 것이므로 CouchDB를 다시 한 번 살펴 보는 것이 좋습니다.

CouchDB를 0.11 소스 코드 버전은 여기에서 확인할 수 있습니다. 바이너리 인스톨러와 다른 것들이 여기에 링크되어 있습니다.

MongoDB에 대해서는 아무것도 모르지만 CouchDB FAQ는 다음과 같습니다.

CouchDB는 생산 준비가 되셨습니까?

예, CouchDB를 사용하는 부분 프로젝트 목록 은 InTheWild 를 참조하십시오 . 또 다른 좋은 개요는 CouchDB 사례 연구입니다.

또한 일부 링크 :

• 다시 : 현재 CouchDB 상태?
• SimpleDB, CouchDB 및 기타 "NEW"데이터 저장소-피드백

우리는 프로덕션 환경에서 couchdb를 사용하며 프로젝트가 Apache 우산 아래에 오기 직전부터 있습니다.

우리는 다른 방법으로 dbms를 사용할 수있는 모든 것과 구조화되지 않은 모든 종류의 데이터를 저장합니다. 개인적으로 모든 종류의 데이터를 던져서 뷰를 사용하여 상황에 따라 필요하지 않은 것을 제거하는 방법을 정말로 좋아합니다.

가장 어려운 부분은 dbms 사고 방식에서 멀어졌습니다. 스토리지 형식이 안전한 것으로 변경되었을 때 자체 마이그레이션 유틸리티를 작성 했으므로 실제로 문제가되지 않았습니다.

우리는 아직 부정적인 경험을하지 않았지만 다시 한 번 큰 부하로 설정을하지 못했습니다. 내가 생각하는 일이 꽤 잘 우리가 쓰기 모두를 얻을 하나의 마스터 서버에서 복제 개의 슬레이브 형 서버가 있기 때문에 작동합니다. 복제가 올바르게 작동하기 위해 그렇게 할 필요는 없지만, 처음에이를 설정하고 고착시키는 방식입니다.

우리는 CouchDB를 사용하여 모바일 인바운드 및 아웃 바운드 메시지를 저장하고 내가 작성한 일부 사용자 정의 뷰를 통해이 트래픽을보고합니다. 프론트 엔드는 Python으로 작성되었습니다. 실제 기술적 인 문제는 없었으며 12 월 말부터 계속 운영되고 있습니다. 내가 만난 유일한 장애물은 처음에 MapReduce와 관련하여 생각하는 것이었지만 일단 그 방법을 알게되면 다른 모든 것이 순조롭게 진행되었습니다.

현재 프로덕션에서 MongoDB를 캐싱 레이어 및 제품 가져 오기 및 제품 데이터 조작을위한 스토리지 엔진으로 사용하고 있습니다. 우리는 10 개 이상의 유통 업체에 걸쳐 2 백만 개 이상의 제품 (1 억 개 이상의 속성)을 관리하는 전자 상거래 회사이며 MongoDB가 없으면이 작업은 거의 불가능합니다.

현재 LAN을 통한 협업을 위해 mongodb를 파일 스토리지 서비스로 사용하고 있습니다. 또한 trello 와 같은 프로젝트 는 mongodb를 백엔드 데이터 저장소로 사용합니다. 나는 couchdb를 더 일찍 사용했지만 생산 능력은 아닙니다.

모바일 백엔드 서비스 인 Netmera 에서 프로덕션 환경에서 MongoDB를 사용하고 있습니다. 우리는 모든 사용자 및 콘텐츠 데이터를 저장하는 데 사용하고 있습니다.

저는 거의 2 년 동안 프로덕션 환경에서 CouchDB를 사용해 왔습니다. 프로젝트가 CouchDB 구현으로 직접 시작되었으므로 마이그레이션 작업이 없습니다. 처음부터 포장까지 단일 전자 제품의 데이터를 저장하는 데이터베이스 역할을합니다.

우리는 높은 정확도를 요구하는 센서를 판매하기 때문에 다른 단계에서 많은 테스트를 수행하며 모든 것은 CouchDB의 하나의 문서에 저장됩니다.

내 경험에서 배운 몇 가지 학습 곡선이 있는데, 이는 뷰 (또는 영구 뷰라고도 함)를 최대한 활용하는 것입니다. 뷰는 자주 호출되는 데이터베이스의 일부에 대한 "작은 필터"여야합니다.

내 CouchDB 데이터베이스는 다른 거대한 회사만큼 미친 것이 아닙니다. 그러나 지금까지는 여전히 잘하고 있습니다. 현재 700MB에 24000 개의 문서가 있습니다.

내가 좋아하는 CouchDB의 기능은 '복제', '문서의 개정판'입니다.

MongoDB에 대한 좋은 리뷰를 많이 읽었으며 기회가 있다면 시도해보고 싶습니다.

우리는 프로덕션에서 mongodb를 사용하고 있습니다.

www.beachfront.io-초당 5k 쓰기 요청 www.beachfrontbuilder.com-초당 500 읽기 / 쓰기 요청, 10m 사용자 데이터 및 olap 유지.

데이터 보관과 관련하여 직면 한 유일한 과제는 사용자 지정 구성 요소를 구현하여 극복하는 것입니다.

이 질문에 대한 답변은 이미 받아 들여졌지만 이제는 NoSQL DB 가 여러 가지 훌륭한 기능으로 인해 유행하고 있습니다. 그것은이다 Couchbase; CouchbaseLite모바일 플랫폼과 Couchbase Server서버 측에서 실행됩니다 .

Couchbase Lite의 주요 기능은 다음과 같습니다.

Couchbase Lite는 경량의 문서 지향 (NoSQL) 동기화 가능 데이터베이스 엔진으로 모바일 앱에 포함하기에 적합합니다.

경량의 의미 :

임베디드 — 데이터베이스 엔진은 별도의 서버 프로세스가 아니라 앱에 연결된 라이브러리입니다. 작은 코드 크기 — 모바일 앱에 중요하며 종종 셀 네트워크를 통해 다운로드됩니다. 빠른 시작 시간 — 모바일 장치의 CPU 속도가 상대적으로 느리므로 중요합니다. 낮은 메모리 사용량 — 일반적인 모바일 데이터 세트는 비교적 작지만 일부 문서에는 큰 멀티미디어 첨부 파일이있을 수 있습니다. 우수한 성능 — 정확한 수치는 물론 데이터와 응용 프로그램에 따라 다릅니다.

문서 지향적 수단 :

사전 정의 된 스키마 또는 정규화를 요구하지 않고 유연한 JSON 형식으로 레코드를 저장합니다. 문서에는 멀티미디어 컨텐츠와 같은 임의 크기의 이진 첨부 파일이있을 수 있습니다. 응용 프로그램 데이터 형식은 명시적인 마이그레이션없이 시간이 지남에 따라 발전 할 수 있습니다. MapReduce 인덱싱은 특수 쿼리 언어를 사용할 필요없이 빠른 조회를 제공합니다.

동기화 가능한 수단 :

효율적이고 신뢰할 수 있으며 입증 된 복제 알고리즘을 통해 데이터베이스의 두 복사본을 동기화 할 수 있습니다. 동기화는 주문형이거나 연속적 일 수 있습니다 (몇 초의 대기 시간으로). 장치는 원격 서버에서 큰 데이터베이스의 하위 집합과 동기화 할 수 있습니다. 동기화 엔진은 간헐적이고 신뢰할 수없는 네트워크 연결을 지원합니다. 병합을 완전히 제어하는 ​​앱 논리를 사용하여 충돌을 감지하고 해결할 수 있습니다. 리비전 트리를 사용하면 서버 간 (여러 데이터 센터의 경우) 및 피어 투 피어를 포함하여 데이터 손실이나 잘못된 충돌없이 복잡한 복제 토폴로지를 사용할 수 있습니다. Couchbase Lite는 완벽한 iOS (Objective-C) 및 Android (Java) 개발을위한 기본 API를 제공합니다. 또한 PhoneGap 용 Couchbase Lite 플러그인이 포함되어 있습니다.

Couchbase Lite 에 대해 더 자세히 알아볼 수 있습니다

및 카우치베이스 서버

이것은 다음 큰 일로 가고 있습니다.

말하기, 원활한 페일 오버 / 복구에는 모두 베이비 시터
1- 카우치베이스가 필요하고, 완벽한 페일 오버 / 복구 는 없으며, 수동 개입이 필요합니다.
재조정은 두 개 이상의 노드가 손실되면 너무 많은 시간과 위험을 초래합니다.

2- 설정 서버를 잃어버린 데이터를 복구하는 샤드가있는 몽고

Adobe 는 곧 출시 될 Adobe Experience Manager (이전의 Day CQ)에 MongoDB 를 사용하고 있습니다. )를 핵심 DB 엔진으로 있습니다.

내가 근무하는 대행사의 여러 고객이 대규모 고객 용 프로젝트에서 CouchDB 를 사용하고 있습니다.

제 생각에는 둘 다 훌륭하고 실행 가능한 DB입니다. :)

다음은 mongoDB가있는 프로덕션 배포 사이트 목록입니다.

• 뉴욕 타임즈 : 사진 제출을 위해 양식 작성 응용 프로그램에서 사용. Mongo의 스키마가 없기 때문에 생산자는 사용자 정의 양식 필드의 조합을 정의 할 수 있습니다.
• SourceForge : SourceForge 첫 페이지, 프로젝트 페이지 및 모든 프로젝트의 다운로드 페이지에서 백엔드 스토리지에 사용됩니다.
• Bit.ly
• 에시
• IGN : IGN의 실시간 트래픽 분석 및 RESTful 컨텐츠 API를 강화합니다.
• Justin.tv : 즉시 사용 가능한 솔루션으로는 제공 할 수없는 바이러스 성, 사용자 유지 및 일반 사용 통계를 위해 Justin.tv의 내부 분석 도구를 강화합니다.
• 포스터
• 인튜이트
• Foursquare : Sharded Mongo 데이터베이스는 foursquare의 대부분의 데이터에 사용됩니다.
• Business Insider : 2008 년 초부터 사용했습니다. 게시물, 댓글 및 이미지를 포함한 모든 사이트 데이터가 MongoDB에 저장됩니다.
• Github : 내부보고 응용 프로그램에 사용됩니다.
• 시험관 : Cold Fusion 및 SQL Server에서 Drupal 7 및 MongoDB로 사이트를 마이그레이션했습니다.
• Grooveshark : 현재 Mongo를 사용하여 하루에 백만 개 이상의 고유 한 사용자 세션을 관리합니다.
• 버즈 피드
• 원반
• Evite : 분석 및 빠른보고에 사용됩니다.
• 제곱
• Shutterfly : Shutterfly 내의 다양한 영구 데이터 저장 요구 사항에 사용됩니다. MongoDB는 Shutterfly가 고객과 자신의 삶에서 가장 중요한 사람들 사이의 더 심층적이고 개인적인 관계를 가능하게하는 독보적 인 서비스를 구축하도록 돕습니다.
• 톱시
• 이 공유
• Mongohq : MongoDB를위한 호스팅 플랫폼을 제공하고 MongoDB를 서비스의 백엔드로 사용합니다. 우리의 호스팅 센터 페이지는 MongoHQ 및 기타 MongoDB 호스팅 옵션에 대한 자세한 정보를 제공합니다.

그리고 더...

에서 추출 : http://lineofthought.com/tools/mongodb

다른 데이터베이스 나 도구도 확인할 수 있습니다.

MongoDB는 비즈니스 라이센스에 몇 가지 문제가 있습니다. 자세한 내용은 확실하지 않지만 법률 부서는 MongoDB를 어떤 제품에도 사용할 수 없다는 특정 조건을 알려주지 않았습니다.