몽고DB의 확장에 문제가 있다는 이야기를 들어보셨을 겁니다. out. Viber가 MongoDB를 Couchbase Server로 대체한다는 소식을 들으셨을 것입니다. MongoHQ로 확장하는 방법에 대해 들어보셨나요?
저는 한 가지 몽고에이치큐의 의견에 동의합니다. 확장하기가 더 쉽습니다. up. 확장하는 동안 up 가 유일한 솔루션일 수는 있지만, 올바른 솔루션은 아닙니다. 더 이상 확장할 공간이 없을 때 일어나는 일 up? 몽고HQ는 스케일아웃을 선호할 것 같지만, 몽고DB가 이를 위해 설계되지 않았다는 것을 깨달았습니다.
기능 손실이 발생합니다...
예를 들어, MongoDB에서 수평 스케일은 주어진 컬렉션에 대한 고유한 보조 인덱스(현재 MongoDB가 지원하는 몇 안 되는 스키마 제약 조건 중 하나)를 잃는다는 의미입니다.
어려운 결정이 필요합니다...
몽고DB에서 이 선택은 숙련된 몽고DB 사용자들이 두려움에 떨며 이야기하는 '샤드 핵심 결정'입니다.
구성 및 유지 관리가 복잡합니다...
그러나 일단 샤딩된 데이터베이스를 프로덕션 환경에 도입하면, 움직이는 부분이 많다는 것은 더 많은 문제가 발생할 수 있다는 것을 의미하므로 시스템에 이상적인 것보다 더 많은 '움직이는 부분'이 있다는 근본적인 현실이 존재합니다.
성능 저하를 초래합니다...
샤드 설정에서는 몽고 라우터, 구성 서버, 각 샤드 간의 네트워크 연결이 전체 성능에 영향을 미칩니다.
반면에 카우치베이스 서버는 스케일아웃이 가능하도록 설계되었습니다. 기능 손실이 발생하지 않습니다. 어려운 결정이 필요하지 않습니다. 구성 및 유지 관리가 복잡하지 않습니다. 성능 저하가 발생하지 않습니다.
- 카우치베이스 서버는 샤딩을 수동으로 구성할 필요가 없습니다. 자동으로 구성됩니다.
- 카우치베이스 서버에는 움직이는 부분이 많지 않습니다. 노드 유형은 하나뿐입니다.
- 카우치베이스 서버를 확장하면 성능이 향상됩니다.
oplog 테일링에 대한 부분은 다소 번거로웠던 것 같습니다. MongoDB가 스케일 아웃을 위해 설계되지 않았다는 사실을 강조한 것 같습니다. 관리자와 개발자는 인사이트와 통합을 위해 로그 파일에 의존하는 것으로 나타났습니다. MongoDB 확장의 문제점은 개발자가 여러 개의 로그 파일을 추적해야 한다는 것입니다. 노드당 로그 파일이 있습니다.
반면에 Couchbase Server는 관리자와 개발자가 인사이트와 통합을 위해 로그 파일을 추적할 필요가 없습니다. 관리자는 모든 노드에서 Couchbase Server를 모니터링할 수 있습니다. 개발자는 개별 Couchbase Server 노드와 상호 작용할 필요 없이 Elasticsearch 또는 Apache Hadoop과 통합할 수 있습니다. 토폴로지는 투명합니다. 이것이 바로 아무것도 공유하지 않는 아키텍처를 갖춘 분산 시스템의 장점입니다.
한 가지 짚고 넘어가야 할 점은 Couchbase Server는 데이터 센터 간 복제를 지원한다는 점입니다. 이를 통해 클러스터의 데이터를 다른 클러스터로 복제할 수 있습니다. 실제로 이것이 우리가 Elasticsearch와 통합하는 방식입니다. Couchbase Server가 데이터를 복제할 수 있는 다른 클러스터입니다. 그것이 Elasticsearch 클러스터라는 것은 중요하지 않습니다. 단순히 데이터를 복제할 수 있는 다른 클러스터일 뿐입니다.
reddit에서 대화에 참여하세요(링크).
해커 뉴스에서 대화에 참여하세요(링크).
추가 읽기
수직 확장을 시작하는 이유(Google 웹 캐시)
참고: 몽고 HQ에서 원래 게시물을 삭제하고 새 게시물로 리디렉션하고 있습니다.
참고: 여기에는 다음과 같은 개요가 포함됩니다. 움직이는 부품 를 확장된 MongoDB 배포 내에서 사용할 수 있습니다.
카우치베이스 서버 엘라스틱서치 통합(페이지 | doc)
카우치베이스 서버 아파치 하둡 통합(페이지 | doc)
그래서 카우치베이스가 더 낫다고요?
어느 쪽이 더 낫다거나 나쁘다고 말하긴 어렵습니다. 필요에 따라 달라집니다. 충분히 조사를 해보면 모든 NoSQL 공급업체가 Riak을 포함한 다양한 데이터 저장소로의 마이그레이션 사례를 가지고 있다는 것을 알 수 있습니다. 단 두 센트만...
{전체 공개 바쇼 직원}
하지만 이것은 확장이라는 훌륭한 주제입니다. 몇 가지 생각을 해봅시다:
그러나 Couchbase가 노드를 추가할 때 vBuckets 복제본이 동일한 참여자가 아닌 경우 다양한 워크로드 성능(즉, 쓰기/읽기 비율)을 어떻게 확장할 수 있는지, 두 가지 복제 전략이 있습니다: 1:n 마스터/슬레이브 및 1...n 체인.
'대규모'에서는 장애가 더 많이 발생하는데(예: 노드 타임아웃, 스플릿 브레인, 부분 장애), 시스템에서 장애를 어떻게 처리하고 사람의 개입이 어느 정도 필요한가요?
이 글은 Riak이 이러한 작업을 '더 잘' 수행하기 때문에 Riak을 자극하고 우호적인 시각으로 보려는 것이 아니라 ....... 어떤 자료를 읽을 때 생각하고 질문하도록 하기 위한 것입니다. Riak에는 JSON 필드 쿼리 등과 같은 자체적인 제한 사항이 있으며, Couchbase는 Memcache API를 사용하는 사람들에게 환상적입니다.
결국 기술은 하나의 도구일 뿐이며 용도/사례별로 평가해야 합니다. 랄루카님께 도움이 되셨기를 바랍니다. 건배! :)
안녕하세요 Frank,
저는 리악에 대해 나쁜 말을 한 적이 없고 지금도 그렇게 생각하지 않습니다. 그렇긴 하지만 귀하의 의견을 완전히 이해했는지 잘 모르겠습니다. 노드가 추가되면 vBuckets가 클러스터 전체에 고르게 분산됩니다. 노드를 추가하면 각 노드가 더 적은 수의 vBuckets에 대해 읽기 및 쓰기를 처리하므로 성능이 향상됩니다. 복제 전략은 하나뿐입니다. 모든 복제본(일대다)에 씁니다. 복제본에 대한 쓰기를 데이지 체인으로 연결하지 않습니다.
네, 하지만 제 말을 믿으실 필요는 없습니다. 몽고DB의 성능 문제는 잘 알려져 있다고 생각합니다.
몽고DB 커뮤니티에서 샤딩이 필요하지 않다고 말하는 사람들을 찾기 위해 멀리 찾아볼 필요가 없습니다. 누군가가 필요하지 않다고 말하는 것은 그들이 그것을 할 수 없기 때문입니다. 가장 먼저 떠오르는 예는 복사 및 붙여넣기 기능이 있는 iPhone입니다.)
인포머셜처럼 들리네요 ...
카우치베이스와 몽고DB를 비교하기는 어렵습니다.
MongoDB는 범용 NoSQL인 반면, Couchbase는 캐싱용으로 설계되어 대부분의 데이터 세트가 메모리에 있어야 하고 복잡한 쿼리 등이 필요하지 않습니다.
또한 Couchbase의 해싱은 노드가 다운되면 전체 데이터 세트가 영향을 받기 때문에 가용성이 낮아집니다.
1. Couchbase Server는 캐싱용으로 설계되지 않았습니다. 캐시, 키/값 저장소, 문서 데이터베이스로 배포하거나 이 세 가지 모두로 배포할 수 있습니다. 이것이 바로 훌륭한 아키텍처의 장점이며, 처음부터 제대로 이해해야 하는 부분입니다. 이것이 바로 MongoDB에 문제가 있는 이유입니다.
2. 해싱은 가용성과는 아무런 관련이 없습니다. 아니요, 노드 장애는 전체 데이터 세트에 영향을 미치지 않습니다. 복제본을 구성할 수 있습니다. 노드에 장애가 발생하면 복제본 중 하나를 '승격'할 수 있습니다. 가용성 손실은 없습니다. 복제본이 없더라도 노드에 장애가 발생하면 해당 노드의 데이터만 손실됩니다.
1. Couchbase가 작동하려면 대부분의 데이터 집합이 메모리에 있어야 하는 경우 캐싱에 최적화되어 있습니다.
2. (범위 파티셔닝을 사용할 수 있는 몽고DB와 달리) Couchbase에서는 일관된 해싱으로 인해 데이터가 어디에 있는지 제어할 방법이 없습니다. 따라서 노드가 다운되면 문서가 여러 노드로 분산되기 때문에 많은 요청이 실패할 수 있습니다(30초 후 장애 조치가 완료될 때까지). 해싱 알고리즘을 추가하면 이 문제를 해결할 수 있습니다.
1. 왜 대부분의 데이터가 메모리에 있어야 한다고 계속 말하나요? MongoDB는 메모리 매핑된 파일을 사용하지 않나요? "캐시"는 데이터가 일시적이거나 별도의 데이터베이스에 유지된다는 것을 의미합니다. Couchbase Server가 키/값 저장소 또는 문서 데이터베이스로 사용되는 경우 둘 다 해당되지 않습니다.
2. 범위 분할의 문제점은 데이터베이스가 꽉 찰 때까지 성능이 제한된다는 것입니다. 이것이 대부분의 (NoSQL) 데이터베이스가 일관된 해싱에 의존하는 이유입니다.
3. 카우치베이스 서버는 CP 분산 시스템입니다. 일관성을 유지합니다. 예, 노드를 페일오버하기 전에 30초를 기다립니다. 이는 해당 노드가 느린 것이 아니라 다운되었는지 확인하기 위한 것입니다. 속도가 느리면 해당 노드가 소유하고 있는 데이터를 사용할 수 없을 수도 있습니다. 요청에 응답하는 데 너무 오래 걸릴 때마다 모든 노드를 페일오버하고 싶지는 않을 것입니다. 불안정해질 수 있습니다. 문제가 있는 노드가 소유한 데이터는 30초 동안 사용할 수 없을 수도 있지만, 다른 노드가 소유한 데이터는 사용할 수 있습니다.