Hi,
My bucket is using the default N=3. When writing, I am using W=1 and
when reading N=1.
My cluster has settled down now. After the addition of the 4th node,
one of the node started to use diskspace at a very rapid pace, heading
quickly toward 100% usage so I had to remove the 4th node. It took
I'm interested to see how it turns out.
One question: Shouldn't you be able to determine equality from the vclocks?
Timestamps could run into issues if the clocks of different machines get out
of sync. They also don't allow for much granularity - there's always a
chance of collisions.
How would t
Rusty,
Thanks for the reply. Yes I read the wiki, but unless I
misunderstood it, I was under the impression that those
rules apply when the system was "indexing". But it seems
the rules also apply to the query statement.
In my case, all my userid are longer than 3 characters.
Therefore, they sho
Hi,
Just wondering if anyone had an opinions on this idea?
Thanks,
-Anthony
On Fri, Dec 17, 2010 at 03:20:58PM -0800, Anthony Molinaro wrote:
> Hi,
>
> I have a situation where I need to store sets of integers as efficiently
> as possible. In order to do so I was going to implement a custom
Hi Collin,
I would not expect keys to return not found even during handoff. An
individual vnode may return not found if the requested data has not been
transferred but the other replicas should be able to satisfy the quorum.
What values of N, R, and W are you using?
Thanks,
Dan
Daniel Reverri
D
Dont feel bad, it got me too. At least you didn't file a show stopping
bug report before figuring it out ;)
@siculars on twitter
http://siculars.posterous.com
Sent from my iPhone
On Dec 21, 2010, at 12:24, Jon Brisbin wrote:
BTW- I hadn't included the X-Riak-Vclock header. I added that to
BTW- I hadn't included the X-Riak-Vclock header. I added that to the PUT and it
updated as expected.
I suspect this is what was screwing me up.
jb
On Dec 21, 2010, at 11:09 AM, Jon Brisbin wrote:
> Is there a scenario that you know of in which a REST API client would not be
> able to update
Is there a scenario that you know of in which a REST API client would not be
able to update an object that already exists using the same key but different
content? I'm seeing this in some testing I'm doing and I don't know exactly
why. If I delete the object and re-PUT, everything's kosher. But
Hi Xiaopong,
Out of the box, Riak Search uses the "DefaultAnalyzer" which tokenizes words
as follows:
1. Split on spaces and punctuation.
2. Lowercases the tokens.
3. Strips out common English words (and, the, then, etc.)
4. Remove any tokens smaller than 3 characters.
You are seeing
