Non-progettazione di database relazionali [chiusa]

https://stackoverflow.com/questions/1189911

19-09-2019
|

Domanda

Sono interessato a sentir parlare di progettazione di strategie che avete usato con non relazionali "NoSQL" basi di dati - cioè, il (per lo più nuovo) classe di archivi di dati che non utilizzano relazionale tradizionale disegno o SQL (come Hypertable, CouchDB, SimpleDB, Google App Engine datastore, Voldemort, Cassandra, SQL Data Services, ecc). Sono anche spesso definito come "chiave / negozi di valore", e alla base si comportano come giganteschi tabelle hash distribuite persistenti.

In particolare, voglio conoscere le differenze di di progettazione concettuale dei dati con questi nuovi database. Che cosa è più facile, quello più difficile, ciò che non può essere fatto a tutti?

Sei venuto con disegni alternativi che funzionano molto meglio nel mondo non-relazionale?
Avete battuto la testa contro tutto ciò che sembra impossibile?
Avete colmato il divario con eventuali modelli di progettazione, per esempio di tradurre da uno all'altro?
Avete anche fare modelli di dati espliciti a tutti ora (per esempio in UML) o li hai buttato tutto a favore di / blob di dati semi-strutturati orientati ai documenti?
Ti manca uno qualsiasi dei principali servizi extra che forniscono RDBMS, come l'integrità relazionale, arbitrariamente supporto delle transazioni complesse, trigger, etc?

Io vengo da uno SQL relazionale DB sfondo, così la normalizzazione è nel mio sangue. Detto questo, ho i vantaggi del database non relazionali per la semplicità e la scalabilità, e il mio istinto mi dice che ci deve essere una sovrapposizione più ricco di funzionalità di progettazione. Che cosa hai fatto?

discussioni FYI StackOverflow, ci sono state su argomenti simili qui:

Soluzione

Credo che bisogna considerare che i DBMS non relazionali differiscono molto per quanto riguarda il loro modello di dati e quindi la progettazione concettuale dei dati dipendono anche molto. Nel thread Dati Design nei database non relazionali della gruppo NoSQL Google i diversi paradigmi sono classificati in questo modo:

sistemi Bigtable-simili (HBase, Hypertable, etc)
chiave-valore negozi (Tokyo, Voldemort, etc)
Banche Dati (CouchDB, MongoDB, etc)
database grafico (AllegroGraph, Neo4j, sesamo, ecc)

Sono per lo più in , e l'eleganza del design dati utilizzando questo paradigma è stato quello che mi ha portato lì, stanco delle carenze del RDBMS . Ho messo alcuni esempi di progettazione dati utilizzando un database grafico su questo e c'è un di come modellare di base IMDB dati di film / attore / di ruolo troppo.

Le slide della presentazione (Slideshare) database del grafico e il futuro di grandi dimensioni Knowledge Management da Marko Rodriguez contiene una bella introduzione al progettazione dati utilizzando un database grafico pure.

Rispondendo alle domande specifiche da un punto di vista graphdb:

disegno alternativo:. L'aggiunta di relazioni tra diversi tipi di entità senza alcuna preoccupazione o la necessità di predefinire quali entità possono ottenere collegato

Colmare il divario: tendo a fare questo diverso per ogni caso, sulla base del dominio stesso, come io non voglio un "grafo table-oriented" e simili. Tuttavia, ecco alcune informazioni sulla traduzione automatica da RDBMS a graphdb.

modelli di dati espliciti:. Faccio questi tutto il tempo (stile lavagna), e quindi utilizzare il modello così com'è nel DB e

Miss dal RDBMS mondo: semplici modi per creare report. Aggiornamento: forse non è che duramente per creare report da un database grafico, vedere Creazione di un report per un Neo4j di database di esempio .

Altri suggerimenti

Ho appena iniziato con DB non-relazionali, e sto ancora cercando di avvolgere la mia testa intorno ad esso e capire ciò che il modello migliore sarebbe. E posso solo parlare per CouchDB.

Ancora, ho alcune conclusioni preliminari:

siete venuti su con disegni alternativi che funzionano molto meglio nel mondo non-relazionale?

Il design di messa a fuoco si sposta:. Il design del modello di documento (corrispondenti alle tabelle DB) diventa quasi irrilevante, mentre tutto cerniere a progettare i punti di vista (corrispondente alla query)

Il documento DB sorta di scambia complessità: SQL ha dati inflessibili e query flessibili, DB documento sono il contrario

Il modello CouchDB è una raccolta di "documenti JSON" (tabelle hash fondamentalmente nidificate). Ogni documento ha un ID univoco, e può essere banalmente recuperato ID. Per qualsiasi altra domanda, si scrive "viste", che prendono il nome set di carta / riducono funzioni. I punti di vista restituiscono un set di risultati come una lista di coppie chiave / valore.

Il trucco è che non si esegue una query del database, nel senso che si ricerca un database SQL: I risultati di esecuzione delle funzioni visualizzazione sono memorizzati in un indice, e solo l'indice possono essere interrogati. (Come "ottenere tutto", "ottenere la chiave" o "get key range").

L'analogia più vicina al mondo SQL sarebbe se si potesse interrogare solo il DB utilizzo di stored procedure - ogni query che si desidera supportare deve essere predefinito.

Il design dei documenti è enormemente flessibile. Ho trovato solo due vincoli:

Mantenere i dati interdipendenti insieme nello stesso documento, dal momento che non v'è nulla che corrisponde ad un join.
Non fare i documenti così grande che essi vengono aggiornati troppo spesso (come mettere tutte le società di vendita per l'anno nello stesso documento), dal momento che ogni aggiornamento del documento innesca un re-indicizzazione.

Ma tutto dipende sulla progettazione i punti di vista.

I disegni si alternano Ho scoperto che gli ordini di lavoro di grandezza migliori con CouchDB di qualsiasi database SQL sono a livello di sistema, piuttosto che il livello di storage. Se si dispone di alcuni dati e si desidera servire loro di una pagina web, la complessità del sistema nel suo complesso è ridotto di almeno il 50%:

Non ci sono tavoli di progettazione DB (problema minore)
senza ODBC / JDBC strato intermedio, tutte le query e transazioni oltre http (problema moderato)
semplice mappatura DB-to-oggetto da JSON, che è quasi banale rispetto allo stesso in SQL (importante!)
è potenzialmente in grado saltare l'intero server di applicazione, come è possibile progettare i documenti che devono essere recuperati direttamente dal browser utilizzando AJAX e aggiungere un po 'di lucidatura JavaScript prima di essere visualizzati come HTML. (ENORME !!)

Per webapps normali, documento / DB JSON-based sono una vittoria enorme, e gli svantaggi di query meno flessibile e un po 'di codice aggiuntivo per la convalida dei dati sembra un piccolo prezzo da pagare.

Avete battuto la testa contro tutto ciò che sembra impossibile?

Non ancora. Map / Reduce come mezzo per interrogare un database è poco familiare, e richiede molto di più pensare che scrivere SQL. C'è un numero relativamente piccolo di primitive, in modo da ottenere i risultati desiderati è principalmente una questione di essere creativi con il modo di specificare le chiavi.

C'è una limitazione che le query non può guardare due o più documenti allo stesso tempo - non si unisce o di altri tipi di relazioni multi-documento, ma nulla finora è stato insormontabile.

A titolo di limitazione esempio, conteggi e somme sono facili ma in media non può essere calcolato da un CouchDB vista / interrogazione. Correzione:. Somma Ritorno e contare separatamente e calcolare la media sul client

Avete colmato il divario con eventuali modelli di progettazione, per esempio di tradurre da uno all'altro?

Non sono sicuro che sia fattibile. E 'più di una completa riprogettazione, come tradurre un programma stile funzionale ad uno stile orientato agli oggetti. In generale, ci sono molto fewer tipi di documenti che ci sono tabelle SQL e più dati in ciascun documento.

Un modo di pensare di esso è di guardare il vostro SQL per inserti e domande comuni: Quali tabelle e le colonne vengono aggiornati quando un cliente effettua un ordine, per esempio? E quali per i rapporti mensili sulle vendite? Che informazioni dovrebbe probabilmente andare nello stesso documento.

Cioè: Un documento per l'ordine, che contiene gli ID di identificazione del cliente e di prodotto, con i campi replicati come necessario per semplificare le query. Tutto ciò all'interno di un documento può essere interrogato facilmente, tutto ciò che richiede riferimenti incrociati tra il dire Ordine e cliente deve essere fatto da parte del cliente. Quindi, se volete una relazione sulle vendite per regione, probabilmente si dovrebbe mettere un codice regionale nell'ordine.

Avete anche fare modelli di dati espliciti a tutti ora (per esempio in UML)?

Siamo spiacenti, non ha mai fatto molto UML prima di DB documento sia :)

Ma è necessario un qualche tipo di modello detto che i campi che appartengono ai vari documenti e quali tipi di valori che essi contengono. Sia per il proprio riferimento futuro e per assicurarsi che everybod con la batteria DB conosce le convenzioni. Dal momento che si ottiene non è più un errore se si memorizza una data in un campo di testo, per esempio, e chiunque può aggiungere o rimuovere qualsiasi campo si sentono come, è necessario sia il codice di validazione e le convenzioni per prendere l'allentamento. Soprattutto se si lavora con risorse esterne.

Ti manca uno qualsiasi dei principali servizi extra che RDBMS forniscono?

No. Ma il mio background è sviluppatore di applicazioni web, abbiamo a che fare con i database solo nella misura in cui dobbiamo :)

Una società che ho usato per lavorare per fatto un prodotto (una webapp) che è stato progettato per funzionare attraverso i database SQL di diversi fornitori, ed i "servizi extra" sono così diversi da DB a DB che dovevano essere attuate separatamente per ogni DB. Così è stato meno lavoro per noi per muoversi la funzionalità di RDBMS. Questo anche estesa a ricerca full-text.

Quindi, qualunque cosa sto dando up è una cosa che non ho mai veramente avuto, in primo luogo. Ovviamente, la vostra esperienza potrebbe essere diversa.

Un avvertimento: Quello che sto lavorando ora è una webapp per i dati finanziari, quotazioni di borsa e simili. Questa è una partita molto buona per un DB di documento, dal mio punto di vista ho tutti i vantaggi di un DB (persistenza e query) senza che nessuna delle fastidio.

Ma questi dati sono abbastanza indipendenti l'uno dall'altro, non ci sono interrogazioni relazionali complesse. Ottenere ultime quotazioni da ticker, ottenere citazioni di ticker e intervallo di date, ottiene società meta-informazioni, che è praticamente tutto. Un altro esempio che ho visto era un'applicazione blog, e i blog non sono caratterizzati da schemi di database in maniera massiccia complicate sia.

Quello che sto cercando di dire è che tutte le applicazioni di successo di documento DB che conosco sono stati con dati che non ha avuto molto interrelazioni, in primo luogo: Documenti (come nella ricerca di Google), post di blog, articoli di notizie , dati finanziari.

Mi aspetto che ci sono serie di dati che mappano meglio a SQL rispetto al modello del documento, quindi immagino SQL sopravviverà.

Ma per quelli di noi che vogliono solo un modo semplice per memorizzare e recuperare i dati - e ho il sospetto che ci sono molti di noi -. Database di documenti (come in CouchDB) sono una manna dal cielo

Sono rispondere a questa con CouchDB nella parte posteriore della mia mente, ma io pretendo la maggior parte sarebbe vero per altri DB anche. Abbiamo guardato con CouchDB, ma alla fine abbiamo deciso contro di essa dato che il nostro accesso ai dati non è noto in anticipo e scalabilità non è il problema.

Harder:

Prende ripensare a livello concettuale in modo che sia 'difficile' dal momento che è solo diverso. Dal momento che è necessario conoscere i vostri modelli di accesso ai dati in anticipo, nessuna traduzione automatica può essere applicata. Si avrebbe bisogno di aggiungere il modello di accesso, almeno.
La coerenza non è gestito dal database, ma deve essere affrontato nella domanda. Meno garanzie mezzi migrazione più semplice, sicuro-over e migliore scalabilità a costo di un'applicazione più complicata. Un'applicazione deve fare i conti con i conflitti e le contraddizioni.
Link quali documenti trasversali (o chiave / valore) devono essere trattate a livello di applicazione anche.
SQL di basi di dati hanno IDE che sono molto più maturo. Si ottiene un sacco di librerie di supporto (anche se la stratificazione di queste librerie rendere le cose molto più complessa di quanto necessario per SQL).

Più facile:

più veloce se si conoscono i vostri modelli di accesso ai dati.
Migrazione / Fail-over è più facile per il database in quanto non promesse sono fatte a voi come un programmatore di applicazioni. Anche se si ottiene eventuale consistenza. Probabilmente. Finalmente. Qualche tempo.
Una chiave / valore è molto più facile da capire di una riga da una tabella. Tutti i (albero) i rapporti sono già, e gli oggetti completi possono essere riconosciuti.

La modellazione dovrebbe essere circa lo stesso, ma bisogna stare attenti a ciò che si mette in un unico documento. UML può essere utilizzato anche per entrambi la modellazione OO così come DB di modellazione, che sono due bestie differenti già

Mi sarebbe piaciuto vedere un buon database open OO ben integrato con C # / Silverlight. Giusto per rendere la scelta ancora più difficile. :)

Lime piatte sono stati a lungo considerati arcano e poco pratico per un insieme di dati di qualsiasi dimensione. Tuttavia, i computer più veloci con più memoria permettono di caricare un file in memoria e ordinare in tempo reale, almeno per ragionevolmente piccolo n e locali, le applicazioni utente singolo.

Ad esempio, di solito si può leggere un file di 10.000 record e ordinare su un campo in meno di mezzo secondo, un tempo di risposta accettabile.

Naturalmente, ci sono ragioni per usare un database invece di un file piatto - operazioni relazionali, l'integrità dei dati, funzionalità multiutente, acccess remoto, maggiore capacità, normalizzazione, ecc, ma una maggiore capacità di memoria e la velocità del computer hanno fatto in la manipolazione dei dati -Memoria più pratico in alcuni casi.

Le basi di dati relazionali che vedo nella vita reale tendono ad essere non molto ben normalizzato affatto, contrariamente al vostro reclamo. Quando è stato chiesto, i progettisti mi dicono che è in gran parte a causa di prestazioni. RDBMS non sono bravi a entrare, quindi le tabelle tendono ad essere troppo ampio da un punto di vista di normalizzazione. i database orientati agli oggetti tendono ad essere molto meglio a questo.

Un altro punto in cui RDBMS hanno problemi è la gestione di storia / tasti dipendenti dal tempo.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow