Hi Ilya Read “quorum” is unusual and a bit against the idea of distributed DB, but I believe what you might find useful is enabling strong consistency, which you can then chose to apply at a bucket(type) level: * http://docs.basho.com/riak/latest/dev/advanced/strong-consistency/
One of the reasons we chose Riak is precisely the fact that you can silo your data into “consistent” and “available” within the same cluster. An important thing to remember is that with strong consistency enabled you will need a minimum of 3 nodes (yes, for your dev environment too), otherwise writes to strong-consistent buckets will fail. Another relevant note here about strong consistency in Riak (and distributed DB in general): is not so much about the performance impact, but more about sacrificing availability to achieve this. (The C vs A in the CAP theorem, if we are to oversimplify this) Regards Cos On Friday, 19 June 2015 at 01:12, Ilya Kutukov wrote: > Hi! > > I am planning to maintain session storage over Riak KV. > > Core case: when user is signing in to the service session token with some > meta is returning to the client and then saving for further usage. At the > back-end side this session key is placing to the session storage. > > Riak could response false "not found" when user is providing client-side > token on next request, what following instantly after the session record is > placed to Riak. > > From the end-user POV you log in, than you surprisingly not logged in, then > you are refreshing/restarting client and everything is back to normal. Bad > glitchy case. > > Riak have typical distributed DB problems when you are reading after write > instantly. Also there is a high consistency mode with performance trade-offs. > > Is it possible to configure or modify Riak cluster to act hybrid way: > > Normally cluster is working in HA mode. E.g. on secondary index searches, > updates, deletions of the existing keys. > > But when you are directly asking for the key that seems to be missing the > full quorum is required to claim that there is really no such key on all > nodes in according partition to say "No". Any other case is "Yes" after long > or a short delay. > In theory, such behaviour will make deletion of keys slower, but situation > with false "not found" will be better. > > Or i'm missing some obvious way to resolve read-after-write problem like > proxying requests to the session storage through the single instance 3-rd > party cache? > > > -- > Best regards, > Ilya Kutukov > > +7 962 909 10 35 > post.i...@gmail.com (mailto:post.i...@gmail.com) > skype: blinkedeye > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com (mailto: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
