MongoDB와 같은 스키마없는 데이터베이스를 관계형 데이터베이스와 비교하면 어떤 이점이 있습니까?

Question

저는 MySQL이나 PostgreSQL과 같은 관계형 데이터베이스를 사용하고 Symfony, RoR 또는 Django와 같은 MVC 프레임 워크와 결합하는 데 익숙합니다.

는 그러나 최근에 나는의 official definition 인용, 비 관계형 데이터베이스, 또는 MongoDB에 대해 많이 들었어요

확장 성, 고성능, 공개 소스, 스키마 무료, 문서 지향적 인 데이터베이스.

저는 정말로 관심이 많습니다. 다음 프로젝트에 대해 가질 수있는 모든 옵션을 알고 싶고 거기에서 최고의 기술을 선택하고 싶습니다.

MongoDB (또는 유사한 데이터베이스)를 사용하는 것이 "고전적인"관계형 데이터베이스를 사용하는 것보다 낫습니까? MongoDB와 MySQL의 장점은 무엇입니까? 아니면 적어도, 왜 그렇게 다른가요?

설명서 및/또는 예제에 대한 지침이 있다면 큰 도움이 될 것입니다.

Answer 1

여기에 웹 애플리케이션을 구축하기위한 MongoDB를의 장점 중 일부입니다 :

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

더 좋은 아이디어를 얻으려면 그것에 대해 더 많이 읽고 놀아야합니다. 여기에 온라인 데모는 다음과 같습니다

http://try.mongodb.org/

Answer 2

많은 이점이 있습니다.

class Setting 
    include MongoMapper::Document 

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

    belongs_to :movie 
end 

: 데이터베이스 스키마가 더 확장 될 것입니다 예를 들어

, 당신은 마이그레이션에 대해 걱정할 필요가 없습니다 코드는 여기에 내 모델의 코드 중 하나 예를 들어 ... 작성하는 더 즐거운 것

키 추가는 코드 줄을 추가하는 것입니다!

더 나은 scallability와 속도처럼 장기적으로 나타날 다른 장점들도 있습니다.

... 하지만 비 관계형 데이터베이스 관계형 하나보다 더 아니라는 것을 명심하십시오. 데이터베이스에 많은 관계와 정규화가있는 경우 MongoDB와 같은 것을 사용하는 것은 거의 이해가되지 않을 수 있습니다. 작업에 적합한 도구를 찾는 것이 중요합니다.

자세한 내용은 mongodb 웹 사이트의 "Why I think Mongo is to Databases what Rails was to Frameworks"또는 this post을 참조하십시오. 흥분을 얻으려면 프랑스어를 사용하는 경우 MongoDB를 처음부터 설정하는 방법을 설명하는 this article을 살펴보십시오.

편집 : 거의 this railscast에 관해에 대해 이야기하는 것을 잊었습니다. 매우 흥미롭고 바로 시작하고 싶습니다!

Answer 3

텍스트 저장 기능이있는 데이터베이스에 대한 질문이 나온 후) 나는 MongoDB 및 유사한 시스템을 훑어 보았다.
제대로 이해했다면 사용하기 쉽고 설정이 쉬워졌으며 훨씬 빨라졌습니다. 아마도 SQL의 부족으로 인해 SQL 주입을 막을 수 있기 때문에 더 안전 할 것입니다 ...
분명히 MongoDB는 주로 웹 응용 프로그램에 사용됩니다.
기본적으로 이러한 데이터베이스는 복잡한 쿼리, 데이터 마이닝 등에 적합하지 않다고 말합니다. 그러나 이들은 많은 양의 데이터를 빠르게 검색하는 데 빛을 발합니다.

Answer 4

하여 MongoDB는 FLOSS 주간에 이번 주에 소개되었습니다 - http://twit.tv/floss105 유사한 개념을 사용하여 데이터베이스를 매주 다른 FLOSS에 등장했다 CouchDB를 수 있습니다 : http://twit.tv/floss36

나는 그것이 links provided by @marcgg

뿐만 아니라 사람들에게 듣고 가치가 있다고 생각

Answer 5

그것은 모든 무역 오프에 관하여이다. MongoDB는 빠르지 만 ACID가 아니기 때문에 트랜잭션이 없습니다. 일부 유스 케이스에서는 MySQL보다 좋고 다른 유스 케이스에서는 더 좋지 않습니다.

Answer 6

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

덤프에 어떤 내용이든 의미를 부여한다는 의미이기도합니다.

어떤 사람들에게는 큰 단점, 다른 사람들에게는 그렇지 않음이 있습니다.

관계형 데이터베이스가 잘 설정된 스키마를 가지고 있다는 사실은 데이터베이스에 기록 된 내용에 의미를 부여 할 수있는 확장 된 조건부 집합이 있다는 사실의 결과입니다 우리가 그렇게하는 데 필요한 전제 조건이기도합니다.

잘 정립 된 스키마가 없으면 확장 술어가없고 확장 성의 precicates가 없기 때문에 사용자가 그 안에 들어있는 것들을 의미 할 수 없습니다.

Answer 7

벨로우즈 라인 MongoDB : The Definitive Guide. 개발자와 관리자를위한 악몽이 될 수있는 동일한 컬렉션 문서의 다른 종류를 유지

1. :

   몇 가지 이유가 있습니다. 개발자는 각 쿼리가 특정 종류의 문서 만 반환하는지 을 확인하거나 쿼리를 수행하는 응용 프로그램 코드가 다른 모양의 문서를 처리 할 수 ​​있는지 확인해야합니다.블로그 게시물을 쿼리하는 경우 작성자 데이터가 포함 된 문서를 에 위탁하는 것이 번거롭습니다.

2. 모음의 목록을 가져 오는 것보다 모음에있는 형식의 목록을 추출하는 것보다 훨씬 빠릅니다. 예를 들어, 각 문서가 "스키밍"인지, "전체"또는 "청키 원숭이"문서인지 여부를 나타내는 컬렉션에 유형 키가 있다면 은 단일 문서에서이 값을 찾기가 훨씬 느립니다. 컬렉션보다 3 개의 컬렉션에 대한 별도의 컬렉션 및 쿼리
3. 동일한 컬렉션의 동일한 그룹화 문서 은 데이터 지역성을 허용합니다. 게시물 만 포함 된 컬렉션에서 여러 블로그 게시물을 얻으려면 게시물 및 작성자 데이터가 포함 된 모음에서 같은 게시물을 가져 오는 것보다 더 적은 디스크 찾기가 필요합니다.
4. 색인을 생성 할 때 문서에 일부 구조를 부과하기 시작합니다. 특히 고유 인덱스의 경우에 특히 그렇습니다. 이러한 인덱스는 컬렉션별로 정의됩니다. 같은 모음으로 단일 유형의 문서를 만 을 넣어, 우리보다 효율적으로

Answer 8

1. MongoDB를이 필드 정규 표현식 searches.Includes 사용자 정의 자바 스크립트 기능으로 검색을 지원하는 인덱스 우리 컬렉션을 할 수 있습니다.
2. MongoDB는 파일 저장을 위해 여러 시스템에서로드 균형 조정 및 데이터 복제 기능을 활용하여 파일 시스템으로 사용할 수 있습니다.

Answer 9

내 프로젝트에서 두 데이터베이스로 작업 한 후 Postgres와 Mongo에 대한 나의 경험. 당신의 미래 응용 프로그램은 조인 또는 우리가 무거운 기록이있는 경우 모든 데이터가 관계가 있거나 많이 필요로하는 복잡한 스키마가있는 경우

포스트 그레스 (RDBMS)을

포스트 그레스 권장합니다. Postgres는 오픈 소스, 더 빠르고 ACID를 준수하며 디스크의 메모리를 적게 사용하며 JSON 저장소에도 좋은 성능을 제공하며 3 단계의 트랜잭션 격리로 트랜잭션의 완벽한 직렬화 기능을 포함합니다.

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

스케일링 포스트 그레스 수평 포스트 그레스

에 대한

일반 제약은 상당히 열심히하지만 행할 수있다.

빠른 읽기 작업은 Postgres로는 완전히 수행 할 수 없습니다.

NO SQL 데이터베이스

MongoDB를 "은 가로 크기"의 치수 포스트 그레스 이길 수

몽고 DB (유선 타이거). JSON을 저장하는 것은 Mongo가하도록 최적화되어 있습니다.Mongo는 데이터를 JSON의 수퍼 세트를 (대략) 바이너리 표현 인 BSONb라는 이진 형식으로 저장합니다. MongoDB는 객체가 설계된대로 정확하게 객체를 저장합니다. MongoDB에 따르면 쓰기 집약적 인 응용 프로그램의 경우 Mongo에 따르면 새로운 엔진 (Wired Tiger)을 사용하면 쓰기 성능이 최대 10 배 향상되고 (필자도 시도해야 함) 저장소 사용률이 80 % 감소하여 저장 비용이 절감됩니다 하드웨어 활용도를 높입니다. MongoDB를

의

일반 제약

적은 스토리지 엔진은 암시 적 스키마의 문제로 연결 스키마의 사용. 이러한 스키마는 스토리지 엔진에 의해 정의되지 않지만 대신 응용 프로그램 동작 및 기대에 따라 정의됩니다.

독립형 NoSQL 기술은 비정형 응용 프로그램의 높은 처리 성능을 위해 중요한 데이터 보호를 희생하기 때문에 ACID 표준을 충족하지 못합니다. NoSQL 데이터베이스에 ACID를 적용하는 것은 어렵지 않지만 어느 정도까지는 데이터베이스가 느리고 유연하지 않게 만듭니다. "대부분의 NoSQL 제한 사항은 이전 버전의 제한 사항을 극복 한 최신 버전 및 릴리스에서 최적화되었습니다."