Ho appena iniziato con i DB non relazionali e sto ancora cercando di capirci qualcosa e capire quale sarebbe il modello migliore. E posso parlare solo per CouchDB.
Tuttavia, ho alcune conclusioni preliminari:
Hai escogitato progetti alternativi che funzionano molto meglio nel mondo non relazionale?
Il focus del design si sposta: il design del modello del documento (corrispondente alle tabelle DB) diventa quasi irrilevante, mentre tutto dipende dalla progettazione delle viste (corrispondenti alle query).
Il tipo di DB dei documenti scambia le complessità: SQL ha dati non flessibili e query flessibili, i DB dei documenti sono il contrario.
Il modello CouchDB è una raccolta di "documenti JSON" (fondamentalmente tabelle hash annidate). Ogni documento ha un ID univoco e può essere facilmente recuperato tramite ID. Per qualsiasi altra query, scrivi "viste", che sono insiemi denominati di funzioni di mappatura / riduzione. Le visualizzazioni restituiscono un set di risultati come un elenco di coppie chiave / valore.
Il trucco è che non si interroga il database nel senso in cui si interroga un database SQL: i risultati dell'esecuzione delle funzioni di visualizzazione vengono memorizzati in un indice e solo l'indice può essere interrogato. (Come "ottieni tutto", "ottieni chiave" o "ottieni intervallo di chiavi".)
L'analogia più vicina nel mondo SQL sarebbe se fosse possibile interrogare il DB solo utilizzando procedure memorizzate: ogni query che si desidera supportare deve essere predefinita.
Il design dei documenti è estremamente flessibile. Ho trovato solo due vincoli:
- Mantieni i dati correlati insieme nello stesso documento, poiché non c'è nulla che corrisponda a un join.
- Non rendere i documenti così grandi da essere aggiornati troppo frequentemente (come mettere tutte le vendite dell'azienda per l'anno nello stesso documento), poiché ogni aggiornamento del documento attiva una reindicizzazione.
Ma tutto dipende dalla progettazione delle viste.
I progetti alternativi che ho scoperto che gli ordini di lavoro di grandezza migliori con CouchDB rispetto a qualsiasi database SQL sono a livello di sistema piuttosto che a livello di archiviazione. Se si dispone di alcuni dati e si desidera servirli su una pagina Web, la complessità del sistema totale viene ridotta di almeno il 50%:
- nessuna progettazione di tabelle DB (problema minore)
- nessun livello intermedio ODBC / JDBC, tutte le query e le transazioni su http (problema moderato)
- semplice mappatura DB-oggetto da JSON, che è quasi banale rispetto alla stessa in SQL (importante!)
- puoi potenzialmente saltare l'intero server delle applicazioni, poiché puoi progettare i tuoi documenti per essere recuperati direttamente dal browser utilizzando AJAX e aggiungere un po 'di lucidatura JavaScript prima che vengano visualizzati come HTML. (ENORME!!)
Per le normali webapp, i DB basati su documenti / JSON sono una grande vittoria e gli svantaggi di query meno flessibili e del codice extra per la convalida dei dati sembrano un piccolo prezzo da pagare.
Hai sbattuto la testa contro qualcosa che sembra impossibile?
Non ancora. Mappare / ridurre come mezzo per interrogare un database non è familiare e richiede molte più riflessioni rispetto alla scrittura di SQL. Esiste un numero piuttosto ridotto di primitive, quindi ottenere i risultati di cui hai bisogno è principalmente una questione di creatività nel modo in cui specifichi le chiavi.
Esiste una limitazione in quanto le query non possono esaminare due o più documenti contemporaneamente: nessun join o altri tipi di relazioni multi-documento, ma finora nulla è stato insormontabile.
Come limitazione di esempio, i conteggi e le somme sono facili ma le medie non possono essere calcolate da una visualizzazione / query CouchDB. Correzione: restituire la somma e contare separatamente e calcolare la media sul client.
Hai colmato il divario con qualsiasi modello di progettazione, ad esempio per tradurre dall'uno all'altro?
Non sono sicuro che sia fattibile. È più una riprogettazione completa, come tradurre un programma di stile funzionale in uno stile orientato agli oggetti. In generale, ci sono molti meno tipi di documento rispetto alle tabelle SQL e più dati in ogni documento.
Un modo per pensarci è guardare al tuo SQL per inserimenti e query comuni: quali tabelle e colonne vengono aggiornate quando un cliente effettua un ordine, ad esempio? E quali per i rapporti mensili sulle vendite? Quelle informazioni dovrebbero probabilmente andare nello stesso documento.
Ovvero: un documento per Ordine, contenente ID cliente e ID prodotto, con campi replicati secondo necessità per semplificare le query. Qualsiasi cosa all'interno di un documento può essere interrogata facilmente, tutto ciò che richiede un riferimento incrociato tra l'ordine e il cliente deve essere fatto dal cliente. Quindi, se desideri un rapporto sulle vendite per regione, dovresti probabilmente inserire un codice regione nell'ordine.
Realizzi anche modelli di dati espliciti ora (ad esempio in UML)?
Spiacenti, non ho mai fatto molto UML prima dei DB dei documenti :)
Ma hai bisogno di una sorta di modello che indichi quali campi appartengono a quali documenti e quali tipi di valori contengono. Sia per il tuo riferimento in seguito sia per assicurarti che tutti gli utenti che utilizzano il DB conoscano le convenzioni. Dal momento che non ricevi più un errore se ad esempio memorizzi una data in un campo di testo e chiunque può aggiungere o rimuovere qualsiasi campo a loro piacimento, hai bisogno sia del codice di convalida che delle convenzioni per riprendere il gioco. Soprattutto se lavori con risorse esterne.
Ti manca qualcuno dei principali servizi extra forniti dagli RDBMS?
No. Ma il mio background è sviluppatore di applicazioni web, ci occupiamo di database solo nella misura in cui dobbiamo :)
Un'azienda per cui lavoravo ha realizzato un prodotto (una webapp) progettato per funzionare su database SQL di più fornitori, ei "servizi extra" sono così diversi da DB a DB che dovevano essere implementati separatamente per ogni DB. Quindi è stato meno faticoso per noi spostare la funzionalità fuori dall'RDBMS. Ciò si è esteso anche alla ricerca full-text.
Quindi qualunque cosa io stia rinunciando è qualcosa che non ho mai avuto davvero in primo luogo. Ovviamente la tua esperienza potrebbe essere diversa.
Un avvertimento: quello su cui sto lavorando ora è una webapp per dati finanziari, quotazioni di borsa e simili. Questo è un ottimo abbinamento per un DB di documenti, dal mio punto di vista ottengo tutti i vantaggi di un DB (persistenza e query) senza alcun problema.
Ma questi dati sono abbastanza indipendenti l'uno dall'altro, non ci sono query relazionali complesse. Ottieni le ultime quotazioni per ticker, ottieni quotazioni per ticker e intervallo di date, ottieni meta-informazioni aziendali, questo è praticamente tutto. Un altro esempio che ho visto è stata un'applicazione per blog, e neanche i blog sono caratterizzati da schemi di database estremamente complicati.
Quello che sto cercando di dire è che tutte le applicazioni di successo dei DB di documenti che conosco sono state con dati che non avevano molte interrelazioni in primo luogo: documenti (come nella ricerca Google), post di blog, articoli di notizie, dati finanziari .
Mi aspetto che ci siano set di dati che mappano meglio a SQL che al modello di documento, quindi immagino che SQL sopravviverà.
Ma per quelli di noi che vogliono solo un modo semplice per archiviare e recuperare i dati - e sospetto che ce ne siano molti di noi - i database dei documenti (come in CouchDB) sono una manna dal cielo.