On Wed, Aug 12, 2009 at 5:35 PM, Andy Freeman wrote:
>
> I just realized that I should have phrased this as a question.
>
> Is it true that updating a single entity more than once a second is
> problematic?
Yes, though this is a 'soft' limit - in practice you may be able to do
anything up to 10 u
I just realized that I should have phrased this as a question.
Is it true that updating a single entity more than once a second is
problematic?
How often can one single entity (using a transaction) with a low
likelyhood of contention?
If the answer depends on the number of indices it's in, what
On Wed, Aug 12, 2009 at 2:47 PM, Markitecht wrote:
>
> Wait a second, am I right in sort of realizing that BigTable doesn't
> support rather basic database functions like counting and grouping
> entities based on certain criteria?
That's correct, because they can't be implemented in a scalable ma
Wait a second, am I right in sort of realizing that BigTable doesn't
support rather basic database functions like counting and grouping
entities based on certain criteria?
In my example, I can implement the suggestion, but it seems silly; if
i am tracking events that have several pieces of metada
> Finally, do look at the info on sharded counters if you expect
> individual counters to be updated more than about once a second.
That is fairly disturbing advice as it seems to suggest that updating
a simple entity more than once a second is problematic.
I would have thought that it would be
On Sun, Aug 9, 2009 at 4:58 PM, Markitecht wrote:
>
> Thanks Nick, makes complete sense.
>
> I'll write it so that for each Interaction, it finds the appropriate
> entity, increments the counter and stores it; if looking for the
> entity turns nothing up, i make a new one with a counter set to 1.
Thanks Nick, makes complete sense.
I'll write it so that for each Interaction, it finds the appropriate
entity, increments the counter and stores it; if looking for the
entity turns nothing up, i make a new one with a counter set to 1.
right?
thanks again for the quick and kind attention.
best
Hi Markitecht,
It sounds like your best option is to have a single Interaction entity
for each unique string. You can use the key name to ensure uniqueness.
Then, to record a new interaction, in a transaction fetch the existing
one (if any), increment the count, and store it.
If you expect some
