Actually people use Riak as a distributed cache all the time. In fact, many customers use it exclusively as a cache system. Not all backends write to disk. Riak supports a main memory backend[1], complete with size limits and TTL.
Eric [1]: http://docs.basho.com/riak/latest/ops/advanced/backends/memory/ On Jan 30, 2014, at 1:48 PM, Jason Campbell <[email protected]> wrote: > I'm not sure Riak is the best fit for this. Riak is great for applications > where it is the source of data, and has very strong consistency when used in > this way. You are using it as a cache, where Riak will be significantly > slower than other cache solutions. Especially since you say that each worker > will have a set of documents it is responsible for. Something like a local > memcache or redis would likely suit this use case just as well, but do it > much faster with less overhead. > > Riak will guarantee 3 writes to disk (by default), where something like > memcache or redis will stay in memory, and if local, won't have network > latency either. In the worst case where a node goes offline, the real data > can be pulled from the backend again, so it isn't a big deal. It will also > simplify your application, because node.js can always request from cache and > not worry about the speed, instead of maintaining it's own cache layer. > > I'm as happy as the next person on this list to see Riak being used for all > sorts of uses, but I believe in the right tool for the right job. Unless > there is something I don't understand, Riak is probably the wrong tool. It > will work, but there is other software that will work much better. > > I hope this helps, > Jason Campbell > > ----- Original Message ----- > From: "Edgar Veiga" <[email protected]> > To: "Russell Brown" <[email protected]> > Cc: "riak-users" <[email protected]> > Sent: Friday, 31 January, 2014 3:20:42 AM > Subject: Re: last_write_wins > > > > 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 < [email protected] > wrote: > > > > > > > > On 30 Jan 2014, at 10:37, Edgar Veiga < [email protected] > 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 < [email protected] > wrote: > > > > Hi Russel, > > > No, it doesn't depend. It's always a new value. > > > Best regards > > > > > > On 29 January 2014 10:10, Russell Brown < [email protected] > wrote: > > > > > > > > On 29 Jan 2014, at 09:57, Edgar Veiga < [email protected] > 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 < [email protected] > 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 > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > > > > _______________________________________________ > riak-users mailing list > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > _______________________________________________ > riak-users mailing list > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
