I database relazionali potrebbero scalare anche (o meglio) delle loro controparti NoSQL se abbandoniamo le relazioni?

Question

Disclaimer: Questa è una domanda ampia, quindi potrebbe essere spostata su un'altra fonte (se gli amministratori lo trovano appropriato).

Tutti i ragazzi fantastici sembrano far cadere database relazionali a favore delle loro controparti NoSQL. Ognuno avrà le sue ragioni, dai problemi di ridimensionamento al semplice essere al margine della tecnologia. E, non sono qui per mettere in discussione le loro motivazioni.

Tuttavia, ciò che mi interessa è se le transizioni NoSQL abbiano mai convalidato i guadagni in termini di prestazioni (manutenzione) rispetto a un RDBMS tradizionale quando le relazioni sono state eliminate. Perché dovremmo utilizzare un RDBMS quando il motivo principale che esiste viene eliminato? Alcuni motivi vengono in mente

1. 30+ anni di ricerca accademica e di lavoro nello sviluppo di questi sistemi
2. Un linguaggio ben noto in Structured Query Language (SQL).
3. stabile e maturo supporto ORM attraverso tecnologie (Hibernate, ActiveRecord)

Chiaramente, nel mondo moderno, dove scala orizzontale è importante, v'è la necessità di assicurarsi che i frammenti siano fault tolerant, aggiornato nel tempo intervalli richiesti dall'app, ecc. Tuttavia, tali esigenze non devono necessariamente essere responsabilità di un sistema che memorizza i dati (esempio: ZooKeeper).

Inoltre, riconosco che la ricerca dovrebbe essere dedicata a NoSQL e che il tempo trascorso in questa arena porterà chiaramente a tecnologie Internet migliori. Tuttavia, un confronto di ordinamenti tra NoSQL e offerte RDBMS tradizionali (meno relazioni) sarebbe utile per prendere decisioni di business.

UPDATE 1: Quando mi riferisco ai database NoSQL, sto parlando di archivi di dati che non possono richiedere schemi di tabelle fisse e di solito evitare operazioni di join. Quindi, l'enfasi nella domanda sulla caduta delle relazioni in un tradizionale RDBMS SQL

Answer 1

Non trovo che le relazioni tra tabelle siano il principale limitatore per la scalabilità. Uso regolarmente query con join e ottengo una buona scalabilità se gli indici sono ben definiti.

Il maggiore limitatore per la scalabilità è il costo dell'I/O sincrono. I requisiti di coerenza e durata: il DBMS in realtà e salva in modo affidabile i dati quando ti dice che i dati salvati sono costosi.

Diversi prodotti NoSQL attualmente in voga raggiungono grandi prestazioni indebolendone la coerenza e le garanzie di durata nella configurazione predefinita. Esistono molte segnalazioni di perdita di dati da CouchDB o MongoDB.

Ci sono modi per configurare quei prodotti NoSQL per essere più rigidi sulla durabilità, ma poi si sacrificano i loro impressionanti numeri di prestazioni.

Allo stesso modo, è possibile fare in modo che un database SQL raggiunga prestazioni elevate come i prodotti NoSQL, disabilitando le funzionalità predefinite che garantiscono la sicurezza dei dati. Vedi RunningWithScissorsDB.

PS: Se pensate che i database orientati ai documenti siano "all'avanguardia", vi invito a leggere su MUMPS. Tutto vecchio è di nuovo nuovo. :-)

Answer 2

SQL ha generalmente problemi di ridimensionamento perché le garanzie fornite non sono solo per una "riga" alla volta. Si estendono su più file. Questo rende il carico difficile da distribuire. Ecco alcuni esempi di di RDBMS dando garanzie che coprono più di un record:

1. Indici: aggiornamento atomico di due tabelle sottostanti in una sola volta (l'indice è internamente una tabella)
2. chiavi esterne
3. viste materializzate

Il problema con queste caratteristiche è che non si prestano bene al partizionamento. In tutti e 3 i casi, una scrittura particolare potrebbe estendersi su più partizioni causando problemi di ridimensionamento.

NoSQL generalmente "risolve" questo semplicemente vietando quelle caratteristiche ;-)

Il prossimo trattenendo SQL è che fornisce semantica ACID per default. Questo non è inerente al modello relazionale: è un dettaglio di implementazione.

Quindi, se si disattivano le funzionalità che sono difficili da distribuire/partizionare e disabilitare ACID, si ottengono prestazioni NoSQL. Di fatto, guarda come HandlerSocket fa questo con MySQL.Ha una velocità NoSQL anche se gira su InnoDB e fornisce un'interfaccia SQL standard con tutte le funzionalità (in realtà è solo un bypass senza caratteristiche su un server MySQL standard).

Nessuna magia in NoSQL, solo meno funzioni. Che va bene È un diverso compromesso.

Answer 3

Sembra che ci siano almeno due idee sbagliate che potrebbero essere implicite in questa domanda. Innanzitutto "NoSQL" non significa "non relazionale", significa solo qualcosa di diverso da SQL. Quindi un RDBMS potrebbe essere anche un DBMS NoSQL.

In secondo luogo, un RDBMS non ha molto a che fare con le relazioni * di per sé. Le relazioni non fanno parte del modello relazionale e possono esistere anche in database non relazionali (compresi quelli No-SQL). La parte "relazionale" di RDBMS si riferisce specificamente alle relazioni - ovvero la struttura dei dati più comunemente chiamata "tabella" (e mai chiamata "relazione"). La domanda sembra mescolare queste due cose importanti e molto diverse: relazione e relazione.

Poiché l'esistenza o l'assenza di relazioni non ha nulla a che fare con il fatto che un database sia relazionale o meno, non sono sicuro di cosa si stia realmente chiedendo. Se ho frainteso qualcosa allora forse potresti chiarire un po 'la domanda.

* Una relazione è una "associazione tra le cose" - o talvolta un vincolo di database che applica una regola a tali associazioni.

Answer 4

Penso che i pro/contro dell'utilizzo di RDBMS o NoSQL dipendano davvero dai dati e da come si prevede di utilizzarli. Mi risulta che le transazioni siano effettivamente rappresentate abbastanza bene con un DB relazionale. La mia esperienza con NoSql è con Infinite Graph & Neo4J. Forensics è un buon esempio per NoSQL, ogni persona è un nodo/vertice e un bordo può rappresentare diversi tipi di comunicazione (email, telefono, incontro faccia a faccia, piccione viaggiatore, ecc ...). È quindi possibile prendere un sospetto/vertice e attraversare il grafico con criteri specifici per scoprire come due individui apparentemente non connessi sono effettivamente connessi (probabilmente con maggiore efficienza rispetto a un DB relazionale tradizionale). I dati del grafico sociale sono un altro buon esempio, ogni utente è un nodo/vertice e la relazione (amico) è un bordo che collega due nodi. In breve, i tuoi dati sono meglio rappresentati & recuperati con tabelle o nodi/bordi.

Answer 5

rapporti non è un buon criterio per confrontare le prestazioni tra RDBMS e NoSQL.

NoSQL è diventato molto popolare a causa di molti fattori

1. scalabilità orizzontale.
2. Supporto per non strutturati & dati semi-strutturati
3. /scrittura di throughput
4. costo economico hardware Leggi ecc

Dai un'occhiata alla RDBMS Overheads

RDBMS avere le sfide a causa di requisiti di coerenza .

Per supportare le transazioni, RDBMS deve sostenere proprietà ACID: atomicità, coerenza, Isolamento, Durabilità). Ciò può essere ottenuto con

Registrazione: l'assemblaggio di record di registro e il rintracciamento di tutte le modifiche nelle strutture di database rallenta le prestazioni. La registrazione potrebbe non essere necessaria se la recuperabilità non è un requisito o se la recuperabilità è fornita attraverso altri mezzi (ad es. Altri siti sulla rete).

Blocco: Il blocco tradizionale a due fasi rappresenta un sovraccarico considerevole poiché tutti gli accessi alle strutture del database sono regolati da un'entità separata, il Gestore blocchi.

Latching: in un database a più thread, molte strutture di dati devono essere bloccate prima di poterle accedere. La rimozione di questa funzionalità e il passaggio a un approccio a thread singolo hanno un notevole impatto sulle prestazioni.

Gestione buffer: Un sistema di database di memoria principale non deve accedere alle pagine attraverso un pool di buffer, eliminando un livello di riferimento indiretto su ogni accesso ai record.

In Riepilogo, RDBMS non viene ridimensionato a causa dei costi generali di cui sopra, che sono necessari per supportare le transazioni ACID.La mancanza di relazioni non migliora le prestazioni del sistema RDBMS.