在GAE / P中创建您自己的活动日志记录 [英] Creating your own activity logging in GAE/P

问题描述

我想在我的应用程序中记录用户活动，以便向用户演示，也用于管理目的。我的客户是公司，所以我有三个级别可以展示活动：

1. 单个用户的活动


2. 公司所有用户的活动


3. 所有活动

日志记录，我会创建一个模型来存储日志条目。首先，我可以将每个已记录的活动存储在自己的实体中，然后根据需要进行查询：

  class Activity（ndb.Model）：
 activity = ndb.StringProperty（）
 user_id = ndb.StringProperty（）
 company_id = ndb.StringProperty（）
  

第二，我可以将用户的所有活动存储在一个实体中：

  class UserActivity（ndb.Model）：
 activity = ndb.StringProperty（repeated = True）＃注意这个现在是列表
 company_id = ndb.StringProperty（）
  

第三，我可以将所有一家公司在一个实体中的活动：

  class CompanyActivity（ndb.Model）：
 activity = ndb.StringProperty （重复=真）＃将在这里存储user_id 
  

这三种功能/性能折衷是什么选择？我知道如果经常投放交易，第二和第三种选择可能存在争议问题，但让我们假设这不是讨论的问题。

对于第二个和第三个选项，在减少数据存储实体总数方面是否有任何显着的优势（因为它们将被合并为更少的实体）？或者我应该选择第一个选项？

使用重复属性的唯一优点是您可以避免使用重复属性最终的一致性问题：无论何时阅读 UserActivity 或 CompanyActivity 实体，您都会知道您获得了完成所有活动的列表。在使用第一种方法时，您必须进行查询以获取此类列表，并且列表可能会错过最近的活动，因为相应的查询索引可能尚未更新以反映它们。

但是，除了您提到的潜在争用问题之外，还有一个缺点需要考虑重复属性方法：随着越来越多的活动添加到列表中，这些实体的大小将逐渐增加，这转换为：

$ ul
逐步减慢 get（） / put（）次，所以应用程序整体性能逐渐恶化

达到最大数据存储区实体大小的风险（〜1MB，请参阅限制），这将需要额外的逻辑来将列表分成多个实体。

特别是第三种方法也需要减少三分之一小瓶获得每用户活动报告的方法。

我会坚持第一种方法，它是最灵活和可扩展的方法，缺点很小：

• 最终的一致性问题是恕我直言，而不是展示限制（并可能有减少其影响的方法）
  
• 额外的存储空间（对于存储在每个活动实体中的用户/公司ID属性加上由于实体数量较多而导致的较大索引）是IMHO值得的（存储是便宜）。

I'd like to log user activity in my app for presentation to users and also for administrative purposes. My customers are companies so there are three levels at which I may be presenting activity:

1. Activity of a single user
2. Activity of all users of a company
3. All activity

To do the logging, I would create a model to store the log entries. I see a few ways of doing this.

First, I could store each logged activity in its own entity and then query as needed:

class Activity(ndb.Model):
    activity = ndb.StringProperty()
    user_id = ndb.StringProperty()
    company_id = ndb.StringProperty()

Second, I could store all activity of a user in a single entity:

class UserActivity(ndb.Model):
    activity = ndb.StringProperty(repeated=True) # Note this is now a list
    company_id = ndb.StringProperty()

Third, I could store all activity of a company in a single entity:

class CompanyActivity(ndb.Model):
    activity = ndb.StringProperty(repeated=True) # Would store user_id here somehow

What are the functionality/performance tradeoffs in the three options? I understand that there are potential contention issues with the second and third options if there are frequent put transactions, but let's assume that is not an issue for the sake of discussion.

For the second and third options, are there any significant advantages in reducing the total number of datastore entities (since they would be consolidated into fewer entities)? Or should I just go with the first option?

解决方案

The only advantage of using the repeated property would be that you'd avoid the eventual consistency problem: whenever you read a UserActivity or CompanyActivity entity you'll know that you get the complete list of all activities. When using the 1st approach you'd have to make a query to obtain such list and the list may miss very recent activities as the respective query index may not have yet been updated to reflect them.

But, in addition to the potential contention problem you mentioned, there is another disadvantage to consider for the repeated property approach: the size of these entities will gradually be increasing as more and more activities are being added to the list, which translates into:

• progressively slower get()/put() times, so gradually deteriorating overall app performance
• the risk of hitting the max datastore entity size (~ 1MB, see Limits), which would require additional logic for splitting the list across multiple entities

The 3rd approach in particular will also require a less trivial method of obtaining per-user activity reports.

I'd stick with the 1st approach, it's the most flexible and scalable approach and the disadvantages are minor:

• the eventual consistency problem is IMHO not a show-stopper (and there could be ways of reducing its impact)
• the extra storage space (for the user/company ID properties stored in each Activity entity plus larger indexes due to the higher number of entities) is IMHO well worthy (storage is cheap).

这篇关于在GAE / P中创建您自己的活动日志记录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！