Forum: Italian Ruby user group cassandra

Ho letto in un post che Twitter sta progettando di abbandonare mysql in
favore di cassandra.
Mi chiedevo se in futuro può diventare lo standard per tutte le
applicazioni Rails...

> Ho letto in un post che Twitter sta progettando di abbandonare mysql in
> favore di cassandra.
> Mi chiedevo se in futuro può diventare lo standard per tutte le
> applicazioni Rails...

Twitter ha esigenze molto lontane dalla maggior parte delle applicazioni 
Rails.

BTW, per un sistema simile a Cassandra "Made in Italy", c'e` Redis:

http://code.google.com/p/redis/

Non l'ho ancora provato.

--
David N. Welton

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

http://www.dedasys.com/
Sent from Padova, PD, Italy

2010/2/24 Marco Dal toè <marco.daltoe@valdoweb.com>

> Ho letto in un post che Twitter sta progettando di abbandonare mysql in
> favore di cassandra.
> Mi chiedevo se in futuro può diventare lo standard per tutte le
> applicazioni Rails...
>
>
Mi sembra veramente improbabile! i database non relazionali, non ACID,
distribuiti, big table, etc etc saranno anche una figata ma solo in
determinati contesti molto poco standard come infrastruttura elastica,
migliaia di richieste al secondo da tutto il mondo e cose del genere..
insomma una gestione di magazzino o un cms ha esigenze "leggermente" 
diverse
rispetto a twitter o fb o amazon, dove temo che i db relazionali 
resteranno
fra le scatole per un altro bel po' di tempo... dico fra le scatole 
perche'
comunque tutta la storia dell'ORM a me non convince piu' di tanto, visto 
che
si programma ad oggetti sarebbe il caso di eliminare questa necessita' 
di
trasformare gli oggetti stessi in qualcosa di completamente diverso per
persisterli.. pero' qualche tempo fa' diedi un'occhiata a degli object 
db
per smalltalk e mi sembravano un po' dei giocattoli se non addirittura
accrocchi, mentre incuriosito da questo post ho fatto una googlata su
eventuali object db ruby e mi pare che la situazione sia ancora piu'
triste.. c'e' qualcosa di interessante che mi e' sfuggito?

Marco Dal Toe' wrote:
> Ho letto in un post che Twitter sta progettando di abbandonare mysql in
> favore di cassandra.
> Mi chiedevo se in futuro può diventare lo standard per tutte le
> applicazioni Rails...

Dall'articolo che ho letto 
http://nosql.mypopescu.com/post/407159447/cassandra-twitter-an-interview-with-ryan-king 
sembra che a twitter importi soprattutto poter scalare le write senza 
preoccuparsi che le read riportino subito quel che c'è nel db.

Ossia: l'importante è che gli status siano memorizzati e che si possano 
aggiungere N db server con facilità. Non è invece importante che gli 
status siano visibili subito, magari neppure da chi li scrive.

Questo in generale non è quello che serve nella maggior parte delle 
applicazioni, sia perché il traffico è risibile rispetto a quello di 
twitter sia perché se il cliente inserisce un ordine e non lo vede 
subito nell'elenco lo considera giustamente un bug :-)

Tuttavia sto guardando cassandra perché per un'applicazione di data 
logging potrei avere requisiti simili a quelli di twitter anche se per 
il traffico che ci sarà un db relazionale sarebbe più che sufficiente.

Ho l'impressione però che db come Cassandra siano difficilmente 
accessibili con ActiveRecord.
Ho visto http://github.com/NZKoz/cassandra_object che prova a renderlo 
compatibile con AR mentre il client usato da twitter 
http://github.com/jamesgolick/cassandra usa un'interfaccia del tutto 
diversa. Riporto l'esempio:

  client = Cassandra.new('twitter', '127.0.0.1', 9160)
  client.insert(:UserRelationships, "5", {"user_timeline" => {UUID.new 
=> "1"}})
  client.get(:UserRelationships, "5", "user_timeline")


Paolo

On 24/02/2010 11:10, Marco Dal toè wrote:
> Ho letto in un post che Twitter sta progettando di abbandonare mysql in
> favore di cassandra.
> Mi chiedevo se in futuro può diventare lo standard per tutte le
> applicazioni Rails...
>    
come hanno già detto, è abbastanza improbabile diventi addirittura uno
"standard" per rails, anzi, sembra che la direzione di rails sia proprio
quella di separarsi dalle "scelte obbligate" per diventare più modulare
ed indipendente possibile.

negli ultimi 2 anni sono nati una serie di db non-relazionali per
rispondere ad altri tipi di esigenze, specie nel web. Cassandra è uno di
questi, così come Redis e molti altri. I principali approcci, al momento
sono due: i key-value stores (redis, cassandra) ed i document-oriented
(mongodb, couchdb); ne esistono altri dei quali non ricordo il nome :P

per quanto mi riguarda, ho solo *giocherellato* con Redis in locale, e
devo dire che l'ho trovato interessante ;)

Ovviamente, come tutti gli strumenti, ci sono campi di applicazione dove
i db nosql *possono* rendere meglio rispetto alle controparti sql.

in ogni caso, tanto per farti qualche idea, prova a leggere questo blog
dedicato all'argomento: http://nosql.mypopescu.com/


ciao,
a.

Postgresql è nato come db ad oggetti.
Ora alla versione 8.4 non saprei.


Ciao Michele.

2010/2/24 Michele Casari <lablinux@gmail.com>

> Postgresql è nato come db ad oggetti.
> Ora alla versione 8.4 non saprei.
>
>
In effetti sul sito dicono che e' object-relational (definizione che ho
sempre pensato fosse stata inventata da qualcuno che si occupava di
marketing e che ha a che vedere con il fatto di supportare 
l'ereditarieta'
fra le tabelle) ... ma mentre un db object-relational dovrebbe ridurre 
il
gap fra il mondo degli oggetti e quello del loro essere resi 
persistenti, un
db ad oggetti lo dovrebbe eliminare... ovvero rendere superfluo 
l'utilizzo
di un livello di traduzione fra i due mondi, livello comunemente noto 
come
ORM.

Andrea Pavoni wrote:
> in ogni caso, tanto per farti qualche idea, prova a leggere questo blog
> dedicato all'argomento: http://nosql.mypopescu.com/
> 
> 
> ciao,
> a.

Molto interessante...non sapevo che esistesse addirittura un "movimento" 
a favore dei database non relazionali!

Proverò a seguirlo ed a sperimentare anch'io, magari cercando qualcosa 
che sia già ben integrato con rails e activerecord.
Grazie!

Il 24 febbraio 2010 13.24, Marco Dal Toe' <marco.daltoe@valdoweb.com>
ha scritto:
> Molto interessante...non sapevo che esistesse addirittura un "movimento"
> a favore dei database non relazionali!
>
> Proverò a seguirlo ed a sperimentare anch'io, magari cercando qualcosa
> che sia già ben integrato con rails e activerecord.

Qualcosa c'è per mongo:

http://railscasts.com/episodes/194-mongodb-and-mongomapper

Mi piacerebbe provare qualcuno di questi giocattoli non relazionali
per un'applicazione che ho in mente, prima o poi.


pietro

)
On 24/02/2010 13:24, Marco Dal Toe' wrote:
> Molto interessante...non sapevo che esistesse addirittura un "movimento"
> a favore dei database non relazionali!
>    
anche su twitter, cercando 'nosql' trovi molto materiale ;)

> Proverò a seguirlo ed a sperimentare anch'io, magari cercando qualcosa
> che sia già ben integrato con rails e activerecord.
> Grazie!
>    
da quanto ne so, esistono un bel po' di progetti/librerie in ruby per i
vari db. per quanto riguarda redis, c'è il client
http://github.com/ezmobius/redis-rb ,
poi una libreria simile ad ActiveRecord chiamata Ohm
http://ohm.keyvalue.org/ . Questi sono quelli che ho provato
personalmente, ma ce ne sono altre dozzine (sempre ruby) che
meriterebbero un approfondimento.

uno che prima o poi vorrei provare è redis-store (
http://github.com/jodosha/redis-store) per gestire il cache, scritto da
Luca Guidi ;)

è proprio il caso di dire che *c'è da farsi una cultura a parte* su
questo argomento :P

ciao,
A.

Il 24 febbraio 2010 14.13, Andrea Pavoni <apeacox@gmail.com> ha scritto:
> da quanto ne so, esistono un bel po' di progetti/librerie in ruby per i
> vari db. per quanto riguarda redis, c'è il client
> http://github.com/ezmobius/redis-rb ,
> poi una libreria simile ad ActiveRecord chiamata Ohm
> http://ohm.keyvalue.org/ . Questi sono quelli che ho provato
> personalmente, ma ce ne sono altre dozzine (sempre ruby) che
> meriterebbero un approfondimento.

Il mio dubbio (che una googlata veloce non ha risolto) è: come si
comportano questi aggeggi in situazioni che potrebbero essere gestite
benissimo con un db relazionale vecchio stampo? Offrono
prestazioni/affidabilità paragonabili ai db oppure sono da considerare
utili solo per situazioni particolari?


pietro

Lupus in fabula, hanno appena pubblicato una interessante intervista al
creatore di Redis su ossblog:
<http://www.ossblog.it/post/5835/salvatore-antirez-sanfilippo-intervista-allo-sviluppatore-di-redis?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+Ossblog/it+%28ossblog%29>
http://www.ossblog.it/post/5835/salvatore-antirez-sanfilippo-intervista-allo-sviluppatore-di-redis

ciao,
a.

On 24/02/2010 14:19, Pietro Giorgianni wrote:
> Il mio dubbio (che una googlata veloce non ha risolto) è: come si
> comportano questi aggeggi in situazioni che potrebbero essere gestite
> benissimo con un db relazionale vecchio stampo? Offrono
> prestazioni/affidabilità paragonabili ai db oppure sono da considerare
> utili solo per situazioni particolari
in teoria, questi *aggeggi* sono molto più performanti dei normali db,
basti pensare che Redis lavora tutto in RAM (ma salva comunque su
disco). chiaramente cambiano anche un po' i pattern per organizzare i
dati. quest'ultimo aspetto, almeno per me, è stato abbastanza
*scioccante*, ed ancora non entro bene nell'ottica del lavorare 'senza
schemi' :P

sul wiki di redis, c'è un esempio che riproduce un semplice clone di
twitter (una versone php, e una ruby/sinatra), tanto per farti un'idea 
:)

continuo a presumere che, per un classico gestionale, un db relazionale
rimanga comunque la scelta migliore, già solo in termini di sbattimento
per imparare a gestire un altro tipo di db.

ciao,
a.

> Il mio dubbio (che una googlata veloce non ha risolto) è: come si
> comportano questi aggeggi in situazioni che potrebbero essere gestite
> benissimo con un db relazionale vecchio stampo? Offrono
> prestazioni/affidabilità paragonabili ai db oppure sono da considerare
> utili solo per situazioni particolari?


MongoDB <http://www.mongodb.org/display/DOCS/Home> hce seguo da tempo ma 
non
ho mai utilizzato, è in produzione su diversi progetti "reali" (una tra le
tante è get.harmonyapp.com) e chi lo utilizza ne è più che felice. Per
quanto ne so database nosql sono "generalmente" più veloci nelle prestazioni
e facilmente scalabili su più server. MongoDB, CouchDB, Redis e molto altri
ne fanno parte (anche se a sua volta possono far parte di sottocategorie 
più 
specifiche)

Per Ruby librerie come 
MongoMapper<http://github.com/jnunemaker/mongomapper>o
MongoID <http://mongoid.org/> permettono una buona gestione delle 
relazioni,
validazioni, callback, etc come fa activerecord per DB relazionali come
SQLite e MySQL. Il vantaggio è una maggiore flessibilità, che non sempre è 
richiesta, ma che per alcuni progetti è fondamentale. No migrazion, 
aggiunta
dinamica di "campi" e di capacità di ricerca tra i vantaggi che si
ottengono.

--
Andrea Reginato, http://mikamai.com
Writing http://sensejs.wordpress.com/
Collaborating http://therubymine.it
Reading http://stacktrace.it

Pietro Giorgianni ha scritto:
> Il mio dubbio (che una googlata veloce non ha risolto) è: come si
> comportano questi aggeggi in situazioni che potrebbero essere gestite
> benissimo con un db relazionale vecchio stampo? Offrono
> prestazioni/affidabilità paragonabili ai db oppure sono da considerare
> utili solo per situazioni particolari?

Da un po' di tempo, in Alca stiamo pensando di usare redis per risolvere
un problema di un nostro cliente, che deriva proprio dall'utilizzo di un
database relazionale (mysql).

Questo articolo potrebbe risultare interessante:
http://adamblog.heroku.com/past/2009/7/8/sql_databases_are_an_overapplied_solution_and_what_to_use_instead/

Ciao,
Nico

Il 24 febbraio 2010 14.59, Domenico Delle Side <nico@delleside.org> ha 
scritto:
> Da un po' di tempo, in Alca stiamo pensando di usare redis per risolvere
> un problema di un nostro cliente, che deriva proprio dall'utilizzo di un
> database relazionale (mysql).
>
> Questo articolo potrebbe risultare interessante:
> http://adamblog.heroku.com/past/2009/7/8/sql_databases_are_an_overapplied_solution_and_what_to_use_instead/

grazie per il link, lettura molto istruttiva. devo proprio trovare il
tempo di sperimentare un po' di queste soluzioni!


pietro

Pietro Giorgianni ha scritto:
> Il 24 febbraio 2010 14.59, Domenico Delle Side <nico@delleside.org> ha scritto:
>> Da un po' di tempo, in Alca stiamo pensando di usare redis per risolvere
>> un problema di un nostro cliente, che deriva proprio dall'utilizzo di un
>> database relazionale (mysql).
>>
>> Questo articolo potrebbe risultare interessante:
>> http://adamblog.heroku.com/past/2009/7/8/sql_databases_are_an_overapplied_solution_and_what_to_use_instead/
> 
> grazie per il link

E' il mitico ripley che li tira fuori dal cilindro come fossero
coniglietti! :-)

Ciao

2010/2/24 Luca De Marinis <loop@interact.it>:
> determinati contesti molto poco standard come infrastruttura elastica,
> migliaia di richieste al secondo da tutto il mondo e cose del genere..

non è detto, "nosql" in realtà non vuol dire granché, tanti di questi
(redis, tokyo tyrant, couchdb) hanno le stesse caratteristiche ACID di
un db sql ma interfacce diverse. Ma ovviamente il discorso rimane
valido :)

> insomma una gestione di magazzino o un cms ha esigenze "leggermente" diverse
> rispetto a twitter o fb o amazon, dove temo che i db relazionali resteranno
> fra le scatole per un altro bel po' di tempo...

amen

> dico fra le scatole perche'
> comunque tutta la storia dell'ORM a me non convince piu' di tanto, visto che
> si programma ad oggetti sarebbe il caso di eliminare questa necessita' di
> trasformare gli oggetti stessi in qualcosa di completamente diverso per
> persisterli.. pero' qualche tempo fa' diedi un'occhiata a degli object db
> per smalltalk e mi sembravano un po' dei giocattoli se non addirittura
> accrocchi, mentre incuriosito da questo post ho fatto una googlata su
> eventuali object db ruby e mi pare che la situazione sia ancora piu'
> triste.. c'e' qualcosa di interessante che mi e' sfuggito?


io ho grandi aspettative per maglev(1), soprattutto perché la società 
che lo sviluppa in realtà è produttrice di un object db (gemstone) che
a detta di amici rubyisti/smalltalker è fantastico :)

(1) http://ruby.gemstone.com/

2010/2/24 gabriele renzi <rff.rff@gmail.com>


> > triste.. c'e' qualcosa di interessante che mi e' sfuggito?
>
>
> io ho grandi aspettative per maglev(1), soprattutto perché la società
> che lo sviluppa in realtà è produttrice di un object db (gemstone) che
> a detta di amici rubyisti/smalltalker è fantastico :)
>
>
Lo sto' scaricando... sembra la cosa piu' fica del mondo! avevo sentito
parlare sommariamente di MagLev ma pensavo fosse solo una versione 
esoterica
di ruby che veniva compilato jit su un dialetto di smalltalk vm.. o 
qualcosa
del genere.. la parte  "integrated object persistence and distributed 
shared
cache" mi era sfuggita del tutto!

Grazie Gabriele!

Pietro Giorgianni wrote:
> grazie per il link, lettura molto istruttiva. devo proprio trovare il
> tempo di sperimentare un po' di queste soluzioni!

E' passato un bel po' di tempo, tuttavia la sperimentazione che stavamo 
conducendo in Alca è terminata con la scrittura di un articoletto 
didattico che spero possa interessarvi: 
http://labs.alcacoop.it/doku.php?id=articles:redis_land


Ciao,
Nico

Articolo molto carino anche se alla fine mi ha lasciato con l'acquolina 
in
bocca :D
Spero di vederne degli altri ;)

2010/4/22 Domenico Delle side <nico@delleside.org>

> Ciao,
> Nico
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Ml mailing list
> Ml@lists.ruby-it.org
> http://lists.ruby-it.org/mailman/listinfo/ml
>



--
Andrea Reginato, http://mikamai.com
Writing http://sensejs.wordpress.com/
Collaborating http://therubymine.it
Reading http://stacktrace.it