Most of the time 'first reply' works even when using strong consistency
because we cache the state of entity groups in all replicas. Though to read
from a replica, it has to be up to date. So setting eventual consistency
will help you if an entity group is written to a lot (likely not up to
date) o
Just to follow up. It appears my app has settled down and appears to be
running once again at around the same speed/price as prior to the HRD
switch. There was one error that kept cropping up which a small code
change fixed. It's odd as I never saw that error prior to the switch and
I'm on p
> If you do a get-by-key in Consistency.STRONG mode (the default), you will
still need a quorum.
Oooh I didn't know/think about this. I don't need strong. I bet I can
switch modes and save money. I'm not sending you any of that saved money.
But I'll buy you a drink in Phoenix :-)
(unless you a
On Sat, Mar 17, 2012 at 6:27 PM, Waleed Abdulla wrote:
> I thought HRD was supposed to solve the bad neighbor problem. As I read
> somewhere (don't have the reference handy right now), when your app issues a
> read request, it's sent to multiple datastore replicas in parallel and the
> app takes t
I did not get an impression that HRD addressed the root cause of bad
neighbor problem in any way. That is not to say it is bad because it
improved data availability. It is the price hike that was key to reducing
bad neighbors. Especially, the clamp down on free quota. That was clearly
targeted
I thought HRD was supposed to solve the bad neighbor problem. As I read
somewhere (don't have the reference handy right now), when your app issues
a read request, it's sent to multiple datastore replicas in parallel and
the app takes the data from whichever datastore replies first.
On Fri, Mar
Interesting, I hadn't though about it that way. Thanks for the info
On Mar 16, 2012, at 5:54 PM, vlad wrote:
> Daniel keep in mind that you data is still co-hosted with dozens or hundreds
> on other apps on the same physical node. That is what makes performance
> volatile not M/S vs HRD. HRD
Daniel keep in mind that you data is still co-hosted with dozens or
hundreds on other apps on the same physical node. That is what makes
performance volatile not M/S vs HRD. HRD did solve the problem for writes
somewhat but not for reads. Fundamentally if an app which runs on the same
node is r
