Forum: Italian Ruby user group Database non-SQL, Redis, CouchDB, Mongo,..

Non è una domanda strettamente legata a ruby, ma vorrei sapere se
qualcuno di voi li usa, con che framework e per cosa.

Tnx

uso MongoDB su di una piattaforma verticale (in produzione) presso un
cliente; il back end e' formato da processi scritti principalmente in
C++ e Ruby, mentre il front end e' fatto con Rails (sistema operativo
linux). Il size "gestito" e' di circa 200 MB in crescita.


Ciao Roberto

Usiamo MongoDB su due progetti:

- Un progetto usa pesantemente Hive & Hadoop > le query sono su una mole 
di dati molto grande, usano map reduce e quindi non sono real time, 
MongoDB cattura i risultati di alcune query su hive usando il gem mongo, 
nient'altro

- Le applicazioni che fanno girare le query su hive hanno la loro 
configurazione su MongoDB, come sopra, nessuna gem in particolare, la 
mongo

- Vantaggi:
* Slegati completamente dal DB
*niente migrations
*massima flessibilita': se qualcuno cambia le query in hive, il report 
automaticamente aggiunge le nuove info (colonne) sul doc mongo

- Mhmm non sono ancora convinto:
* La command line di mongo... ok e' javascript ma non e' il massimo
* le api di mongo-ruby, pochi esempi, a volte si deve scrivere un po' di 
javascript per ottenere i result set (group by per esempio!)

CMQ molto, molto entusiasta al momento!

On Tue, 31 Aug 2010 18:15:28 +0200
"Luigi Maselli - grigio.org" <riccio@inmail.sk> wrote:

> Non è una domanda strettamente legata a ruby, ma vorrei sapere se
> qualcuno di voi li usa, con che framework e per cosa.

Ultimamente in Alca abbiamo sviluppato una soluzione basata su Redis
per fotografare lo stato (che cambia piuttosto spesso) di una serie di
client voip.

In precedenza abbiamo usato CouchDB, ma la scelta aveva dei limiti
legati alla velocità con cui i dati cambiavano; con Redis tutto si è 
risolto ed andremo in produzione a giorni.

L'approccio è stato molto differente rispetto alle usuali tabelle SQL,
ma niente di trascendente.

Qui puoi trovare della documentazione che abbiamo scritto per fare una
specie di resoconto di quello che abbiamo imparato:
http://labs.alcacoop.it/doku.php?id=articles:redis_land


Ciao,
Nico

Aggiungo la mia...

Stiamo utilizzando Redis (con il mapper Ohm) per l'estrazione di dati
e generazione di report/query complesse da un tool (PolarionALM) per
la "gestione dei progetti" (è un leggero abuso di linguaggio ma rende
grossolanemente l'idea).

Il principale vantaggio: slegati completamente dalle migration.

PS: per chi volesse approfondire
http://carlopecchia.eu/blog/2010/07/30/place-released.

Il 01 settembre 2010 01:30, Domenico Delle Side <nico@delleside.org> ha 
scritto:
> In precedenza abbiamo usato CouchDB, ma la scelta aveva dei limiti
> Ciao,
> Nico
> _______________________________________________
> Ml mailing list
> Ml@lists.ruby-it.org
> http://lists.ruby-it.org/mailman/listinfo/ml
>



--
Carlo Pecchia
email: c.pecchia@gmail.com
twitter: @carlopecchia

Luigi Maselli - grigio.org wrote:
> Non è una domanda strettamente legata a ruby, ma vorrei sapere se
> qualcuno di voi li usa, con che framework e per cosa.
> 
> Tnx

Ho usato CouchDB e MongoDB in passato, ma preferisco CouchDB.
nel mio blog ( www. rublings.com ) trovi una semplice introduzione 
all'utilizzo (4 articoli) , e devo ancora scriverne altri.

Wow.. non credevo che ci fossero già così tanti utilizzi.

Grazie a tutti per aver condiviso le vostre esperienze tecniche in 
merito (e in italiano :P).

Riesumo la discussione aggiungendo un caso concreto, come realizzereste 
una relazione di amicizia (m-n alla twitter) con un db NO/SQL?

Finora ho trovato questi spunti interessanti che sostanzialmente di 
conocose opposte.

http://www.bencurtis.com/2010/08/excessive-use-of-redis/
http://www.engineyard.com/blog/2010/pragmatic-polyglot-persistence-with-rails/

Generalmente, le relazioni n-m si rendono in redis utilizzando 2 
insiemi.

Ad esempio, nel caso della relazione libri-autori spiegata in
http://labs.alcacoop.it/doku.php?id=articles:redis_land, per ogni libro 
si
ha un insieme book:ID:authors, che contiene gli id degli autori del 
libro
con id ID, mentre per ogni autore esiste un insieme author:ID:books che
contiene gli id di tutti i libri scritti dall'autore in questione.

Il caso delle relazioni di amicizia non dovrebbe essere molto 
differente.


Ciao,
Nico

Il giorno 11 settembre 2010 22:28, Luigi Maselli - grigio.org <
riccio@inmail.sk> ha scritto:

Secondo me la struttura dati ideale per Twitter è un grafo direzionale,
perché il la relazione tra due persone non è implicitamente bidirezionale.

@jodosha follows @user

è differente da:

@user follows @jodosha

Su InfoQ c'è un ottimo articolo a riguardo:
http://www.infoq.com/articles/graph-nosql-neo4j

Luca

Twitter usa ancora un altro db NOSQL per gestire le connessioni, è 
flockdb
http://github.com/twitter/flockdb

Stando alla documentazione, per sapere se la connessione è reciproca 
fanno un'intersezione tra chi segui e chi ti segue (1 è l'id utente).
flock.select(1, :follows, nil).intersect(nil, :follows, 1).to_a
Su Facebook invece, non dovrebbero fare nessuna intersezione visto che è 
una connessione reciproca a priori.

Ci sono davvero tante "variabili" in gioco valutare la scelta migliore.

Luca Guidi wrote:
> Secondo me la struttura dati ideale per Twitter � un grafo direzionale,
> perch� il la relazione tra due persone non � implicitamente bidirezionale.
> 
> @jodosha follows @user
> 
> � differente da:
> 
> @user follows @jodosha
> 
> Su InfoQ c'� un ottimo articolo a riguardo:
> http://www.infoq.com/articles/graph-nosql-neo4j
> 
> Luca

quello che dici è vero, ma non è un problema con redis, perchè nella
lista dei followers di @jodosha c'è @user, ma non è detto che tra i
followers di @user ci sia @jodosha

ciao,
A.



Il 12/09/2010 20:05, Luca Guidi ha scritto: