Qual è l'attrazione di sistemi di database schemaless?

https://stackoverflow.com/questions/3856222

27-09-2019
|

Domanda

Ho sentito un gran parlare di schema-less (spesso distribuita) sistemi di database come MongoDB, CouchDB, SimpleDB, ecc ...

Anche se posso capire che potrebbe essere utile per alcuni scopi, nella maggior parte delle mie applicazioni che sto cercando di persistere oggetti che hanno un determinato numero di campi di un tipo specifico, e penso solo automaticamente nel modello relazionale. Sono sempre pensare in termini di righe con ID interi unico, null / campi non nulli, i tipi di dati SQL e query di selezione per trovare set.

Mentre sto attratto dalla natura distribuita e facile JSON / interfacce RESTful di questi nuovi sistemi, io non capisco come debolmente tipizzato hash chiave / valore mi aiuterà con il mio sviluppo. Perché un tipizzato, sistema di schema-meno sciolto essere buono per mantenere insiemi di dati puliti? Come posso per esempio, trovare tutti gli elementi con le date tra X e Y quando potrebbe non hanno date? C'è un concetto di partecipare?

Capisco molti sistemi hanno i loro differenze e punti di forza, ma mi chiedo la differenza di paradigma. Suppongo che questa è una domanda a tempo indeterminato, ma forse risposte e modi della comunità hanno visto personalmente i vantaggi di questi sistemi aiuteranno illuminarmi e altri circa quando vorrei fare uso di questi (certamente più alla moda) sistemi, invece di RDBMS tradizionale.

Soluzione

Mi limiterò a chiamare uno o due motivi comuni (sono sicuro che la gente sarà scrivendo risposte saggio)

Con i sistemi altamente distribuiti, un dato insieme di dati possono essere distribuiti su più server. Quando ciò accade, i vincoli relazionali che il motore DB può garantire sono notevolmente ridotte. Alcuni della vostra integrità referenziale dovranno essere trattati nel codice dell'applicazione. Nel fare ciò, potrete scoprire rapidamente diversi punti di dolore:
- la logica si sviluppa su più livelli (app e db)
- la logica è diffusa in più lingue (SQL e la lingua app di scelta)
Il risultato è che la logica è meno incapsulato, meno portatile, e molto più costoso al cambiamento. Molti sviluppatori si trovano a scrivere più logica nel codice app e meno nel database. Portato alle estreme conseguenze, lo schema del database diventa irrilevante.
gestione, soprattutto schema nei sistemi in cui i tempi di inattività non è un'opzione-è difficile. riducendo la complessità dello schema riduce questa difficoltà.
ACID non funziona molto bene per i sistemi distribuiti ( BASE , PAC , ecc). Il linguaggio SQL (e l'intero modello relazionale in una certa misura) è ottimizzato per un mondo transazionale ACID. Così alcuni del linguaggio SQL caratteristiche e le migliori pratiche sono inutili, mentre altri sono effettivamente dannosi. Alcuni sviluppatori si sentono a disagio per "controcorrente" e preferiscono rilasciare SQL interamente a favore di un linguaggio che è stato progettato da zero per le loro esigenze.
Costo: maggior parte dei sistemi RDBMS non sono liberi. I leader in scala (Oracle, Sybase, SQL Server) sono tutti prodotti commerciali. Quando si tratta di grandi dimensioni ( "scala web") i sistemi, i costi di licenza del database possono soddisfare o superare le costi hardware! I costi sono alti abbastanza per cambiare la corporatura normale / acquistare considerazioni drasticamente verso la costruzione di una soluzione personalizzata in cima ad un'offerta OSS (tutte le offerte significative NoSQL sono OSS)

Altri suggerimenti

Schemaless è grande per due motivi:

Cervello ottimizzare intuitività di archiviazione dei documenti
Sparse-Matrix e Entità-attributo-valore problemi di stoccaggio.

Ho usato sia SQL e No-SQL per applicazioni di produzione in Ruby on Rails. Io non sono un esperto di database e devo confessare di googling termini ACID e simili in quanto non sono a me familiare.

"Ah ah! Un altro know-niente Trend Follower saltare sulle ultime carrozzone" si potrebbe dire. Ma, in realtà, sono davvero contento della mia decisione di utilizzare MongoDB sulla nostra più recente di 2 anni app ed ecco perché ...

Il rovescio della intuitività cervello-ottimizzazione è stata la mia esperienza con il sistema di e-commerce Magento. Non voglio per colpire perché mi ha servito bene al momento, ma in realtà ha colpito il processore difficile cercare di calcolare gli attributi per ciascun prodotto. La ragione di fondo è stato il negozio Entità-attributo-valore dei dati di prodotto. Cache o essere dannati era la soluzione.

Il principale vantaggio per me è l'ottimizzazione nell'unico posto che conta davvero - il vostro cervello . Così molte tecnologie sono criticati sulla loro efficienza nella memoria, processori, hardware e avendo ancora un DB che è estremamente intuitivo per comprendere porta i suoi meriti. Abbiamo trovato rapido per aggiungere funzionalità al nostro codice perché il database sembra semplicemente un po 'come il mondo reale Siamo modellazione. Quando ho chiesto i client di e-commerce per presentare me con la lista dei prodotti che sarà naturalmente tendono ad usare Excel (si pensi negozio tabella). Le prime colonne sono facili:

Nome del prodotto
Prezzo
Tipo di prodotto (

Poi si fa più duro e coperto di note, codici colore e link ad altri tavoli (sì .. relazioni)

Colore (solo per alcuni prodotti)
Dimensioni (X Large, grandi, piccole) - solo per i prodotti 8'9'10, mazze da golf utilizzare una scala diversa
Colore 2. I collari gatto hanno due scelte di colore.
Potenza
Risoluzione tipo (maschio, femmina)

Così finisce in un terribile pasticcio di tabelle di Excel che non hanno senso per me, e non ha molto senso per le persone che lavorano con il giorno prodotti dopo giorno. Gettiamo le braccia in aria e decidiamo di passare attraverso il catalogo e poi mi colpisce! Non sarebbe bello se si potesse memorizzare i dati come appare nel catalogo !? collezioni soli di record su ogni prodotto che solo le liste l'attributo di tale prodotto. È quindi possibile scegliere gli attributi comuni a indice per il recupero in un secondo momento. Naturalmente, questo è un negozio di documento.

In sintesi, i negozi di documenti sono grandi quando si ha un problema matrice sparsa o oggetti che mutano i loro attributi nel corso del tempo. Avendo vissuto in un mondo No-SQL per 2 anni, non riesco a pensare a un vero e proprio dell'applicazione mondo che non abbia queste caratteristiche, perché il mondo stesso si presenta come un negozio di documento.

La preoccupazione principale dovrebbe essere quello che avete bisogno di fare con i vostri dati. Se si dispone di un set di dati enorme e stanno trovando un RDBMS tradizionali per essere un collo di bottiglia, allora si può decidere di sperimentare con uno schemaless o AA soluzione NoSQL .

La maggior parte dei ambienti che sono a conoscenza di utilizzare NoSQL soluzioni utilizzare anche una soluzione RDBMS in qualche forma o di moda. Le soluzioni basate RDBMS sono la norma in cui l'integrità dei dati è estremamente importante ed è necessario transazioni ACID. Tuttavia, se il sistema non è fortemente basato sulle transazioni, ma è necessario per scalare verso l'alto o fuori scala reale veloce, un nosql soluzione può essere desiderabile.

Ho giocato solo con MongoDB, ma una cosa che veramente mi interessava era come si potrebbe documenti nido. In un documento MongoDB è fondamentalmente come un record. Questo è veramente bello perché tradizionalmente, in un RDBMS, se avevi bisogno di tirare un record "Persona" e ottenere l'indirizzo associato, informazioni datore di lavoro, ecc avresti spesso deve andare a più tabelle, unirsi a loro in su, fanno base di dati multiple chiamate. In una soluzione NoSQL come MongoDB, si può solo nido i record associati (documenti) e non hanno a pasticciare con chiavi esterne, unendo, chiamate al database multipli. Tutto ciò associato a quel record è tirato.

Questo è particolarmente utile quando si tratta di oggetti. È possibile in molti casi basta memorizzare un oggetto come una serie di documenti nidificati.

database NoSQL non schemaless sono; lo schema è incorporato nei dati. Essi sono propriamente chiamata semistrutturata. In alcuni negozi di dati KV, tuttavia, lo schema può anche essere incorporato nel codice. Il vantaggio dell'approccio semi-strutturato è duplice: flessibilità in cui le colonne sono parte di una riga (una riga potrebbe avere 5 colonne e un'altra hanno 5 colonne diverse, e la flessibilità nelle caratteristiche delle colonne (ad esempio, lunghezze variabili)

Normalmente l'attrazione è quello di olio di serpente - la maggior parte delle persone li favourising non hanno alcun indizio circa il teorema relazionale e parlano SQL su un livello che i professionisti vomitare. Non ho idea di quali condizioni ACID sono, ehy sono importanti ecc.

Non dicendo che non hanno usi validi .... solo dicendo che per lo più l'attrazione è la gente non sapendo ciò che dovrebbero sapere e fare conclusioni stupidi. Anche in questo caso, non tutti sono così, ma la maggior parte degli sviluppatori di loro favorendo sono -. Non va bene nella loro comprensione di ciò che un sistema di database è acutally responsabile

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow