I'm planing the migration of our app to HRD. It is a "collective buying"
site, and found lots of places where I need to change my models/queries. In
fact, some cases where we need consistency is this scenario:
class Product {
@Id Long productId;
}
class Order {
@Id Long orderId;
List pr
I get that indexes are "just bigtable rows too," and that the normal
replication rules we all know and love apply, so I guess this boils
down to indexes being written separately from the entity. Does the
index write apply to the same nodes, or possibly to different nodes?
Alfred, your next projec
I've been using the same pattern as Jeff mentions for quite some time
-- even while I was on M/S. I use it because it reduces my problems
to "fetch by key" scenarios, and I can build multiple specialized
"indexes" in this way. Part of the reason I started doing this was
due to "exploding indexes"
Thanks... while I didn't follow it exactly, I get the gist of what's
going on. Sounds like I should expect five- or six-sigma
probabilities of minute+ eventuality in global query indexes.
Jeff
On Tue, Sep 20, 2011 at 1:28 PM, Alfred Fuller
wrote:
> Ikai is correct to think about replication in
The problem with using a key-parent is that it limits to a single
index -- say I want to index Things by color and texture.
The downside of this multiple-thing index entity is that (like a
parent-key) it limits throughput. And since there's a 2pc involved,
it probably limits throughput quite a lo
Ikai is correct to think about replication in this case. In a single replica
you could have one of three states:
Applied - fully visible
Committed - has the log entry, but has yet to apply it
Missing - the log entry has yet to be replicated
Only in the first case is it visible to a global query.
An interesting notion. Although you could also just
use ColorThings(key_name=color) as the parent entity for all the Things.
This way the list of things would be queriable directly (using
an ancestor query) and there would not be a limit on the number and size of
Things. They also exist next to eac
I'm doing a lot of work lately with data that requires a large degree
of transactional consistency. One pattern I've found that makes some
of the pain of HRD eventuality go away is to add an extra entity that
uses your query field as a natural key. This really requires global
transactions to work
Well, indexes are just Bigtable rows, so replication lag does apply to them
as well.
--
Ikai Lan
Developer Programs Engineer, Google App Engine
plus.ikailan.com | twitter.com/ikai
On Tue, Sep 20, 2011 at 7:42 AM, Mike Wesner wrote:
> And then I went and used the word replication... i meant in
And then I went and used the word replication... i meant index lag.
On Sep 20, 9:40 am, Mike Wesner wrote:
> I don't think Ikai read your post...
>
> Robert and I wanted to write a little HRD status site to track this
> and get real data, but we haven't done so yet. I have never seen the
> repli
I don't think Ikai read your post...
Robert and I wanted to write a little HRD status site to track this
and get real data, but we haven't done so yet. I have never seen the
replication take more than about 1s. I think 1s will cover about four
9's, but that is just an educated guess. Until we (
11 matches
Mail list logo
