使用google-cloud-ndb进行交易的不同实体组 [英] different entity group on transaction using google-cloud-ndb
问题描述
我想使用google-cloud-ndb在Google App Engine中运行交易操作.我部署了此应用.
I would like to run a transaction operation in Google App Engine using google-cloud-ndb. I deployed this app.
这是我的代码.
# -*- coding: utf-8 -*-
from flask import Flask
from google.cloud import ndb
import time
app = Flask(__name__)
class Book(ndb.Model):
hoge = ndb.IntegerProperty()
class Book2(ndb.Model):
hoge = ndb.IntegerProperty()
@ndb.transactional()
def test1():
ent = ndb.Key(Book, "a").get()
print("after get: %s", ent)
ent.hoge = ent.hoge + 1
ent.put()
print("after put: %s", ent)
print("wakeup")
@ndb.transactional()
def test2():
ent = ndb.Key(Book2, "a").get()
print("after get: %s", ent)
ent.hoge = ent.hoge + 1
ent.put()
print("after put: %s", ent)
time.sleep(10)
print("wakeup")
@app.route('/piyo')
def piyo():
print("before transaction")
try:
with ndb.Client().context():
print("enter transaction")
test1()
except Exception as e:
print(e)
print("completed")
return '', 204
@app.route('/foo')
def foo():
print("before transaction")
try:
with ndb.Client().context():
print("enter transaction")
test2()
except Exception as e:
print(e)
print("completed")
return '', 204
if __name__ == "__main__":
app.run()
尝试运行此命令对我来说将是意外的结果. 数据存储区不会针对不同的实体组发生冲突(据我所知). 但是它们似乎有冲突，请等待完成前面的操作.
The attempt to run this will unexpected result for me. Datastore dont conflict for different entity-groups(As far as i know). But they seem to be conflicting and wait completing the preceding operation.
为什么这样做?
记录:
2020-01-30 21:23:18.878 GET 204 116B 10.3s /foo
2020-01-30 21:23:18.882 before transaction
2020-01-30 21:23:18.887 enter transaction
2020-01-30 21:23:19.061 after get: %s Book2(key=Key('Book2', 'a'), hoge=33)
2020-01-30 21:23:19.062 after put: %s Book2(key=Key('Book2', 'a'), hoge=34)
★ sleep
2020-01-30 21:23:29.062 wakeup
2020-01-30 21:23:29.130 completed
2020-01-30 21:23:22.699 GET 204 116B 6.6s Android /piyo
★ confrict and wait completing "Book2" transaction
2020-01-30 21:23:29.132 before transaction
2020-01-30 21:23:29.136 enter transaction
2020-01-30 21:23:29.221 after get: %s Book(key=Key('Book', 'a'), hoge=30)
2020-01-30 21:23:29.221 after put: %s Book(key=Key('Book', 'a'), hoge=31)
2020-01-30 21:23:29.221 wakeup
2020-01-30 21:23:29.285 completed
我正在使用Python 3.7.我的环境中安装了以下工具:
I'm using Python 3.7. I have these tools installed in my environment:
Flask==1.0.3
google-cloud-ndb==0.2.2
请帮助我解决我的问题.谢谢你
Please help me with my problem. Thank you before
推荐答案
从技术上讲，您没有冲突，因为您在不同的实体组上进行操作.
Technically you don't have a conflict since you're operating on different entity groups.
但是，在两个跨组事务调用仍在进行中时，仍有可能发生潜在冲突-您尚不知道它们中的任何一个是否都不会访问被另一个触摸的实体.顺便说一句，访问不必只是实体写入(引起冲突)，它们也可以是实体读取(引起争用)，请参见
There is however room for potential conflicts while both cross-group transactional calls are still in progress - you don't know yet if any of them won't access an entity touched by the other one. BTW, the accesses don't have to be just entity writes (causing conflicts), they could just as well be entity reads (causing contention), see Contention problems in Google App Engine.
但是，一旦交易调用结束，我希望它的交易完成(一种或另一种方式，在这种情况下并不重要)，而不必等待其他正在进行的交易调用结束，无论它如何是否更早开始.观察到的行为-准备完成的事务调用一直在等待仍在进行的其他事务调用这一事实-可能导致严重的应用程序性能下降.除非错过了某些内容，否则可能表示某种错误.
But as soon as a transactional call ends I'd expect its transaction to complete (one way or another, not really relevant in this case) without waiting for some other transactional call still in progress to end as well, regardless of it being started earlier or not. The behaviour observed - the fact that a transactional call being ready for completion keeps waiting for some other transactional call still in progress - can cause severe app performance degradation. Unless something was missed it would probably indicate a bug of some sort.
One thing that can be tried (as an experiment only) is to force the 2 transactions to be executed by different GAE instances, by configuring automatic_scaling with max_concurrent_requests set to 1 in the app.yaml file:
可选.并发请求数自动缩放 实例可以在调度程序生成新实例之前接受 (默认:10，最大:80).
Optional. The number of concurrent requests an automatic scaling instance can accept before the scheduler spawns a new instance (Default: 10, Maximum: 80).
...
我们建议您不要将max_concurrent_requests设置为小于10
除非您需要单线程.小于10的值可能会
导致创建的实例多于线程安全所需的实例
应用程序，这可能会导致不必要的费用.
We recommend you do not set max_concurrent_requests to less than 10
unless you need single threading. A value of less than 10 is likely to
result in more instances being created than you need for a threadsafe
app, and that may lead to unnecessary cost.
在单独的实例中执行将确保完全隔离客户端上下文.如果症状消失，则问题出在客户端，可能在云ndb库中-也许是一些(不需要的)序列化?我会在 https://github.com/googleapis/python-ndb 提交问题(我扫描了过去几个月提交的问题，这些问题仍处于打开状态，最近合并的PR，我没有发现任何明显相关的信息.
Executing in separate instances would ensure total isolation of the client context. If the symptom goes away the problem is on the client side, possibly in the cloud ndb library - maybe some (undesired) serialization? I'd file an issue at https://github.com/googleapis/python-ndb (I scanned the issues filed in the past several months, those still open as well as recently merged PRs, I didn't notice anything apparently related).
如果对于来自不同的隔离客户端的事务而言，症状仍然存在，则问题出在数据存储方面.可能与从较旧的数据存储区到数据存储区模式下的Firestore的过渡有关? -我认为我会在旧的数据存储中注意到这种行为，在过渡之前，我对大量事务的应用程序进行了广泛的测试.我会在 https://issuetracker.google.com/提出问题.
If the symptom persists for transactions from different, isolated clients then the problem is somewhere on the datastore side. Maybe related to the transition from the older datastore to the firestore in datastore mode? - I think I would have noticed such behaviour with the old datastore, I did extensive testing for my transaction-heavy app before the transition. I'd file an issue at https://issuetracker.google.com/.
这篇关于使用google-cloud-ndb进行交易的不同实体组的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
