Architektura aplikacji opartej na Neo4j - trzymaj się API wanilii za pomocą zwykłych węzłów i relacji lub użyj Spring/GORM?

Question

Mam nadzieję usłyszeć od każdego z was, którzy zaprojektowali i wdrożyli przyzwoitą aplikację Neo4j (10 milionów węzłów/relacje) - i jakie są wasze zalecenia w szczególności w zakresie modelowania i różnych interfejsów API (vanilla java/groovy Neo4j vs Spring -Data-Neo4j vs Grails GORM/Neo4j).

Jestem zainteresowany, czy to naprawdę się opłaca, aby dodać dodatkową warstwę OGM (obiekt-wykres-mapowanie) i związane z nią abstrakcje?

Czy ktoś ma doświadczenie, że najlepiej jest trzymać się "prostego" modelowania wykresów z węzłami + właściwościami, relacjami + właściwościami, przejazdami i (np.) Cypher, aby modelować i przechowywać swoje dane?

Moim zmartwieniem jest to, że "wymuszenie" szczególnej abstrakcji OGM na bazie danych wykresów wpłynie na przyszłą elastyczność w adaptacji/zmianie modelu domeny i/lub elastyczność w wyszukiwaniu danych.

Jesteśmy sklepem Grails i eksperymentowałem z GORM/Neo4J, a także z danymi sprężynowymi-neo4j.

Głównym celem zbioru danych będzie modelowanie i sprawdzanie relacji między liczebnością osób, ich pseudonimami, współpracownikami oraz wszelkimi rodzajami działalności przestępczej i historią. Będzie ponad 50 głównych klas domeny. Model musi charakteryzować się elastycznością (która musi szybko ewoluować we wczesnych fazach projektu) oraz szybkością i elastycznością zapytań.

Muszę się przyznać, walczę, aby znaleźć nieodparty powód do użycia warstwy OGM, gdy mogę użyć (np.) POJO lub POGO, trochę magii Groovy i jakiegoś prostego ręcznego zwiniętego obiektu domeny < -> węzeł/kod odwzorowania relacji. O ile mogę powiedzieć, myślę, że byłbym szczęśliwy mając do czynienia z węzłami & traversals & Cypher (aka KISS). Ale byłbym bardzo szczęśliwy słysząc doświadczenia i zalecenia innych.

Dzięki za swoimi myślami czas &,

TP

Answer 1

ponieważ jestem autorem wtyczki Grails Neo4j, mogę być nieobiektywna. Głównym powodem utworzenia wtyczki było zastosowanie łatwej klasy domen Grails z ich potężnym, gotowym do użycia rusztowaniem do Neo4j w ~ 80% przypadków użycia. Dla pozostałych 20%, w których określone wymagania wymagają takich elementów, jak ruchy itp., Korzystamy bezpośrednio z interfejsów API Neo4j (traversals/cypher) i nie używamy interfejsu API GORM.

Obecna wersja wtyczki Neo4j cierpi na problem z supernodą, ponieważ każda instancja domeny jest połączona z węzłem podrzędnym. Jeśli wiele jednoczesnych żądań (takich jak wątki) dodaje nowe instancje domeny, istnieje szansa na uzyskanie wyjątku blokowania. Zaraz poprawię to poprzez podejście pod-subreferencyjne lub za pomocą indeksowania.

Cypher może być również użyty w wtyczce Neo4j Grails.

Z kolei Spring-Data-Neo4j to bardziej zaawansowane podejście z dokładniejszą kontrolą szczegółów mapowania, ale wymaga użycia określonych adnotacji. I nie znalazłem łatwego sposobu na zintegrowanie go z Grails w sposób, w jaki działa rusztowanie.

Używamy poprzedniej wersji wtyczki w produktywnej aplikacji z ~ 60 tys. Użytkowników i ~ 10^6 rel. Z powodu NDA nie mogę podać więcej szczegółów na ten temat.

Answer 2

Nie używamy grails, ale używamy hybrydowego prostego rozwiązania neo4j/spring-data-neo4j.Powodem tego jest fakt, że niektóre z naszych danych domeny mają stały schemat, a niektóre nie. SDN zabiera dużo ciężaru i może zostać wymieszany z prostym neo4j, jeśli zajdzie taka potrzeba.

Mamy klasy opisujące model danych, obiekty dla tych klas utrzymujemy za pomocą SDN, bez dodatkowych sztuczek, używamy tylko podstaw z SDN. Następnie mamy klasy zawierające dane dla modelu, które nie są znane wcześniej. Są one przechowywane w węzłach, które zawierają specjalne właściwości opisujące typ modelu, do którego odnoszą się dane. Kiedy zostanie wydany neo4j 2, prawdopodobnie przeniesiemy te informacje do etykiet. Pomiędzy tymi węzłami mogą istnieć relacje, również opisane przez wspomniany model danych zarządzany przez sdn. Mamy również relacje od ogólnych węzłów do węzłów SDN, co działa dobrze, ponieważ wszystko kończy się tym samym: węzłami.

Nie napotkaliśmy żadnych problemów przy użyciu tego podejścia. Najbardziej podoba nam się to, że dane, o których nie wiemy w zaawansowany sposób, jak zostaną zamodelowane, są przechowywane w taki sposób, w jaki chcielibyśmy przechowywać dane, gdy bylibyście o tym wcześniej poinformowani, dzięki czemu dane faktycznie pasują do siebie. wybrany model, który jest bardzo trudny do zrobienia, gdy korzysta się z innej bazy danych (innej niż graficzna).