Perf/zl/remove unnecessary delete to solr idx when crdt or sc #452
Conversation
|
_[posted via JIRA by Zeeshan Lakhani]_ |
| %% strong consistency. | ||
| -spec is_datatype_or_consistent(obj()) -> boolean(). | ||
| is_datatype_or_consistent(Obj) -> | ||
| case riak_kv_crdt:value(Obj) of |
There was a problem hiding this comment.
Similar to the is_strongly_consistent/1 below, you could check the bucket properties only to determine if it's a CRDT. Calling riak_kv_crdt:value/1 will perform a deserialization of the value, which is extra work if you are not intending to use the result.
There was a problem hiding this comment.
Makes sense. Will do.
Zeeshan Lakhani
programmer |
software engineer at @basho |
org. member/founder of @papers_we_love |
twitter => @zeeshanlakhani
On Feb 14, 2015, at 3:50 PM, Sean Cribbs notifications@github.com wrote:
In src/yz_kv.erl:
@@ -460,3 +463,131 @@ is_owner_or_future_owner(P, Node, Ring) ->
-spec is_service_up(atom(), node()) -> boolean().
is_service_up(Service, Node) ->
lists:member(Service, riak_core_node_watcher:services(Node)).
+
+%% @Private
+%%
+%% @doc Check if object has 2.0 CRDT datatype entry or property for
+%% strong consistency.
+-spec is_datatype_or_consistent(obj()) -> boolean().
+is_datatype_or_consistent(Obj) ->
- case riak_kv_crdt:value(Obj) of
Similar to the is_strongly_consistent/1 below, you could check the bucket properties only to determine if it's a CRDT. Calling riak_kv_crdt:value/1 will perform a deserialization of the value, which is extra work if you are not intending to use the result.—
Reply to this email directly or view it on GitHub.
|
@borshop will now fail until basho/riak_kv#1081 is reviewed/merged, but eunit tests pass locally. |
zeeshanlakhani
force-pushed
the
perf/zl/remove-unnecessary-delete-to-solr-idx-when-crdt-or-sc
branch
from
8390aff to
13b819a
Compare
| %% @doc Set yz_solr:index delete operation(s) on write_reason. | ||
| -spec delete_operation(obj(), put|handoff|anti_entropy, [doc()], bkey(), lp()) -> | ||
| []|[{id, _}]|[{siblings, _}]. | ||
| delete_operation(Obj, put, Docs, BKey, LP) -> |
There was a problem hiding this comment.
Can you explain why handoff or anti_entropy should result in cleanups? Shouldn't the same reasons apply in those cases as for put?
There was a problem hiding this comment.
In a conversation I had w/ @drewkerrigan, it was to keep the delete operation for handoff/anti_entropy as cleanup b/c there was an edge case where data-typed keys could actually have a siblings and "one of the test cases the client had was like deleting without using a context and then updating the datatype object."
There was a problem hiding this comment.
Understood. I think we should fix the underlying problem in that case, but that should be ok for now.
There was a problem hiding this comment.
Agreed, as there's another issue altogether.
|
Holding off final review on this for benchmarks. |
|
@seancribbs, yep, will post results here comparing |
|
@seancribbs will reopen w/ a new PR... as the rebase w/ the changes to dev got a bit funky. |
zeeshanlakhani
deleted the
perf/zl/remove-unnecessary-delete-to-solr-idx-when-crdt-or-sc
branch
|
Updated fix version to 2.0.6 since the GH was included in release notes by Zeeshan. _[posted via JIRA by Patricia Brewer]_ |
Fixes https://bashoeng.atlassian.net/browse/RIAK-1504.
Improves performance by avoiding an extra delete operation to remove siblings through Solr on the put path when riak datatypes or strong consistency is used. Initial patch/issue was discovered by @drewkerrigan, https://github.com/basho-labs/yokozuna_perf_patch.