Co jest szybsze: PostgreSQL vs MongoDB na dużych zestawach danych JSON?

Mam duży zestaw danych z 9-metrowymi obiektami JSON o wielkości ~ 300 bajtów każdy. Są to posty z agregatora linków: w zasadzie linki (adres URL, tytuł i identyfikator autora) oraz komentarze (tekst i identyfikator autora) + metadane.

Mogą to być rekordy relacyjne w tabeli, z wyjątkiem tego, że mają jedno pole tablicy z identyfikatorami wskazującymi na rekordy potomne.

Jakie wdrożenie wygląda bardziej solidnie?

1. Obiekty JSON w bazie danych PostgreSQL (tylko jedna duża tabela z jedną kolumną, a mianowicie obiekt JSON)
2. Obiekty JSON na MongoDB
3. Rozbij obiekty JSON na kolumny i użyj tablic na PostgreSQL

Chcę zmaksymalizować wydajność połączeń, aby móc masować dane i eksplorować je, dopóki nie znajdę ciekawych analiz. W tym momencie myślę, że lepiej będzie przekształcić dane w formę specyficzną dla każdej analizy.

W przypadku ładowania danych Postgre przewyższa MongoDB. MongoDB jest prawie zawsze szybszy, gdy zwraca liczbę zapytań. PostgreSQL jest prawie zawsze szybszy w przypadku zapytań korzystających z indeksów.

Sprawdź tę stronę internetową i tę, aby uzyskać więcej informacji. Mają bardzo szczegółowe wyjaśnienia.

Możesz zyskać więcej na schemacie Mongodb. Oznacza to, że bardzo łatwo można modyfikować struktury danych w locie.

W Mongodb nie ma czegoś takiego jak dołączenie. Tak więc, jak ktoś myśli o danych i jak z nich korzystać, musi zostać zmodyfikowany, aby uwzględnić środowiska baz danych oparte na dokumentach i bez schematów.

Może prędkość staje się mniej ważna, gdy zmienia się perspektywa i priorytety.

Mam nadzieję że to pomogło.

-Todd

Jeśli chodzi o liczby, o których wspominasz, myślę, że wszystkie alternatywy powinny zadziałać (czytaj: będziesz w stanie zakończyć analizę w rozsądnym czasie). Polecam projekt, który może prowadzić do znacznie szybszych rezultatów.

Jak już wcześniej wspomniano, ogólnie postgresql jest szybszy niż mongo, czasami ponad 4 razy szybszy. Zobacz na przykład: http://www.enterlictb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality

Powiedziałeś, że jesteś zainteresowany poprawą wydajności połączeń. Zakładam, że interesuje Cię obliczanie podobieństw między jednostkami (np. Post, autor), więc dołączysz głównie do siebie z tabelą (np. Post lub autor) i agregujesz.

Dodaj do tego fakt, że po początkowym załadowaniu baza danych będzie tylko do odczytu, co sprawia, że ​​problem jest bardzo odpowiedni do indeksowania użycia. Nie zapłacisz za aktualizację indeksu, ponieważ nie będziesz go mieć i myślę, że masz dodatkowe miejsce na indeks.

Chciałbym użyć postgres i przechowywać dane w dwóch tabelach:

twórz posty w tabeli (liczba całkowita post_id, url varchar (255), liczba całkowita autor_id);

- Załaduj dane, a następnie utwórz indeksy. - Doprowadzi to do szybszego ładowania i lepszych indeksów zmienia wpisy w tabeli dodaje ograniczenie klucz podstawowy posts_pk (post_id); utwórz indeks post_author na postach (autor_id);

twórz komentarze do tabeli (liczba_skomentarzy, liczba całkowita post_id, liczba całkowita autor_id, komentarz varchar (255)); zmień komentarze do tabeli dodaj ograniczenie comments_pk klucz podstawowy (comment_id); utwórz indeks comment_author na komentarze (autor_id); utwórz indeks comment_post na komentarzach (post_id);

Następnie możesz obliczyć podobieństwo autora na podstawie komentarzy w zapytaniach takich jak select m. autor_id jako m_autor_id, a. autor_id jako a_author_id, policz (odrębny m.post_id) jako posty z komentarzy, gdy m dołącz do komentarzy jako grupa używająca (post_id) przez m.author_id, a. autor_id

Jeśli interesuje Cię tokenzowanie słów w komentarzu do nlp, dodaj do tego kolejną tabelę, ale pamiętaj, że znacznie zwiększy to objętość twoich danych. Zazwyczaj lepiej nie reprezentować całej tokenizacji w bazie danych.