I'll try to explain this the best I can, although it's a simples architecture I'm not describing it in my native language :)
I have a set of node.js workers (64 for now) that serve as a cache/middleware layer for a dozen of php applications. Each worker deals with a set of documents (it's not a distributed cache system). Each worker updates the documents in memory, and tags them as dirty (just like OS file cache), and from time to time (for now, it's a 5 seconds window interval), a persister module will deal with the persistence of those dirty documents to riak. If the document isn't in memory, it will be fetched from riak. If you want document X, you need to ask to the corresponding worker dealing with it. Two different workers, don't deal with the same document. That way we can guarantee that there will be no concurrent writes to riak. Best Regards, On 30 January 2014 10:46, Russell Brown <russell.br...@me.com> wrote: > > On 30 Jan 2014, at 10:37, Edgar Veiga <edgarmve...@gmail.com> wrote: > > Also, > > Using last_write_wins = true, do I need to always send the vclock while on > a PUT request? In the official documention it says that riak will look only > at the timestamp of the requests. > > > Ok, from what you've said it sounds like you are always wanting to replace > what is at a key with the new information you are putting. If that is the > case, then you have the perfect use case for LWW=true. And indeed, you do > not need to pass a vclock with your put request. And it sounds like there > is no need for you to fetch-before-put since that is only to get context > /resolve siblings. Curious about your use case if you can share more. > > Cheers > > Russell > > > > Best regards, > > > On 29 January 2014 10:29, Edgar Veiga <edgarmve...@gmail.com> wrote: > >> Hi Russel, >> >> No, it doesn't depend. It's always a new value. >> >> Best regards >> >> >> On 29 January 2014 10:10, Russell Brown <russell.br...@me.com> wrote: >> >>> >>> On 29 Jan 2014, at 09:57, Edgar Veiga <edgarmve...@gmail.com> wrote: >>> >>> tl;dr >>> >>> If I guarantee that the same key is only written with a 5 second >>> interval, is last_write_wins=true profitable? >>> >>> >>> It depends. Does the value you write depend in anyway on the value you >>> read, or is it always that you are just getting a totally new value that >>> replaces what is in Riak (regardless what is in Riak)? >>> >>> >>> >>> On 27 January 2014 23:25, Edgar Veiga <edgarmve...@gmail.com> wrote: >>> >>>> Hi there everyone! >>>> >>>> I would like to know, if my current application is a good use case to >>>> set last_write_wins to true. >>>> >>>> Basically I have a cluster of node.js workers reading and writing to >>>> riak. Each node.js worker is responsible for a set of keys, so I can >>>> guarantee some kind of non distributed cache... >>>> The real deal here is that the writing operation is not run evertime an >>>> object is changed but each 5 seconds in a "batch insertion/update" style. >>>> This brings the guarantee that the same object cannot be write to riak at >>>> the same time, not event at the same seconds, there's always a 5 second >>>> window between each insertion/update. >>>> >>>> That said, is it profitable to me if I set last_write_wins to true? >>>> I've been facing some massive writting delays under high loads and it would >>>> be nice if I have some kind of way to tune riak. >>>> >>>> Thanks a lot and keep up the good work! >>>> >>>> >>> _______________________________________________ >>> riak-users mailing list >>> riak-users@lists.basho.com >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> >>> >>> >> > >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
