mongoose vs mongodb (mô-đun / phần mở rộng nodejs), cái nào tốt hơn? và tại sao?

Tôi vừa mới đến Node.js và thấy rằng có rất nhiều lib để sử dụng với MongoDB, phổ biến nhất dường như là hai thứ này: (mongoose và mongodb). Tôi có thể nhận được ưu và nhược điểm của những tiện ích mở rộng đó không? Có lựa chọn thay thế tốt hơn cho hai loại này không?

Chỉnh sửa: Đã tìm thấy một thư viện mới có vẻ cũng rất thú vị là node-mongolian và là "Mongolian DeadBeef là một trình điều khiển Mongo DB node.js tuyệt vời cố gắng gần đúng với shell mongodb." (readme.md)

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

Đây chỉ là để thêm nhiều tài nguyên hơn cho những người mới xem điều này, vì vậy về cơ bản tiếng Mông Cổ giống như một ODM ...

Mongoose là cấp cao hơn và sử dụng trình điều khiển MongoDB (đó là một phần phụ thuộc, hãy kiểm tra package.json), vì vậy bạn sẽ sử dụng theo cách đó với các tùy chọn đó. Câu hỏi bạn nên tự hỏi mình là, "Tôi muốn sử dụng trình điều khiển thô hay tôi cần một công cụ mô hình tài liệu-đối tượng?" Nếu bạn đang tìm kiếm một công cụ mô hình hóa đối tượng (ODM, một đối tác của ORM từ thế giới SQL) để bỏ qua một số công việc cấp thấp hơn, bạn muốn Mongoose.

Nếu bạn muốn một trình điều khiển, vì bạn có ý định phá vỡ nhiều quy tắc mà ODM có thể thực thi, hãy sử dụng MongoDB. Nếu bạn muốn có một trình điều khiển nhanh và có thể tồn tại với một số tính năng còn thiếu, hãy dùng thử Mongolian DeadBeef: https://github.com/marcello3d/node-mongolian

Mongoose, cho đến nay, là phổ biến nhất. Tôi sử dụng nó, và không sử dụng những người khác. Vì vậy, tôi không thể nói về những người khác, nhưng tôi có thể cho bạn biết mối quan hệ của tôi với Mongoose.

• Tài liệu khó / nghèo nàn
• Các mô hình được sử dụng. Và chúng xác định cấu trúc cho tài liệu của bạn. Tuy nhiên, điều này có vẻ kỳ lạ đối với Mongo khi một trong những lợi thế của nó là bạn có thể ném vào một cột (err, thuộc tính?) Hoặc đơn giản là không thêm một cột.
• Mô hình có phân biệt chữ hoa chữ thường - Bản thân tôi và các nhà phát triển khác mà tôi làm việc cùng đã gặp vấn đề trong đó trường hợp tên bộ sưu tập mà mô hình được xác định có thể khiến nó không lưu được gì, có lỗi. Chúng tôi nhận thấy rằng việc sử dụng tất cả các tên viết thường là tốt nhất. Ví dụ: thay vì làm điều gì đó giống như mongooseInstace.model('MyCollection', { "_id": Number, "xyz": String })tốt hơn nên làm (mặc dù tên bộ sưu tập thực sự là như vậy MyCollection):mongooseInstace.model('mycollection', { "_id": Number, "xyz": String })

Nhưng thành thật mà nói, nó thực sự hữu ích. Vấn đề lớn nhất là tài liệu. Nó ở đó, nhưng nó khô khan và khó tìm thấy thứ bạn cần. Nó có thể sử dụng các giải thích tốt hơn và nhiều ví dụ hơn. Nhưng một khi bạn vượt qua những điều này, nó hoạt động thực sự tốt.

Tôi đang xây dựng ứng dụng mới và hiện đang thiết kế cấu trúc của nó, sau đây là một số suy nghĩ về lý do tại sao nên sử dụng hoặc không sử dụng mongoose:

1. Mongoose sẽ chậm hơn (đối với các ứng dụng lớn)
2. Mongoose khó hơn với các truy vấn phức tạp hơn
3. Sẽ có những tình huống khi bạn muốn tốc độ cao hơn và bạn sẽ chọn không có mongoose, sau đó bạn sẽ có một nửa truy vấn với mongoose và nửa có w / o. Đó là tình huống điên rồ, đã từng ..
4. Mongoose sẽ giúp bạn viết mã nhanh hơn với các ứng dụng đơn giản có cấu trúc db đơn giản
5. Mongoose sẽ khiến bạn đọc tài liệu mongodb VÀ tài liệu mongoose
6. Với mongoose ngăn xếp của bạn sẽ có thêm một thứ để phụ thuộc vào và có thêm một khả năng nữa là sụp đổ và cháy thành tro.

trình điều khiển mongodb là trình điều khiển thô, bạn giao tiếp trực tiếp với mongodb. mongoose là lớp trừu tượng. Bạn nhận được I / O đến db dễ dàng hơn trong khi cấu trúc db của bạn đủ đơn giản.

Tính trừu tượng mang đến những yêu cầu và bạn phải tuân theo những yêu cầu đó. Ứng dụng của bạn sẽ chậm hơn, ngốn nhiều RAM và phức tạp hơn, nhưng nếu biết cách sử dụng, bạn có thể ghi nhanh hơn các đối tượng đơn giản, lưu chúng vào cơ sở dữ liệu.

Nếu không có mongoose, bạn sẽ có ứng dụng nhanh hơn với kết nối trực tiếp đến mongodb. Không ai nói rằng bạn không thể viết mô hình của riêng mình để lưu nội dung vào db. Bạn có thể. Và tôi nghĩ nó dễ dàng hơn. Bạn viết mã, mà bạn sẽ sử dụng, bạn biết bạn cần gì. Layer trừu tượng của bạn sẽ nhỏ hơn một chút, sau đó là mongoose.

Tôi đến từ thế giới PHP, ở đó chúng tôi có sql thô với các hàm mysql_ bị giảm giá trị, sau đó chúng tôi có PDO - lớp trừu tượng định hướng đối tượng để giao tiếp với sql. Hoặc bạn có thể chọn một số ORM nặng như Doctrine để có những thứ tương tự như mongoose trên mongoDB. Các đối tượng với phương thức setter / getters / save, v.v. Điều đó tốt, nhưng bằng cách thêm nhiều trừu tượng hơn, bạn đang thêm nhiều tệp hơn, nhiều logic hơn, nhiều tài liệu hơn, nhiều phụ thuộc hơn. Tôi muốn giữ mọi thứ đơn giản và ít phụ thuộc hơn trong ngăn xếp của mình. BTW, đó là lý do tại sao tôi chuyển từ PHP sang Javascript máy chủ-máy khách ngay từ đầu ..

Với mongoose, tôi nghĩ thật tuyệt khi viết một số ứng dụng đơn giản, có cấu trúc db đơn giản tương tự như sql . Khi bạn bắt đầu có các tài liệu phụ và muốn thực hiện tất cả những truy vấn điên rồ đó, tôi thấy nó thực sự khó khăn với mongoose. Bạn phải xem tài liệu mongodb, sau đó xem tài liệu mongoose để tìm cách thực hiện truy vấn bạn muốn. Đôi khi bạn sẽ thấy rằng tương lai X của mongodb không nằm trong mongoose, vì vậy bạn đi xuống trình điều khiển mongodb thô và viết các truy vấn mongodb thô ở một hoặc nơi khác. Nếu không có mongoose, bạn nhìn vào tài liệu mongodb và thực hiện truy vấn của mình.

Tôi đã chỉ sử dụng mongodb. Theo ý kiến ​​cá nhân của tôi, tôi khuyên bạn nên bắt đầu với mức thấp và sau đó tăng lên. Nếu không, bạn có thể thấy mình sử dụng các tính năng nâng cao bổ sung do trình điều khiển cấp cao hơn cung cấp như mongoose không mang lại lợi ích thực tế.

Vấn đề tôi gặp phải với mongodb, đặc hữu của node.js là tài liệu nghèo nàn. Có rất nhiều tài liệu nhưng không phải lúc nào cũng hữu ích nhất. Điều đó tôi đã thấy cho đến nay không có ví dụ tốt và kỹ lưỡng về việc sử dụng sản xuất trình điều khiển. Tài liệu này chứa đầy cùng một ví dụ mẫu về mở kết nối, ra lệnh và đóng kết nối. Bạn có thể biết đó là bản sao và được dán từ một mẫu vì mọi ví dụ đều bao gồm yêu cầu cho mọi thứ có thể cần thay vì chỉ những gì cần thiết cho mỗi ví dụ.

Để đưa ra một ví dụ được lấy hoàn toàn ngẫu nhiên:

• raw {Boolean, default: false}, thực hiện các thao tác sử dụng bộ đệm bson thô.

Chính xác thì "thực hiện các hoạt động bằng cách sử dụng bộ đệm bson thô" làm gì? Tôi không thể tìm thấy nó được giải thích ở bất cứ đâu và tìm kiếm trên Google cho cụm từ đó không giúp được gì. Có lẽ tôi có thể Google xa hơn nhưng tôi không nên làm vậy. Thông tin phải có ở đó. Có bất kỳ lợi thế về hiệu suất, tính ổn định, tính toàn vẹn, tính tương thích, tính di động hoặc chức năng nào để bật / tắt tùy chọn này không? Tôi thực sự không biết gì nếu không đi sâu vào mã và nếu bạn đang ở trong thuyền của tôi thì đó là một vấn đề nghiêm trọng. Tôi có một daemon mà không yêu cầu tính bền bỉ hoàn hảo nhưng chương trình cần phải rất ổn định trong thời gian chạy. Tôi có thể cho rằng điều này có nghĩa là nó mong tôi giải mã hóa và tuần tự hóa thành JSON hoặc là một thứ gì đó cấp thấp, nội bộ và minh bạch đối với người dùng nhưng tôi có thể đã nhầm. Mặc dù tôi có xu hướng đưa ra các giả định tốt nhưng tôi không thể dựa vào giả định và phỏng đoán khi đưa ra các hệ thống quan trọng. Vì vậy, ở đây tôi có thể kiểm tra khẳng định của mình bằng mã hoặc tìm hiểu sâu hơn về Google hoặc mã của họ. Nhìn chung, điều này không quá tệ nhưng tôi thấy mình ở trong tình huống này nhiều lần khi đọc tài liệu của họ. Sự khác biệt có thể có nghĩa là số ngày dành cho một nhiệm vụ so với số giờ. Tôi cần xác nhận và tài liệu hầu như không cung cấp cho tôi lời giải thích, chứ đừng nói đến xác nhận.

Tài liệu được gấp rút. Nó không giải thích các sự kiện, cung cấp các chi tiết mơ hồ về thời điểm xuất hiện lỗi hoặc bản chất của những lỗi đó và thường có một số cách để thực hiện kết nối có thể không rõ ràng. Bạn có thể nhận được và nó không hoàn toàn vô dụng, nhưng nó rất thô xung quanh các cạnh. Bạn sẽ thấy một số thứ còn lại để phỏng đoán và thử nghiệm.