Jaka jest różnica między MongoDB Spring Data i Hibernate OGM dla MongoDB?

Question

Nie korzystałem wcześniej ze Spring Data, ale użyłem Hibernacji ORM kilka razy dla aplikacji bazującej na MySQL. Po prostu nie rozumiem, które ramy wybrać między tymi dwoma dla aplikacji opartej na MongoDB.

Próbowałem wyszukać odpowiedź, ale nie mogę znaleźć odpowiedzi, która dokonuje porównania między nimi w środowisku produkcyjnym. Czy ktoś miał problemy z pracą z tymi dwoma frameworkami za pomocą MongoDB?

Answer 1

Zastrzeżenie: Jestem wiodący projektu Wiosna danych, więc będę głównie pokrycie strony Wiosna danych rzeczy tutaj:

myślę rozróżnienie między rdzeń obu projektów ist że zespół wybrał Hibernate OGM skoncentrować wysiłki na WZP, podczas gdy zespół Spring Data wyraźnie tego nie zrobił. Powody są następujące:

• JPA to z natury relacyjny interfejs API. Pierwsze dwa zdania specyfikacji wskazują, że jest to interfejs API do mapowania obiektowo-relacyjnego. Jest to również zawarte w podstawowych tematach API: mówi o tabelach, kolumnach, połączeniach, transakcjach. Koncepcje, które niekoniecznie można przenieść do świata NoSQL.
• Zazwyczaj wybiera się magazyn NoSQL ze względu na jego specjalne cechy (np. Zapytania geo-przestrzenne na MongoDB, możliwość wykonywania ruchów wykresu dla Neo4j). Żadne z nich nie jest (i będzie) dostępne w WZP, dlatego i tak musisz dostarczyć zastrzeżone rozszerzenia.
• Co gorsza, JPA zawiera koncepcje, które po prostu poprowadzą użytkowników w niewłaściwą stronę, jeśli założą, że będą pracować w sklepie NoSQL, tak jak to było zdefiniowane w JPA: w jaki sposób należy wycofać transakcję rozsądnie na szczycie MongoDB?

Więc z wiosennym Danych zdecydowaliśmy się raczej zapewnić spójne programowania modelu dla obsługiwanych sklepów, ale nie starają się wymusić wszystko w jednym ciągu, abstrahując API: masz dobrze znane implementacje szablonów, można uzyskać abstrakcja repozytorium, która działa identycznie dla wszystkich sklepów, ale wykorzystajmy specyficzne cechy i koncepcje sklepu.

Answer 2

Nota prawna: Jestem jednym z programistów Hibernate OGM, więc postaram się podać niektóre z przyczyn.

Hibernate OGM zapewnia obsługę Java Persistence (JPA) dla rozwiązań NoSQL. Ponownie wykorzystuje silnik platformy ORM w trybie hibernacji, ale nadal utrzymuje dane w magazynie danych NoSQL zamiast w relacyjnej bazie danych. Ma również na celu zapewnienie dostępu do określonych funkcji magazynu danych, gdy JPA nie jest dobrze dopasowany.

Takie podejście jest interesujący z kilku powodów:

• znane semantyczny i API. Programiści Javy są już zaznajomieni z JPA, co oznacza, że ​​nie trzeba uczyć się API niższego poziomu. Obsługuje również HQL i rodzime zapytania backendu.

• Opóźniony wybór backendu. Wybór odpowiedniego magazynu danych NoSQL nie jest trywialny. Dzięki Hibernate OGM nie będziesz musiał angażować się w konkretne rozwiązanie NoSQL i będziesz w stanie łatwo przełączać i testować różne backendy.

• Istniejące narzędzia i biblioteki. JPA i Hibernate ORM istnieją już od jakiegoś czasu, a będziesz mógł ponownie korzystać z bibliotek i narzędzi, które ich używają.

• Większość modelu logicznego JPA jest dopasowana. Przykładem dobrego dopasowania jest @Embedded, @EmbeddedCollection i @Entity (który może być węzłem, dokumentem lub pamięcią podręczną w oparciu o wybrany magazyn danych). Prawdą jest, że nazwy adnotacji mogą być dziwne, ponieważ będziesz musiał także poradzić sobie z @Table i @Column.

• Weryfikacja abstrakcji JPA na poziomie obiektu, pozostawiając miejsce na wiele sztuczek i optymalizacji. Zaplanowaliśmy kilka pomysłów, takich jak trwałość poliglota: przechowywanie danych w kilku magazynach danych i używanie najlepszych w konkretnym zadaniu odczytu.

Główną wadą jest to, że niektóre koncepcje JPA nie są łatwo mapowane do świata NoSQL: transakcje na przykład. Podczas gdy będziesz miał dostęp do metod rozgraniczania transakcji, nie będziesz w stanie wycofać się z magazynów danych, które nie obsługują transakcji natywnie (transakcje, w tym przypadku będą używane do grupowania operacji i próbują zoptymalizować liczbę połączeń do db).

Ponadto, jeśli twój zestaw danych ma z natury charakter inny niż model domenowy, to nie powinieneś używać hibernacji OGM.