La mappa riduce il fattore di base che rende NoSQL più scalabile di SQL?

3

Sto studiando le differenze tra NoSQL e SQL e ciò che rende il primo più scalabile. Penso di aver capito il punto, quindi cercherò di spiegare:

Supponiamo che un'app abbia un elenco di miliardi di utenti, ciascuno con una quantità di denaro, e che voglia visualizzare la somma di tutti loro. In SQL, dovrebbe essere SELECT SUM(money) FROM users , il che farebbe sì che il motore iterasse attraverso ogni utente (O (n)) per calcolare la somma, che è lenta. In NoSQL, in altre mani, potrebbe precedentemente impostare una funzione di riduzione della mappa come nosql_engine.mapReduce(get_money,sum) . Ciò farebbe sì che il recupero della somma sia istantaneo (O (1)) come verrebbe memorizzato nella cache, e l'aggiornamento di tale calcolo si riduce a O (log (n)), a causa dell'associazione dell'operazione di riduzione. Quindi, in generale, questa capacità di riduzione della mappa è il principio base di base che rende NoSQL più scalabile di SQL. È corretto in qualche misura?

    
posta MaiaVictor 14.03.2013 - 12:13
fonte

1 risposta

16

No, non è affatto così. Quello che descrivi sta ottenendo un vantaggio sia dal caching (avendo calcolato la risposta prima che la richiesta sia arrivata) sia dalla parallelizzazione (incaricando più di un nodo con il calcolo di una grande somma). Né è necessariamente esclusivo per le basi di dati 'NoSQL'. (Uso le virgolette perché ciò che la gente chiama "NoSQL" al giorno d'oggi è per lo più caratterizzato non dalla mancanza di un linguaggio di query strutturato, ma dalla mancata aderenza ai rigorosi principi relazionali .

La memorizzazione nella cache di aggregazioni calcolate frequentemente può essere eseguita in qualsiasi tipo di archivio dati. In termini relazionali questo è chiamato denormalizzazione , e mentre secondo i più stretti aderenti alla teoria relazionale non dovresti mai farlo mai, ha evidenti vantaggi in alcuni casi d'uso ed è quindi spesso fatto senza molto dispiacere motori di database sia vecchi che nuovi. I trade-off sono ben noti (ad esempio letture più veloci rispetto a inserimenti più lenti) e sono generalmente gestibili; sono in effetti abbastanza simili ai trade-off per l'indicizzazione normale.

Il vantaggio caratteristico di map-reduce è che più di un nodo si unisce in un calcolo, il che significa che i dati devono essere distribuiti . Ciò viene spesso fatto anche dai database relazionali, sia sotto forma di sharding, partizionamento orizzontale o qualsiasi altra variante. Ovviamente la distribuzione dei dati può anche essere combinata con denormalizzazione.

Ciò che rende le basi di dati non relazionali in genere più veloci è l'omissione delle classiche garanzie ACID sull'integrità dei dati. Ad esempio, il sistema potrebbe non garantire che tutte le tue scritture siano visibili contemporaneamente a tutti gli altri client, o addirittura che diventino visibili a tutti. Un frequente compromesso è che tutti i dati che scrivi diventeranno visibili a tutti i clienti con un tempo sufficiente, in cui "sufficiente" non è un importo strettamente limitato ("consistenza finale"). Ovviamente, questo permette di scrivere molto velocemente perché non devi aspettare fino a quando tutte le garanzie non sono state messe in atto. Per la lettura, il fattore decisivo è spesso quanto ti preoccupi dei risultati inesatti (ad es. Non contando cose che sono nel sistema ma non ancora visibili). Per calcolare una somma, è probabile che il calcolo effettivo (cioè l'esecuzione di istruzioni ADD nel core del processore) sia molto, molto più veloce dell'i / O coinvolto nel recupero di tutti i blocchi di dati rilevanti da qualsiasi luogo, quindi la parallelizzazione non è molto buona - il tempo totale sarà quasi sicuramente dominato dalla velocità con cui puoi arrivare a tutti gli operandi e da quanto duramente cerchi di non perdere nessuno.

    
risposta data 14.03.2013 - 13:16
fonte

Leggi altre domande sui tag