I database orientati ai documenti sono più adatti di quelli relazionali per oggetti persistenti?

Question

In termini di utilizzo del database, l’ultimo decennio è stata l’era dell’ORM con centinaia di persone in competizione per mantenere i nostri grafici a oggetti in un semplice RMDBS vecchio stile.Ora sembra che stiamo assistendo al raggiungimento della maggiore età dei database orientati ai documenti. Questi banche dati sono altamente ottimizzati per documenti privi di schema ma sono anche molto interessanti per la loro capacità di scalare ed eseguire query su un cluster in parallelo.

I database orientati ai documenti presentano anche un paio di vantaggi rispetto agli RDBMS per la persistenza dei modelli di dati nei progetti orientati agli oggetti.Poiché le tabelle sono prive di schema, è possibile archiviare oggetti appartenenti a classi diverse in una gerarchia di ereditarietà fianco a fianco.Inoltre, man mano che il modello di dominio cambia, purché il codice sia in grado di gestire il recupero di oggetti da una vecchia versione delle classi di dominio, si può evitare di dover migrare l'intero database ad ogni modifica.

D'altra parte, i vantaggi in termini di prestazioni dei database orientati ai documenti sembrano verificarsi principalmente quando si archiviano documenti più profondi.In termini orientati agli oggetti, classi composte da altre classi, ad esempio un post di blog e i relativi commenti.Nella maggior parte degli esempi che mi vengono in mente, come quello del blog, il guadagno nell'accesso in lettura sembrerebbe essere compensato dalla penalità di dover scrivere l'intero "documento" del post del blog ogni volta che viene inserito un nuovo commento. aggiunto.

Mi sembra che i database orientati ai documenti possano apportare vantaggi significativi ai sistemi orientati agli oggetti se si presta estrema attenzione a organizzare gli oggetti in grafici profondi ottimizzati per il modo in cui i dati verranno letti e scritti, ma ciò significa conoscere i casi d'uso davanti.Nel mondo reale, spesso non lo sappiamo finché non disponiamo effettivamente di un'implementazione live di cui possiamo profilare.

Così è il caso relazionale vs.database orientati ai documenti uno di altalene e rotatorie?Sono interessato alle opinioni e ai consigli delle persone, in particolare se qualcuno ha creato applicazioni significative su un database orientato ai documenti.

Answer 1

Beh, dipende da come sono strutturati i tuoi dati e dai modelli di accesso ai dati.

I database di documenti archiviano e recuperano documenti e l'unità atomica memorizzata di base è un documento.Come hai detto, devi pensare ai tuoi modelli / casi d'uso di accesso ai dati per creare un modello di documento intelligente.Quando il tuo modello di dominio può essere suddiviso e partizionato su alcuni documenti, un database di documenti funziona a meraviglia.Ad esempio per un software blog, un CMS o un software wiki, un database di documenti funziona estremamente bene.Finché riesci a trovare un buon modo per comprimere i tuoi dati in un documento non hai problemi.Ma non provarci per inserire un modello relazionale in un database di documenti.Non appena i modelli di accesso ai dati utilizzano molta "navigazione" sulle relazioni, i database di grafici o oggetti diventano una scelta più naturale.

Un'altra cosa riguarda i compromessi in termini di prestazioni di lettura/scrittura.Ad esempio un software per blog.In un modello dati RDBMS transitorio i dati sono normalizzati.Ciò significa che leggere i dati è costoso, perché leggere da tabelle diverse, calcolare le relazioni con i join ecc. per leggere un post sul blog.In cambio, cambiare un tag è poco costoso.Al contrario, in un database di documenti leggere un post sul blog è economico, perché si carica semplicemente il post-documento.Tuttavia l'aggiornamento è probabilmente più costoso perché è necessario archiviare l'intero documento.O peggio, sfoglia molti documenti per cambiare qualcosa (rinominare un tag-scenario).Nella maggior parte dei sistemi, leggere è molto più importante della scrittura.Quindi ha effettivamente senso utilizzare gli archivi dati rinormalizzati.

Penso che su database di grandi dimensioni la progettazione senza schema possa avere i suoi vantaggi.In RDBMS è necessario aggiornare lo schema, il che è un processo davvero doloroso.Soprattutto per convertire i dati esistenti nel nuovo schema.In un database privo di schema, l'applicazione deve occuparsene, il che offre maggiore flessibilità.Ad esempio, puoi aggiornare lo schema al volo, quando è possibile accedere a un vecchio documento.In questo modo, puoi mantenere attivo e funzionante il tuo gigantesco database, mentre l'applicazione gestisce al volo le versioni precedenti.