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


10

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.


może chcieć sprawdzić płatek śniegu. Może obsługiwać zarówno dane ustrukturyzowane, jak i częściowo ustrukturyzowane. www.snowflake.net

Myślę, że musisz rozwinąć kwestię „maksymalizacji wydajności połączeń”. Dołączasz do czego?
Spacedman

Odpowiedzi:


10

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.


Bardzo dobre linki, zwłaszcza pierwsze, które wygląda bardziej szczegółowo i dokładniej. Podczas wyszukiwania roku (ciągu znaków) i zwracania identyfikatora rekordu (liczby całkowitej) potgresql jest około 4x szybszy, ale podczas zwracania autora rząd wielkości jest taki sam. MongoDB jest tylko około 20% wolniejszy po powrocie autora. Czy istnieje zasadnicza różnica między zwracaniem wartości int a zwracaniem łańcucha, który mógłby to wyjaśnić? Oznacza to, że gdyby recid był łańcuchem, przewaga postgresql zniknąłaby i oba byłyby mniej więcej takie same jak w przypadku autora?
MASL

1

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


W najnowszych wzorców, PostgreSQL całkowicie posiadanych MongoDB ...
zrezygnował - anony-Mousse

@ Anony-Mousse: Interesujące. Czy znasz jakieś źródła?
Isaac

np tiborsimko.org/postgresql-mongodb-json-select-speed.html i enterprisedb.com/postgres-plus-edb-blog/marc-linster/... z drugiej odpowiedzi. Głównym powodem jest to: Postgres ma dobre indeksy, podczas gdy indeksy w MongoDB nie są tego warte. Ponadto Postgres otrzymał wsparcie BSON i inne dodatki do obsługi JSON, które znacznie poprawiły wydajność. Dlatego stało się znacznie szybciej niż w pierwszych wersjach.
Ma ZAKOŃCZENIE - Anony-Mousse,

0

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.