如何在 Google App Engine 数据存储区中对我的应用程序进行建模
我很难对应用程序数据进行建模以获得合理的性能。
它是一个跟踪一群人的成本的应用程序,今天我有以下实体:
class Event(db.Model):
# Values
name = db.StringProperty(required=True)
password = db.StringProperty(required=True)
class Person(db.Model):
# References
event = db.ReferenceProperty(Event, required=True)
# Values
name = db.StringProperty(required=True)
class Transaction(db.Model):
# References
event = db.ReferenceProperty(Event, required=True)
paidby = db.ReferenceProperty(Person, required=True)
# Values
description = db.StringProperty(required=True)
amount = db.FloatProperty(required=True)
datetime = db.DateTimeProperty(auto_now_add=True)
# This is used because a transaction might not distribute costs
# evenly across all persons belonging to the event
class TransactionPerson(db.Model):
# References
event = db.ReferenceProperty(Event, required=False)
transaction = db.ReferenceProperty(Transaction, required=True)
person = db.ReferenceProperty(Person, required=True)
# Values
amount = db.FloatProperty(required=True)
问题是当我想要计算每个人的余额时,我必须获取与事件和循环关联的所有数据通过每个交易/人员组合的所有 TransactionPerson(在下面的示例中约为 65.000 次操作)
我有一个事件示例:
- 4 人
- 76 交易
- 213 交易人
以及对起始页的请求,显示每个人和所有交易的余额摘要需要:
real: 1863ms cpu: 6900ms (1769ms real) api: 2723ms (94ms real)
目前我只执行 3 个 RPC 请求来获取事件的所有人员、事务和事务人员,然后执行应用程序中的所有“关系”工作,这就是 cpu ms 相当高的原因。
问题:
API cpu 需要 2723 毫秒才从 3 个数据存储请求中获取 293 个对象,这不是相当高吗?实时时间还可以(94 毫秒),但是它占用了我的 api cpu 配额很多?
我该如何设计才能获得更好的性能?对于上面的示例,今天的实际毫秒数是 1863,但如果有 12 个人,则时间将增加两倍。这些响应时间是不可接受的。
谢谢!
I have a hard time to model my applications data to get reasonable performance.
It is an application that track costs within a group of people and today I have the following entities:
class Event(db.Model):
# Values
name = db.StringProperty(required=True)
password = db.StringProperty(required=True)
class Person(db.Model):
# References
event = db.ReferenceProperty(Event, required=True)
# Values
name = db.StringProperty(required=True)
class Transaction(db.Model):
# References
event = db.ReferenceProperty(Event, required=True)
paidby = db.ReferenceProperty(Person, required=True)
# Values
description = db.StringProperty(required=True)
amount = db.FloatProperty(required=True)
datetime = db.DateTimeProperty(auto_now_add=True)
# This is used because a transaction might not distribute costs
# evenly across all persons belonging to the event
class TransactionPerson(db.Model):
# References
event = db.ReferenceProperty(Event, required=False)
transaction = db.ReferenceProperty(Transaction, required=True)
person = db.ReferenceProperty(Person, required=True)
# Values
amount = db.FloatProperty(required=True)
The problem is when I for example want to calculate the balance for each person, then I have to get all the data associated with an event and loop through all TransactionPerson for each Transaction/Person combination (in the below example that is ~65.000 operations)
I have an event example with:
- 4 Persons
- 76 Transaction
- 213 TransactionPerson
And a request to the start page that shows this balance summary per person and all transactions takes:
real: 1863ms cpu: 6900ms (1769ms real) api: 2723ms (94ms real)
At the moment I only do 3 RPC requests to get all persons, transactions and transactionpersons for an event and then do all the "relational" work in the application, thats why the cpu ms is pretty high.
Questions:
It takes 2723ms api cpu to only get the 293 objects from 3 datastore requests, isn't that pretty high? The real time is OK (94ms), but it takes a lot from my api cpu quotas?
How can I design this to get a lot better performance? Real ms today is 1863 for this example above, but if there are for example 12 persons the time would triple. These are not acceptable response times.
Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
一般来说,您想要优化读取。
不是在读取时计算人员的余额,而是在写入时计算更改并进行非规范化,将计算出的余额存储在 Person 实体中。
Generally you want to optimize for reads.
Instead of calculating a person's balance at read time, calculate changes at write time and denormalize, storing the calculated balance in the Person entity.