For clarity, I was responding to Jason's assertion that Riak shouldn't be used as a cache, not to your specific issue, Edgar.
Eric On Jan 30, 2014, at 2:54 PM, Edgar Veiga <edgarmve...@gmail.com> wrote: > Hi! > > I think that you are making some kind of confusion here... I'm not using riak > for cache purposes, thats exactly the opposite! Riak is my end persistence > system, I need to store the documents in a strong, secure, available and > consistent place. That's riak. > > It's like I've said before, just make an analogy with the linux file cache > system. Node.js workers simulate that in-memory cache, php applications write > and read from them and when something is dirty, it's persisted to riak... > > Best regards > > > > > On 30 January 2014 22:26, Eric Redmond <eredm...@basho.com> wrote: > 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 <xia...@xiaclo.net> 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" <edgarmve...@gmail.com> >> To: "Russell Brown" <russell.br...@me.com> >> Cc: "riak-users" <riak-users@lists.basho.com> >> 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 < 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 >> >> _______________________________________________ >> 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
