저는 MySQL 또는 PostgreSQL과 같은 관계형 데이터베이스를 사용하고 Symfony, RoR 또는 Django와 같은 MVC 프레임 워크와 결합하는 데 익숙하며 훌륭하게 작동한다고 생각합니다.
그러나 최근에 나는 인용, 비 관계형 데이터베이스, 또는 MongoDB에 대해 많이 들었어요 공식 정의를 ,
확장 가능한 고성능 오픈 소스 스키마가없는 문서 지향 데이터베이스입니다.
저는 엣지에있는 것에 정말 관심이 있고, 다음 프로젝트를 위해 내가 가질 모든 옵션을 인식하고 최고의 기술을 선택하고 싶습니다.
어떤 경우에 MongoDB (또는 유사한 데이터베이스)를 사용하는 것이 “전통적인”관계형 데이터베이스를 사용하는 것보다 낫습니까? 그리고 일반적으로 MongoDB와 MySQL의 장점은 무엇입니까? 아니면 적어도 왜 그렇게 다른가요?
문서 및 / 또는 예제에 대한 포인터가 있으면 큰 도움이 될 것입니다.
답변
웹 애플리케이션 구축을위한 MongoDB의 몇 가지 장점은 다음과 같습니다.
- 문서 기반 데이터 모델. 기본 저장 단위는 JSON, Python 사전, Ruby 해시 등과 유사합니다. 이는 배열 및 기타 문서를 보유 할 수있는 풍부한 데이터 구조입니다. 즉, 관계형 db에서 적절하게 표현하기 위해 여러 테이블이 필요한 구조를 단일 엔티티로 표현할 수 있습니다. 이는 데이터가 변경 불가능한 경우 특히 유용합니다.
- 깊은 쿼리 기능. MongoDB는 SQL만큼 강력한 문서 기반 쿼리 언어를 사용하여 문서에 대한 동적 쿼리를 지원합니다.
- 스키마 마이그레이션이 없습니다. MongoDB는 스키마가 없으므로 코드가 스키마를 정의합니다.
- 수평 적 확장성에 대한 명확한 경로.
더 나은 아이디어를 얻으려면 그것에 대해 더 많이 읽고 가지고 놀아야합니다. 다음은 온라인 데모입니다.
답변
많은 장점이 있습니다.
예를 들어 데이터베이스 스키마가 더 확장 가능하고 마이그레이션에 대해 걱정할 필요가 없으며 코드를 작성하는 것이 더 즐거울 것입니다 … 예를 들어 여기에 내 모델 코드 중 하나가 있습니다.
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와 같은 것을 사용하는 것은 의미가 없을 수 있습니다. 작업에 적합한 도구를 찾는 것이 전부입니다.
더 많은 것을 읽으려면 ” 왜 Mongo가 데이터베이스에 레일스가 프레임 워크에 있었는지 “또는 mongodb 웹 사이트 의이 게시물 을 살펴 보는 것이 좋습니다 . 흥미를 느끼고 프랑스어 를 사용하는 경우 MongoDB를 처음부터 설정하는 방법을 설명하는 이 기사를 살펴보십시오 .
편집 : 나는 Ryan 의이 railscast 에 대해 당신에게 말하는 것을 거의 잊었습니다 . 매우 흥미롭고 즉시 시작하고 싶게 만듭니다!
답변
스키마 프리의 장점은 부하가 무엇이든 덤프 할 수 있으며 아무도 그것에 대해 불평하거나 잘못되었다고 말할 근거가 없다는 것입니다.
그것은 또한 당신이 그 안에 버리는 것이 무엇이든 당신이 그렇게 한 후에도 의미가 전혀 없다는 것을 의미합니다.
일부는 심각한 단점이라고 표시하고 일부는 그렇지 않습니다.
관계형 데이터베이스가 잘 확립 된 스키마를 가지고 있다는 사실은 잘 확립 된 확장 술어 세트가 있다는 사실의 결과입니다. 이를 위해 필요한 전제 조건이기도합니다.
잘 확립 된 스키마, 확장 술어 및 확장 정밀도 없이는 사용자가 그 안에 채워진 것에서 의미를 만들 수 없습니다.
답변
MongoDB를 치실 주간에 이번 주에 소개되었습니다 – http://twit.tv/floss105
유사한 개념을 사용하여 데이터베이스를 다른 FLOSS 주간에 등장했다 CouchDB를 수 있습니다 : http://twit.tv/floss36
@marcgg에서 제공 하는 링크 외에도 이들을 들어 볼 가치가 있다고 생각합니다.
답변
내 프로젝트에서 두 데이터베이스를 모두 사용한 후 Postgres와 Mongo에 대한 나의 경험.
Postgres (RDBMS)
Postgres는 향후 애플리케이션에 많은 조인이 필요한 복잡한 스키마가 있거나 모든 데이터에 관계가 있거나 많은 쓰기 작업이있는 경우 권장됩니다. Postgres는 오픈 소스이고 더 빠르며 ACID를 준수하며 디스크에서 메모리를 적게 사용하며 JSON 스토리지에 대해 모두 우수한 성능을 제공하며 3 단계의 트랜잭션 격리를 통해 트랜잭션의 완전한 직렬 성을 포함합니다.
Postgres에 머무르는 것의 가장 큰 장점은 두 가지 장점을 모두 갖추고 있다는 것입니다. 제약, 일관성 및 속도로 데이터를 JSONB에 저장할 수 있습니다. 반면에 다른 유형의 데이터에 대해 모든 SQL 기능을 사용할 수 있습니다. 기본 엔진은 매우 안정적이며 다양한 데이터 볼륨에 잘 대처합니다. 또한 선택한 하드웨어 및 운영 체제에서 실행됩니다. 전체 트랜잭션 지원과 함께 NoSQL 기능을 제공하는 Postgres는 필드 데이터에 대한 제약 조건이있는 JSON 문서를 저장합니다.
Postgres에 대한 일반 제약
Postgres를 수평으로 확장하는 것은 훨씬 어렵지만 가능합니다.
Postgres로는 빠른 읽기 작업을 완전히 수행 할 수 없습니다.
SQL 데이터베이스 없음
Mongo DB (Wired Tiger)
MongoDB는 “수평 적 규모”측면에서 Postgres를 능가 할 수 있습니다. JSON 저장은 Mongo가 최적화 된 작업입니다. Mongo는 데이터를 BSONb라는 바이너리 형식으로 저장하는데, 이는 (대략) JSON 상위 집합의 바이너리 표현입니다. MongoDB는 설계된 그대로 객체를 저장합니다. MongoDB에 따르면 쓰기 집약적 인 애플리케이션을 위해 Mongo는 새로운 엔진 (Wired Tiger)이 사용자에게 쓰기 성능을 최대 10 배 향상시키고 (이것을 시도해야 함) 스토리지 사용률을 80 % 감소시켜 스토리지 비용을 절감 할 수 있다고 말합니다. , 하드웨어 활용도를 높이십시오.
MongoDb의 일반 제약
스키마가 적은 스토리지 엔진을 사용하면 암시 적 스키마 문제가 발생합니다. 이러한 스키마는 스토리지 엔진에 의해 정의되지 않고 대신 애플리케이션 동작 및 기대치를 기반으로 정의됩니다.
독립형 NoSQL 기술은 비정형 애플리케이션의 높은 처리량 성능을 위해 중요한 데이터 보호를 희생하기 때문에 ACID 표준을 충족하지 못합니다. NoSQL 데이터베이스에 ACID를 적용하는 것은 어렵지 않지만 데이터베이스를 어느 정도까지 느리고 유연하지 않게 만듭니다. “대부분의 NoSQL 제한 사항은 이전 제한 사항을 크게 극복 한 최신 버전 및 릴리스에서 최적화되었습니다.”
답변
트레이드 오프에 관한 모든 것입니다. MongoDB는 빠르지 만 ACID는 아니며 트랜잭션이 없습니다. 일부 사용 사례에서는 MySQL보다 낫고 다른 사례에서는 더 나쁩니다.
답변
MongoDB에 작성된 벨로우 라인 : 최종 가이드.
몇 가지 좋은 이유가 있습니다.
- 같은 컬렉션에 여러 종류의 문서를 보관하는 것은 개발자와 관리자에게 악몽이 될 수 있습니다. 개발자는 각 쿼리가 특정 종류의 문서 만 반환하는지 또는 쿼리를 수행하는 응용 프로그램 코드가 다른 모양의 문서를 처리 할 수 있는지 확인해야합니다. 블로그 게시물을 쿼리하는 경우 작성자 데이터가 포함 된 문서를 걸러내는 것이 번거 롭습니다.
- 컬렉션의 유형 목록을 추출하는 것보다 컬렉션 목록을 얻는 것이 훨씬 빠릅니다. 예를 들어 컬렉션에 각 문서가 “skim”, “whole”또는 “chunky monkey”문서인지 여부를 나타내는 유형 키가있는 경우 단일 컬렉션에서 이러한 세 가지 값을 찾는 것보다 훨씬 느립니다. 세 가지 별도의 컬렉션과 이름에 대한 쿼리가 있습니다.
- 같은 종류의 문서를 같은 컬렉션으로 그룹화하면 데이터 지역성이 가능합니다. 게시물 만 포함 된 컬렉션에서 여러 블로그 게시물을 가져 오는 것은 게시물과 작성자 데이터를 포함하는 컬렉션에서 동일한 게시물을 가져 오는 것보다 디스크 검색이 더 적게 필요할 수 있습니다.
- 인덱스를 만들 때 문서에 일부 구조를 적용하기 시작합니다. (특히 고유 인덱스의 경우에 그렇습니다.) 이러한 인덱스는 컬렉션별로 정의됩니다. 단일 유형의 문서 만 동일한 컬렉션에 넣으면 컬렉션을보다 효율적으로 인덱싱 할 수 있습니다.
