NoSQL/RDBMS ibrido con integrità referenziale (elimina cascata)?

Question

C'è un database là fuori che offre il vantaggio dell'integrità referenziale e la possibilità di utilizzare un linguaggio di tipo SQL per l'interrogazione, ma consente anche alle entità di essere definite in modo approssimativo rispetto ai loro attributi di dati e anche alle relazioni tra loro?

E.g. prendere un modello di tipo RBAC in cui sono presenti autorizzazioni, utenti, gruppi utenti & ruoli. Un modello complesso/flessibile potrebbe avere le seguenti regole:

• ruoli possono avere uno o più autorizzazioni e permessi possono appartenere a uno o più ruoli
• Gli utenti possono avere uno o più autorizzazioni e permessi possono appartenere a uno o più utenti
• utenti gruppi possono avere uno o più autorizzazioni e permessi possono appartenere a uno o più utenti Gruppi
• Gli utenti possono avere uno o più ruoli e un ruolo può appartenere a uno o più utenti
• utente I gruppi possono avere uno o più ruoli e un ruolo può appartenere a on e o più gruppi di utenti
• ruoli possono avere uno o più ruoli e un ruolo possono appartenere a uno o più ruoli

Per modellare quanto sopra in un RDBMS comporterebbe la creazione di un sacco di tavoli di intersezione. Idealmente, tutto ciò che vorrei definire nel database sono le entità stesse (Utente, Ruolo, ecc.) Oltre ad alcuni attributi obbligatori. Tutto il resto sarebbe quindi dinamico (cioè non è richiesto alcun DDL), ad es. Potrei creare un utente con un nuovo attributo che non era predefinito. Potrei anche creare una relazione tra entità che non sono state predefinite, sebbene il database gestisca l'integrità referenziale come un normale RDBMS.

quanto sopra può essere raggiunto in una certa misura in un RDBMS con la creazione di una tabella per memorizzare entità e un altro per memorizzare le relazioni, ecc, ma questo complica eccessivamente l'SQL necessario per eseguire query semplici e possono anche avere implicazioni sulle prestazioni.

Answer 1

La maggior parte dei database NoSQL è costruita per scalare molto bene. Questo viene fatto a costo di coerenza, di cui l'integrità referenziale fa parte. Quindi la maggior parte di NoSQL non supporta alcun tipo di vincoli relazionali.

C'è un tipo di database NoSQL che supporta le relazioni. In realtà, è stato progettato appositamente per le relazioni: lo graph database. I database grafici memorizzano nodi e relazioni esplicite (spigoli) tra questi nodi. Sia i nodi che i bordi possono contenere dati sotto forma di coppie chiave/valore, senza essere legati a uno schema predefinito.

I database grafici sono ottimizzati per le query relazionali e le operazioni di grafici eleganti, come trovare il percorso più breve tra due nodi o trovare tutti i nodi entro una determinata distanza dal nodo corrente. Non avresti bisogno di questo in uno scenario ruolo/permesso, ma se lo fai, sarà molto più difficile da raggiungere utilizzando un RDBMS.

Un'altra opzione è quella di rendere ibrido l'intero livello dati, utilizzando un RDBMS per memorizzare le relazioni e un database di documenti per memorizzare i dati effettivi. Ciò complicherebbe leggermente la tua applicazione, ma non penso che sia una soluzione così brutta. Utilizzerai due tecnologie diverse, entrambe che si occupano dei problemi con cui sono state progettate.

Answer 2

C'è la lingua Gremlin, supportata dal database grafico Neo4j. Per quanto riguarda il tuo esempio, dai un'occhiata a Access control lists the graph database way e here.C'è anche uno strumento basato sul web che include un'API REST per Neo4j e una console Gremlin, vedi neo4j/webadmin.

Answer 3

Dati i requisiti specificati nella domanda, un database grafico è probabilmente il tipo di oggetto che stai cercando, ma ci sono altre opzioni. Come ha affermato @Niels van der Rest, i due vincoli di "schema non a priori" e "integrità referenziale" sono molto difficili da conciliare. Potresti essere in grado di trovare un database basato su Topic Map che potrebbe farlo, ma non ho familiarità con le implementazioni specifiche, quindi non posso dirlo con certezza.

Se decidi che non puoi davvero fare a meno dell'integrità referenziale, temo che probabilmente sei bloccato con un RDBMS. Ci sono alcuni trucchi che puoi usare per evitare alcuni dei problemi che prevedi, copro un paio in https://stackoverflow.com/questions/3395606..., che potrebbe darti qualche idea. Tuttavia, per questo tipo di modello di dati che richiede uno schema dinamico, post-priori, con elementi meta-schema, un RDBMS sarà sempre scomodo.

Se si è disposti a rinunciare all'integrità referenziale, allora si hanno ancora tre approcci da considerare.

1. Map/Reduce - in due versioni: record-oriented distribuito (si pensi, MongoDB), e la colonna-oriented (si pensi, Cassandra). Le bilance sono davvero molto buone, ma non avrai la tua sintassi simile a SQL; si unisce a succhiare; e la corrispondenza della tua architettura con i tuoi specifici tipi di query è fondamentale. Nel tuo caso, concentrati sulle entità e sui loro attributi, piuttosto che sulle relazioni tra le entità stesse, quindi probabilmente prenderemo in considerazione un archivio distribuito orientato ai record; ma solo se mi aspettassi di dover scalare oltre un singolo nodo, essi si adattano davvero bene.

2. Document-store - tecnicamente in due versioni, ma una di queste è una mappa distribuita orientata ai record/riduce il datastore sopra discusso. L'altro è un indice invertito (pensa, Lucene/Solr). NON ignorare la potenza di un indice invertito; possono risolvere predicati di record oscenamente complessi sorprendentemente veloci. Ciò che non possono fare è gestire bene le query che includono la correlazione o grandi join relazionali. Tuttavia, sarete sorpresi dall'incredibile flessibilità, i predicati di record sufficientemente complessi.

3. Graph-store: in pochi gusti il ​​primo è l'archivio di valori-chiave su larga scala ad hoc (si pensi, DBM/TokyoTyrant); il secondo è lo spazio-tupla (si pensi, Neo4j); il terzo è il database RDF (pensa, Sesame/Mulgara). Ho un soft-spot per RDF, avendo contribuito a sviluppare mulgara, quindi non sono il commentatore più obiettivo. Tuttavia, se i vostri vincoli di scalabilità vi permetteranno di usare un RDF-store, trovo inestimabile l'inferenza permessa dalla semantica denotazionale di RDF (rara tra le opzioni di datastore noSQL).

Answer 4

Si consiglia di controllare MongoDB si tratta di un database basato su documenti e quindi ha uno schema flessibile. È fantastico e vale la pena dedicare tempo per vedere se soddisferà le tue esigenze.

Answer 5

Alcune soluzioni NoSQL supportano sicurezza e SQL. Uno di questi è OrientDB. Il sistema di sicurezza è (abbastanza) ben spiegato here.

Supporta inoltre SQL.