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.dedasys.com/
Sent from Padova, PD, Italy
2010/2/24 Marco Dal toè [email protected]
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
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 GitHub - NZKoz/cassandra_object: A library for persisting your objects into cassandra. che prova a renderlo
compatibile con AR mentre il client usato da twitter
GitHub - jamesgolick/cassandra: A Ruby client for the Cassandra distributed database. 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 
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 C. [email protected]
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 P. 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’ [email protected]
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:
Mi piacerebbe provare qualcuno di questi giocattoli non relazionali
per un’applicazione che ho in mente, prima o poi.
pietro
Il 24 febbraio 2010 14.13, Andrea P. [email protected] 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
GitHub - ezmobius/redis-rb: A Ruby client library for Redis ,
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+(ossblog)
ciao,
a.
)
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
GitHub - ezmobius/redis-rb: A Ruby client library for Redis ,
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 (
GitHub - redis-store/redis-store: Namespaced Rack::Session, Rack::Cache, I18n and cache Redis stores for Ruby web frameworks) per gestire il cache, scritto da
Luca G.
è proprio il caso di dire che c’è da farsi una cultura a parte su
questo argomento
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
MongoMapperhttp://github.com/jnunemaker/mongomappero
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 R., http://mikamai.com
Writing http://sensejs.wordpress.com/
Collaborating http://therubymine.it
Reading http://stacktrace.it
Pietro G. 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
On 24/02/2010 14:19, Pietro G. 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’
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 24 febbraio 2010 14.59, Domenico Delle S. [email protected] 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 G. ha scritto:
Il 24 febbraio 2010 14.59, Domenico Delle S. [email protected] 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 gabriele renzi [email protected]
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!
2010/2/24 Luca De Marinis [email protected]:
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
Pietro G. 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