Integrità dei dati in situazioni NoSQL

7

Sfondo

Per iniziare, al lavoro lavoro con un sistema legacy che, ai suoi tempi, era piuttosto spettacolare, ma ora è ... interessante ... con cui lavorare. Usa IBM (ora Rocket) UniVerse come database di supporto. Una parte in particolare che ha causato alcuni problemi è la mancanza di controlli sull'integrità dei dati. Per integrità dei dati, non intendo corruzione dei file, ma piuttosto cose come record orfani o chiavi non valide. La versione particolare che usano non supporta cose come i trigger e così via, a meno che il programmatore non si sia ricordato di aggiornare i propri indici calcolati, diventa "rotto" e pieno di dati errati. Ora, gli altri programmi sono stati creati per vivere con questi dati errati, ma è più fastidioso quando lo si inserisce in un altro database, come MySQL (utilizzando InnoDB come motore) che ha effettivamente dei vincoli sui dati.

La domanda

Sto sperimentando con MongoDB e NodeJS solo per vedere di cosa si tratta. Mi piace molto anche Mongoose e il suo sistema di schemi. Ho letto molto su cosa memorizzare su ogni disco in una raccolta separata. Forse è solo un mio pregiudizio RDBMS, ma ho deciso di memorizzare ogni "tipo" di cosa in una raccolta separata e utilizzare la funzionalità "popolare" di Mongoose per collegare essenzialmente i record. Ora, sono sicuro che qualcuno dirà che va contro l'intera cosa di NoSQL, ma non ho letto da nessuna parte che dice che solo perché qualcosa memorizza i documenti invece dei record e non ha uno schema impostato sul livello db che sia non può essere reso relazionale.

Nel mio esperimento, ho "Post" e "Commenti". Vedo quattro modi per memorizzare la relazione tra questi due:

  • I dati completi per ogni commento vengono inseriti direttamente nel post sotto forma di documento secondario. Ci sono due svantaggi principali che ho visto con questo: se decido di mettere commenti su qualcos'altro (diciamo una "pagina"), devo essenzialmente ripetermi e non è così semplice scoprire come molti commenti che un utente ha pubblicato se i commenti sono effettivamente memorizzati in varie raccolte
  • I commenti sono una raccolta separata e memorizzano la chiave del genitore e un nome dello schema per mangusta da utilizzare durante il popolamento (il cambio del nome dello schema non sarebbe automatico). Questo non è male, ma è orientato verso il caricamento dei commenti prima e post più tardi. Trovare i commenti su un post non è difficile, ma richiede una query manuale.
  • I commenti sono una raccolta separata e i post hanno un elenco di ID di commento che si riferiscono a loro. Questo è prevenuto per prima cosa nel caricare i post e scoprire che cosa è associato a un commento diventa difficile. Tuttavia, la mangusta mi consente di caricare i commenti senza dover scrivere nulla di aggiuntivo.
  • I commenti sono una raccolta separata e hanno un ID genitore. I post contengono anche un elenco di ID commenti. Questo combina i due metodi precedenti e neutralizza i loro contro e fa relativamente poche query "manuali", ma introduce la possibilità che i dati diventino sporchi e non sincronizzati come il sistema legacy che ho descritto sopra (ad esempio un commento dice che appartiene a un post e un altro post (o più post) afferma di essere il proprietario di quel commento).

Stavo seguendo l'ultimo percorso sopra elencato e mi sono reso conto che stavo iniziando a entrare nel regno di questo sistema legacy che aveva causato così tanti mal di testa con i suoi indici aggiornati manualmente e la possibilità di dati errati.

Ora, non mi aspetto di fare un sacco con questo mio piccolo esperimento, ma è il principale della cosa che mi fa pensare. Cosa consiglieresti di seguire su questo? Voglio essere in grado di mantenere bassi i conteggi delle query, ma non voglio nemmeno dover ricordare di aggiornare tutti questi indici. Deve esserci un mezzo felice da qualche parte.

Un'altra opzione, ovviamente, è utilizzare MySQL con alcuni vincoli di schema, ma non è questo il punto di questo particolare esercizio, visto che l'ho già fatto un sacco di volte.

    
posta Los Frijoles 14.07.2013 - 08:21
fonte

1 risposta

3

la mia esperienza sull'utilizzo di node.js con NoSQL ha comportato il salto di Mongoose e l'utilizzo del driver nativo-mongodb-nodo .

Le ragioni di ciò sono che Mongoose in realtà è in conflitto con il modo node.js di fare le cose, questo significa costruire il proprio framework di bisogni incollando insieme diversi strumenti. Mongoose sembra ottimo se vieni da un ambiente tradizionale ma noterai dei limiti rapidi di cose che diventano complicate. È meglio utilizzare il driver nativo e, se necessario, creare un gestore helper clienti per raccolte specifiche.

Per quanto riguarda la tua domanda di origine ti consiglierei di prendere il primo concetto e mettere tutto in un unico documento. So che all'inizio sembra sciocco perché senti sprecare risorse. Questo è qualcosa che abbiamo imparato dalle strutture delle tabelle di modellazione dei dati in MySQL. Tutto questo non è necessario con i DB orientati ai documenti. La loro idea è rendere le cose il più semplici possibile e archiviare semplicemente il documento che prendi. Credimi, tutto il resto è solo una perdita di tempo. Quando ripenso a quanto tempo ho sprecato, ho provato a creare un'API REST che supporta la popolamento di Mongoose ...

Come conclusione, raccomanderei di pensare solo ai database orientati ai documenti come a una persistenza per gli oggetti serializzati e finché non si pianificano query complicate o si pianifica di avere dati una sola volta per mantenerli aggiornati i dati evitano di perdere tempo con il tentativo di ricostruire MySQL.

Spero ti possa aiutare.

    
risposta data 14.07.2013 - 10:55
fonte