MongoDB 또는 기타 문서 지향 데이터베이스 시스템을 언제 사용해야합니까? [닫은]

비디오 및 오디오 클립, 사진 및 벡터 그래픽을위한 플랫폼을 제공합니다. 우리는 MySQL을 데이터베이스 백엔드로 시작했으며 최근 MongoDB 가 요구 사항에 더 잘 맞기 때문에 파일의 모든 메타 정보를 저장하는 MongoDB 를 포함 시켰습니다 . 예를 들어, 사진에는 Exif 정보가 있고 비디오에는 메타 정보를 저장하려는 오디오 트랙이있을 수 있습니다. 비디오와 벡터 그래픽은 일반적인 메타 정보 등을 공유하지 않으므로 MongoDB는이 구조화되지 않은 데이터를 저장하고 검색 가능하게 유지하는 것이 완벽하다는 것을 알고 있습니다.

그러나 우리는 계속 플랫폼을 개발하고 기능을 추가합니다. 다음 단계 중 하나는 사용자를위한 포럼을 제공하는 것입니다. 이제 발생하는 문제는 포럼 및 포럼 게시물 등을 저장하는 데 적합한 MySQL 데이터베이스를 사용하거나 MongoDB를 사용하는 것입니까?

문제는 MongoDB 사용시기와 RDBMS 사용시기입니다. 선택했다면 mongoDB 또는 MySQL 중에서 무엇을 선택하고 왜 선택해야합니까?

에서 NoSQL이 : 그것은 그렇게 쉬운 일 경우에만 MongoDB에 대한 저자의 쓰기 :

MongoDB는 키 / 값 저장소가 아니며 훨씬 더 중요합니다. RDBMS도 아닙니다. 프로덕션 환경에서 MongoDB를 사용하지는 않았지만 테스트 앱을 약간 빌드하는 데 사용했으며 매우 멋진 키트입니다. 성능이 매우 뛰어나고 내결함성과 자동 샤딩 (일명 스케일링)이 있거나 곧있을 것입니다. Mongo가 지금까지 본 RDBMS 대체품에 가장 가까운 것으로 생각합니다. 모든 데이터 세트 및 액세스 패턴에 대해 작동하지는 않지만 일반적인 CRUD에 적합합니다. 본질적으로 거대한 해시를 저장하고 해당 키를 선택할 수 있다는 것은 대부분의 사람들이 관계형 데이터베이스를 사용하는 것입니다.DB가 3NF이고 조인을 수행하지 않으면 (많은 테이블을 선택하고 모든 객체를 모으는 것, 대부분의 사람들이 웹 응용 프로그램에서하는 일명 AKA) MongoDB는 아마도 당신을 위해 엉덩이를 걷어차 것입니다.

그런 다음 결론에서 :

실제로 지적해야 할 것은 데이터베이스를 선택할 수 없기 때문에 멋진 것을 만드는 것을 막고 있다면 잘못하고 있다는 것입니다. mysql을 알고 있다면 사용하십시오. 실제로 필요할 때 최적화하십시오. ak / v store처럼 사용하고 rdbms처럼 사용하지만 신을 위해 킬러 앱을 빌드하십시오! 이 중 어느 것도 대부분의 앱에 중요하지 않습니다. Facebook은 여전히 ​​MySQL을 많이 사용합니다. 위키 백과는 MySQL을 많이 사용합니다. FriendFeed는 MySQL을 많이 사용합니다. NoSQL은 훌륭한 도구이지만 경쟁 우위가 될 수 없으며 앱을 뜨겁게 만들지 않을 것입니다. 무엇보다도 사용자는 이것에 대해 신경 쓰지 않을 것입니다.

다음 앱은 무엇으로 만들 예정입니까? 아마 Postgres. NoSQL을 사용합니까? 아마도. Hadoop과 Hive를 사용할 수도 있습니다. 모든 것을 평평한 파일로 유지할 수 있습니다. 어쩌면 Maglev에서 해킹을 시작할 것입니다. 나는 직업에 가장 적합한 것을 사용할 것이다. 보고가 필요한 경우 NoSQL을 사용하지 않습니다. 캐싱이 필요한 경우 Tokyo Tyrant를 사용합니다. ACIDity가 필요한 경우 NoSQL을 사용하지 않습니다. 많은 카운터가 필요한 경우 Redis를 사용합니다. 거래가 필요한 경우 Postgres를 사용합니다. 단일 유형의 문서가 많은 경우 Mongo를 사용합니다. 하루에 10 억 개의 객체를 작성해야한다면 Voldemort를 사용했을 것입니다. 전체 텍스트 검색이 필요하다면 Solr을 사용했을 것입니다. 휘발성 데이터에 대한 전체 텍스트 검색이 필요하다면 Sphinx를 사용했을 것입니다.

나는이 기사를 좋아한다. 나는 매우 유익한 정보를 얻는다. NoSQL 환경과 과대 광고에 대한 좋은 개요를 제공한다. 그러나 가장 중요한 부분은 RDBMS와 NoSQL 중에서 선택할 때 올바른 질문을하는 데 실제로 도움이됩니다. 읽을만한 가치가 있습니다.

기사에 대한 다른 링크

2 년 동안 MongoDb를 소셜 앱으로 사용한 후 SQL RDBMS없이 살기의 의미가 무엇인지 목격했습니다.

1. RDBMS가 자동으로 수행하는 다른 테이블 / 컬렉션의 데이터 조인과 같은 작업을 수행하는 작업을 작성하게됩니다.
2. NoSQL의 쿼리 기능이 크게 손상되었습니다. MongoDb는 SQL에 가장 가까운 것이지만 여전히 매우 뒤떨어져 있습니다. 날 믿어. SQL 쿼리는 매우 직관적이고 유연하며 강력합니다. MongoDb 쿼리는 그렇지 않습니다.
3. MongoDb 쿼리는 하나의 컬렉션에서만 데이터를 검색하고 하나의 인덱스 만 활용할 수 있습니다. 그리고 MongoDb는 아마도 가장 유연한 NoSQL 데이터베이스 중 하나 일 것입니다. 많은 시나리오에서 이는 관련 레코드를 찾기 위해 서버로 더 많은 왕복을 의미합니다. 그런 다음 데이터 비정규 화를 시작합니다. 즉 백그라운드 작업을 의미합니다.
4. 데이터베이스가 관계형 데이터베이스가 아니라는 사실은 데이터의 일관성을 유지하기 위해 외래 키 제약 조건이없는 것을 의미합니다. 이것이 결국 데이터베이스에 데이터 불일치를 생성 할 것이라고 확신합니다. 준비하십시오. 대부분의 경우 데이터베이스의 일관성을 유지하기 위해 프로세스 작성 또는 검사를 시작하게되므로 RDBMS가이를 수행하도록하는 것보다 성능이 떨어질 수 있습니다.
5. 동면과 같은 성숙한 프레임 워크는 잊어 버리십시오.

모든 프로젝트의 98 %가 NoSQL보다 일반적인 SQL RDBMS에서 더 나을 것이라고 생각합니다.

이 비정형 데이터를 저장

말했듯이 MongoDB는 비정형 데이터를 저장하는 데 가장 적합합니다. 그리고 이것은 데이터를 문서 형식으로 구성 할 수 있습니다. NoSQL 데이터 저장소 ( MongoDB , CouchDB , Voldemort ) 라고하는 이러한 RDBMS 대체 기능은 대규모로 확장되고 이러한 빅 데이터 저장소에서 더 빠른 데이터 액세스가 필요한 애플리케이션에 매우 유용합니다.

그리고 이러한 데이터베이스의 구현은 일반 RDBMS보다 간단합니다. 이것들은 단순한 키-값 또는 문서 스타일 바이너리 객체이기 때문에 디스크에 직접 직렬화됩니다. 이러한 데이터 저장소는 ACID 속성 및 스키마를 적용하지 않습니다 . 이것은 거래 능력을 제공하지 않습니다 . 따라서 확장 성이 커지고 더 빠른 액세스 (읽기 및 쓰기)를 달성 할 수 있습니다.

그러나 RDBM은 데이터에 ACID 및 스키마를 적용합니다. 구조화 된 데이터로 작업하려면 RDBM을 사용하십시오.

이런 종류의 포럼 을 만들기 위해 MySQL 을 선택합니다 . 이것은 크게 확장되지 않기 때문입니다. 그리고 이것은 데이터 사이에 구조화 된 관계를 갖는 매우 간단한 (공통) 응용 프로그램입니다.

Mongo는 기본적으로 JSON을 저장합니다. 앱이 많은 JS 객체 (중첩 포함)를 처리하고 있으며 이러한 객체를 유지하려는 경우 Mongo를 사용하는 데 대한 강력한 논거가 있습니다. DAL 및 MVC 레이어는 모든 JS 객체 속성의 패키지를 풀지 않고 자연스럽게 맞지 않는 구조 (스키마)에 강제로 맞추려고하지 않기 때문에 매우 얇습니다.

우리는 몇 개의 복잡한 JS 객체를 중심으로하는 시스템을 가지고 있으며, 모든 것을 실제로, 정말 쉽게 유지할 수 있기 때문에 Mongo를 좋아합니다. 우리의 객체는 다소 비정질이며 구조화되어 있지 않으며 Mongo는 깜박이지 않고 그 합병증을 흡수합니다. 우리는 인간 소비에 대한 비정질 데이터를 해독하는 사용자 정의보고 계층을 가지고 있으며 개발하기가 어렵지 않았습니다.

복잡한 트랜잭션이 필요한 경우 RDBMS를 사용한다고 말합니다. 그렇지 않으면 MongoDB와 함께 갈 것입니다-더 유연하게 작업하고 필요할 때 확장 할 수 있다는 것을 알고 있습니다. (하지만 편견이 있습니다-MongoDB 프로젝트에서 작업합니다)

분산 된 샤드 포럼이 필요한 사람은 누구입니까? 아마도 Facebook이지만 Facebook 경쟁자를 만들지 않는 한 Mysql, Postgres 또는 가장 편한 것을 사용하십시오. MongoDB를 사용 해보고 싶다면 좋아하지만 마술을 기대하지 마십시오. 당신이 이미 이미 작업하고 있다면 이미 발견했듯이 다른 모든 것과 마찬가지로 기발하고 일반적인 성실함이 있습니다.

물론, MongoDB는 과장되어 표면에서 쉬워 보일 수 있지만 더 성숙한 제품이 이미 극복 한 문제가 발생할 수 있습니다. 그렇게 쉽게 유혹하지 말고 "nosql"이 성숙하거나 죽을 때까지 기다리십시오.

개인적으로, "nosql"은 정해진 표준 (거의 정의에 따라)이 없기 때문에 조각화로 시들어 죽을 것이라고 생각합니다. 그래서 나는 장기 프로젝트에 개인적으로 투자하지 않을 것입니다.

필자의 책에 "nosql"을 저장할 수있는 유일한 방법은 Ruby 나 유사한 언어에 완벽하게 통합 될 수 있고 코딩과 디자인에 거의 오버 헤드없이 언어를 "지속적"으로 만들 수 있다는 것입니다. 그것은 지나갈 지 모르지만 지금은 아니고 그때까지 기다릴 것이고 물론 더 성숙해야합니다.

Btw, 왜 처음부터 포럼을 만들고 있습니까? 차세대 포럼을 만들지 않는 한 대부분의 요구 사항에 맞게 조정할 수있는 수많은 오픈 소스 포럼이 있습니다 (의심 할 것입니다).

많은 회사에서 애플리케이션 로그의 실시간 분석을 위해 MongoDB를 사용하고있는 것을 보았습니다. 스키마가없는 것은 레코드 스키마가 때때로 변경되는 경향이있는 응용 프로그램 로그에 실제로 적합합니다. 또한 Capped Collection 기능은 오래된 데이터를 자동으로 제거하여 데이터를 메모리에 맞추기 때문에 유용합니다.

그것은 실제로 MongoDB가 적합하다고 생각하는 영역이지만 MySQL / PostgreSQL이 일반적으로 더 권장됩니다. 웹에는 기능과 견고성뿐만 아니라 많은 문서와 개발자 리소스가 있습니다.

몽고를 선호하는 2 가지 주요 이유는

• 스키마 디자인의 유연성 (JSON 유형 문서 저장소).
• 확장 성-노드를 추가하기 만하면 수평 확장이 가능합니다.

빅 데이터 애플리케이션에 적합합니다. RDBMS는 빅 데이터에 적합하지 않습니다.

조인과 '복잡한 트랜잭션'에 관한이 모든 것들을 알고 있습니다.하지만 수년 전에 COMMIT / ROLLBACK의 "필요한"부분을 설명해 준 Monty 자신이었습니다. (데이터베이스가 아닌) 어쨌든 '-다시 한 번 같은 일입니다. 필요한 것은 웹 앱의 99 %에 대해 멍청하지만 매우 정교하고 빠른 데이터 저장 / 검색 엔진입니다.

이전에 말했듯이 많은 선택 중에서 선택할 수 있으며 모든 선택을 살펴보십시오. http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

내가 제안하는 것은 최고의 조합을 찾는 것입니다 : MySQL + Memcache는 ACID가 필요하고 일부 테이블을 조인하려는 경우 정말 좋습니다. MongoDB + Redis는 문서 저장소에 적합 Neo4J는 그래프 데이터베이스에 완벽합니다

내가하는 일 : 사용하기 때문에 MySQl + Memcache로 시작한 다음 다른 데이터베이스 프레임 워크를 사용하기 시작합니다. 단일 프로젝트에서 예를 들어 MySQL과 MongoDB를 결합 할 수 있습니다!