mongoose 대 mongodb (nodejs 모듈 / 확장), 어느 것이 더 낫습니까? 그리고 왜?

방금 Node.js에 도착했고 MongoDB와 함께 사용할 많은 라이브러리가 있다는 것을 알았습니다. 가장 인기있는 것은 다음 두 가지 인 것 같습니다 : (mongoose 및 mongodb). 이러한 확장의 장단점을 얻을 수 있습니까? 이 두 가지에 대한 더 나은 대안이 있습니까?

편집 : 흥미로운 node-mongolian으로 보이는 새 라이브러리를 찾았으며 "Mongolian DeadBeef는 mongodb 셸에 가깝게 접근하려는 멋진 Mongo DB node.js 드라이버입니다." (readme.md)

https://github.com/marcello3d/node-mongolian

이것은 단지 이것을 보는 새로운 사람들에게 더 많은 자원을 추가하는 것입니다. 기본적으로 몽골어는 ODM과 같습니다.

Mongoose는 더 높은 수준이며 MongoDB 드라이버 (종속성, package.json 확인)를 사용하므로 해당 옵션이 주어지면 어느 쪽이든 사용하게됩니다. 스스로에게 물어봐야 할 질문은 "원시 드라이버를 사용하고 싶습니까, 아니면 객체 문서 모델링 도구가 필요합니까?"입니다. 낮은 수준의 작업을 건너 뛰기 위해 개체 모델링 (ODM, SQL 세계의 ORM에 대응) 도구를 찾고 있다면 Mongoose가 필요합니다.

드라이버를 원하면 ODM이 적용 할 수있는 많은 규칙을 위반할 계획이므로 MongoDB를 사용하십시오. 빠른 드라이버를 원하고 누락 된 기능으로 살 수 있다면 Mongolian DeadBeef를 사용해보세요 : https://github.com/marcello3d/node-mongolian

몽구스는 지금까지 가장 인기가 있습니다. 나는 그것을 사용하고 다른 것을 사용하지 않았습니다. 그래서 다른 사람들에 대해 말할 수는 없지만 몽구스에 대한 나의 불만은 말할 수 있습니다.

• 어렵거나 잘못된 문서
• 모델 이 사용됩니다. 그리고 문서의 구조를 정의합니다. 그러나 Mongo의 장점 중 하나는 열 (오류, 속성?)을 넣거나 단순히 열을 추가 할 수 없다는 점에서 이상하게 보입니다.
• 모델은 대소 문자를 구분합니다-나와 함께 일하는 다른 개발자는 모델이 정의 된 컬렉션 이름의 대소 문자로 인해 오류없이 아무것도 저장하지 못하는 문제가있었습니다. 우리는 모든 소문자 이름을 사용하는 것이 가장 효과적이라는 것을 발견했습니다. 예 mongooseInstace.model('MyCollection', { "_id": Number, "xyz": String })를 들어 (컬렉션 이름이 실제로 임에도 불구하고)하는 것이 더 좋습니다 MyCollection.mongooseInstace.model('mycollection', { "_id": Number, "xyz": String })

하지만 솔직히 정말 유용합니다. 가장 큰 문제는 문서입니다. 거기에 있지만 건조하고 필요한 것을 찾기가 어렵습니다. 더 나은 설명과 더 많은 예를 사용할 수 있습니다. 그러나 이러한 것들을지나 치면 정말 잘 작동합니다.

나는 새로운 앱을 만들고 지금 그 구조를 설계하고 있는데, 몽구스를 사용하거나 사용하지 않는 이유에 대한 몇 가지 생각이 있습니다.

1. 몽구스는 느려질 것입니다 (큰 앱의 경우)
2. Mongoose는 더 복잡한 쿼리로 더 어렵습니다.
3. 더 빠른 속도를 원하고 몽구스없이 선택하는 상황이있을 것입니다. 그러면 몽구스를 사용하여 절반을 쿼리하고 절반을 사용하지 않을 것입니다. 미친 상황 이네요 ..
4. Mongoose는 간단한 db 구조의 간단한 앱으로 더 빠르게 코딩 할 수 있습니다.
5. Mongoose는 mongodb 문서와 mongoose 문서를 읽을 수있게합니다.
6. 몽구스를 사용하면 스택이 한 가지 더 의존 할 수 있으며 충돌하여 재로 타 버릴 가능성이 하나 더 있습니다.

mongodb 드라이버는 원시 드라이버이며 mongodb와 직접 통신합니다. 몽구스는 추상화 계층입니다. db 구조가 충분히 단순하면서 db에 대한 I / O가 더 쉬워집니다.

추상화는 그것의 요구 사항을 가져오고 당신은 그것을 따라야합니다. 앱 속도가 느려지고 RAM이 더 많이 소모되며 더 복잡해 지지만 사용 방법을 알고 있다면 간단한 객체를 더 빨리 작성하고 데이터베이스에 저장할 수 있습니다.

mongoose가 없으면 mongodb에 직접 연결하여 더 빠른 응용 프로그램을 사용할 수 있습니다. 아무도 DB에 물건을 저장하기 위해 자신의 모델을 작성할 수 없다고 말합니다. 할 수 있습니다. 그리고 나는 그것이 더 쉽다고 생각합니다. 사용할 코드를 작성하면 필요한 것을 알 수 있습니다. 추상화 레이어는 몽구스보다 훨씬 작습니다.

나는 PHP 세계에서 왔고, 우리는 감가 상각 된 mysql_ 함수가있는 원시 SQL을 가지고 있었고 PDO-객체 지향 추상화 계층을 사용하여 SQL과 통신했습니다. 또는 Doctrine과 같은 무거운 ORM을 선택하여 mongoDB의 mongoose와 유사한 것을 가질 수 있습니다. setter / getters / save 메소드 등이있는 객체. 괜찮지 만 더 많은 추상화를 추가하면 더 많은 파일, 더 많은 논리, 더 많은 문서, 더 많은 종속성이 추가됩니다. 나는 물건을 단순하게 유지하고 스택에 덜 의존하는 것을 좋아합니다. BTW, 그래서 처음에 PHP에서 서버-클라이언트 자바 스크립트로 옮겼습니다 ..

mongoose를 사용하면 sql과 유사한 간단한 db 구조를 가진 간단한 앱 을 작성하는 것이 좋습니다 . 하위 문서를 만들기 시작하고 모든 미친 쿼리를 만들고 싶을 때 나는 몽구스로 정말 힘들다는 것을 알았습니다. mongodb 문서를 살펴본 다음 mongoose 문서를 살펴보고 원하는 쿼리를 만드는 방법을 찾아야합니다. 때때로 mongodb의 X future가 몽구스에 없다는 것을 알게 될 것이므로 원시 mongodb 드라이버로 이동하여 원시 mongodb 쿼리를 하나 또는 다른 위치에 작성합니다. mongoose가 없으면 mongodb 문서를보고 쿼리를 수행합니다.

나는 mongodb 만 사용했습니다. 제 개인적인 의견으로는 낮은 수준으로 시작한 다음 위로 올라가는 것이 좋습니다. 그렇지 않으면 몽구스와 같은 상위 레벨 드라이버가 제공하는 추가 고급 기능을 사용하여 실제 이점이 없음을 알 수 있습니다.

node.js 고유의 mongodb 문제는 문서가 좋지 않다는 것입니다. 문서와 많은 것이 있지만 항상 가장 도움이되는 것은 아닙니다. 지금까지 본 드라이버의 프로덕션 사용에 대한 훌륭하고 철저한 예제는 없습니다. 문서는 연결 열기, 명령 실행 및 연결 닫기에 대한 동일한 템플릿 예제로 채워져 있습니다. 모든 예제에는 각 예제에 필요한 것만이 아니라 필요할 수있는 모든 것을 포함하므로 템플릿에서 복사하여 붙여 넣었다는 것을 알 수 있습니다.

전적으로 무작위로 가져온 예제를 제공하려면 :

• raw {Boolean, default : false}, 원시 bson 버퍼를 사용하여 작업을 수행합니다.

"원시 bson 버퍼를 사용하여 작업 수행"은 정확히 무엇을합니까? 어디서도 설명을 찾을 수 없으며 해당 구문에 대한 Google 검색은 도움이되지 않습니다. Google을 더 많이 할 수는 있지만 그럴 필요는 없습니다. 정보가 있어야합니다. 이 옵션을 활성화 / 비활성화하는 데 성능, 안정성, 무결성, 호환성, 이식성 또는 기능상의 이점이 있습니까? 코드를 깊이 파고 들지 않고서는 정말 모르겠습니다. 당신이 내 보트에 있다면 그것은 심각한 문제입니다. 완벽한 지속성이 필요하지 않지만 프로그램이 런타임에 매우 안정적이어야하는 데몬이 있습니다. 나는 이것이 내가 JSON으로 deserialize하고 직렬화 할 것으로 기대하거나 사용자에게 낮은 수준의 내부적이며 투명한 것이지만 틀릴 수 있음을 의미한다고 가정 할 수 있습니다. 나는 좋은 가정을하는 경향이 있지만 중요한 시스템을 만들 때 가정과 추측에 의존 할 수는 없습니다. 따라서 여기에서 코드로 내 주장을 테스트하거나 Google 또는 해당 코드를 훨씬 더 깊이 파고들 수 있습니다. 하나로서 이것은 그렇게 나쁘지는 않지만 문서를 읽을 때이 상황에서 여러 번 내 자신을 찾습니다. 차이는 작업에 소요 된 일수와 시간을 의미 할 수 있습니다. 확인이 필요하며 문서는 확인은 말할 것도없고 거의 설명을 제공하지 않습니다.

문서가 쇄도합니다. 이벤트를 설명하지 않고 오류가 발생하는시기 또는 해당 오류의 특성에 대한 모호한 세부 정보를 제공하며 종종 불분명 할 수있는 연결을 수행하는 여러 방법이 있습니다. 당신은 지나갈 수 있으며 완전히 쓸모가 없지만 가장자리가 매우 거칠습니다. 추측과 실험에 남은 몇 가지 사항을 발견하게 될 것입니다.