mongodb는 왜 안돼요?

mongodb는 왜 안돼요?

저는 최근에 MongoDB를 처음으로 사용해 봤는데, 사용하기가 매우 쉽고 성능이 뛰어나다는 것을 알게 되었습니다.그것은 제 질문으로 이어집니다 - 왜 MongoDB가 아닌가요?

제가 Q&A 앱을 구현하고 있다고 가정해 보겠습니다.MySQL 데이터베이스에 사용자 데이터를 구현한 다음 질문과 모든 응답을 저장하는 하나의 컬렉션인 질의응답 스토리지에 MongoDB를 사용하는 것이 제 접근 방식입니다.

이 접근법에 잘못된 점이 있습니까?

MongoDB는 당신의 문제에 적합한 애플리케이션처럼 들리지만, 당신이 그것을 사용하지 않는 많은 이유가 있습니다.

MongoDB는 다음이 필요한 애플리케이션에 적합하지 않습니다.

1. 다중 개체 트랜잭션:MongoDB는 단일 문서에 대한 ACID 트랜잭션만 지원합니다.
2. SQL: SQL은 잘 알려져 있고 많은 사람들이 많은 일을 하기 위해 매우 복잡한 쿼리를 작성하는 방법을 알고 있습니다.이 지식은 MongoDB의 쿼리 언어가 특정한 많은 구현에 걸쳐 전달될 수 있습니다.
3. 강력한 산도 보장:MongoDB는 일관성 없는 읽기와 같은 것을 허용합니다. 일부 응용 프로그램에서는 문제가 없지만 전체적으로는 문제가 없습니다.
4. 기존 BI: OLAP 및 기타 강력한 BI 애플리케이션을 지원하고 기존 SQL 데이터베이스를 기반으로 실행되는 매우 강력한 툴이 많이 있습니다.

MongoDB는 훌륭한 데이터베이스이고 저는 그것을 사용하는 것을 즐깁니다.즉, SQL의 세계에서 온 사람이라면 몇 가지 gotchas가 있습니다.

ACID 및 기타 잘 문서화된 사항(및 다른 답변에도 포함됨) 외에도 다음과 같은 사항들이 우리를 놀라게 했습니다.

• MongoDB는 당신이 메모리를 가질 것을 기대합니다.많은 기억력.작업 세트를 메모리에 저장할 수 없으면 잊어버릴 수 있습니다.이것은 메모리를 캐시로만 사용하는 대부분의 관계형 DB와는 다릅니다!좀 더 구체적으로 말하자면, MongoDB는 RAM을 기본 스토리지로 사용하고 불필요한 부품을 디스크로 "스왑"합니다(Mongo는 어떤 부품을 커널로 "스왑"할지에 대한 결정을 남깁니다).기존 RDBMS는 디스크를 기본 스토리지로 사용하고 RAM을 캐슁 메커니즘으로 사용합니다.따라서 일반적으로 MongoDB는 더 많은 RAM을 사용합니다.이는 그 자체로 나쁜 것은 아니지만, 결과적으로 "실제" RAM 소비는 예측하기 어렵기 때문에 작업 세트가 (예측하기 어려운) 한계를 초과하면 성능이 심각하게 저하될 수 있습니다.

• 레코드를 제거할 때 저장소가 자동으로 실행되지 않습니다.컬렉션당 할당된 공간은 다음 중 하나가 될 때까지 할당된 상태로 유지됩니다.repair수집을 DB하거나 삭제합니다.또한 DB 수준(데이터 파일)에서 대량으로 할당된 다음 필요할 때 컬렉션(범위)에 할당됩니다.즉, 컬렉션의 할당된 공간 내에서 제거된 문서는 동일한 컬렉션의 다른 문서에 대한 공간을 해제합니다.이것은 개념에 대한 좋은 설명입니다: http://www.10gen.com/presentations/storage-engine-internals

• 구문 분석된 서버 측 SQL과 대조적으로 Mongo에서는 데이터 구조를 쿼리 및 CRUD 함수에 전달합니다.결과적으로 각 드라이버는 서로 다른 구문을 제공하기 때문에 약간 짜증이 납니다.예를 들어, PyMongo는 사전 대신 튜플 목록을 사용합니다 (아마도 Python의 dict는 키 순서를 보존하지 않기 때문일 것입니다).find()(공정하게 말하자면, 그것이 아마도 그것을 할 수 있는 유일한 방법이었을 것입니다 - 하지만 그것은 SQL과 같은 문자열 기반 언어를 사용하지 않은 결과입니다.)
  • 셸: MongoDB »:db.test.find({}, {a:1})
  • db.find({}, fields=[(a,1,)]

이것은 MongoDB에 대한 비판으로 간주되어서는 안 됩니다. 저는 이것을 즐겨 사용하며 신뢰할 수 있고 성능이 뛰어난 도구로 입증되었습니다.하지만 그것을 적절하게 사용하기 위해서는 그것의 공간 관리에 대해 배울 필요가 있습니다.

가능한 단점:

1. SQL 관계형 데이터베이스만 사용한 조직에서 작업합니다.NoSQL 데이터베이스 사용에 대한 승인 또는 지원이 아직 없습니다.
2. MongoDB 클러스터를 관리한 적이 없습니다. 모든 기술과 마찬가지로 학습 곡선이 있습니다.
3. 데이터는 실제로 관계형입니다(예: 한 사용자는 질문이 많고 질문에는 답변이 많음). 가능성을 간과했습니다.

MondoDB는 훌륭한 솔루션이며, 적용되는 상황에 대한 좋은 대안입니다.사용할 수 있다면 왜 안 됩니까?

데이터스토어(SQL 또는 NoSQL)에 대한 결정은 복제 요구 사항에 따라 크게 달라질 수 있습니다.

MongoDB는 MySQL-esque master-slave-*(마스터 1개, 다중 슬레이브) 구성을 따릅니다.마스터에만 쓸 수 있습니다.

지리적으로 분산된 시스템에서는 이를 허용할 수 없습니다(모든 마스터에 기록하고 서버를 조정할 수 있어야 함).

이러한 경우에는 Cassandra, Riak, CouchDB와 같은 서버가 이러한 상황에서 더 낫습니다.

따라서 MySQL이 앱에 적합하고 NoSQL로 작업하려면 Mongo가 완벽한 솔루션입니다.

@johndo는 메모리 사용을 합니다.공식 FAQ 페이지에서 다음과 같이 말합니다.

MongoDB는 RAM이 많이 필요합니까?

꼭 그렇다고 할 수는 없죠.MongoDB를 적은 양의 RAM이 있는 기계에서 실행하는 것은 확실히 가능합니다.MongoDB는 자동으로 시스템의 모든 사용 가능한 메모리를 캐시로 사용합니다.시스템 리소스 모니터를 보면 MongoDB는 메모리를 많이 사용하지만 동적으로 사용됩니다.다른 프로세스에서 갑자기 서버 RAM의 절반이 필요할 경우 MongoDB는 다른 프로세스에 캐시된 메모리를 제공합니다.

기술적으로, 운영 체제의 가상 메모리 서브시스템은 MongoDB의 메모리를 관리합니다.즉, MongoDB는 사용 가능한 메모리를 최대한 많이 사용하여 필요에 따라 디스크로 스왑합니다.RAM에 있는 애플리케이션의 작업 데이터 세트에 적합할 만큼 충분한 메모리가 있는 배포는 최상의 성능을 달성합니다.

그래서 저는 학습 곡선이 답이라고 생각합니다.기술을 더 잘 알면 알수록 시스템이 더 좋아질 것입니다.

사용자 정보에서 q&a에 이르기까지 모든 데이터를 MongoDB에 넣지 않을 이유를 찾을 수 없습니다. 단, 다음과 같은 실질적인 이유가 있습니다.

공유 호스팅 환경에서 MongoDB 호스팅을 제공하는 서비스 공급자를 찾는 것은 쉽지 않습니다.mySql과는 달리 호스팅 계획의 표준이 됩니다.

저는 여러 SQL DB 기반 시스템에서 작업해 왔으며 3년 이상 mongodb(Rails mongoid 드라이버 사용)를 수행한 후 세 가지 주요 이유가 있습니다.

• 저는 테이블에 앉을 필요가 없어서 더 빠릅니다.대부분의 경우 문서에는 필요한 모든 내용이 들어 있습니다. 그렇지 않으면 관련 문서를 빠르게 가져옵니다.
• 저는 일단 문서를 가져온 후 배열/json을 매핑하여 데이터를 수집하고 작업을 수행합니다.그래서 저는 DB에 덜 액세스하고 메모리에서 매핑/수집이 훨씬 더 빠릅니다.이것은 내장된 문서를 사용할 때 훨씬 더 효율적입니다.
• 고객이 자신의 분야를 쉽고 효율적으로 정의할 수 있도록 할 수 있습니다.SQL DB는 시도할 가치가 없습니다.

제 프로젝트의 데이터베이스를 결정하면서 mongoDB가 무료라고 들었는데 왜 mongoDB가 아닌가 하는 생각이 들었습니다.

MongoDB 고객 지원 팀에 전화를 걸었습니다.MongoDB는 현재 세 가지 버전이 있습니다.

1. 커뮤니티 서버
2. 전문적인
3. 엔터프라이즈

사실 커뮤니티 서버는 무료이고 나머지 2개는 유료 소프트웨어입니다.

내가 그 남자에게...

mongodb의 커뮤니티 서버는 어디서 사용할 수 있습니까?

이메일로 받은 답변 아래-

커뮤니티 서버의 권장 용도는 개발 환경입니다.생산 목적을 위해서는 엔터프라이즈 오퍼링이 필요합니다.

버전을 사용하기 전에 확인하십시오.

이것이 당신에게 도움이 되기를 바랍니다 :)

당신의 사용 사례에 MongoDB를 사용하지 않을 이유가 없습니다.MongoDB에 당신의 사용자 정보를 저장하고 원활한 경험을 할 것을 제안합니다.

Q&A 컬렉션에 대해 제가 제안하고 싶은 유일한 제안은 다음과 같습니다. 만약 한 질문이 이론적으로 무한한 수의 응답을 가질 수 있다면, 질문에 대한 모든 대답을 동일한 문서에 포함시킬 수 있습니다(예: "응답"이라는 배열).또는 일반적으로 문서 크기가 16MB를 초과하게 하는데, 이는 MongoDB의 문서 크기 제한입니다.일반적으로 이러한 큰 문서는 성능 저하의 원인이 될 수 있으므로 권장하지 않습니다.

Q&A 컬렉션을 모델링하기 위해 서브셋 패턴 또는 확장 참조 패턴을 사용하는 것이 좋습니다.

부분 집합 패턴 사용:이 경우 가장 최근의 답변, 상위 투표된 답변 또는 질의가 가장 자주 액세스하는 답변을 Q&A 컬렉션에 보관하고 나머지는 "응답"이라는 다른 컬렉션으로 오프로드할 수 있습니다.이 경우 질문과 관련된 모든 답변을 검색하려면 $lookup 연산자(SQL의 왼쪽 외부 조인과 동일)를 사용해야 합니다. 이는 기본 컬렉션에 포함된 문서를 검색하는 것보다 성능이 떨어집니다(예: Q&A 컬렉션).하지만 여기서 생각하는 것은 "응답" 컬렉션이 거의 또는 덜 자주 액세스된다는 것입니다.

사용 사례가 상대적으로 작고 개발 모드에만 있다면 MongoDB Atlas에서 M0 클러스터 계층을 사용하는 것이 좋습니다. 이 계층은 평생 무료이며 데이터베이스 클러스터를 구축 및 유지 관리하는 데 드는 관리 오버헤드를 제거합니다. (단, M0 계층은 운영에 적합하지 않으며, 주의해야 할 제한 사항이 있습니다.)

언급URL : https://stackoverflow.com/questions/4288615/why-not-mongodb