Forum: Italian Ruby user group mongodb.

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`.

http://www.mongodb-is-web-scale.com/

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

http://www.welton.it/davidw/

http://www.dedasys.com/

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 Welton <davidnwelton@gmail.com>

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 Pigozzi <stefano.pigozzi@gmail.com>

Qui ci sono delle slide e se cerchi c'é anche un video che parla di 
perché hanno migrato Diaspora da MongoDB a Mysql.
http://www.slideshare.net/sarahmei/taking-diaspora...

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 08/05/12 17:44, Stefano Pigozzi ha scritto:
> Qui, imho, uscir un flame.

Supporto la nascita del flame, cos  la volta buona che capisco quando
usare noSQL! :)

> 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

http://www.welton.it/davidw/

http://www.dedasys.com/

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: roberto@jabber.unbit.it

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 Maselli - grigio.org ha scritto:

Complemento citando l'approccio della "polyglot persistence"
http://martinfowler.com/bliki/PolyglotPersistence.html

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:

http://www.postgresql.org/docs/current/static/data...
http://www.postgresql.org/docs/current/static/hstore.html

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:

http://www.postgresql.org/docs/9.1/static/hstore.html

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.

a chi non l'avesse letto segnalo anche l'articolo molto interessante

http://martinfowler.com/bliki/OrmHate.html

Ciao,
--
gk

Infatti, l'articolo di Martin Fowler 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 Mastrodonato <m.mastrodonato@gmail.com>:
> 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

> 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.

2012/5/15 Marco Mastrodonato <m.mastrodonato@gmail.com>

>
> 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.

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 Mastrodonato <m.mastrodonato@gmail.com>:

2012/5/15 Marco Mastrodonato <m.mastrodonato@gmail.com>:
>> 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?

ni, per esempio:

> - scalabilit

Penso intenda scalabilit multi-macchina (senn il buon vecchio
exadata con 80 core e 2T di ram fa sempre la sua figura :)
Nel caso:
riak, cassandra, hbase: si
couchdb, redis (almeno finch non si materializza redis cluster): no
(o sharding che si fa anche con mysql).


> - prestazioni

dipende da cosa fai: se non usi join applicative o a seconda di come
configuri un db relazionale o no e dipendentemente se  ram-based o no
(e.g.  "mongodb tutto in ram senza ACK" vs voltdb).
Come contro esempio, Amazon SimpleDB  ha prestazioni abbastanza scarse.

> - ridondanza

ancora, dipende, per esempio neo4j e redis (da quel che mi ricordo)
supportano hot/cold spare come molti db sql "classici" ma non cose
fighe tipo dynamo.
Anche HBase da quel che mi ricordo poteva andare gi completamente se
moriva un region master, rispetto a riak che rimane allegro finch non
muoiono N(configurabile) nodi.

> - sicurezza

questa non son sicuro: sicurezza del server in se?
Autorizzazioni pi o meno fine grained? Forse si, nei db relazionali
sono comuni rispetto ai vari nosql.

> - integrit

vedi il discorso che facevo sul fatto che spesso i db relazionali non
vengono usati con vincoli di integrit.
O in casi (senza voler trollare) anche la definizione di "integrit"
abbastanza vaga, tipo mysql che mette maiuscole e minuscole insieme
negli indici, o fa truncate di nascosto invece di dare errore sui
varchar troppo lunghi etc etc

> - utilizzo

beh  chiaro :)


Insomma, se "nosql" significa "non un database sql" ce ne sono
talmente tanti che  difficile generalizzare.
Anche lucene e bdb alla fine sono dei database  nosql :)


>> 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.

Ah, capito, grazie.





--
twitter: @riffraff
blog (en, it): www.riffraff.info riffraff.blogsome.com
work: circleme.com