如何在 Google App Engine 数据存储区中对我的应用程序进行建模

发布于 2024-11-26 22:03:35 字数 1702 浏览 0 评论 0原文

我很难对应用程序数据进行建模以获得合理的性能。

它是一个跟踪一群人的成本的应用程序,今天我有以下实体:

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 相当高的原因。

问题:

  1. API cpu 需要 2723 毫秒才从 3 个数据存储请求中获取 293 个对象,这不是相当高吗?实时时间还可以(94 毫秒),但是它占用了我的 api cpu 配额很多?

  2. 我该如何设计才能获得更好的性能?对于上面的示例,今天的实际毫秒数是 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:

  1. 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?

  2. 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

温柔戏命师 2024-12-03 22:03:35

一般来说,您想要优化读取。

不是在读取时计算人员的余额,而是在写入时计算更改并进行非规范化,将计算出的余额存储在 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文