Google数据存储 - 没有看到每个实体组限制的每秒写入1次 [英] Google Datastore - Not Seeing 1 Write per Second per Entity Group Limitation

查看:91
本文介绍了Google数据存储 - 没有看到每个实体组限制的每秒写入1次的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我读了很多关于强大vs最终一致性的内容,使用祖先/实体组,以及Google数据存储的每个实体组每秒限制1次写入。



但是,在我的测试中,我从来没有遇到过这些数据存储实体上的太多争用的异常。请尝试一次。 ,并试图了解我是否误解了这些概念或错过了一小部分难题。


$ b

  func usersKey(c appengine.Context)* datastore.Key {
return datastore.NewKey(c,User,default_users,0,nil)
}

func(a * UserDS)UserCreateOrUpdate(c appengine.Context,用户模型。用户)错误{

key:= datastore.NewKey(c,User,user.UserId,0,usersKey(c))
_,err:= datastore.Put(c ,键和用户)

返回错误
}

然后用 datastore.Get 读取它们。我知道我不会有问题,因为我正在按关键字进行查找,但是如果我有大量用户创建和更新他们的信息,理论上我会不断地每秒钟最多写入1次。



为了测试这个,我试图一次创建25个用户(使用上面的方法,没有配料),但我不记录任何异常,这篇文章暗示我应该:



什么是我错过了?这个争用只适用于查询,是不是一个足够高的数量,或者我完全错过了其他东西吗?

限制是针对每个实体组的,这意味着只要不共享相同的祖先,您可以创建尽可能多的用户,而不受限制(这是缩放闪光的地方)。

一旦您开始使用用户密钥作为其他实体的祖先,事物就会发生变化,使它们成为同一组的一部分,从而限制您每秒可以对其进行多少次更改。



顺便提一句,这是一个泛化,很有可能你每秒能够做出~5次更改,这个限制是由于一个实体组的事务属性而存在的,所以有一些表的变化必须按顺序执行,因此必须锁定,因此吞吐量有限。

然而,经验法则认为您只能每秒执行1次来强制自己考虑如何在这种情况下工作。



像上面提到的,这只与更新数据库有关,获取和查询应根据需要进行扩展。


I've read a lot about strong vs eventual consistency, using ancestor / entity groups, and the 1 write per second per entity group limitation of Google Datastore.

However, in my testing I have never hit the exception Too much contention on these datastore entities. please try again. and am trying to understand whether I'm misunderstanding these concepts or missing a piece of the puzzle.

I'm creating entities like so:

func usersKey(c appengine.Context) *datastore.Key {
    return datastore.NewKey(c, "User", "default_users", 0, nil)
}

func (a *UserDS) UserCreateOrUpdate(c appengine.Context, user models.User) error {

    key := datastore.NewKey(c, "User", user.UserId, 0, usersKey(c))
    _, err := datastore.Put(c, key, &user)

    return err
}

And then reading them with datastore.Get. I know I won't have issues reading since I'm doing a lookup by key, but if I have a high volume of users creating and updating their information, I would theoretically hit the max of 1 write per second constantly.

To test this, I attempted to create 25 users at once (using the above methods, no batching), yet I don't log any exceptions, which this post implies I should: Google App Engine HRD - what if I exceed the 1 write per second limit for writing to the entity group?

What am I missing? Does the contention only apply to querying, is 25 not a high enough volume, or am I missing something else entirely?

解决方案

The limitation is per entity group, that means you could create as many users as you need without limitation (that's where scaling shines), as long as they don't share the same ancestor.

Things change once you start using the user key as the ancestor of other entities, making them part of the same group and thus having a limit on how many changes you can make to it per second.

Btw this is a generalization, most likely you will be able to make ~5 changes per second, this limitation exist because of the transactional properties of an entity group, so there's some kind of table with changes that must be executed sequentially, so you have to lock, and thus there's limited throughput.

Still, rule of thumb is thinking you can only do 1 per second to force yourself think about how to work under this conditions.

And like mentioned, this is only relevant when you update the database, gets and queries should scale as needed.

这篇关于Google数据存储 - 没有看到每个实体组限制的每秒写入1次的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆