Mongoid czy MongoMapper? [Zamknięte]

Wypróbowałem MongoMapper i jest on kompletny (oferuje prawie wszystkie funkcje AR), ale nie byłem zbyt zadowolony z wydajności podczas korzystania z dużych zestawów danych. Czy ktoś porównał z Mongoidem? Jakieś korzyści z wydajności?

Używałem MongoMapper od jakiegoś czasu, ale zdecydowałem się na migrację do MongoId. Powodem są ukryte problemy i arogancja wobec użytkowników. Musiałem przeskoczyć przez obręcze, aby MongoMapper działał z Cucumber (ostatecznie się udało) i założyć kilka łatek, nawet projekt był prosty, ale nie o to chodzi. Kiedy próbowałem zgłosić błąd (z powodu niezgodności z ActiveRecord), najwyraźniej wkurzyli się, że znalazłem problem i zostałem popchnięty. Podczas testowania napotkałem również poważny błąd w ich implementacji zapytań, podczas gdy ich testowanie było dostrojone w taki sposób, że testy przechodzą. Po moim poprzednim doświadczeniu nie odważyłem się go przesłać.

Mają znacznie mniejszą liczbę żądań ściągnięcia i zgłoszeń błędów / funkcji niż MongoId, co oznacza, że ​​udział społeczności jest znacznie niższy. Takie samo doświadczenie jak moje?

Nie wiem, który z nich ma teraz więcej funkcji, ale nie widzę wiele przyszłości w MongoMapper. Nie mam nic przeciwko samodzielnemu naprawianiu problemów i dodawaniu funkcjonalności, ale przeszkadzają mi sytuacje, w których nie naprawiliby błędów.

używam obu od kilku tygodni. Mongomapper ma lepsze wsparcie dla powiązań relacyjnych (nie osadzonych) i ma większe wsparcie dla stron trzecich. Mongoid ma lepszą obsługę zapytań, znacznie lepszą dokumentację (MM prawie jej nie ma, chociaż podobno działa strona internetowa), obsługę Rail 3 (a tym samym wsparcie Devise) i nieco bardziej aktywną społeczność na Grupach dyskusyjnych Google.

Skończyło się na Mongoid.

Różnice

MongoMapper

• Twierdził, że ma lepsze wsparcie dla związków relacyjnych.
• Twierdzono, że jest bardziej rozszerzalny ze względu na architekturę wtyczek.
• Używa DSL do wykonywania zapytań.
• Powiązania wiele do wielu są aktualizowane tylko jednostronnie w MongoMapper.
• Mniej niezawodna obsługa osadzonych dokumentów. Aktualizuje cały model, nawet jeśli zmodyfikowano tylko kilka atrybutów.

Mongoid

• Sugerowano, że jest szybszy niż MongoMapper na podstawie niepotwierdzonych dowodów.
• Bardziej niezawodna obsługa dokumentów osadzonych, wykorzystująca niepodzielne operacje MongoDB ($ set, $ push, $ pull itp.) Do aktualizowania zagnieżdżonych dokumentów w miejscu.
• Obsługuje dwukierunkowe asocjacje wiele do wielu.
• Używa do wykonywania zapytań składni podobnej do łańcucha ARel.

Podobieństwa

• Zarówno MongoMapper, jak i Mongoid mają witryny internetowe z dobrą dokumentacją. Od dawna twierdzono, że MongoMapper ma złą dokumentację, ale ich nowa witryna wydaje się wypełniać tę lukę.
• Oba można skonfigurować za pomocą pliku YAML i oba mają generator szyn dla tego pliku.
• Oba są w pełni kompatybilne z Rails 3.

Konfiguracja

MongoMapper

defaults: &defaults
  host: 127.0.0.1
  port: 27017

development:
  database: database_name

Mongoid

development:
  sessions:
    default:
      database: database_name
      hosts:
        - 127.0.0.1:27017

Biblioteki zewnętrzne

Obie strony twierdziły, że mają lepsze wsparcie innych firm. Github ujawnia następujące informacje:

• Wyszukiwanie frazy „Mongoid” daje 12671 wyników.
• Wyszukiwanie „MongoMapper” daje 4708 wyników.

Warto zauważyć, że Devise nie obsługuje MongoMapper.

Zatwierdź działanie

Wygląda na to, że w ciągu ostatniego roku Mongoid był bardziej regularnie konserwowany i aktualizowany niż MongoMapper.

MongoMapper

Mongoid

Różnica, którą znalazłem, polega na tym, że update_attributew MongoMapper wydaje się pisać cały dokument, niezależnie od tego, jakie atrybuty faktycznie się zmieniły. W Mongoid zapisuje tylko zmienione atrybuty. Może to stanowić poważny problem z wydajnością w przypadku dużych rekordów. Dotyczy to zwłaszcza dokumentów osadzonych (tutaj labels), np

profile = Profile.find(params[:id])
label = profile.labels.find_or_create_by(idx: params[:idx])
# MongoMapper doesn't have find_or_create_by for embedded docs
# -- you'll have to write custom code
profile.save

W przypadku saveMongoMapper zapisze cały profilerekord, ale MongoId użyje $setoperatora z logiką pozycyjną, aby zaktualizować tylko zmienioną etykietę.

Kolejną kwestią jest wybór pól do zwrócenia. Oba obsługują onlykryterium, ale Mongoid obsługuje również withoutkryterium, które jest natywnie obsługiwane przez Mongo.

Wydaje mi się, że Mongoid jest po prostu bardziej „zaokrąglony” i kompletny w swoim API, co prawdopodobnie wyjaśnia, że ​​jest to większa baza kodu. Wydaje się również, że jest lepiej udokumentowany.

Czy zainstalowałeś mongo_ext? Myślę, że wydajność jest bardziej związana ze sterownikiem niż z samym maperem. Patrząc na dziennik mongo widzę bez rozszerzenia, że ​​transer wydaje się mieć pewne opóźnienia.

Zrób również to, co zalecają na stronie monogdb, zaznacz tylko te pola, których potrzebujesz.

Przeprowadziłem kilka testów z MongoMapper w zeszłym tygodniu, był stabilny, ale uważałem, że interfejs zapytań jest trochę ograniczony (również niektóre z logiki AR były dziwne), przeszedłem dziś na Mongoid i czuje się znacznie lepiej w użyciu - i bardziej intuicyjny, jeśli jesteś używany do AR.

Brak wniosków dotyczących prędkości - ale przejście było bezbolesne - działa również z Rails 3.

Jeśli używasz Rails3, polecam Mongoid - używa on również „include” zamiast dziedziczenia „<” do utrwalania klas - użycie „include” jest lepszym paradygmatem w Ruby do dodawania trwałości. Mongoid działa dobrze dla mnie z Devise.

Aby poprawić wydajność, spróbuj selektywnie korzystać z dostępu niższego poziomu, np.Moped - widziałem, że jest to nawet 10x szybsze

Użyłem obu z nich i wkrótce będą miały taką samą funkcjonalność, ale spójrz na statystyki kodu

Wygląda na to, że MongoMapper ma znacznie lepszą jakość kodu (jeśli robi to samo z mniejszą ilością).

Możesz obliczyć te statystyki samodzielnie, oto analizator https://github.com/alexeypetrushin/code_stats

Myślę, że Mongoid jest znacznie lepszy w konfiguracji i mapowaniu.

Spodziewałbym się, że wydajność będzie taka sama, ostatnim razem, gdy sprawdzałem, że MongoMapper nie obsługuje Rails 3 - więc na razie patrzę na Mongoid.

sudo gem install mongo_ext jest kluczem do uzyskania wydajności.

MongoDB zdmuchuje CouchDB pod względem surowej szybkości - chociaż CDB ma swój własny zestaw zalet.

Benchmark: http://www.snailinaturtleneck.com/blog/?p=74

Devise nie wspierało MongoMapper, ja też wolę poruszać się po Rails3. Więc przeszedłem na mangusty.

Mongoid w pełni obsługuje Rails3 i ma funkcję mapy tożsamości.

Więcej dokumentów można znaleźć pod adresem http://mongoid.org

Zobacz wydajność tutaj http://mongoid.org/performance.html

Mam nadzieję, że poniższe punkty dodają wartości do powyższych odpowiedzi.

1.Mongoid jest w pełni kompatybilny z Rails 3 i używa ActiveModel w każdym miejscu (walidacja, serializacja itp.), Gdzie MongoMapper nadal koncentruje się na Railsach 2 i używa walidowalnego klejnotu do swoich walidacji.

2.Mongoid oficjalnie obsługuje i działa na głowicach Ruby 1.8.7, 1.9.1 i 1.9.2.

3. Mongoid bardziej solidnie obsługuje osadzone dokumenty, wykonując wewnętrznie niepodzielne operacje MongoDB na dowolnym obszarze hierarchii. ($ set, $ push, $ pull itp.). W przypadku MM musisz wyraźnie powiedzieć mu, aby wykonał te operacje.

4.MongoMapper ma lepsze wsparcie dla skojarzeń relacyjnych i domyślnie działa w ten sposób.

5.MongoMapper jest bardziej rozszerzalny dzięki architekturze wtyczek, która sprawia, że ​​ludzie mogą łatwo rozszerzać go o własne biblioteki. Mongoid tego nie ma.

6.MM obsługuje mapy tożsamości, Mongoid nie.

7.MM ma większą społeczność i prawdopodobnie większe wsparcie bibliotek zewnętrznych. Oszalałem na punkcie dokumentacji i rdoc.

8. Mongoid obsługuje klastry replikacji typu Master / Slave. (Pisze do mistrza, okrężny czyta do niewolników) MM nie.

9. Mongoid ma niezwykle bogate API kryteriów w stylu ARel, MM używa wyszukiwarek w stylu AR2.