Commenti al post Redis - REmote DIctionary Server

accoral scrive: Mi sembra molto interessante, mi guardo la parte client python, provo a vedere se risco a fare un connettore per FLEX
Luca M scrive: molto interessante, per un progetto di medie dimensioni lo scorso anno ho usato memcached per gestire delle code (con client in ruby), ma in quel caso la (non)persistenza non era un problema. Comunque una cosa come Redis sarebbe stata perfetta ;) Mi piacerebbe provarlo (magari posso testare o aiutare per il client ruby)
j scrive: sei un grande :)
antirez scrive: ah... cosi' per dovere di cronaca. Ieri ho perso una giornata appresso a redis perche' su Linux (testo sempre sia su Linux che Mac os X) accadeva una strana cosa. C'era un ritardo di alcuni millisecondi in ogni GET facendone una serie molto velocemente... il che lo rendeva lentissimo. Di norma fa tipo 15000 GET al secondo sul macbook, invece andava una merda. Al che ho detto, sara' certamente il nagle algorithm, con una botta di TCP_NODELAY me ne esco. Ho chiamato subito la lib che uso per queste cose di networking che mi sono scritto una volta per tutte N anni fa, ma niente da fare. E dire che il problema sembrava quello... dopo N ore di debugging (accavallato da N ore di fare altre cose di lavoro vero) vado a vedere la lib di networking e guarda caso la funzione anetTcpNoDelay() faceva tutt'altro ;) settava il buffer di uscita a 8k, frutto di un residuato bellico di un programma a cui lavoravo anni fa (tcpcam). Ogni baco ha una sua storia affascinante e frustrante allo stesso tempo!
antirez scrive: @riffraff: ci sono molte differenze, ti illustro solo quelle davvero importanti a mio avviso: - tokyo cabinet e' una hash table su disco. Redis e' una hash table in memoria, che salva sul disco ogni tanto (configurabile dall'utente) in background. Per cui hai le prestazioni che ti puoi aspettare da una cosa che funziona solo in memoria come memcached, ma in realta' anche la persistenza. Ovviamente nell'informatica tutto ha un costo, il costo e' che se ti si spegne la macchina puoi perdere magari gli ultimi minuti di query invece che l'ultima. - Il layer di networking fa parte integrante di Redis, non c'e' la separazione di Tokyo cabinet/tyrant dunque Redis e' pensato in maniera specifica per uno uso da server, non e' supportata la possibilita' di usarlo come libreria. - Redis non implementa una hash table chiave/valore, il valore puo' essere una lista o un set. Questa parte ancora e' in fase di implementazione dunque non so di preciso cosa sara' supportato ma certamente c'e' tutto quello che ti puoi aspettare da una lista linkata oltre a popl popr atomici. Anche le operazioni sui set saranno supportate, ad esempio se in un set hai messo tutti gli ID di pagine dove c'e' la parola 'ciao' e in un set quelle di 'mondo' puoi farti ritornare l'intersezione tra le due per avere solo le pagine dove c'e' sia 'ciao' che 'mondo'. Penso che queste siano le differenze principali, bisogna vedere dove mi porta lo sviluppo ma non voglio complicare le cose oltre un certo livello. Una cosa che supporto DI CERTO e ho gia' progettato abbastanza dettagliatamente e' la replication. Funziona piu' o meno cosi': ./redis-server --replicate 192.168.1.2 6379 il server che parte in questo modo si connette al master indicato con IP/porta come un normale client ma gli spara il comando REPLICATE. Il master tiene ferme tutte le altre connessioni, gli passa tutto il DB che ha in memoria in quel momento, appena hanno finito ripartono assieme e lasciano il canale aperto e tutte le nuove modifiche che arrivano al master vengono comunicate allo slave tramite quel canale. Non e' ancora chiaro cosa deve fare lo slave se cade la connessione. Di certo deve risincronizzarsi ma dovrebbe continuare a rispondere? Ci sto pensando un po' su... consigli apprezzatissimi.
riffraff scrive: fico, un paragone con tokyo cabinet/tyrant?
ludo scrive: Oh, l'affare si complica. :) Poi sarà magari utile mettere giù qualche guideline per i "meccanici dell'informatica" come me per spiegare vantaggi e svantaggi di usare DB multipli, ecc. Aspetto con ansia l'alpha, anche perchè è un po' di tempo che cerco un "poor man's queue manager" senza trovare niente di sufficientemente stabile/semplice.
antirez scrive: Prima di rispondere agli ultimi due commenti un aggiornamento: in questi giorni ho implementato il supporto per DB multipli e l'operazione atomica MOVE che sposta una chiave da un DB ad uno diverso atomicamente. In questo modo ad esempio in nel DB 0 ci possono essere delle chiavi da processare da parte di N clients workers, quando uno acquisisce una chiave sul DB 0 grazie a "RANDOMKEY" lo fa facendo un MOVE sul DB 1, move che fallisce se la chiave esiste gia' nel DB 1 o se non esiste piu' nel DB 0: in pratica e' un meccanismo di locking. Poi la chiave sara' processata da chi la acquisisce e la riposta scritta nel DB 2, tanto per fare un esempio. Era facile implementare questo supporto multi-DB e mi e' sembrato utile farlo subito. Di conseguenza ho aggiornato il formato di dump sul disco che ora salva tutti i DB. D'altra parte se non si usa il comando SELECT che seleziona il DB tutte le connessioni sono per default sul DB 0 e dunque si comporta come memcached come se fosse un unico dizionario. Altra modifica degli ultimi giorni, la GET zero-copy, in pratica il buffer di uscita ora e' una lista di buffer, e gli oggetti sono dotati di reference counter, dunque nel buffer di output ci stanno gli stessi oggetti, referenziati magari N volte in diversi buffer, e questo aumenta le prestazioni in maniera sensibile. Ora pero' ho fatto talmente modifiche che sto ritestando tutte le funzioni con valgrind, leaks, eccetera dunque a questo punto sto scrivendo una piccola suite di test automatica da far girare ad ogni modifica. Insomma sono davvero vicinissimo ad avere una cosa da spedire. @ludo: mi sa che il client non e' ancora pronto! Ma il server e' a buon punto ed e' documentato. Il protocollo e' banale, facilmente parsabile programmaticamente ma anche usabile via telnet, sara' banale implementare i client. @Doxaliber: con piacere! in qualche giorno spedisco questa alpha a te, ludo e Davide. Grazie dell'interesse.
Doxaliber scrive: Sembra una cosa davvero interessante. Attendo la beta per poterlo provare personalmente.
ludo scrive: Ottimo, aspetto la tua mail con il sorgente allora. Se avessi voglia/tempo di descrivere il protocollo di comunicazione con i client potrei farmi un'idea di cosa c'è da fare, ma va benissimo anche un'occhiata al client PHP (che immagino sia nei sorgenti che mi mandi).
antirez scrive: @ludo: ok ci siamo quasi :) credo che tra una settimana si puo' gia' iniziare a testare. Lo stato attuale e' un core che funziona bene con i client di test ma supporta solo le operazioni sulle stringhe e alcune di base sulle liste. Il tutto e' stabile, testato con valgrind, fixati bachi, memory leaks, e il comportamento in caso di comandi spediti in pipelining e altre situazioni che probabilmente si presenteranno nella pratica. Credo che tra 1 settimana ti spedisco la prima beta. Sure l'email ce l'ho :) @davidonzo: tante chiamate + strutturalmente semplice = probabilmente potreste usare Redis senza problemi :) Redis sara' la struttura su cui poggia il nuovo LLOOGG, e probabilmente anche altri due progetti che per via di partnership avranno alti carichi. In tutti e tre i casi l'approccio e' misto: tutte le tabelle di "dati puri" e in grandi quantita' stanno su Redis, cose invece come le tabelle degli utenti ed altre cose dove e' desiderabile fare query di alto livello stanno su MySQL. Ti faccio sapere presto. @capobecchino: scusami a volte non vedo le email, non leggo la posta con moltissima attenzione visto che non riesco ad accettare il tempo che ci vuole per leggerla bene... ti prego di rispedirmi questa email con un subject esplicativo! Grazie mille. Non so come fare questo atteggiamento sembra quasi altezzoso, credimi chiunque mi conosce ti potra' dire che sono abbastanza umile da non fare queste minchiate, e' che ODIO l'email, come il telefono ;)
capobecchino scrive: @antirez: come fare per poterti contattare in privato? ho provato alla tua mail ma non rispondi :(
davidonzo scrive: Sarebbe l'ideale per whoishim. Abbiamo scelto di fare valutazione di ogni motore come *mondo* a se stante e pure particolareggiata per la stringa. Ergo, una miriade di chiamate al database, che comunque è strutturalmente abbastanza semplice. Appena rilasciate qualcosa mi piacerebbe implementarlo lì e vedere il guadagno. Le perdite occasionali di dati non sono un problema.
ludo scrive: Ottimo. E' proprio quello che cercavo da un po', mi sembra un progetto super interessante. :) Per il client Python fammi un fischio quando sei pronto, ovviamente sono curioso di vedere la "bestia" in funzione, il client è una scusa per averlo subito (scherzo). L'email dovresti averla, comunque ludo_at_qix_it.
antirez scrive: Ciao Ludo! esatto, come per INCR/DECR di memcachediana memoria e presenti anche in redis, sono presenti operazioni atomiche anche con le liste, come popl e popr (rispettivamente prendono e rimuovono atomicamente un elemento dalla testa e dalla coda della lista). Altri algoritmi possono essere implementati grazie alla funzione 'randomkey' che ritorna una chiave a caso in O(1) e 'poprandomkey' che ritorna la chiave e il suo valore rimuovendola. Questa funzione fa assomigliare Redis ad un 'tuple space' dove vari "consumatori" in una computazione distribuita possono prendere delle chiavi, processarle, restituirle "computate" in un server diverso. Insomma ce la mettero' tutta perche' ci siano delle funzioni che permettano l'implementazione di algoritmi distribuiti locking free. Riguardo al client Python, certamente! E' molto interessante. Fabio lo scrive per PHP, a Kiurma lo scriviamo per Ruby, se potessi fare quello Python la triade sarebbe completa :) Grazie mille, ti scrivo una email con i link non appena ho una alpha un po' piu' completa. Ce l'ho gia' a dire il vero ma le operazioni sulle liste non sono complete, almeno vorrei finire queste, per le operazioni tra i set forse ci vorra' qualche settimana in piu'. Grazie!
ludo scrive: Bel progetto! Potrebbe essere usato come "poor man's message queue" sfruttando le liste. Se ti interessa un client Python fammi un fischio. Io lo userei volentieri anche in alfa su BlogBabel.
home