Salve.
Qualcuno ha felicemente lasciato definitivamente i classici db
relazionali come postgres per lanciarsi nel mondo del NOSQL
utilizzando db come mondodb?
Devo sviluppare un’app di gestione ditte:
ciascuna ditta ha un’attivita’ commerciale in varie forme: negozio,
ecommerce, corrispondenza, ecc. e di ciascuna di queste attivita’
commerciali devo tenere un history, sapere quando sono state attivate,
quando e se sono state cessate, i vari passaggi volture, subingressi,
ecc.
Stavo iniziando il progetto con postgresql che uso sempre ma noto, da
letture in rete, che i db detti NOSQL, stanno prendendo sempre piu’
piede.
Che ne pensate?
Che ne pensate?
Penso che buttare via un signor database come Postgres, che va
benissimo per dei dati strutturati, dove sicuramente hai bisogno di
tracciare i rapporti fra le varie componenti (join!) per un database
sperimentale non sia il massimo.
Il bello dell’informatica e che ci sono sempre cose nuove e interessanti da imparare, ma per quanto riguarda i nosql, punterei di piu su qualcosa come redis come sostegno/appoggio nel momento quando
ti rendi conto che Postgres ha bisogno di qualcosa in piu`.
Io ho avuto a che fare con MongoDB lo scorso anno, e non mi e piaciuto molto: dovendo fare dei query un po' piu “complessi”,
diventava molto lento. E i numeri nel DB (migliaia di record) erano
numeri che Postgres gestisce senza fatica. Hanno usato Mongo per
provare una cosa nuova…
–
David N. Welton
Qui, imho, uscir un flame. Io sono della opinione di David, che mi ha
preceduto di pochi minuti.
“does /dev/null support sharding? :-)”
2012/5/8 David W. [email protected]
Non si “lascia” nessuno strumento, si usa quello giusto.
I database NoSQL non sono “i nuovi database”, ma DEI nuovi database con
delle caratteristiche precise.
NoSQL is not the same thing as no SQL 
2012/5/8 Stefano P. [email protected]
Il 08/05/12 17:44, Stefano P. ha scritto:
Qui, imho, uscir un flame.
Supporto la nascita del flame, cos la volta buona che capisco quando
usare noSQL! 
Qui ci sono delle slide e se cerchi c’é anche un video che parla di
perché hanno migrato Diaspora da MongoDB a Mysql.
Il problema in generale è che molte tecnologie “moderne” servono per
gestire meglio dei casi di nicchia specifici piuttosto che per
rimpiazzare a 360 un db classico.
Luigi
Il giorno 08/mag/2012, alle ore 17:33, Mauro ha scritto:
Stavo iniziando il progetto con postgresql che uso sempre ma noto, da
letture in rete, che i db detti NOSQL, stanno prendendo sempre piu’
piede.
Che ne pensate?
Che hai un classico caso di progetto dove e’ richiesto (per vari motivi)
il modello
“relazionale” (o qualcosa che ci si avvicini molto). Qui NOSQL ci
azzecca poco, ma di sicuro
tieni d’occhio questo mondo, alcuni prodotti risolvono problemi ben
specifici (che magari il tuo applicativo potrebbe avere).
Personalmente uso molto mongodb e redis.
Il primo quando ho bisogno di gestire dati schema-free (il cms
locomotive e’ secondo me l’esempio migliore di questo utilizzo),
il secondo per le code e la gestione di liste e set.
–
Roberto De Ioris
http://unbit.it
JID: [email protected]
Supporto la nascita del flame, cos la volta buona che capisco quando
usare noSQL!
Quando devi fare qualcosa che un DB tradizionale non fa molto bene.
–
David N. Welton
Complemento citando l’approccio della “polyglot persistence”
In realt i motivi per cui hanno migrato non sono insiti nel db, ma
nella loro scarsa esperienza con mongoDb, nella poca documentazione e
poco supporto dalla comunit.
Dopo di che o non avrei scelto mysql, ma piuttosto postgresql quindi
avrei da ridire anche sulla loro migrazione. Ci sono molti ambiti in cui
sia un db sql che uno NoSql possono risolvere la situazione, il problema
capire quale lo fa meglio.
Francesco
Il 08/05/2012 17:50, Luigi M. - grigio.org ha scritto:
Per l’applicazione che hai descritto io sceglierei un database Postgres.
Ho scelto mongodb in almeno un paio di progetti, ma c’erano presupposti
diversi.
Nella mia esperienza, l’euforia nell’uso di un database noSQL come
mongodb presto mitigata
dal dover fare i conti proprio con la struttura mancante. Voglio dire
che con un database SQL ci sono pochi
modi per sbagliare il disegno della base dati. E’ tutto molto
comprovato, e con ActiveRecord
viaggi veramente sui binari.
Non la stessa cosa con un noSQL. Paradossalmente molto pi importante
pensare prima alla
struttura dei tuoi dati di quanto non lo sia con database SQL, almeno
per quanto riguarda mongodb, in
cui hai le ‘collection’ e l’atomciti negli update dei singoli documenti
delle collection.
Altra nota importante sono le transazioni, che se non sbaglio non sono
ancora implementate con la
stessa atomicit in nessun noSQL.
Per concludere, non userei mai un nosql per un gestionale. Scegli lo
strumento giusto per il lavoro giusto.
Tra l’altro considera che se volessi sperimentare schemaless alcune
parti della tua applicazione, in postgres
hai almeno due modi per farlo, il data type XML e il pi recente HStore:
Ho usato il datatype XML con gran soddisfazione di recente.
Per concludere, non userei mai un nosql per un gestionale. Scegli lo strumento
giusto per il lavoro giusto.
Grazie, questo thread e’ stato …salutare
Ho poco da aggiungere ma se serve una soluzione per persistere dati con
struttura variabile:
ma credo che anche questo sia stato citato. Per chi e stanco di usare le migrazioni, potrebbe passare a Datamapper, non c'e' bisogno di cambiare DB. Credo che mongodb riesca a gestire meglio piu nodi,
rispetto a postgres e mysql, anche se usa comunque il paradigma
master-slave. Riak usa un circular buffer e` scala molto meglio.
Comunque ci sono anche delle soluzioni per la replicazione su Mysql e
soprattutto per Postgres. Per MySql uso Xeround DB ma e su EC2 ed e un
PaaS. Un progetto di replicazione semplice e` http://www.rubyrep.org/ ma
usa il metodo dei trigger, quindi non proponibile su piattaforme di
hosting, ma utile se la app usa una sua infrastruttura.
Ho letto un post contro mongodb, parlava della perdita di dati ed altri
problemi derivati ad una grossa mole di dati da gestire, purtroppo non
ricordo il link.
Infatti, l’articolo di Martin F. porta all’attenzione il mito del
fatto che gli ORM ti fanno dimenticare l’esistenza del DB. Purtroppo
questo mito ha fatto danni, visto che astrarre il db non cosi
semplice e nemmeno gli ORM sofisticati ci riescono.
Il punto capire se database come MongoDb riescono a risolvere il
problema e al momento sembra che qualcosa riescono a risolvere, ma
forse presto per cantare vittoria.
Per la mia seppur breve esperienza, i db nosql (parlo di mongo perch
un po’ lo conosco) risolvono il problema del salvare i dati in modo
semplice: prendo un grafo di oggetti e lo sparo in una collezione. Il
problema nasce quando devo ricaricare i dati e andare “in join” per
prendere altre informazioni.
Ho capito che la cosa pi difficile quando si lavora con i nosql
disegnare bene quelli che in DDD sono gli aggregati, se davvero si
disegnano bene gli aggregati il 95% dei problemi scompare creando una
collezione per aggregato.
Siccome l’aggregato un’unita consistente posso salvarla e caricarla
in autonomia senza che mi servano altre informazioni da altre
collezioni.
Questo vuol dire denormalizzare i dati (e a volte duplicare)…ma
credete davvero che la normalizzazione completa sia cos importante?
Per me non lo .
Quindi io uno sguardo ai nosql lo darei e li terrei in considerazione
in molti contesti…
bye
Io non ho esperienza diretta anche se mi piacerebbe approfondire. Quali
sono le differenze tra i relazionali ed i nosql? Queste quelle che mi
vengono in mente:
- scalabilità
- prestazioni
- ridondanza
- sicurezza
- integrità
- utilizzo
La questione cruciale è analizzare il contesto. Io non ho mai creato un
gestionale che avesse bisogno di tanta scalabilità orizzontale e se mai
mi capiterà mi chiederò, prima di scegliere il database, come farò a
gestirla e presentarla.
C’è anche la questione sicurezza o forse si tratta ormai solo di
fiducia. Mi chiedo poi come venga gestita la ridondanza dei dati, nei
relazionali ci pensano le join, se pur col peso che hanno. Infine
l’utilizzo: devono essere accoppiati ad un orm altrimenti l’integrità
dei dati può diventare un grosso problema. Activerecord però è nato sui
relazionali e forse è meglio aspettare qualcosa creato ad hoc?
@Emanuele DelBono
Non ho capito la questione dei danni a proposito degli orm, a cosa ti
riferisci?
2012/5/15 Marco M. [email protected]:
Io non ho esperienza diretta anche se mi piacerebbe approfondire. Quali
sono le differenze tra i relazionali ed i nosql? Queste quelle che mi
vengono in mente:
- scalabilit
- prestazioni
- ridondanza
- sicurezza
- integrit
- utilizzo
FWIW, se intendevi che queste sono possibili “dimensioni” per
differenziare relazionali o no, direi che non funzionano (posso dare
esempi di sql o non sql con si/no per tutti i casi).
Come dimensioni per cui valutare invece chiaramente si.
Per non direi che ci voglia un ORM se non si relazionali (beh a
parte che sarebbe un O*M
Io in passato ho lavorato con cassandra avendo fatto un layer DAO
abbastanza classico a mano mi son trovato bene.
Oltretutto activerecord+migration di default praticamente uguale a
usare un database documentale: ogni tabella un lista di hash, la
validazione applicativa e i riferimenti tra tabelle vengono generati
senza foreign key/integrit referenziale.
O cambiato qualcosa ultimamente e me lo sono perso?
–
twitter: @riffraff
blog (en, it): www.riffraff.info riffraff.blogsome.com
work: circleme.com
2012/5/15 Marco M. [email protected]
All’atto pratico dici? Perch i primi hanno struttura fissa. Io da
quando uso rails non sfrutto pi le caratteristiche per l’integrit sul
db, ho tanti vantaggi tra cui il diretto controllo mentre se li usassi
sul db devo sempre passare da un sistemista. Ovviamente per bisogna
utilizzare rake per le operazioni batch altrimenti si avrebbero i
problemi di cui accennavo prima. Le prestazioni per sono ben diverse e
mi fermo qu che gli argomenti da discutere sarebbero tantissimi.
beh, in quest’ultimo caso ci sarebbe DataMapper, di cui dovrebbe uscire
la
versione 2.0, se la scelta un DB Sql relazionale mi pare una scelta
molto
adatta.
–
Riccardo
L’esperienza quello che ottieni quando, non ottieni quello che
desideri.
FWIW, se intendevi che queste sono possibili “dimensioni” per
differenziare relazionali o no, direi che non funzionano (posso dare
esempi di sql o non sql con si/no per tutti i casi).
ho fatto di tutta l’erba un fascio per non perderci nei dettagli,
secondo te non sono elementi che differiscono la macro categoria “nosql”
dai relazionali?
Per non direi che ci voglia un ORM se non si relazionali (beh a
parte che sarebbe un O*M
Chiedo scusa, in realtà mi stavo riferendo all’intero pacchetto rails,
si è trattato di un lapsus. Senza un framework come rails che gestisce
cose che normalmente si gestisce un database sarebbe difficoltoso:
validazioni, dipendenze, observer (trigger) ecc.
Io in passato ho lavorato con cassandra avendo fatto un layer DAO
abbastanza classico a mano mi son trovato bene.
Interessante
Oltretutto activerecord+migration di default praticamente uguale a
usare un database documentale: ogni tabella un lista di hash, la
validazione applicativa e i riferimenti tra tabelle vengono generati
senza foreign key/integrit referenziale.
O cambiato qualcosa ultimamente e me lo sono perso?
All’atto pratico dici? Perchè i primi hanno struttura fissa. Io da
quando uso rails non sfrutto più le caratteristiche per l’integrità sul
db, ho tanti vantaggi tra cui il diretto controllo mentre se li usassi
sul db devo sempre passare da un sistemista. Ovviamente però bisogna
utilizzare rake per le operazioni batch altrimenti si avrebbero i
problemi di cui accennavo prima. Le prestazioni però sono ben diverse e
mi fermo quà che gli argomenti da discutere sarebbero tantissimi.
Danni forse una parola spropositata, ma la mia sensazione che gli
ORM sono nati con l’idea di colmare il gap tra il mondo relazionale e
il mondo ad oggetti e non ci sono riusciti fino in fondo. La soluzione
al problema non certo banale e l’introduzione di un ORM semplifica
alcune cose e ne complica altre (performance, mapping difficili,
dominio dipendentende dallo schema, compromessi).
Invece i DB no-sql (sembra) che risolvano bene questo problema: ho un
grafo lo “butto” nello store. Fine. Il problema disegnare bene i
grafi (aggregati) per questo DDD ci aiuta molto.
ema
2012/5/15 Marco M. [email protected]: