And you only need to send the context object if you’re removing things, so if you can partition your work between adds and removes, you can have more efficient adds.
On 4 Mar 2014, at 16:27, Sam Elliott <[email protected]> wrote: > Yes, batch your updates, it'll be much more efficient that way. > > Do not try to decode the `context` object. Use it as an opaque value, as the > data it holds could change without warning. > > Sam > > -- > Sam Elliott > Engineer > [email protected] > -- > > > On Tuesday, 4 March 2014 at 10:22AM, EmiNarcissus wrote: > >> >> >> Hi Sean, >> >> >> >> Thanks very much, that’s very helpful. Anyways, I’ve noticed in update_dt >> function they are preferred to apply a context dict, which in the mail list >> described as a encoded version of original object(dict,set, so to say on a >> single update action, each time a new record is being added/removed it will >> apply the full original object to the server?), so for frequently >> operations, how much performance difference is between batch/single actions? >> >> >> >> I’m only thinking about the possibilities on large dataset, but really in >> fact the dataset I’m planning to use at most contains 1-2k records is >> already big enough. currently I’m working on a project which using Riak Link >> to hold the identical items,also need to update the object data itself a >> lot(inside have a few counters(but indeed currently is just a number,didn’t >> put it into a separated counter yet), so is very non-efficient to update >> when new record is being inserted, don’t know if CRDT will provide more >> efficiency on that. >> >> >> On 2014年3月4日 at 下午11:12:03, Sam Elliott ([email protected] >> (mailto:[email protected])) wrote: >>> To answer another thing brought up in your message: >>> >>> When you say "big enough" set sizes of 10k, be very careful. Riak Data >>> Types should not >>> be larger than you would make a normal Riak Object. There's more guidance >>> in this thread: >>> http://lists.basho.com/pipermail/riak-users_lists.basho.com/2014-February/014722.html >>> >>> >>> Sam >>> >>> -- >>> Sam Elliott >>> Engineer >>> [email protected] (mailto:[email protected]) >>> -- >>> >>> >>> On Tuesday, 4 March 2014 at 10:02AM, Sean Cribbs wrote: >>> >>>> Hi Tim, >>>> >>>> We punted on sub-type queries for 2.0. We intend to address them in 2.1, >>>> so yes you must >>> fetch the entire set or map in order to find out things like membership and >>> cardinality. >>>> >>>> >>>> On Tue, Mar 4, 2014 at 8:01 AM, EmiNarcissus >>> wrote: >>>>> Hi, >>>>> >>>>> I’m now porting the riak 2.0 driver for twisted, it works beautifully now >>>>> with what >>> Yokozuna provides, also have a great back-port ability,really appreciate >>> everything >>> what this team have brought us XD. But because it still in lacks of >>> document, I must read >>> the implementation both from ruby and riakc-erl repo to get it >>> started(erlang is okay >>> for me, but I’m not quite familiar with ruby,sadly looks like only ruby’s >>> client implementation >>> is throughly right now). >>>>> >>>>> So here is my question on the datatype implementation on CRDT system. >>>>> >>>>> From the code I can tell , fetch_dt/update_dt/modify_dt is what have been >>>>> exposed >>> from the pbc interface. Now I’m more focused on Set object, so each time >>> client will fetch >>> the whole set(fetch_dt) from the server and build the set on the local end, >>> and maintain >>> a add/remove operation list to send to the server when user does a >>> update/add/remove >>> action. >>>>> >>>>> But I’m a little bit confused here, like what redis provides, a set have >>>>> a ismember function >>> is being done on the server instead of fetch/test manner. Does this >>> available for Riak >>> 2.0 Set datatype(just like what Riak1.4 Counter object provided, it will do >>> the operation >>> on the server side,MISMEMBER a b, it will either return True/False). >>> Currently I only >>> can see add/update/delete operation on pbc proto file, and don’t have >>> something alike, >>> is that in a Todo list ? or will not implement at all(I will reconsider how >>> the data should >>> be structured if so). This feature will be really helpful when the dataset >>> is big enough(like >>> more than 10k values in it.) >>>>> >>>>> >>>>> Best, >>>>> Tim Lee >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> riak-users mailing list >>>>> [email protected] (mailto:[email protected]) >>>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Sean Cribbs >>>> Software Engineer >>>> Basho Technologies, Inc. >>>> http://basho.com/ >>>> >>>> >>>> _______________________________________________ >>>> riak-users mailing list >>>> [email protected] (mailto:[email protected]) >>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> >> >> @basho.com>@me.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
