MongoDB는 언제 사용해야합니까?

MongoDB는 사용하기 쉬운 NoSQL 데이터베이스입니다. 최근에는 HTTP 요청을 사용하여 데이터를 수집하고 데이터를 처리 한 후 결과를 저장 해야하는 간단한 응용 프로그램을 개발해야했으며 MongoDB를 사용해 보았습니다.

이 경험을 통해 기존의 관계형 데이터베이스보다 사용하기가 훨씬 좋았으며 DBA가 아닌 개발자이기 때문에 작업이 크게 단순화되었습니다.

그럼에도 불구하고 때로는 SQL Server 또는 MySQL과 같은 전통적인 관계형 데이터베이스 대신 MongoDB를 사용해야하는 시점이 확실하지 않은 경우가 있습니다.

이 경우 관계형 데이터베이스 대신 MongoDB를 사용할 수 있습니까? MongoDB에 대한 일부 큰 경고가 있습니까?

원래:

• 여러 문서 형태로 데이터를 표현할 수 있다면 MongoDB를 선택하는 것이 좋습니다.

• 데이터를 상호 연결된 여러 테이블로 생각하면 MongoDB가 적합하지 않을 수 있습니다.

다음은 내가 찾은 두 가지 예입니다.

• 몇 년 전에 블로그 엔진을 만들었습니다. 블로그 기사를 호스팅하고 모든 기사마다 다른 버전, 일부 메타 데이터, 방문 통계 등을 저장하는 것이 목적입니다.

  이것은 많은 테이블로 저장 될 수 있지만 모델을 만들려고 할 때 더 이상 그렇지 않으면 수십 개의 테이블로 매우 빠르게 커집니다. 일부 SQL 쿼리는 많은 것들로 인해 추악해질 수 join있으며 ... 음, 당신은 그림을 얻습니다.

  여기서 문제는 블로그 기사의 중심적인 부분이 있으며 기사 주위에이 모든 것들이있어 문서 기반 데이터베이스에 적합하다는 것입니다. MongoDB를 사용하면 데이터베이스 모델링이 매우 쉬워졌습니다. 하나의 컬렉션에는 블로그 기사가 있고 다른 하나의 작은 컬렉션에는 기사를 작성할 수있는 사용자 목록이 포함되어 있습니다. 첫 번째 컬렉션 내의 각 문서에는 기사를 표시 할 때 필요한 모든 정보가 포함되어 있으며 저자의 이름 또는 태그가 될 수 있습니다.

• 이제 매우 다른 프로젝트를 상상해보십시오. 글을 쓰고 다른 사용자가 작성한 내용을 공유 할 수있는 일부 사용자가 있습니다. 사용자의 페이지에서이 사용자가 작성한 것과 공유 한 것을 모두 찾을 수 있습니다. 한 가지 제약이 있습니다. 누군가 과거에 쓴 내용을 편집하면 원본 텍스트가 공유 된 모든 곳에 변경 사항이 나타납니다.

  문서 기반 접근 방식을 사용하면 문서가 무엇인지 찾기가 어렵습니다. 아마도 사용자? 글쎄, 그것은 좋은 시작입니다. 사용자 문서에는이 사용자가 작성한 모든 내용이 포함됩니다. 그러나 그녀가 공유 한 것들은 어떻습니까?

  가능한 방법은 그 것들을 같은 문서에 넣는 것입니다. 이 방법의 문제점은 누군가가 항목을 편집하는 경우 응용 프로그램은 데이터베이스의 모든 사용자 문서를 탐색하여 이전 항목의 모든 항목을 편집해야한다는 것입니다. 데이터 중복을 계산하지 않습니다.

  대안은이 사용자가 공유 한 항목 목록 (참조 된 사용자 및 항목의 ID와 함께) 만 사용자 문서 내에 유지하는 것입니다. 그러나 이제 다른 문제가 발생합니다. 사용자가 수천 명의 사용자로부터 수천 개의 항목을 공유 한 경우 해당 항목을 가져 오려면 수천 개의 문서를 열어야합니다.

  또는 항목 자체를 기준으로 컬렉션을 모델링 할 수 있습니다. 각 항목은 작성자를 참조하고 해당 항목을 공유 한 사용자 목록이 있습니다. 여기서도 특정 사용자가 게시 한 문서를 보여주기 위해 모든 문서를 살펴 봐야 할 때 성능 문제가 눈에 띄게 될 수 있습니다.

  이제 관계형 데이터베이스를 사용하는 경우 얼마나 많은 테이블이 필요합니까? 그래, 셋 모델링하는 것이 간단하고 사용하기도 쉽습니다.

각 기술에는 장점이 있습니다.

관계형 데이터베이스의 장점은 RDBMS가 다음과 같은 몇 가지 작업을 수행한다는 것입니다.

• 참조 무결성 적용 (인보이스가 존재하지 않는 경우 인보이스 세부 사항 삽입을 허용하지 않음)
• 중복 방지 : 항목은 한 번만 저장됩니다.
• 성숙하고 시간이 오래 걸리며 널리 퍼져있는 선언적 언어 (SQL)로 복잡한 쿼리를 수행 할 수 있습니다.

RDBMS가 당신을 위해 일을 강제하기 때문에 더 적은 코드를 작성해야 한다는 사실로 요약됩니다 .

또한 데이터 독립성 : 종종 표준 SQL 구조를 사용하고 공급 업체별 구조를 사용하지 않는 경우 번거 로움을 최소화하면서 한 RDBMS에서 다른 RDBMS로 데이터를 마이그레이션 할 수 있지만 NOSQL 데이터베이스는 전혀 표준화되지 않습니다.

반면, NOSQL 데이터베이스의 장점 중 하나는 수백만 행에 대한 성능을보다 잘 유지 관리 할 수 ​​있다는 것입니다. 비 구조적 데이터와 같은 문서 기반 스토리지에 더 적합합니다. 그러나 대부분의 응용 프로그램에는 이러한 기능이 필요하지 않습니다.

특별한 경우, MongoDB는 좋은 선택처럼 들리지만 최선의 선택이 아닌 많은 시나리오 (아마도 대부분)가 있습니다.

MongoDB는 트랜잭션 안전성에 중점을 두지 않고 많은 양 의 데이터 를 읽거나 쓰는 시나리오에 더 적합 합니다 (일부 데이터가 서버 충돌로 인해 때때로 손실되는 경우 큰 문제는 아닙니다). 실제로 안정적인 스키마가 없습니다.

MongoDB는 다음이 필요한 시나리오에 적합 하지 않습니다 .

1. 강력한 ACID 보장 : MongoDB는 중복 데이터를 저장하고, 일관되지 않은 읽기 및 심지어 데이터 손실까지 허용합니다. 이러한 것은 일부 응용 프로그램에서는 문제가 없지만 대부분의 응용 프로그램에서는 그렇지 않습니다.
2. 다중 객체 트랜잭션 : MongoDB는 ACID 트랜잭션을 지원하지만 단일 객체 / 문서에 대해서만 지원합니다. 이것은 은행 송금, 예약 등의 복잡한 작업을 위해 그것을 잘라 내지 않습니다.
3. 기존 BI : 기존 SQL 과만 잘 작동하는 BI 도구가 많이 있습니다.
4. SQL : MongoDB는 매우 구체적인 쿼리 언어를 가지고 있지만 SQL은 많은 사람들에게 잘 알려져 있으며 (고려해야 할 중요한 측면 일 수 있음) 많은 복잡한 작업을 수행 할 수 있습니다 (MongoDB의 경우 간단한 수행에 어려움이 있습니다) join) 많은 구현을 통해 양도 할 수 있습니다.

MongoDB는 더 빠르며 무결성 검사와 같이 RDBMS가 기본적으로 시행하는 많은 것들을 제거하여 시스템에서 더 많은 성능을 얻을 수 있습니다 (어쨌든 그러한 목적으로 RDBMS를 조정할 수도 있음). 대부분의 시나리오에서는 필요하지 않습니다. 또한 안정성과 유연성이 절충됩니다 (나중에 기존 데이터로 더 복잡한 작업을 수행해야하는 경우 문제가 발생할 수 있음).

그것은 모두 당신이 만들고있는 응용 프로그램의 요구에 달려 있습니다. 속도와 가용성 또는 안전, 신뢰성 및 유연성입니까? 데이터의 어느 부분 (및 데이터의 연결 부분)이 더 가치가 있는지 알아야합니다. 아직 모를 경우에는 나중에 구석에 페인트하지 않을 기능을 선택하고 기능을 추가하고 응용 프로그램에 필요한 작업을 수행 할 수있는 것이 가장 좋습니다.

MongoDB는 데이터를 독립적 인 정보 "패키지"로 나타낼 수있을 때 유용합니다. 우편 번호에 포함 된 Google지도 우편 번호는 회사이며 회사 내부는 직원입니다. 모든 우편 번호는 서로 독립적이며 간단하고 예쁘고 빠른 방법으로 전체 정보를 얻을 수 있습니다. 이는 비 SQL 솔루션에 대한 좋은 시나리오입니다.

일단 말하면, 나는 현재보고있는 추세에 완전히 동의하지 않습니다. MongoDB는 RDBMS에 대한 일종의 포스트 및 우수한 솔루션이며 noSQL은 기본적으로 솔루션이어야 함을 암시합니다. 터무니없는 모든 것. MongoDB는 틈새 데이터베이스이며 프로젝트의 90 %가 관계형이며 SQL과 같은 강력한 쿼리 솔루션에서 보고서를 생성하고 분산 된 데이터를 찾기를 원하므로 RDBMS 옵션이 필요합니다. "조인"은 사기가 아닌 전문가입니다. 또한 최신 RDBMS는 BSON 수집 및 지리 공간 통합을 지원하므로 noSQL의 틈새 시장은 더욱 좁아 질 수 있습니다.

MongoDB는 웹 페이지의 특정 인스턴스를 작성하는 데 필요한 전체 구조화 된 데이터를 저장하는 데 유용합니다. 주어진 페이지의 데이터를 검색하여 클라이언트 응용 프로그램으로 전달한 다음 렌더링 할 수 있습니다.

이러한 맥락에서 MongoDB는 매우 빠르고 안정적입니다. 그러나 데이터베이스에 관계형 정보가 없다는 것을 잊지 마십시오. 즉, 웹 페이지 구조에서 무언가를 변경하면 필요한 데이터가 없기 때문에 이미 저장된 페이지의 구멍을 채울 수 없습니다. 여기에 더 많은 것 : http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/