Fast user get option [JIRA: RCS-240] #1191
Conversation
Basho-JIRA
changed the title
|
Nice PR! I agree this is great direction for latency improvements. I give big 👍 for the simple(st) approach of current diff is sufficient for some users like private object storage purpose. Maybe not in the scope of this PR, for more general purpose or finally to make this fast path by default setting, I want to discuss on pruning of bucket list [1] and consistency. Pruning path along with fast path can be achieved by using the strong option to get user objects in some of APIs. To avoid latency issue, such APIs should be not hot APIs. The tentative list is:
For consistency, it would be safer to use strong option for user modifying API calls. These includes following ones as well as above two S3 APIs.
It's no problem if these discussion will not be reflected in this PR :) I will just create new issue or PR based on this comment. Aside from it, any comments/correction/etc are appreciated. [1] Short description of pruning deleted buckets skip this if you already know about it :) There is a bucket list in user records and deleted buckets will be there as a kind of tombstone. These tombstones should be removed in any way eventually in general purpose, e.g. public object storage, to keep the list bounded. The pruned object will be overwritten only when user objects has been fetched by the strong option. |
|
Those thoughts are definitely needed when we make this option on by default. However, I thought such APIs finally go to Stanchion and PR=3 and PW=3 saves consistency ... but it does not sound like that ... In reality, currently most |
Agreeeeeee. Currently some update for bucket is done by stanchion for bucket objects (and maybe user objects) and done by riak_cs for user objects. This is a problem but totally another issue 🙈 |
Basho-JIRA
added
JIRA: In Progress
JIRA: Needs Review
and removed
JIRA: To Do
JIRA: In Progress
labels
| @@ -211,6 +211,12 @@ | |||
| {datatype, bytesize} | |||
| ]}. | |||
|
|
|||
| %% @doc Whether to omit PR=all get at retrieving user info. | |||
There was a problem hiding this comment.
If this is not hidden, warning should be included that pruning never happens.
There was a problem hiding this comment.
What pruning did you mean?
|
Will 👍 after discussing on riak-cs.conf documentation and rebasing on current develop. |
kuenishi
force-pushed
the
feature/fast-get-user
branch
from
6e926a8
to
da0fc2b
Compare
|
Updated. |
kuenishi
force-pushed
the
feature/fast-get-user
branch
from
fb0f260
to
1585e3b
Compare
|
Updated. |
| @@ -30,6 +30,7 @@ | |||
| is_admin/1, | |||
| get_user/2, | |||
| get_user_by_index/3, | |||
| from_riakc_obj/2, | |||
There was a problem hiding this comment.
Ah. This was remain of my effort to try consistency updating user object. Fruitless effort without strong consistency.
|
Updated. |
Fast user get option [JIRA: RCS-240] Reviewed-by: shino
|
@borshop merge |
|
For release note:
|
|
For release note (correct version): Add an option to replace |
If
fast_user_getis turned on, all requests to get user record skip PR=3 get to Riak to avoid unnecessary unavailability. The case this merits is where one of Riak nodes isdownslow or going to down, get_fsm should wait for all of them or request fails. For consistency PW=3 when updating user record would be enough.fast_user_getis off by default now, but will be on by default in some future.All riak_test items have passed with this option (except
stats_testwhich is currently failing continously), but I don't think additional riak_test for this because current riak_test does not simulate any failure (which we have to do some).