mongoose対mongodb(nodejsモジュール/拡張)、どちらが良いですか?なぜ?


109

私はNode.jsにたどり着き、MongoDBで使用する多くのライブラリがあることを確認しました。最も人気があるのは、これら2つ(mongooseとmongodb)のようです。これらの拡張機能の長所と短所を取得できますか?これら2つに代わるより良い代替手段はありますか?

編集:node-mongolianにも興味深く、「Mongolian DeadBeefはmongodbシェルを厳密に近似しようとする素晴らしいMongo DB node.jsドライバーです」という新しいライブラリーを見つけました。(readme.md)

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

これは、これを表示する新しい人々にリソースを追加するためだけなので、基本的にモンゴル語はODMのようなものです...


スキーマレスデータベースにスキーマレイヤーを使用する理由 スキーマベースのデータベースが必要な場合は、データベース用に構築された別のデータベースを使用してください。(Mongooseはmongodbのスキーマ抽象化にすぎません)
SimonDragsbæk16年

回答:


123

Mongooseはより高いレベルであり、MongoDBドライバーを使用します(これは依存関係です。package.jsonを確認してください)。これらのオプションを指定すると、どちらの方法でも使用できます。「生のドライバを使用したいですか、それともオブジェクトドキュメントモデリングツールが必要ですか?」より低いレベルの作業をスキップするオブジェクトモデリング(ODM、SQLの世界のORMに相当するもの)ツールを探している場合は、Mongooseが必要です。

ドライバーが必要な場合は、ODMが適用する可能性のある多くのルールに違反するため、MongoDBを使用してください。高速なドライバーが必要で、いくつかの機能が不足している可能性がある場合は、Mongolian DeadBeefを試してみてください:https : //github.com/marcello3d/node-mongolian


34

マングースは、断然、最も人気があります。使用しており、他は使用していません。だから私は他の人について話すことはできませんが、マングースとの私の不満をあなたに伝えることができます。

  • 難しい/不十分なドキュメント
  • モデルが使用されます。また、ドキュメントの構造を定義します。しかし、これはMongoにとって奇妙に思われます。Mongoの利点の1つは、列をスローする(err、attribute?)か、単純に列を追加できないことです。
  • モデルでは大文字と小文字が区別されます-私と一緒に働く他の開発者は、モデルが定義されているコレクション名の大文字と小文字が、何も保存せず、エラーなしで問題を引き起こす可能性があります。すべての小文字の名前を使用するのが最適です。たとえばmongooseInstace.model('MyCollection', { "_id": Number, "xyz": String })、コレクション名が実際にそうであるとしても、それを行うほうが良いようなことをする代わりにMyCollectionmongooseInstace.model('mycollection', { "_id": Number, "xyz": String })

しかし正直なところ、それは本当に便利です。最大の問題はドキュメントです。そこにありますが、乾燥していて、必要なものを見つけるのは難しいです。より良い説明とより多くの例を使用できます。しかし、これらの事柄を乗り越えると、それは本当にとてもうまくいきます。


11
再:ドキュメント。私はこれ以上同意できませんでした。ドキュメンテーションは悪いし、あまりにも悪いことに、場所によっては正しくありません。私は自分でコードを解読していることがよくありますが(これはそれほど悪いことではありません)、ドキュメントの問題が原因です。
JPリチャードソン

1
AFAIKコレクションの名前は、MongooseではなくMongoで大文字と小文字が区別されます。
ニックキャンベル

34
誰かがドキュメントが今かなり良いと思っていた場合のために。
Kevin Beal 2013年

7
私は同意しません、ドキュメントはまだ遅いです。
スティーブK

5
文書がまだ不足していることにも同意します
ブレンダンヴァインスタイン

25

私は新しいアプリを作成し、その構造を設計しています。mongooseを使用する理由と使用しない理由について、以下に考えます。

  1. マングースは遅くなります(大きなアプリの場合)
  2. より複雑なクエリでは、マングースはより難しくなります
  3. より高速にしたい状況で、マングースなしで実行することを選択すると、マングースでクエリが半分になり、半分がw / oになります。それはクレイジーな状況でした。
  4. Mongooseは、シンプルなDB構造を持つシンプルなアプリでコードを高速化します
  5. Mongooseを使用すると、mongodbドキュメントとmongooseドキュメントを読むことができます
  6. mongooseを使用すると、スタックに依存するものが1つ増え、クラッシュして灰に焼かれる可能性が1つ増えます。

mongodbドライバーはrawドライバーで、mongodbと直接通信します。マングースは抽象化レイヤーです。db構造が十分にシンプルである一方で、dbへのI / Oが容易になります。

抽象化はそれの要件をもたらし、あなたはそれらに従う必要があります。アプリは遅くなり、より多くのRAMを消費し、より複雑になりますが、それを使用する方法を知っている場合は、単純なオブジェクトをより速く記述し、それらをデータベースに保存できます。

mongooseを使用しない場合、mongodbに直接接続して、より高速なアプリケーションを使用できます。自分でモデルを作成してデータをdbに保存することはできないと言う人は誰もいません。あなたはできる。そして私はそれが簡単だと思います。あなたはあなたが使うコードを書いて、あなたはあなたが何が必要かを知っています。あなたの抽象化層はマングースのものよりもずっと小さくなります。

私はPHPの世界から来ています。そこには、mysql_関数が廃止された生のSQLがあり、SQLと通信するためのオブジェクト指向の抽象化レイヤーであるPDOがありました。あるいは、Doctrineのような重いORMを選択して、mongoDB上のmongooseに似たものを持つことができます。setter / getters / saveメソッドなどを持つオブジェクト。それは問題ありませんが、抽象化を追加することで、ファイル、ロジック、ドキュメント、依存関係を追加できます。私はものをシンプルに保ち、スタック内の依存関係を減らしたいと思っています。ところで、そもそもPHPからサーバークライアントのJavascriptに移行したのはそのためです。

mongooseでは、sqlに似た単純なdb構造を持ついくつかの単純なアプリを書くのは素晴らしいと思います。サブドキュメントを作成し始めて、それらすべてのクレイジーなクエリを作成したいとき、マングースでは本当に難しいと思いました。mongodb docsを見て、次にmongoose docsを見て、必要なクエリを作成する方法を見つける必要があります。mongodbのXの未来がマングースではないことが時々あります。そのため、生のmongodbドライバーに行き、生のmongodbクエリをどこかで書きます。mongooseがなければ、mongodb docsを見てクエリを実行します。


3
また、高速で複雑なクエリを実行できるので、mongodbはmongooseよりも優れていると思います。大きなアプリにはより良いので、生のmongodbドライバーを使うべきです。私はあなたに強く同意します。
Abdul Alim Shakir、2018年

あなたが大きなアプリをしていない場合でも、私は強く同意します。複雑なクエリはマングースでそれらをやっに比べモンゴドライバではるかに簡単です
フアン

14

私はmongodbのみを使用しました。私の個人的な意見では、まずは低いレベルから始めて、上に移動することをお勧めします。そうしないと、mongooseのようなより高いレベルのドライバーが提供する追加の高度な機能を使用しても、実際のメリットは得られません。

node.jsに固有のmongodbで発生した問題は、不十分なドキュメントです。ドキュメントとその多くはありますが、常に最も役立つとは限りません。私がこれまで見てきたことは、ドライバーの本番使用の良い完全な例はありません。ドキュメントには、接続を開いてコマンドを発行し、接続を閉じるのと同じテンプレートの例が含まれています。すべての例には、各例に必要なものだけでなく、必要になる可能性のあるすべてのものが含まれているため、テンプレートからコピーして貼り付けることができます。

完全にランダムに取られた例を挙げます:

  • raw {Boolean、default:false}、生のbsonバッファを使用して操作を実行します。

「生のbsonバッファーを使用して操作を実行する」とは、具体的には何を行うものですか。私はそれがどこにも説明されているのを見つけることができず、そのフレーズをグーグルで検索しても役に立たない。多分私はさらにググることができたが、私はする必要はありません。情報があるはずです。このオプションを有効/無効にするためのパフォーマンス、安定性、整合性、互換性、移植性、または機能上の利点はありますか?コードを深く掘り下げない限り、私には本当にわからない。あなたが私のボートに乗っているのなら、それは深刻な問題だ。完全な永続性が要求されないデーモンがありますが、プログラムは実行時に非常に安定している必要があります。これは、JSONに逆シリアル化してシリアル化することを期待している、またはユーザーにとって内部的で透過的な低レベルであると想定できますが、間違っている可能性があります。私は良い仮定をする傾向がありますが、私は重要なシステムを作るときに仮定と当て推量に頼ることはできません。したがって、ここでコードを使用してアサーションをテストするか、Googleまたはそのコードをさらに深く掘り下げることができます。1回限りの場合、これはそれほど悪くはありませんが、ドキュメントを読んでいるときに何度もこの状況に陥っています。この違いは、タスクに費やした日数と時間数を意味します。確認が必要です。ドキュメントでは、確認は言うまでもなく、ほとんど説明がありません。

ドキュメントが急いでいます。イベントについては説明していません。エラーがスローされたときやそれらのエラーの性質について漠然とした詳細を示しています。接続を実現するには、多くの場合、不明確な方法がいくつかあります。完全に役に立たないわけではありませんが、エッジの周りは非常に粗くなっています。推測と実験に委ねられているものがいくつかあります。


優れたドキュメントには、優れたソフトウェアが付属しています。それは最も重要な部分の1つです。
Lukas Liesis 16
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.