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 M. - grigio.org” [email protected] 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
Luigi M. - 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.
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
Place released.
Il 01 settembre 2010 01:30, Domenico Delle S. [email protected] ha
scritto:
In precedenza abbiamo usato CouchDB, ma la scelta aveva dei limiti
Ciao,
Nico
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
Carlo P.
email: [email protected]
twitter: @carlopecchia
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/
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).
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 M. - grigio.org <
[email protected]> 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:
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 G. ha scritto:
Twitter usa ancora un altro db NOSQL per gestire le connessioni, è
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 G. 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:
Graph Databases, NOSQL and Neo4jLuca