NosqlDay
25 - 26 Mar 2011 at Novotel

d'accordo con stefano su tutto

Ho apprezzato molto l'approccio con cui sono state descritte le scelte progettuali "opinionate" di couch.
A mio parere ottimo il bilanciamento tra descrizione delle caratteristiche di couch (parte + teorica) e esempio di codice (+ pratica).
Mi sarebbe piaciuto, ma effettivamente di tempo non ce n'era molto, avere una panoramica + completa sulle feature disponibili (e mancanti) nelle couchapps servite da futon.

dlondero+3

Personalmente, concordo pienamente con entrambi. Con questo voglio dire che pur essendo vero che il talk è sembrato una marketta è anche vero che il suo scopo principale non era quello. Come ha detto Alberto, mostrare l'architettura piuttosto che l'intero flusso (e mi riferisco anche alla semplicità della slide in cui si tenta di mostrarlo) nasce dal fatto che i logs essendo così diversi tra di loro non permettono una spiegazione generale sul processamento/interpretazione che gli raggruppi.

D'altra parte vorrei anche far notare che l'utilizzo di mongodb come ha ben precisato Gabriele nel suo talk e come ha anche citato Alberto nel suo commento, richiede a tutti i costi un refactoring degli applicativi nonché di tutta l'architettura e modelli ed è per questo (ancora una volta) che vengono citate le soluzione interne (e mi riferisco a quelle create in azienda e rilasciate Open Source) che sono state utilizzate dentro l'architettura (stack interno di sfoftware e librerie) con le quali siamo riusciti ad evitare questa necessità di refactoring adottando la soluzione consigliata anche da Salvatore che è quella di modificare il layer di estrazione dati e far si che soddisfi quello business.

Veramente mi dispiace la strada che ha preso il talk e sopratutto l’impressione che ha lasciato in tutti dato che la mancanza di tempo (per errore nostro) ci ha penalizzati ed ha fatto si che la parte più tecnica (intendo dire quella che spiegava più in dettaglio il come e perché delle soluzioni adottate) no sia stata portata avanti nella maniera giusta e pur sapendo che questa non è la soluzione a ciò che è successo metto a disposizione il mio indirizzo email e contatto skype dove potete contattarmi liberamente per chiedere qualsiasi informazione riguardante a ciò che è mancato o vi aspettavate del talk (risponderò tutto ciò che il mio contratto permetta).

Ad ogni modo, colgo anche l’occasione per proporre un nuovo evento, meeting, “pirlo” (aperitivo) in cui potremmo discutere approfonditamente su i dettagli delle architetture destinate a gestire grossi moli di dati senza tralasciare la possibilità di ricerca e facile accesso ad essi.

flaper87 su skype
flaper87 chiocciola flaper87 punto org

P.S: Ho create un gruppo[0] anche su convore per discutere su nosql e le soluzioni esistenti per problemi reali basate su nosql

[0] https://convore.com/nosql-it/

Accetto le critiche e vorrei fare un paio di chiarimenti, poichè spesso ci sono delle incomprensioni.
Il nostro obiettivo era fornire delle idee e soluzioni per "vere" che abbiamo incontrato/sviluppato e sono in produzione con una serie di "consigli" su come sopravvivere all'integrazione di prodotti NoSql.
Se riguardi le slide (titoli "self note" e ricette Problemi/Soluzioni alla fine) vedrai una serie di problemi e soluzioni, che ti aiutano a scalare e evitare tranelli nella gestione dei dati.
Il nostro concetto di trasferimento di informazioni era mirato a fare capire che le soluzione NoSQl non sempre sono la soluzioni ai problemi e tal volta come altri speaker hanno detto più volte "la soluzione NoSQL te la sposi". Ciò implica che occorre avere profonda conoscenza di tali strumenti perché:
- sono carenti ("Some base functionalities, but a lot of missing features")
- le necessità di sviluppo/utilizzo nella pratica spesso si discostano da quelli dalla vision di chi li ha progettati ("There are divergent choices between developers and the company’s needs")
- quante volte gli altri speakers hanno detto che non solo la soluzione a tutto ("There’s no any “Best NoSQL Solution” at all")

Tutto dipende dalla posizione nel famoso grafico che è stato più volte mostrato da Lana. Noi (io, Flavio e gli altri miei compagni di lavoro) per costrizioni e tempi siamo dopo la delusione: siamo nel punto in cui facciamo funzionare le cose, abbiamo vivisezionato i tools (io elasticsearch, Flavio mongodb), abbiamo appreso i pregi delle architetture ed i loro difetti, come "le cose funzionano".
Non capisco la frase "ecco, questo l'abbiamo fatto noi; ma non lo rilasciamo Open Source", visto che abbiamo presentato per prima cosa i progetti che noi stessi abbiamo rilasciato per la comunità e che sono usati da molti. Esistono diversi motivi per cui invece altro codice non è stato rilasciato alla comunità quali:
- materiale copyright delle azienda (spetta al proprietario dell'azienda la decisione e non a noi: lui ci paga gli stipendi)
- io parlo frequentemente con Shay Banon: l'autore di ElasticSearch e certe feature che abbiamo implementato in azienda sono rischiose per gli "utonti" che userebbero il sistema (ElasticSearch è basato su Lucene: sai ciò che implica).
- altre sono talmente custom che altri non se ne farebbero niente (legate troppo alle strutture dati aziendali LDAP, Databases, ...)
Il nostro spirito è sempre di poter condividere con la comunità se no non avremmo mai condiviso così tanti progetti su mongodb e ES. Se gestisci progetti su codice opensource sai l'importanza sulla mantenibilità e come essa passi dallo sharare il codice.

Sulla parte dei log, abbiamo preferito parlare dell'architettura, delle lezioni imparate, di come approcciarsi al mondo NoSQL; piuttosto che mostrarti come interpretiamo un log di Apache. Abbiamo avuto un approccio più sul mostrare come poterlo fare a livello di tools, che sul come farlo fisicamente il codice.

Il tempo è stato tiranno, forse sarebbe stato necessario fare due talk.

Per quanto riguarda XML vs JSON, nella gestione dei dati, il mondo va verso il JSON per vari fattori: compatezza, idempotenza con XML, performance in parsing/writing. Negli anni precedenti, c'era il processo che tutti i dati erano strutturati, XML, ora JSON e YAML è evoluzione. Senza dubbio a parte vari settori (Semantica), XML può essere usato idempotente a JSON: e viene usato JSON, lo dimostrano il fatto che tutti i nuovi sistemi NoSQL usano JSON come base. I dati sono JSON.

Purtroppo hai perfettamente ragione sul fatto che sul "cercare di tenere maggiormente in considerazione le attese e le aspettative della platea", ma non conoscevamo le aspettative della platea e ci aspettavamo che fossero a conoscenza degli argomenti trattati ed avessero un minimo di esperienza in questi ambienti (parte in cima ed almeno in discesa della curva della delusione).
Spero che le soluzioni ed il nostro talk sia servito almeno a far capire che "There’s no any “Best NoSQL Solution” at all".

La cosa che mi è sembrata strana è che nessuno mi abbia mai chiesto niente di elasticsearch (http://www.elasticsearch.org/) ma magari se la curiosità ti stuzzica visita il siti http://blog.mozilla.com/data/2010/12/30/flume-hive-and-realtime-indexing-via-elasticsearch-2/ e il risultato http://glow.mozilla.org/
Per le architetture e la loro scalabilità: http://highscalability.com/

MongoDB map/reduce: http://stackoverflow.com/questions/2794377/mongodb-whats-the-point-of-using-mapreduce-without-parallelism
L'attuale stato è che se chiedi a 10gen ti consigliano di evitare il map/reduce se hai tanti dati. Io personalmente ho provato a sostituire V8 a spidermonkey, ma senza risultati. Nessuno nei talk ha parlato di ciò e di come tenendosi gli indici in memoria le macchine devono essere carozzate di memoria e tante! (Una configurazione safe sono 9 macchine 3x3 con shard).

Scusami per la risposta lunga e se hai bisogno di chiarimenti sono a tua disposizione.

@EdMcBane grazie per le tue critiche. In effetti hai ragione, avrei dovuto almeno presentare un caso di studio verosimile per inquadrare la soluzione. Pero' i requisiti non funzionali di crescita verso milioni di utenti, picchi di richieste, replica/shard, bassi costi di sviluppo e bassi costi di manutenzione sono stati presentati e sono quelli che ci hanno guidato nella scelta di mongodb.

Per quanto riguarda il keep it simple ovvero l'aver introdotto Solr anche se lo stiamo usando solo parzialmente, hai perfettamente ragione. Probabilmente avremmo potuto evitarlo e forse dovremmo pensare proprio di rimuoverlo dall'architettura e scegliere, quando c'e' ne sara' bisogno, lo strumento adatto ai nostri scopi.

grazie ancora per il tuo risconto :)

Il contenuto, per chi non conosce Couch, è sicuramente interessante; forse sarebbe stato utile (avendo un po' di tempo in più) approfondire la tematica del map/(re)reduce.

L'introduzione l'ho trovata troppo assertiva, avrei preferito maggiore "cautela" nel contrapporre couchApp e applicazione "tradizionale"/MVC. L'approccio mi ha ricordato molto quello di Joe Armstrong quando parla di Erlang.

Brillante, chiaro, coinvolgente.
Complimenti!

Con tutto il rispetto per lo speaker, io sono rimasto molto perplesso dal questo intervento.
Descrivere una architettura senza indicarne lo scopo è, a mio parere, inutile, sbagliato e fuorviante.
Scegliere, progettare una architettura richiede di valutare, nel contesto degli obiettivi e dei vincoli di progetto, pro e contro delle possibili soluzioni, tecnologie, approcci.

Descrivere la soluzione senza parlare del problema è come dare una risposta senza indicare la domanda.
Dopo il talk non ho modo di concordare o dissentire con le scelte proposte, non ho elementi per farlo.

Un'altro cosa che mi ha fatto storcere il naso è stato che, più di una volta, si è detto "Questo lo abbiamo messo qui, per ora non è utilizzato e dobbiamo vedere come lo useremo"; questo va contro diversi principi universalmente riconosciuti ("Keep it simple", "You ain't gonna need it", "Delay commitment").
Il mondo dei NoSQL è giovane e complesso, credo sia fondamentale affrontarlo un passo alla volta e in risposta a necessità chiare e precise; come ha detto Salvatore Sanfilippo, molti di quelli che ora usano un NOSQL avrebbero in realtà bisogno di un database relazionale.

Interessante proposta implementativa, presentata con chiarezza; e soprattutto in modalità FOR REAL. Auguro ogni successo al progetto italiano!