누군가 관계형 DBMS를 통해 MongoDB (또는 유사한)를 언제 사용합니까?

나는 NoSQL과 관련하여 약간 혼란스러워합니다. 언제 Oracle 또는 MySQL과 같은 MongoDB와 같은 것을 사용 하시겠습니까? 사용법이 서로 다른 한 "차이"를 실제로 이해하지 못합니다.

내 이해에서 NoSQL 유형 데이터베이스는 RDBMS를 대체하기위한 것이 아니라 정확히 무엇을 의미합니까?

나는 애완 동물 프로젝트를 위해 CouchDB를 사용했습니다.

• 마이크로 블로그 시스템.
• 내가 작성한 작은 메모 작성 앱의 정보를 저장하십시오.
• 범용 브레인 스토밍 애플리케이션.

내가 MSSQL 또는 MySQL과 같은 것을 선택했을 때 가장 큰 이유는 사용시 얻을 수있는 유연성 때문입니다. 엄격한 스키마가 없습니다. 3 개월 줄 아래로 여분의 필드를 가지려면 특정 테이블이 필요합니다.이 테이블과 그 테이블을 변경하면 테이블이 변경됩니다.

내가 사용 CouchDB를부터 그것을 사용하는 방법을 배울 Apress의에 의해.

예를 들어, CouchDB는 json을 사용하여 데이터베이스와 통신합니다. 언어가 데이터를 POST 할 수 있으면이를 사용하여 DB와 통신 할 수 있습니다.

또한 읽기 : 관계형 데이터베이스 대신 문서 기반 데이터베이스를 사용해야하는 이유는 무엇입니까? StackOverflow에서

다른 답변을 추가하여 죄송하지만 여기에 대한 답변 중 어느 것도 매우 만족스럽지 않습니다. 이 답변은 MongoDB에만 해당됩니다 (관계형 데이터베이스가 아닌 광범위한 다른 데이터 저장소 옵션과 대조적 임).

장점 :

• MongoDB는 쿼리 당 대기 시간이 짧고 쿼리 당 CPU 시간을 줄입니다 (조인, 트랜잭션 등). 결과적으로 초당 쿼리 측면에서 더 높은로드를 처리 할 수 있으므로 많은 수의 사용자가있는 경우에 종종 사용됩니다.
• MongoDB는 트랜잭션 및 일관성에 대해 걱정할 필요가 없기 때문에 클러스터에서 사용하기 가 더 쉽습니다 .
• MongoDB는 쓰기 속도가 빠르기 때문에 트랜잭션이나 롤백에 대해 걱정할 필요가 없으므로 잠금에 대해 걱정할 필요가 없습니다.
• MongoDB 에는 이를 활용할 수있는 특수 사용 사례가있는 경우 스키마가 없습니다 .

단점 :

• MongoDB 는 트랜잭션을 지원하지 않습니다 . 이것이 대부분의 이점을 얻는 방법입니다.
• 일반적으로 MongoDB는 클라이언트 서버에 더 많은 작업 (예 : CPU 비용)을 생성합니다 . 예를 들어, 데이터를 결합하려면 여러 쿼리를 발행하고 클라이언트에서 결합을 수행해야합니다.
• 2017 년에도 MongoDB에 대한 툴링 지원 은 관계형 데이터베이스보다 새롭기 때문에 덜 지원 됩니다. 또한 관계형 전문가 보다 MongoDB 전문가 가 적습니다 .

종종 오해 된 점 :

• MongoDB 및 관계형 데이터베이스 모두 인덱싱을 지원합니다. 쿼리 성능은 큰 쿼리 실행 측면에서 비슷합니다 .
• MongoDB는 마이그레이션의 필요성을 제거하지 않으며 스키마가 발전함에 따라 기존 데이터를 업데이트 하지 않습니다 . 예를 들어, 특정 데이터를 포함하기 위해 users 테이블에 의존하는 응용 프로그램이 있고 다른 데이터를 포함하도록 해당 테이블을 수정하는 경우 (프로필 그림 필드를 추가한다고 가정) 여전히 다음 중 하나를 수행해야합니다.
  • 이 속성이 정의되지 않은 객체를 처리하는 응용 프로그램을 작성하십시오. 또는
  • 이 특성의 기본값을 설정하기 위해 일회성 마이그레이션을 작성하거나
  • 이 필드가 없으면 쿼리시 기본값을 제공하는 코드 작성 또는
  • 다른 방법으로 누락 된 필드 처리

르네 시스 에서 부끄러운 도둑질하기 위해 (실제로 나는이 답변을 CW로 만들고 있습니다) :

다른 유형 대신 RDBMS 사용 :

• "NoSQL"및 기타 DB 유형에 대한 아이디어를 읽으십시오.
  • NoSQL : 그렇게 쉬운 경우
  • (위의 링크) 하여 MongoDB 또는 다른 문서 지향 데이터베이스 시스템을 사용하는 경우? ^{현재 SO에서 삭제됨} ( more )
  • https://softwareengineering.stackexchange.com/questions/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql-going
  • CouchDB와 RDBMS를 함께 사용하는 경우
• RDBMS는 성능을 위해 인덱싱을 많이 사용합니다. 대용량 데이터베이스에서이 수 부정적인 성능에 영향을 미치거나 심지어 DB 당 행의 최적의 수를 줄일 수있다 / 파편은 더 많은 하드웨어를 필요로
• 방대한 양의 데이터를 저장하지만 덜 자주 읽는 경우에는 이상적이지 않습니다.
• 외래 관계 가 많지 않으면 관계형 데이터베이스가 이상적이지 않을 수 있습니다 (문서 저장소).

데이터가 관계형이 아닌 경우 성능 및 확장 성 (환경에 따라 다름)과 같은 NoSQL 데이터베이스를 사용하면 큰 이점이 있습니다. CQRS와 같은 일부 디자인 패턴은 일반적으로 SQL 데이터베이스의 독점적 사용을 요구하는 영역에서 비 관계형 데이터를 훨씬 쉽게 활용할 수 있도록합니다.

캐시 된 데이터에 mongo와 같은 데이터베이스를 사용하는 것이 일반적입니다. 예를 들어, 보고서를 생성해야하는 경우 즉시 많은 데이터를 결합하고 집계하는 복잡한 SQL 쿼리를 수행하거나 이미 생성해야하는 모든 것이있는 몽고 데이터베이스에서 단일 json 문서를 가져올 수 있습니다. 보고서. 이렇게하면 데이터를 정말 쉽고 빠르게 읽을 수 있지만 데이터를 매우 복잡하게 만들 수 있습니다 (CQRS가 들어오는 곳).

MongoDB와 같은 데이터베이스는 일반적으로 데이터가 어디에 있는지 알고있을 때 유용합니다 (복잡한 쿼리를 여러 개 작성하지 않아도 됨). Mongo를 사용하면 "관련"데이터가 상위 데이터에 중첩되거나 기본 / 외국 키가 있습니다. 예를 들어 게시물과 댓글이있는 경우 유용합니다. 일반적으로 게시물 컨텍스트 외부에 주석을 표시하지 않으므로 게시물에 주석을 포함시키는 것이 좋습니다 (따라서 별도의 테이블을 쿼리 할 필요없이 게시물에 대한 모든 주석을 얻습니다).

MongoDB는 스키마가 없습니다. 즉, 대부분의 경우 데이터 구조를 취하게됩니다.

반면에 집계 함수를 사용해야하고 Mongo에서 임베드 또는 간단한 관계를 통해 달성 할 수없는 복잡한 방식으로 데이터를 쿼리해야하는 경우, MySQL 또는 PostgreSQL과 같은 RDBMS를 사용할 때가되었음을 알 수 있습니다.

MongoDB는 SQL을 대체하지 않습니다. 단순히 다른 요구를 충족 시키며 MongoDB와 RDBMS를 함께 사용할 수 있습니다. 내 의견으로는 MongoDB가 데이터를 유연하게 만들거나 부모 문서에 포함 할 필요가 없다면 필요한 것은 아닙니다. MongoDB를 사용한 개발은 프로젝트를 시작하고 실행하는 데 훨씬 적은 단계가 있기 때문에 매우 재미 있습니다. 변경이 필요하십니까? 문제 없어요. 모델에 속성을 추가하기 만하면됩니다. 끝난.

다른 많은 NoSQL 데이터베이스에 대해서는 말할 수 없지만 RDBMS가 충족 할 수없는 특정 요구를 충족하도록 유사하게 설계되어 있다는 것을 알고 있습니다. 일부는 전적으로 메모리에 상주하거나 매우 쉽게 샤딩 또는 확장 할 수 있습니다. Cassandra는 노드가 다운되면 데이터 손실없이 계속 작동하도록 설계되었습니다. Redis는 기본적으로 메모리에 상주하는 주요 값 저장소이며 (지속성을 위해 주기적 디스크 쓰기 사용) 세트와 같은 데이터 유형을 저장하고 정렬 할 수 있습니다.

주요한 승리는 데이터를 분할하거나 다중 마스터 데이터베이스를 보유하려는 경우입니다. MySQL에서 데이터를 파쇄 할 수 있지만 큰 고통으로 바뀝니다. 많은 쓰기 작업을 수행하는 경우 여러 서버에서 데이터를 분할하는 것이 유용한 경우가 종종 있습니다. 문제가되는 동안 강력한 참조 일관성을 유지하려면 CAP 정리를 조회 할 수없는 경우 매우 어려울 수 있습니다.

SQL 데이터베이스는 일관성은 뛰어나지 만 파티션 지원은 매우 나쁘고 NoSQL 데이터베이스는 다른 방향으로 가고 있습니다. 분할하기 쉽지만 종종 최종 일관성이라고합니다. 은행이 괜찮다면 메시징 사이트를 구축하는 것이 좋습니다.

또한 데이터를 저장하는 방법에 대한 여러 모델이 있으므로 SQL 데이터베이스를 사용하기 전에 물건을 구현하는 방법을 선택할 수 있습니다.

SE Radio는이 주제에 관한 몇 가지 좋은 에피소드를 가지고 있습니다.

MongoDB는 많은 양의 데이터를 작성하고 쿼리 요구가 너무 복잡하지 않을 때 잘 작동합니다. 따라서 MongoDB는 명령 측에서 이벤트 소싱으로 CQRS를 구현할 때 적합합니다. 즉, 이벤트 저장소는 MongoDB 데이터베이스입니다.

쿼리 측면에서 우리는 여전히 유연성으로 인해 뷰와 WCF 데이터 서비스가있는 SQL Server db를 사용합니다. 나는 대부분의 경우 쿼리를 위해 관계형 DB의 힘이 정말로 필요하다고 생각합니다.

MongoDB와 RDBMS의 즉각적이고 근본적인 차이점은 기본 데이터 모델입니다. 관계형 데이터베이스는 데이터를 테이블과 행으로 구성하고 MongoDB는 데이터를 JSON 문서 모음으로 구성합니다. JSON은 스스로 설명하고 사람이 읽을 수있는 데이터 형식입니다. 브라우저와 서버 간의 가벼운 교환을 위해 원래 설계된이 응용 프로그램은 많은 유형의 응용 프로그램에서 널리 사용되고 있습니다.

JSON 문서는 여러 가지 이유로 데이터 관리에 특히 유용합니다. JSON 문서는 자체적으로 키-값 쌍인 필드 세트로 구성됩니다. 즉, 각 JSON 문서는 어디에서나 사람이 읽을 수있는 사람이 읽을 수있는 스키마 디자인을 가지고 있으므로 문서가 의미를 잃지 않고 데이터베이스와 클라이언트 애플리케이션간에 쉽게 이동할 수 있습니다.

JSON은 또한 응용 프로그램 계층에서 사용하기위한 자연스러운 데이터 형식입니다. JSON은 열과 행으로 구성된 테이블보다 풍부하고 유연한 데이터 구조를 지원합니다. JSON 필드는 숫자, 문자열, 부울 등과 같은 필드 유형을 지원할뿐만 아니라 배열 또는 중첩 된 하위 오브젝트 일 수 있습니다. 이는 애플리케이션이 작업하는 객체를보다 자세히 표현하는 일련의 정교한 관계를 나타낼 수 있음을 의미합니다. 데이터베이스에서 JSON 문서를 사용한다는 것은 데이터베이스와 데이터베이스가 제공하는 애플리케이션간에 객체 관계형 매퍼가 필요하지 않음을 의미합니다. 올바른 형식으로 데이터를 유지할 수 있습니다

데이터에 많은 쿼리가 필요한 경우 NoSQL 솔루션이 좋지 않으며 트랜잭션 지원 (ACID)이 필요한 경우 NoSql이 가장 적합하지 않습니다. 빠른 읽기가 필요한 구조가 다소 독창적 일 때 문서 나 페이지 구조로 검색하는 경우 NoSQL이 빛을 발한다고 생각합니다. 그러나 많은 NoSQL 솔루션이 상당히 빠르게 향상되어 단점이 곧 사라질 것입니다. 어쨌든 관계형 데이터베이스는 여전히 대부분의 응용 프로그램에 적합하다고 생각합니다.