Valutazioni sull'uso di nosql

[vco87]

Salve a tutti,
devo valutare la scelta riguardo al modello dei dati da utilizzare in un'applicazione e mi servirebbe qualche suggerimento.
Quest'applicazione prima di tutto deve fare inserimenti giornalieri di una gran quantità di dati (circa 1 gb e più) nel minor tempo possibile perchè subito dopo deve partire l'elaborazione di questi dati. Quindi per l'elaborazione devo creare una super matrice (anche 1000000 e più righe) e per creare la matrice carico i dati dal db.

Ora mi verrebbe da usare normalmente un db relazionale, ma vorrei capire se dovessi avere vantaggi dall'uso di un db nosql. Se dovessi usare un db relazionale avrei 4-5 tabelle.
Non ho necessità di propietà acid, il db lo uso per mantenere lo storico e per effettuare elaborazioni sui dati,poi i risultati li do in output non li devo neanche scrivere su db.
Quindi vorrei un consiglio, se è il caso di prendere in considerazione l'uso di un db nosql e i vantaggi che ne avrei, tenendo conto che il mio obiettivo è scrittura rapida e una select su tutte le tuple( della tabella più grande).


Grazie

[deleted_29]

mancano delle informazioni essenziali.

cominciando da "quanto sei bravo a programmare", col corollario "quanto tempo puoi dedicare".

Cosa significa "grande" (db), magari è un sinonimo per "minuscolo".

Cosa significa "minor tempo possibile", e cosa significa una "select su tutte le tuple".

Dal lato prestazioni il miglioramento dell'uso di un RDBMS riguarda, essenzialmente, la disponibilità di indici di adeguata selettività.

Se hai dei dati statistici, dei quali ad esempio vuoi ottenere la somma di una colonna (esempio banale), anche il miglior DB non ti aiuterà, perchè non hai selettività.

In questo caso serve solo "forza bruta", anzi (meglio ancora) un programma che si forka ed esamina in parallelo i dati, per usare macchine multi-core.
Ovviamente, anche sotto questo profilo, le matrici di dati vanno splittati, per impedire race condition tra i vari thread, i quali potrebbero paradossalmente aver necessità di cospicue opere di sincronizzazione.
---
Riassumendo: inizia con dimensioni, tempi e lavori.

[vco87]

Grazie per la risposta ora cercherò di esser più preciso

-cominciando da "quanto sei bravo a programmare", col corollario "quanto tempo puoi dedicare".

Bè diciamo che ho programmato a livello universitario e ho fatto qualche lavoretto, bene o male me la cavo, certo non sono un esperto, questo dovrebbe essere un primo progetto serio

-Cosa significa "grande" (db), magari è un sinonimo per "minuscolo".

per grande intendo qualche milione di record

-Cosa significa "minor tempo possibile", e cosa significa una "select su tutte le tuple".

le tabelle sono poche, il dominio è semplice, in particolare c'è una tabella relativa a dei feedback degli utenti su dei prodotti e questa è quella destinata a cresecere enormente (anke milioni di record)


Su tutti i feedback farò dei calcoli globali e quindi farò una select su tutta la tabella (nella maggior parte dei casi)
ecco perchè mi servirebbe capire da ora se sarebbe una buona scelta l'opzione nosql

Spero di esser stato più chiaro

[deleted_29]

Originariamente inviato da vco87
Grazie per la risposta ora cercherò di esser più preciso

-cominciando da "quanto sei bravo a programmare", col corollario "quanto tempo puoi dedicare".

Bè diciamo che ho programmato a livello universitario e ho fatto qualche lavoretto, bene o male me la cavo, certo non sono un esperto, questo dovrebbe essere un primo progetto serio

Ok, allora nella categoria quasi-niubbo

per grande intendo qualche milione di record

Ok, allora è "minuscolo"

-Cosa significa "minor tempo possibile", e cosa significa una "select su tutte le tuple".

le tabelle sono poche, il dominio è semplice, in particolare c'è una tabella relativa a dei feedback degli utenti su dei prodotti e questa è quella destinata a cresecere enormente (anke milioni di record)


Su tutti i feedback farò dei calcoli globali e quindi farò una select su tutta la tabella (nella maggior parte dei casi)

Ecco un esempio di errore concettuale.
Se gli utenti danno dei feedback, e questi son tanti, basta che li storicizzi man mano in tabelle riassuntive.
Questo riduce il carico di almeno 3 ordini di grandezza, se non di più.
Non ha un gran senso ricontare quanti giudizi positivi ci sono sul prodotto X "da sempre a sempre".
Basta che li conti "da X a Y", li metti in una tabellina di appoggio.

Ne tieni un'altra con "dati non elaborati", nottetempo (o quando vuoi) fai tutte le statistiche che vuoi=>aggiorni la tabellina dei conteggi.
Elimini i dati-non-elaborati (o li passi nella tabellona storico, se ti interessa).

ecco perchè mi servirebbe capire da ora se sarebbe una buona scelta l'opzione nosql

Direi proprio, date le tue conoscenze, NO

Qualsiasi tipo di analisi statistica ha due grandi problemi
1) se sono richieste robe "strane" (ad esempio difficilmente con sql riesci a calcolare uno jacobiano per decidere se fare un "+1")
2) la possibilità di usare indici di elevata selettività.
Se hai una tabellona del tipo
utente; voto

e vai qualcosa del tipo select sum(voto) from tabellona

l'RDBMS più evoluto non ti darà nulla più, anzi in generale meno, di un banale (o anche non banale) programma che elabora i dati grezzi, perchè deve fare un fullscan della tabella.

qualcosa tipo select sum(voto) from tabellona where utente='pippo' invece può (o non può) essere grandemente velocizzata.
Se la cardinalità di utente='pippo' è = cardinalità(tutto)-1, allora paradossalmente è più lento, perchè l'overhead della gestione dell'indice su "utente" non paga il risparmio di fare uno scan - 1 riga.
---
Come vedi solo la conoscenza perfetta sia dei dati, che del tipo di elaborazioni che vuoi fare, che degli strumenti, ti danno la possibilità di scegliere la strada migliore.

E, spesso, paradossalmente ti accorgi che una soluzione che sembrava "buona" (o anche "ottima") sulla carta non lo è minimamente in produzione

[vco87]

Ti ringrazio franzauker
per la risposta esauriente e tempestiva

ciao