Czy to porównanie Neo4j z czasem wykonania RDBMS jest prawidłowe?

Tło: Poniżej znajduje się książka Graph Graph , która obejmuje test wydajności wspomniany w książce Neo4j in Action :

Relacje na wykresie w naturalny sposób tworzą ścieżki. Zapytanie lub przejście przez wykres obejmuje następujące ścieżki. Ze względu na zasadniczo zorientowany na ścieżkę charakter modelu danych, większość operacji opartych na ścieżkach graficznych baz danych jest ściśle dopasowana do sposobu, w jaki dane są ułożone, co czyni je niezwykle wydajnymi. W swojej książce Neo4j in Action, Partner i Vukotic przeprowadzają eksperyment przy użyciu sklepu relacyjnego i Neo4j.

Porównanie pokazuje, że baza danych grafów jest znacznie szybsza dla połączonych danych niż sklep relacyjny. Eksperyment Partnera i Vukotic ma na celu znalezienie przyjaciół znajomych w sieci społecznościowej, maksymalnie do pięciu. Biorąc pod uwagę dowolne dwie osoby wybrane losowo, czy istnieje ścieżka, która ich łączy, co najwyżej pięć związków? W przypadku sieci społecznościowej zawierającej 1 000 000 osób, z których każda ma około 50 znajomych, wyniki zdecydowanie sugerują, że bazy danych wykresów są najlepszym wyborem dla połączonych danych, jak widać w tabeli 2-1.

Tabela 2-1. Znajdowanie rozszerzonych znajomych w relacyjnej bazie danych w porównaniu do skutecznego wyszukiwania w Neo4j

Depth   RDBMS Execution time (s)    Neo4j Execution time (s)     Records returned
2       0.016                       0.01                         ~2500    
3       30.267                      0.168                        ~110,000 
4       1543.505                    1.359                        ~600,000 
5       Unfinished                  2.132                        ~800,000

Na głębokości drugiej (znajomi znajomych) zarówno relacyjna baza danych, jak i baza danych grafów działają wystarczająco dobrze, abyśmy mogli rozważyć użycie ich w systemie online. Podczas gdy zapytanie Neo4j działa w dwóch trzecich czasu relacyjnego, użytkownik końcowy ledwo zauważyłby różnicę w milisekundach między nimi. Jednak zanim osiągniemy głębokość trzecią (przyjaciel-przyjaciel-przyjaciel), jasne jest, że relacyjna baza danych nie jest w stanie poradzić sobie z zapytaniem w rozsądnym czasie: trzydzieści sekund potrzebnych do wypełnienia byłoby całkowicie niedopuszczalne dla systemu online. Natomiast czas odpowiedzi Neo4j pozostaje względnie płaski: zaledwie ułamek sekundy, aby wykonać zapytanie - zdecydowanie wystarczająco szybko dla systemu online.

Na głębokości czwartej relacyjna baza danych wykazuje paraliżujące opóźnienia, co czyni ją praktycznie bezużyteczną dla systemu online. Czasy Neo4j również nieco się pogorszyły, ale opóźnienie jest na obrzeżach akceptacji dla responsywnego systemu online. Wreszcie na głębokości piątej relacyjna baza danych po prostu trwa zbyt długo, aby ukończyć zapytanie. Natomiast Neo4j zwraca wynik po około dwóch sekundach. Na głębokości piątej okazuje się, że prawie cała sieć jest naszym przyjacielem: w wielu rzeczywistych przypadkach użycia prawdopodobnie skrócilibyśmy wyniki i czasy.

Pytania są następujące:

• Czy to rozsądny test naśladujący to, co można znaleźć poza siecią społecznościową? (To znaczy, że prawdziwe sieci społecznościowe zwykle mają na przykład węzły z około 50 przyjaciółmi; wydaje się, że model „ wzbogacania się ” jest bardziej naturalny dla sieci społecznościowych, choć może być błędny).
• Niezależnie od naturalności emulacji, czy istnieje jakiś powód, by sądzić, że wyniki są nieaktualne lub niemożliwe do odtworzenia?

Patrząc na ten dokument zatytułowany Anatomia Facebooka , zauważam, że mediana wynosi 100. Patrząc na wykres funkcji skumulowanej, mogę się założyć, że średnia jest wyższa, blisko 200. Zatem 50 nie wydaje się tutaj najlepszą liczbą. Myślę jednak, że nie jest to tutaj główny problem.

Głównym problemem jest brak informacji o sposobie korzystania z bazy danych.

Wydaje się uzasadnione, że pamięć danych zaprojektowana specjalnie dla struktur grafowych jest bardziej wydajna niż tradycyjne RDBM. Jednak nawet jeśli RDBM nie są zgodne z najnowszymi trendami w zakresie przechowywania danych z wyboru, systemy te ewoluowały w sposób ciągły w wyścigu o wymiarach zestawu danych. Istnieją różne rodzaje możliwych projektów, różne sposoby indeksowania danych, ulepszenia związane z współbieżnością i tak dalej.

Podsumowując, uważam, że jeśli chodzi o odtwarzalność, w badaniu brakuje właściwego opisu sposobu zaprojektowania schematu bazy danych. Nie oczekuję, że baza danych zdominuje takiego króla przesłuchań, ale spodziewam się, że przy dobrze dostrojonym projekcie różnice nie będą tak ogromne.

Istnieją dobre / szybkie sposoby modelowania wykresów w RDBMS oraz głupie / wolne sposoby.

• Niektórzy używają sprytnego indeksowania i przechowywanych procesów, handlowania obciążeniem procesora i dostrajanych tabel temp na dyskach RAM dla szybszej prędkości pobierania wykresów.

• Niektórzy używają wstępnie obliczonych ścieżek graficznych (może to być mniej wykonalne w scenariuszu z sieciami społecznościowymi, ale w drzewie z większością węzłów stanowiących węzły liściowe, jest to całkiem niezła kompromis czasowo-czasowy

• Niektóre po prostu obliczają w pętli, używając niestrunionej tabeli indeksowanej. Z #s wyrzuconych w artykule, który pachnie jak to zrobili (30 sekund - wydajność na dość niewielkim zestawie danych)

  Na przykład mam własne obliczenia drzewa.

  • Jest zamknięty w wysoce dostrojonym przechowywanym proc

  • Serwer ten, choć działa na serwerze danych Sybase ASE15 wielkości korporacyjnej wielkości, jest współużytkowany z kilkoma terabajtami danych ze wszystkich innych aplikacji korporacyjnych, a niektóre z nich są bardziej głodne niż moje; i nie jest przeznaczony wyłącznie do wykonywania moich zapytań.

  • I nie , nie mają dostępu do głównego narzędzia SpeedUp, tabeli temp na dysku RAM.

  • Reprezentatywny zestaw danych, które pobierałem, a które wydają się nieco do nich pasować, polegał na uzyskaniu 150 000 poddrzewa z 2,5 mln węzłów z pełnego zestawu danych lasu węzłów (nieograniczona głębokość drzewa, która waha się między 5 a 15, ale mniejsza średnia aranżacja danego węzła niż 50 znajomych wymienionych w eksperymencie)

  • Dostroiłem go do tego stopnia, że ​​to zapytanie ~ 30-45 sekund. Z pewnością NIE wykazuje on wykładniczego spowolnienia, które liczby w pytaniu wydają się wskazywać na ich wydajność RDBMS, co jest dodatkowo podwójnie dziwne, biorąc pod uwagę, że nie ma wykładniczego wzrostu w zestawie wyników (co dla mnie cuchnie nieregulowanym indeksem na tabela temp z własnego doświadczenia).

Porównanie to jest prawdopodobnie niepoprawne i oparte na złym projekcie strony RDBMS, chociaż, jak zauważono w poprzedniej odpowiedzi, nie można ustalić bez nich otwartego pozyskiwania 100% ich definicji kodu i tabeli.