mongoose vs mongodb (moduły / rozszerzenia nodejs), które lepsze? i dlaczego?

Właśnie dotarłem do Node.js i zobaczyłem, że istnieje wiele bibliotek, których można używać z MongoDB, najpopularniejsze wydają się być te dwie: (mongoose i mongodb). Czy mogę uzyskać zalety i wady tych rozszerzeń? Czy są lepsze alternatywy dla tych dwóch?

Edycja: Znalazłem nową bibliotekę, która wydaje się również interesująca dla węzłów mongolskich i brzmi: „Mongolski DeadBeef to niesamowity sterownik Mongo DB node.js, który próbuje bardzo przybliżyć powłokę mongodb”. (readme.md)

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

Ma to na celu dodanie większej liczby zasobów do nowych ludzi, którzy to widzą, więc w zasadzie mongolski jest jak ODM ...

Mongoose jest na wyższym poziomie i używa sterownika MongoDB (jest to zależność, sprawdź plik package.json), więc będziesz go używać w obu przypadkach, biorąc pod uwagę te opcje. Pytanie, które powinieneś sobie zadać, brzmi: „Czy chcę używać surowego sterownika, czy potrzebuję narzędzia do modelowania dokumentów obiektowych?” Jeśli szukasz narzędzia do modelowania obiektów (ODM, odpowiednika ORMów ze świata SQL), które pomija niektóre prace na niższym poziomie, potrzebujesz Mongoose.

Jeśli potrzebujesz sterownika, ponieważ zamierzasz złamać wiele zasad, które może egzekwować ODM, skorzystaj z MongoDB. Jeśli chcesz mieć szybki sterownik i możesz żyć z brakującymi funkcjami, wypróbuj Mongolian DeadBeef: https://github.com/marcello3d/node-mongolian

Zdecydowanie najpopularniejsza jest Mongoose. Używam go i nie korzystałem z innych. Nie mogę więc mówić o innych, ale mogę ci powiedzieć, co mam na myśli Mongoose.

• Trudna / słaba dokumentacja
• Używane są modele . I definiują strukturę Twoich dokumentów. Jednak wydaje się to dziwne w przypadku Mongo, gdzie jedną z jego zalet jest to, że można wrzucić kolumnę (błąd, atrybut?) Lub po prostu jej nie dodać.
• W modelach jest rozróżniana wielkość liter - ja i inni deweloperzy, z którymi pracuję, mieliśmy problemy, w których wielkość liter w nazwie kolekcji, w której model jest zdefiniowany, może spowodować, że nie zapisuje niczego, bez błędu. Odkryliśmy, że używanie wszystkich małych liter działa najlepiej. Np. Zamiast robić coś takiego mongooseInstace.model('MyCollection', { "_id": Number, "xyz": String }), jak to lepiej zrobić (mimo że nazwa kolekcji to naprawdę MyCollection):mongooseInstace.model('mycollection', { "_id": Number, "xyz": String })

Ale szczerze, to naprawdę przydatne. Największym problemem jest dokumentacja. Jest tam, ale jest sucho i trudno znaleźć to, czego potrzebujesz. Przydałoby się lepsze wyjaśnienia i więcej przykładów. Ale kiedy już miniesz te rzeczy, działa naprawdę naprawdę dobrze.

Buduję nową aplikację i projektuję teraz jej strukturę, oto kilka myśli o tym, dlaczego używać mangusty lub nie:

1. Mongoose będzie wolniejszy (dla dużych aplikacji)
2. Mongoose jest trudniejsze z bardziej skomplikowanymi zapytaniami
3. Będą sytuacje, w których będziesz chciał większej szybkości i zdecydujesz się przejść bez mangusty, wtedy będziesz mieć połowę zapytań z mangustą i połowę bez. To szalona sytuacja, kiedyś ...
4. Mongoose przyspieszy pisanie kodu dzięki prostym aplikacjom z prostą strukturą bazy danych
5. Mongoose sprawi, że będziesz czytać dokumenty mongodb i mongoose docs
6. Z mangustą Twój stos zyska jeszcze jedną rzecz, na której możesz polegać i jest to jeszcze jedna możliwość rozbicia się i spalenia na popiół.

Sterownik mongodb jest sterownikiem surowym, komunikujesz się bezpośrednio z mongodb. mangusta to warstwa abstrakcji. Uzyskujesz łatwiejsze I / O do db, podczas gdy struktura bazy danych jest wystarczająco prosta.

Abstrakcja wprowadza swoje wymagania i musisz ich przestrzegać. Twoja aplikacja będzie wolniejsza, zużywa więcej pamięci RAM i będzie bardziej skomplikowana, ale jeśli wiesz, jak z niej korzystać, możesz szybciej pisać proste obiekty, zapisując je w bazie danych.

Bez mangusty będziesz miał szybszą aplikację z bezpośrednim połączeniem z mongodb. Nikt nie mówi, że nie możesz pisać własnych modeli, aby zapisywać rzeczy do bazy danych. Możesz. Myślę, że to łatwiejsze. Piszesz kod, którego będziesz używać, wiesz czego potrzebujesz. Twoja warstwa abstrakcji będzie znacznie mniejsza, niż warstwa mangusty.

Pochodzę ze świata PHP, tam mieliśmy surowy sql ze zdeprecjonowanymi funkcjami mysql_, a potem otrzymaliśmy PDO - obiektową warstwę abstrakcji do komunikacji z sql. Lub możesz wybrać ciężki ORM, taki jak Doctrine, aby mieć podobne rzeczy do mongoose w mongoDB. Obiekty z metodą setter / getters / save i tak dalej. To dobrze, ale dodając więcej abstrakcji, dodajesz więcej plików, więcej logiki, więcej dokumentacji, więcej zależności. Lubię upraszczać rzeczy i mieć mniej zależności w moim stosie. Przy okazji, właśnie dlatego przeniosłem się z PHP na Javascript na kliencie serwera.

Myślę, że w przypadku Mongoose wspaniale jest pisać proste aplikacje, które mają prostą strukturę db podobną do sql . Kiedy zaczynasz mieć subdokumenty i chcesz robić te wszystkie szalone zapytania, okazało się, że jest to naprawdę trudne z mangustą. Musisz spojrzeć na dokumenty mongodb, a następnie przejrzeć dokumenty mongoose, aby dowiedzieć się, jak utworzyć zapytanie, które chcesz. Czasami okaże się, że X future of mongodb nie jest w mangusta, więc przechodzisz do surowego sterownika mongodb i piszesz surowe zapytania mongodb w jednym lub innym miejscu. Bez mangusty przeglądasz dokumenty mongodb i wykonujesz zapytanie.

Użyłem tylko mongodb. Osobiście osobiście radziłbym zacząć od czegoś niskiego, a następnie przejść wyżej. W przeciwnym razie możesz skorzystać z dodatkowych zaawansowanych funkcji dostarczanych przez sterowniki wyższego poziomu, takie jak mangusta, bez żadnych rzeczywistych korzyści.

Problem, który miałem z mongodb, który jest endemiczny dla node.js, to słaba dokumentacja. Istnieje dokumentacja i dużo jej, ale nie zawsze jest ona najbardziej pomocna. Z tego, co widziałem do tej pory, nie ma dobrych i dokładnych przykładów wykorzystania sterownika w produkcji. Dokumentacja jest wypełniona tym samym szablonowym przykładem otwierania połączenia, wydawania polecenia i zamykania połączenia. Możesz powiedzieć, że jest skopiowany i wklejony z szablonu, ponieważ każdy przykład zawiera wymagane dla wszystkiego, co może być potrzebne, a nie tylko to, co jest potrzebne dla każdego przykładu.

Aby podać przykład wzięty całkowicie przypadkowo:

• raw {Boolean, default: false}, wykonuje operacje przy użyciu surowych buforów bson.

Co dokładnie oznacza „wykonywanie operacji przy użyciu surowych buforów bson”? Nie mogę znaleźć tego nigdzie wyjaśnionego, a wyszukiwanie tego wyrażenia w Google nie pomaga. Być może mógłbym dalej Google, ale nie powinienem. Informacje powinny tam być. Czy są jakieś korzyści związane z wydajnością, stabilnością, integralnością, kompatybilnością, przenośnością lub funkcjami włączania / wyłączania tej opcji? Naprawdę nie mam pojęcia bez zagłębienia się w kod, a jeśli jesteś na mojej łodzi, jest to poważny problem. Mam demona, w którym doskonała trwałość nie jest wymagana, ale program musi być bardzo stabilny w czasie wykonywania. Mogę założyć, że oznacza to, że oczekuje ode mnie deserializacji i serializacji do JSON lub jest czymś niskopoziomowym, wewnętrznym i przezroczystym dla użytkownika, ale mogę się mylić. Chociaż zwykle robię dobre założenia, nie mogę polegać na przypuszczeniach i domysłach podczas tworzenia ważnych systemów. Więc tutaj mogę albo przetestować moją asercję za pomocą kodu, albo zagłębić się w Google lub ich kod. Jako jedyny nie jest to takie złe, ale wielokrotnie znajduję się w tej sytuacji, czytając ich dokumentację. Różnica może oznaczać liczbę dni spędzonych na zadaniu w porównaniu z godzinami. Potrzebuję potwierdzenia, a dokumentacja ledwo daje mi wyjaśnienie, nie mówiąc już o potwierdzeniu.

Dokumentacja jest pospieszna. Nie wyjaśnia wydarzeń, podaje niejasne szczegóły dotyczące pojawiania się błędów lub natury tych błędów, a często istnieje kilka sposobów osiągnięcia łączności, które mogą być niejasne. Możesz sobie poradzić i nie jest to całkowicie bezużyteczne, ale jest bardzo szorstkie na krawędziach. Przekonasz się, że niektóre rzeczy są pozostawione domysłom i eksperymentom.