Che è più veloce: PostgreSQL vs MongoDB su grandi set di dati JSON?

Ho un grande set di dati con oggetti JSON da 9m a ~ 300 byte ciascuno. Sono post da un aggregatore di link: sostanzialmente link (un URL, titolo e ID autore) e commenti (testo e ID autore) + metadati.

Potrebbero benissimo essere record relazionali in una tabella, tranne per il fatto che hanno un campo array con ID che puntano a record figlio.

Quale implementazione sembra più solida?

1. Oggetti JSON su un database PostgreSQL (solo una tabella di grandi dimensioni con una colonna, ovvero l'oggetto JSON)
2. Oggetti JSON su MongoDB
3. Esplodi gli oggetti JSON in colonne e usa gli array su PostgreSQL

Voglio massimizzare le prestazioni nei join, così posso massaggiare i dati ed esplorarli fino a quando non trovo analisi interessanti, a quel punto penso che sarà meglio trasformare i dati in un modulo specifico per ogni analisi.

Per il caricamento dei dati, Postgre supera MongoDB. MongoDB è quasi sempre più veloce quando restituisce il conteggio delle query. PostgreSQL è quasi sempre più veloce per le query che utilizzano gli indici.

Dai un'occhiata a questo sito e anche a questo per maggiori informazioni. Hanno spiegazioni molto dettagliate.

Puoi trarre maggiori benefici dal design schematico di Mongodb. Ciò significa che è molto semplice modificare al volo le strutture dati.

Non esiste un join in Mongodb. Quindi il modo in cui si pensa ai dati e come usarli deve essere modificato per tenere conto degli ambienti db basati su documenti e senza schemi.

Forse la velocità diventa meno importante quando cambiano prospettiva e priorità.

Spero che aiuti.

-Todd

Per i numeri che menzioni, penso che tutte le alternative dovrebbero funzionare (leggi: sarai in grado di completare la tua analisi in tempi ragionevoli). Consiglio un design che può portare a risultati significativamente più veloci.

Come già detto, in generale postgresql è più veloce di mongo, alcune volte più di 4 volte più veloce. Vedi ad esempio: http://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality

Hai detto di essere interessato a migliorare le prestazioni dei join. Suppongo che tu sia interessato a calcolare le somiglianze tra le entità (ad esempio, posta, autore), quindi ti unirai principalmente alla tabella con se stesso (ad esempio, per posta o autore) e aggregato.

Aggiungete a ciò il fatto che dopo il caricamento iniziale il vostro database sarà di sola lettura, ciò che rende il problema molto adatto all'utilizzo dell'indice. Non pagherai per l'aggiornamento dell'indice poiché non ne avrai e suppongo che tu abbia lo spazio di archiviazione aggiuntivo per l'indice.

Avrei usato Postgres e archiviato i dati in due tabelle:

creare post di tabella (numero intero post_id, url varchar (255), numero intero autore_id);

- Carica i dati e quindi crea gli indici. - Ciò comporterà un caricamento più rapido e una migliore variazione degli indici nella tabella aggiunge il vincolo chiave primaria posts_pk (post_id); crea indice post_author sui post (author_id);

creare commenti tabella (intero comment_id, intero post_id, intero autore_id, comment varchar (255)); modifica tabella commenti aggiungi vincolo commenti_pk chiave primaria (comment_id); crea indice comment_author sui commenti (author_id); creare un indice comment_post sui commenti (post_id);

Quindi è possibile calcolare la somiglianza dell'autore in base ai commenti nelle query come selezionare m. author_id come m_author_id, a. author_id come a_author_id, conta (distinto m.post_id) come post dai commenti come m unisci i commenti come gruppo usando (post_id) di m.author_id, a. author_id

Nel caso in cui tu sia interessato a tokenare le parole nel commento per nlp, aggiungi un'altra tabella per questo, ma ricorda che aumenterà in modo significativo il volume dei tuoi dati. Di solito è meglio non rappresentare l'intera tokenizzazione nel database.