관계형 데이터베이스에 비해 MongoDB와 같은 스키마가 없는 데이터베이스를 사용하는 장점은 무엇입니까?

관계형 데이터베이스에 비해 MongoDB와 같은 스키마가 없는 데이터베이스를 사용하는 장점은 무엇입니까?

MySQL이나 Postgre와 같은 관계형 데이터베이스를 사용하는 데 익숙합니다.SQL과 Symfony, RoR, Django 등의 MVC 프레임워크와의 조합이 매우 효과적이라고 생각합니다.

하지만 최근에는 MongoDB에 대해 많이 들었습니다.MongoDB는 비관계형 데이터베이스입니다.공식적인 정의를 인용하면

확장성이 뛰어난 고성능 오픈 소스 스키마가 필요 없는 문서 지향 데이터베이스입니다.

저는 긴장하고 있고 다음 프로젝트에서 사용할 수 있는 모든 옵션을 파악하고 최고의 기술을 선택하고 싶습니다.

"클래식" 관계형 데이터베이스를 사용하는 것보다 MongoDB(또는 유사한 데이터베이스)를 사용하는 것이 더 나은 경우는 무엇입니까?MongoDB와 MySQL의 일반적인 장점은 무엇입니까?아니면 적어도 왜 이렇게 다를까요?

문서 및/또는 예제에 대한 조언이 있다면 도움이 될 것입니다.

다음은 웹 어플리케이션 구축 시 MongoDB의 장점입니다.

1. 문서 기반 데이터 모델입니다.스토리지의 기본 단위는 JSON, Python 사전, Ruby 해시 등과 유사합니다.이는 어레이 및 기타 문서를 저장할 수 있는 풍부한 데이터 구조입니다.즉, 관계형 DB에서 적절하게 표현하기 위해 여러 테이블이 필요한 구성을 단일 엔티티로 나타낼 수 있습니다.이것은 데이터가 불변인 경우에 특히 유용합니다.
2. 심층 쿼리 기능.MongoDB는 SQL만큼 강력한 문서 기반 쿼리 언어를 사용하여 문서에 대한 동적 쿼리를 지원합니다.
3. 스키마 마이그레이션이 없습니다.MongoDB는 스키마가 없기 때문에 코드에 의해 스키마가 정의됩니다.
4. 수평적 확장성을 실현하기 위한 명확한 경로.

더 나은 아이디어를 얻으려면 그것에 대해 더 많이 읽고 그것을 가지고 놀 필요가 있을 것이다.다음은 온라인 데모입니다.

http://try.mongodb.org/

많은 장점이 있습니다.

예를 들어 데이터베이스 스키마의 확장성이 향상되고 마이그레이션에 대해 걱정할 필요가 없으며 코드를 쓰는 것이 더 쾌적해집니다.예를 들어, 여기 내 모델의 코드 중 하나가 있습니다.

class Setting
  include MongoMapper::Document

  key :news_search, String, :required => true
  key :is_availaible_for_iphone, :required => true, :default => false

  belongs_to :movie
end

키를 추가하는 것은 코드의 한 줄만 추가하는 것입니다!

더 나은 가리비와 속도 등 장기적으로 나타날 다른 장점들도 있다.

그러나 비관계형 데이터베이스가 관계형 데이터베이스보다 나은 것은 아니라는 점에 유의하십시오.데이터베이스에 많은 관계와 정규화가 있는 경우 MongoDB와 같은 것을 사용하는 것은 의미가 없을 수 있습니다.업무에 적합한 도구를 찾는 것이 중요합니다.

자세한 내용은 "왜 Mongo가 데이터베이스에 대해 Rails와 Frameworks의 관계와 같이 생각하는가" 또는 mongodb 웹사이트의 이 게시물을 참조하십시오.프랑스어를 할 줄 아는 경우 이 기사를 읽고 MongoDB를 처음부터 설정하는 방법을 설명하십시오.

편집: Ryan의 이 레일쇼에 대해 말하는 것을 거의 잊었습니다.그것은 매우 흥미롭고 바로 시작하고 싶게 만든다!

스키마가 없는 것의 장점은 부하가 무엇이든 덤프할 수 있다는 것입니다.또, 이것에 대해 불평하거나, 그것이 잘못되었다고 말할 근거는 아무도 없습니다.

그것은 또한 무엇을 버리든지 간에, 그렇게 한 후에도 전혀 의미가 없다는 것을 의미합니다.

어떤 사람들은 그것을 엄청난 불이익이라고 부를 것이고, 어떤 사람들은 그렇지 않을 것이다.

관계형 데이터베이스가 잘 확립된 스키마를 가지고 있다는 것은 데이터베이스에 기록된 내용에 의미를 부여할 수 있는 확장 술어 집합이 잘 확립되어 있다는 사실의 결과이며, 이를 위해 필요한 전제 조건이기도 합니다.

스키마가 제대로 확립되어 있지 않으면 확장 술어가 없고 확장 술어가 없으면 사용자가 스키마에 채워진 내용을 의미 있게 해석할 수 없습니다.

Postgres와 Mongo에 대한 나의 경험은 내 프로젝트에서 두 데이터베이스를 모두 사용한 후.

포스트그레스(RDB)MS)

Postgres는 향후 응용 프로그램에 많은 결합이 필요한 복잡한 스키마가 있거나 모든 데이터에 관계가 있거나 쓰기 작업이 많은 경우 권장됩니다.Postgres는 오픈 소스, 고속, ACID 준거, 디스크 메모리 사용량 감소, JSON 스토리지의 뛰어난 퍼포먼스, 트랜잭션의 완전한 시리얼라이제이션(serializability) 등 3가지 수준의 격리 기능을 갖추고 있습니다.

Postgres와 함께 있는 것의 가장 큰 장점은 우리가 양쪽 모두의 장점을 가지고 있다는 것이다.JSONB에는 제약, 일관성 및 속도로 데이터를 저장할 수 있습니다.반면 다른 유형의 데이터에는 모든 SQL 기능을 사용할 수 있습니다.기본 엔진은 매우 안정적이며 다양한 데이터 볼륨을 잘 처리합니다.또한 사용자가 선택한 하드웨어 및 운영 체제에서도 실행됩니다.Postgres는 완전한 트랜잭션 지원과 함께 NoSQL 기능을 제공하며 필드 데이터에 제약이 있는 JSON 문서를 저장합니다.

포스트그레의 일반적인 제약사항

Postgres를 수평으로 스케일링하는 것은 상당히 어렵지만 실행할 수 있습니다.

Postgres에서는 고속 읽기 작업을 완전히 수행할 수 없습니다.

SQL 데이터베이스 없음

Mongo DB(Wired Tiger)

MongoDB는 "수평적 규모"에서 Postgres를 능가할 수 있습니다.JSON을 저장하는 것은 Mongo가 최적화한 것입니다.Mongo는 데이터를 BSONb라는 바이너리 형식으로 저장합니다.이것은 (대략) JSON의 슈퍼셋을 바이너리 형식으로 표현한 것입니다.MongoDB는 오브젝트를 설계한 그대로 저장합니다.MongoDB에 따르면 쓰기 집약적인 애플리케이션에 대해 Mongo는 새로운 엔진(Wired Tiger)을 통해 사용자의 쓰기 퍼포먼스가 최대 10배 향상되고 스토리지 사용률이 80% 감소하여 스토리지 비용을 절감하고 하드웨어 사용률을 높일 수 있다고 합니다.

MongoDb의 일반적인 제약사항

스토리지 엔진을 덜 사용하는 스키마를 사용하면 암묵적인 스키마 문제가 발생합니다.이러한 스키마는 NAT 스토리지 엔진에 의해 정의되지 않고 애플리케이션 동작 및 기대에 따라 정의됩니다.

독립형 NoSQL 기술은 구조화되지 않은 애플리케이션의 높은 처리 성능을 위해 중요한 데이터 보호를 희생하기 때문에 ACID 표준을 충족하지 못합니다.NoSQL 데이터베이스에 ACID를 적용하는 것은 어렵지 않지만 데이터베이스가 어느 정도 느리고 유연성이 떨어집니다."NoSQL 제한사항의 대부분은 이전 제한을 상당 부분 극복한 새로운 버전 및 릴리스에서 최적화되었습니다."

이 모든 것은 트레이드오프에 관한 것이다.MongoDB는 빠르지만 ACID가 아니라 트랜잭션이 없습니다.일부 사용 사례에서는 MySQL보다 더 좋기도 하고 더 나쁘기도 합니다.

MongoDB로 작성된 Bellows 행:최종 가이드

몇 가지 타당한 이유가 있습니다.

1. 서로 다른 종류의 문서를 같은 컬렉션에 보관하는 것은 개발자와 관리자에게 악몽이 될 수 있습니다.개발자는 각 쿼리가 특정 종류의 문서만 반환하는지 또는 쿼리를 수행하는 응용프로그램 코드가 다른 모양의 문서를 처리할 수 있는지 확인해야 합니다.블로그 투고에 대해 문의할 경우 작성자 데이터가 포함된 문서를 삭제하는 것이 번거롭습니다.
2. 컬렉션에서 유형 목록을 추출하는 것보다 컬렉션 목록을 가져오는 것이 훨씬 빠릅니다.예를 들어 각 문서가 "skim", "whole" 또는 "chunky monkey" 문서인지 여부를 나타내는 입력 키가 컬렉션에 있는 경우 세 개의 개별 컬렉션을 가지고 이름을 쿼리하는 것보다 단일 컬렉션에서 이러한 세 개의 값을 찾는 것이 훨씬 느립니다.
3. 같은 종류의 문서를 같은 컬렉션으로 그룹화하면 데이터 인접성을 확보할 수 있습니다.투고만을 포함한 컬렉션에서 여러 블로그 투고를 취득하는 것은 투고와 작성자 데이터를 포함한 컬렉션에서 동일한 투고를 취득하는 것보다 디스크 검색이 적게 필요할 수 있습니다.
4. 인덱스를 작성할 때 문서에 어떤 구조를 적용하기 시작합니다.(이는 고유 인덱스의 경우에 특히 해당됩니다.)이러한 인덱스는 컬렉션별로 정의됩니다.단일 유형의 문서만 동일한 컬렉션에 포함시킴으로써 컬렉션의 인덱스를 보다 효율적으로 작성할 수 있습니다.

텍스트 스토리지를 갖춘 데이터베이스에 대한 질문 후, MongoDB 및 이와 유사한 시스템을 살펴보았습니다.
제가 제대로 이해했다면, 사용 및 셋업이 쉽고, 훨씬 더 빠를 것입니다.SQL이 부족하면 SQL 주입이 방해되기 때문에 더 안전할 수도 있습니다.
MongoDB는 주로 웹 어플리케이션에서 사용된다고 합니다.
기본적으로 이러한 데이터베이스는 복잡한 쿼리, 데이터 마이닝 등에 적합하지 않다고 말합니다.하지만 많은 플랫 데이터를 빠르게 검색하는 데 탁월합니다.

1. MongoDB는 필드별 검색, 정규 표현식 검색을 지원합니다.사용자 정의 Java 스크립트 함수를 포함합니다.
2. MongoDB는 파일 시스템으로 사용할 수 있으며, 여러 머신에 걸친 로드밸런싱 및 데이터 리플리케이션 기능을 활용하여 파일을 저장할 수 있습니다.

언급URL : https://stackoverflow.com/questions/2117372/what-are-the-advantages-of-using-a-schema-free-database-like-mongodb-compared-to