To the extent you limit your sliced data via an m/r you will reap those savings
on the wire when transferring back to the client
You can feed an m/r from riak search, 2i or enumerated keys thereby skipping a
costly bucket scan.
@siculars
http://siculars.posthaven.com
Sent from my iRotaryPhon
On July 16, 2013 12:00:36 PM Gabriel Littman wrote:
> Please correct me if I'm wrong, but I think the right answer is doing a GET
> first so you have a vector clock that is after the delete. Then you should
> be able to be sure your new write wins in any sibling resolution.
>
> Gabe
>
I would as
Not a problem.
MapReduce across an entire keyspace is slow.
MapReduce when provided with a few bucket/key pairs is the same as a
multi-get + processing.
You can combine 2i + MR to get quick processing of data. Although, at that
point, you might as well just process your data on the client side.
Hi Hector,
My bad..Thanks for the quick response it helped.
Thanks,
Shrikar
On Tue, Jul 16, 2013 at 4:14 PM, Hector Castro wrote:
> Hi Shrikar,
>
> It appears that you may be using incorrect expiry settings. You want
> `expiry_secs` and `expiry_grace_time`, not `expire_secs` and
> `expire_grac
Hi Shrikar,
It appears that you may be using incorrect expiry settings. You want
`expiry_secs` and `expiry_grace_time`, not `expire_secs` and
`expire_grace_time`. [0]
--
Hector
[0] http://docs.basho.com/riak/latest/tutorials/choosing-a-backend/Bitcask/
On Tue, Jul 16, 2013 at 6:52 PM, Shrikar a
Wow, high speed on this list!
I wanted it for near realtime anyway so Map/reduce is out of the question.
Thought somehow it could be done through Riak Search or directly on
secondary indices instead of map/reduce.
Guess not. Oh well, can't have it all.
Thanks
2013/7/17 Jeremiah Peschka [via Ria
Following up on Alex's comments -
If you know which bytes you need to slice, you can store this in a
secondary index. You can perform range queries across secondary indices (as
well as keys).
As long as you're storing your data in a way that allows it to be read by
either Erlang or JavaScript, yo
Hi All,
I am looking at the auto expire feature in Riak and it seems that it
doesn't work.
Am I missing something here??
Here is the app config for the bitcask section
{bitcask, [
%% Configure how Bitcask writes data to disk.
%% erlang: Erlang's built-in file API
I would say no. Riak is generally oblivious as to the content of your data. Any
ranges or other method you would use to query needs to be explicitly indexed
via riak search or secondary indexes. Once you have found your data you could
operate over that data in a map reduce, but I can't speak to
First, hello all!
Coming from Redis, I love that you can just put any binary blob in Redis
which is just treated as a string. This is possible because Redis strings
are what they call 'binary safe'. This makes it possible to return slices of
string-encoded binary data, which is super useful for bi
Please correct me if I'm wrong, but I think the right answer is doing a GET
first so you have a vector clock that is after the delete. Then you should
be able to be sure your new write wins in any sibling resolution.
Gabe
On Mon, Jul 15, 2013 at 8:59 PM, Matthew Dawson wrote:
> On July 15, 20
On Tue, Jul 16, 2013 at 10:02 AM, Simon Effenberg wrote:
> Changing the n_val setting in the default bucket properties will only
> affect new PUT operations moving forward. Older replicas will not be
> removed, and the AAE process will not purge older, unneeded replicas.
>
> Is there a way to get
On Tuesday, July 16, 2013 at 8:32 AM, Simon Effenberg wrote:
> is it possible to reduce the n_val? I mean you can change it but what
> happens then?
>
> - is old data removed or is it laying around? (or maybe deleted after
> some time thanks to AAE?)
Changing the n_val setting in the default buck
Hi @list,
is it possible to reduce the n_val? I mean you can change it but what
happens then?
- is old data removed or is it laying around? (or maybe deleted after
some time thanks to AAE?)
- is it causing problems like:
- reducing n_val from 3 to 2
- update data
- sleep 10minutes
- re
14 matches
Mail list logo