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.